{"type":"rich","version":"1.0","author_name":"npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","author_url":"https://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-05-23\n🗒️ Summary of this message: A proposed alternative relay mechanism for Bitcoin transactions, called Nostr, could address limitations in the current P2P system and support non-standard transactions. Miners would listen for broadcasted transaction packages and insert them into their local mempool, potentially boosting the system's resilience and democratizing access to miner mempools. Nostr could also delegate responsibility for dealing with DoS threats to relays and introduce more flexibility in the system. A prototype has been developed and demonstrated in a video.\n📝 Original message:Hi,\n\n\nI write to get your thoughts on an alternative approach for Bitcoin\ntransaction relay, addressing some of the limitations in the current\npeer-to-peer transaction relay system. To the best of my knowledge, the\ncredit for the original concept goes to Ben Carman. I felt it would be\nbeneficial to share the idea on this list to garner wider perspectives and\nfeedback.\n\n\nThe existing peer-to-peer (P2P) transaction relay system comes with a set\nof limitations that may negatively impact applications, notably those like\nLightning that make extensive use of pre-signed transactions. A key\nlimitation lies in the system's inability to relay transaction packages.\nThis constraint can lead to HTLCs expiring before being swept, thereby\nrisking fund losses. In addition, the P2P system falls short in supporting\nnon-standard transactions, despite an established demand for such\ntransactions in the marketplace.\n\n\nNostr, an open and decentralized network of relays for public and ephemeral\nmessages between pseudonymous entities, could help address these\nshortcomings. With the standards defined in NIP-89 [1], it becomes possible\nto broadcast arbitrary Bitcoin transaction packages, overcoming one of the\nkey hurdles in the current relay system.\n\n\nIn this proposed alternative relay mechanism, miners would listen for these\nbroadcasted transaction packages and insert the packages into their local\nmempool. They can take advantage of the `submitpackage` RPC, limited to\nsafe topologies only - specifically child and direct parents, tree only\n[2]. This feature could serve as an interim solution for package relay\nuntil it becomes available through the traditional P2P method.\n\n\nA notable advantage of this approach is that it delegates the\nresponsibility of dealing with Denial-of-Service (DoS) threats to the\nrelays themselves. They could, for example, require a payment to mitigate\nsuch concerns. There are in fact paid nostr relays already in operation.\nThis partitioning would result in a clear separation between the Bitcoin\ntransaction layer and DoS protection, introducing more flexibility in the\nsystem and potentially boosting its resilience.\n\n\nImplementing Nostr as a relay mechanism also has the potential to\ndemocratize access to miner mempools, thus leveling the playing field in\nthe Bitcoin network. In the current state, those with direct connections or\ncertain privileges can more readily submit transactions to miners, perhaps\neven through means as informal as email.\n\n\nI have been working on a prototype of this concept (based on [3]) and have\ncaptured its workings in a demonstration video [4].\n\n\nJoost\n\n\n[1] https://github.com/nostr-protocol/nips/pull/476\n\n[2] https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1544414801\n\n[3] https://github.com/benthecarman/nostr-tx-broadcast\n\n[4] https://twitter.com/joostjgr/status/1658487013237211155\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230523/6866548f/attachment.html\u003e"}