NIP-89 Ephemeral Bitcoin Transaction Package Relay #476
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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 | ||
benthecarman marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - testnet3: 0b110907 | ||
| - signet (default): 0a03cf40 | ||
|
There was a problem hiding this comment. I think since money is involved, I think it's good to be explicit when using mainnet.
-- https://en.bitcoin.it/wiki/Invoice_address#Testnet But I think for signet and regtest this is not the case? 🤔 There was a problem hiding this comment. No objection to being explicit, but maybe then always be explicit? Signet doesn't look like such a natural choice for a default to me.
Contributor
Author
There was a problem hiding this comment. Signet is not meant to be the default, this is the magic bytes for the default signet. I see how that can be confusing, is there a better way to convey this? There was a problem hiding this comment. Ah maybe just |
||
| - regtest: fabfb5da | ||
|
There was a problem hiding this comment. Is it really a good idea to use these not very well-known magic hex codes here? There was a problem hiding this comment.
There was a problem hiding this comment. Right. But I suppose those alternative signets will also get their own name? Same as with the base64 vs hex for the txes, I think keeping this human readable is helpful in various situations.
Contributor
Author
There was a problem hiding this comment. I think this is better, this way we don't get any overlap, this could even be used for things like litecoin without needing new specifications. I do agree just writing "mainnet" is more clear but I figured just enumerating them here would make it easy enough. Also, most bitcoin libraries will have these values available anyways. There was a problem hiding this comment. I think chances are low that it will ever come to the point where advantage can be taken of this. |
||
|
|
||
| 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. | ||
Uh oh!
There was an error while loading. Please reload this page.