nips/89.md

NIP-89

Bitcoin Transaction Package Relay

draft optional author:benthecarman

A special event with kind 28333, that contains encoded bitcoin transactions. The bitcoin transactions are encoded as a hex string, and are contained in a transactions tag.

The network magic is contained in the tags field. This is to identify the network that the transactions are for. The common ones are:

• mainnet: f9beb4d9
• testnet3: 0b110907
• signet (default): 0a03cf40
• regtest: fabfb5da

If another value is present it is likely a custom signet.

The tags field MUST contain a transactions tag that contains a list of bitcoin transactions encoded in hex. These transactions should be ordered in the order that they should be broadcasted. This can be important for making sure that the transactions are valid when doing things like Child Pays For Parent.

The content field should just be an empty string.

This is an ephemeral event, and is not stored on the server. So relays or other custom clients could receive these events, and broadcast them to the bitcoin network.

For example:

{
  "kind": 28333,
  "content": "",
  "tags": [
    [
      "magic",
      "0b110907"
    ],
    [
      "transactions",
      "02000000000102d917a3cb762dfa88c10f813d083f2d976a02d01beb56d8d3322316fbf1313b460000000000fdffffff8fcc2f39a14be43cfed024ca5cd2b1c6fd46aeeb0ca6cddaa1db17406a7de7180000000000fdffffff022c03d30500000000225120482a8cb5fc92b519d7d68628bc28b7c1a28660dea4fb226bb0c300bab76793ea888a01000000000022512066d148e01c76ac3a817b85fdfa5cc4861ecac5c6b7b4d13d97f41f1ff660850102473044022055d8ee7e8ec915f3f1fe52ece046e92eda0080c25984ae2797ad2e6c71ba278002202d60fab8df011a9c84ee036d5f88f19e4352858f328e175c8e1b074784405891012102e50a785247e2bd6280278145a3f789a9b4785c5582468bead3de5c00a487a4910247304402203c2b2b46077ed676050b018c77496fcf53969cef737cfc135c0681ba8855105002207a274517b8f8e26fe81e5666997a8ab8bd80fe7c3cfcdf9a39389460f484c50c0121035a2ad998f47785db0138dcdce5125d2243bef228b03780b07c9e8309387e4713340b2500",
      ... more hex encoded transactions
    ]
  ],
  ...other fields
}

Uses

This offers a way for users to broadcast bitcoin transactions in a private way without having to connect to the bitcoin network directly.

Today, users have to connect to the bitcoin network directly or use an api like mempool.space to broadcast transactions. This is not private, as you can leak your ip address to the service or a bitcoin node.

Nostr provides a better opportunity for users to broadcast transactions in a private way. Nostr relays are at most bitcoin adjacent and have a much lower risk of being run by a chain analysis company, thus providing a possibly better way to broadcast transactions.

Nostr being an alternative to the bitcoin p2p network provides a potentially easier way to get package relay. Not being a p2p network means that there is no need to worry about compatibility with the bitcoin p2p network, and can be backed into by using an alternative transport like nostr.

Recommendations

If transactions have no relation to each other, they should be broadcasted in separate events and with separate keypairs. This help with user privacy and to not unnecessarily link transactions together.

Clients should generate an ephemeral keypair for each package of transactions they want to broadcast. This keypair should only ever be used for broadcasting that package. This is to best preserve the privacy of the user and to not link any extra metadata to the transaction package.

Obviously, the user should avoid broadcasting the channel to a relay run by a chain analysis company to prevent IP leaks. To prevent this, they should try to broadcast to a minimal amount of relays to prevent the chance of broadcasting to a malicious relay. This is a tradeoff between privacy and reliability as your transactions have a lower chance of being broadcasted if you broadcast to fewer relays.