On 2023-05-22 21:19, Joost Jager via bitcoin-dev wrote:
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.
Hi Joost, Thanks for working on this! One quick thought I had was that a possibly interesting avenue for exploration would be that, in addition to relaying individual transactions or packages, it might be worth relaying block templates and weak blocks as both of those provide inherent DoS resistance and can offer useful features. A block template is an ordered list of raw transactions that can all be included in the next block (with some space reserved for a coinbase transaction). A full node can validate those transactions and calculate how much fee they pay. A Nostr relay can simply relay almost[1] any template that pays more fees than the previous best template it saw for the next block. That can be more flexible than the current implementation of submitblock with package relay which still enforces a lot of the rules that helps keep a regular relay node safe from DoS and a miner node able to select mineable transactions quickly. A weak block is a block whose header doesn't quite hash to low enough of a value to be included on the chain. It still takes an extraordinary amount of hashrate to produce, so it's inherently DoS resistant. If miners are producing block that include transactions not seen by typical relay nodes, that can reduce the efficiency and effectiveness of BIP152 compact block relay, which hurts the profitability of miners of custom blocks. To compensate, miners could relay weak blocks through Nostr to full nodes and other miners so that they could quickly relay and accept complete blocks that later included the same custom transactions. This would also help fee estimation and provide valuable insights to those trying to get their transactions included into the next block. Regarding size, the block template and weak block could both be sent in BIP152 compact block format as a diff against the expected contents of a typical node, allowing Alice to send just a small amount of additional data for relay over what she'd have to send anyway for each transaction in a package. (Although it's quite possible that BetterHash or Stratum v2 have even better solutions, possibly already implemented.) If nothing else, I think Nostr could provide an interesting playground for experimenting with various relay and mining ideas we've talked about for years, so thanks again for working on this! -Dave [1] In addition to validating transactions, a relay would probably want to reject templates that contained transactions that took excessively long to validate (which could cause a block including them to become stale) or that included features reserved for upgrades (as a soft fork that happened before the relay's node was upgraded might make that block invalid). _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev