alicexbt [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-23 🗒️ Summary of this message: Nostr, a ...
📅 Original date posted:2023-05-23
🗒️ Summary of this message: Nostr, a decentralized network of relays, could improve Bitcoin transaction relay by broadcasting arbitrary transaction packages, overcoming limitations of the current P2P system.
📝 Original message:Hi Joost,
Transaction relay over nostr sounds interesting. I have 2 suggestions:
- Transactions could be encrypted when published as nostr events initially except size, fee rate and offer. This can be used by different clients to show them as external mempool with transactions sorted by fee rate without affecting privacy of users.
- Mining pools will be incentivized to include these transaction in their blocks if they are using a higher fee rate compared to transactions in normal mempool used by bitcoin nodes or there is a mechanism to accept published offers, NIP4 is used to privately coordinate everything between user and pool. User can lock some sats in a 2of2 multisig and release it to mining pool on confirmation.
/dev/fd0
floppy disk guy
Sent with Proton Mail secure email.
------- Original Message -------
On Tuesday, May 23rd, 2023 at 12:49 PM, Joost Jager via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
>
>
> I write to get your thoughts on an alternative approach for Bitcoin transaction relay, addressing some of the limitations in the current peer-to-peer transaction relay system. To the best of my knowledge, the credit for the original concept goes to Ben Carman. I felt it would be beneficial to share the idea on this list to garner wider perspectives and feedback.
>
>
>
> The existing peer-to-peer (P2P) transaction relay system comes with a set of limitations that may negatively impact applications, notably those like Lightning that make extensive use of pre-signed transactions. A key limitation lies in the system's inability to relay transaction packages. This constraint can lead to HTLCs expiring before being swept, thereby risking fund losses. In addition, the P2P system falls short in supporting non-standard transactions, despite an established demand for such transactions in the marketplace.
>
>
>
> Nostr, an open and decentralized network of relays for public and ephemeral messages between pseudonymous entities, could help address these shortcomings. With the standards defined in NIP-89 [1], it becomes possible to broadcast arbitrary Bitcoin transaction packages, overcoming one of the key hurdles in the current relay system.
>
>
>
> In this proposed alternative relay mechanism, miners would listen for these broadcasted transaction packages and insert the packages into their local mempool. They can take advantage of the `submitpackage` RPC, limited to safe topologies only - specifically child and direct parents, tree only [2]. This feature could serve as an interim solution for package relay until it becomes available through the traditional P2P method.
>
>
>
> A notable advantage of this approach is that it delegates the responsibility of dealing with Denial-of-Service (DoS) threats to the relays themselves. They could, for example, require a payment to mitigate such concerns. There are in fact paid nostr relays already in operation. This partitioning would result in a clear separation between the Bitcoin transaction layer and DoS protection, introducing more flexibility in the system and potentially boosting its resilience.
>
>
>
> Implementing Nostr as a relay mechanism also has the potential to democratize access to miner mempools, thus leveling the playing field in the Bitcoin network. In the current state, those with direct connections or certain privileges can more readily submit transactions to miners, perhaps even through means as informal as email.
>
>
>
> I have been working on a prototype of this concept (based on [3]) and have captured its workings in a demonstration video [4].
>
>
>
> Joost
>
>
>
> [1] https://github.com/nostr-protocol/nips/pull/476
>
> [2] https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1544414801
>
> [3] https://github.com/benthecarman/nostr-tx-broadcast
>
> [4] https://twitter.com/joostjgr/status/1658487013237211155
🗒️ Summary of this message: Nostr, a decentralized network of relays, could improve Bitcoin transaction relay by broadcasting arbitrary transaction packages, overcoming limitations of the current P2P system.
📝 Original message:Hi Joost,
Transaction relay over nostr sounds interesting. I have 2 suggestions:
- Transactions could be encrypted when published as nostr events initially except size, fee rate and offer. This can be used by different clients to show them as external mempool with transactions sorted by fee rate without affecting privacy of users.
- Mining pools will be incentivized to include these transaction in their blocks if they are using a higher fee rate compared to transactions in normal mempool used by bitcoin nodes or there is a mechanism to accept published offers, NIP4 is used to privately coordinate everything between user and pool. User can lock some sats in a 2of2 multisig and release it to mining pool on confirmation.
/dev/fd0
floppy disk guy
Sent with Proton Mail secure email.
------- Original Message -------
On Tuesday, May 23rd, 2023 at 12:49 PM, Joost Jager via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
>
>
> I write to get your thoughts on an alternative approach for Bitcoin transaction relay, addressing some of the limitations in the current peer-to-peer transaction relay system. To the best of my knowledge, the credit for the original concept goes to Ben Carman. I felt it would be beneficial to share the idea on this list to garner wider perspectives and feedback.
>
>
>
> The existing peer-to-peer (P2P) transaction relay system comes with a set of limitations that may negatively impact applications, notably those like Lightning that make extensive use of pre-signed transactions. A key limitation lies in the system's inability to relay transaction packages. This constraint can lead to HTLCs expiring before being swept, thereby risking fund losses. In addition, the P2P system falls short in supporting non-standard transactions, despite an established demand for such transactions in the marketplace.
>
>
>
> Nostr, an open and decentralized network of relays for public and ephemeral messages between pseudonymous entities, could help address these shortcomings. With the standards defined in NIP-89 [1], it becomes possible to broadcast arbitrary Bitcoin transaction packages, overcoming one of the key hurdles in the current relay system.
>
>
>
> In this proposed alternative relay mechanism, miners would listen for these broadcasted transaction packages and insert the packages into their local mempool. They can take advantage of the `submitpackage` RPC, limited to safe topologies only - specifically child and direct parents, tree only [2]. This feature could serve as an interim solution for package relay until it becomes available through the traditional P2P method.
>
>
>
> A notable advantage of this approach is that it delegates the responsibility of dealing with Denial-of-Service (DoS) threats to the relays themselves. They could, for example, require a payment to mitigate such concerns. There are in fact paid nostr relays already in operation. This partitioning would result in a clear separation between the Bitcoin transaction layer and DoS protection, introducing more flexibility in the system and potentially boosting its resilience.
>
>
>
> Implementing Nostr as a relay mechanism also has the potential to democratize access to miner mempools, thus leveling the playing field in the Bitcoin network. In the current state, those with direct connections or certain privileges can more readily submit transactions to miners, perhaps even through means as informal as email.
>
>
>
> I have been working on a prototype of this concept (based on [3]) and have captured its workings in a demonstration video [4].
>
>
>
> Joost
>
>
>
> [1] https://github.com/nostr-protocol/nips/pull/476
>
> [2] https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1544414801
>
> [3] https://github.com/benthecarman/nostr-tx-broadcast
>
> [4] https://twitter.com/joostjgr/status/1658487013237211155