nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-20 14:55:49 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

NIP-89 Epheremal bitcoin transaction broadcasting

Browse Source
This commit is contained in:
benthecarman 2023-04-26 22:12:27 -05:00
parent badabd513e
commit 57c09ba17c
No known key found for this signature in database
GPG Key ID: D7CC770B81FD22A8
2 changed files with 84 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

81
89.md Normal file
View File

@ -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.

4
README.md
View File

@ -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) |