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@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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
