NIP-89 Epheremal bitcoin transaction broadcasting

89.md

@@ -0,0 +1,81 @@
+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:
+
+```json
+{
+  "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](https://bitcoinops.org/en/topics/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.

README.md

@@ -59,12 +59,13 @@ They exist to document what may be implemented by [Nostr](https://github.com/fia
 - [NIP-58: Badges](58.md)
 - [NIP-65: Relay List Metadata](65.md)
 - [NIP-78: Application-specific data](78.md)
+- [NIP-89: Bitcoin Transaction Broadcasting](89.md)
 - [NIP-94: File Metadata](94.md)
 
 ## Event Kinds
 
 | kind    | description                | NIP         |
-| ------- | -------------------------- | ----------- |
+|---------|----------------------------|-------------|
 | `0`     | Metadata                   | [1](01.md)  |
 | `1`     | Short Text Note            | [1](01.md)  |
 | `2`     | Recommend Relay            | [1](01.md)  |
@@ -88,6 +89,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/fia
 | `10002` | Relay List Metadata        | [65](65.md) |
 | `22242` | Client Authentication      | [42](42.md) |
 | `24133` | Nostr Connect              | [46](46.md) |
+| `28333` | Bitcoin Transactions       | [89](89.md) |
 | `30000` | Categorized People List    | [51](51.md) |
 | `30001` | Categorized Bookmark List  | [51](51.md) |
 | `30008` | Profile Badges             | [58](58.md) |