On Wed, 7 May 2025 12:11:09 +0000 (UTC) Greg Maxwell <[email protected]> wrote:
> That creates a withholding attack where you announce a block then > withhold some transactions entirely. > > It does already relay to other full nodes before validating > everything, but the nodes need to have the data. > > Of course the recipient's mining is also still delayed until > validation so even if not for the withholding issue it would only > reduce the hop by hop component. (As the recipient would presumably > not have the transaction either with its relay blocked in the network > and the transaction submitted directly to the party that included.) > > There are, of course, numerous optimizations that could be done to > reduce the impact... but none so effective as actually having the > transaction and even having already validated it, and all with > considerable development effort. > That creates a withholding attack where you announce a block then > withhold some transactions entirely. A miner can already do this to all of their direct peers. The only difference is whether it gets passed along. What's the functional difference between this, and a miner delaying broadcast of a block entirely, besides the fact withholding transactions is network-visible? > It does already relay to other full nodes before validating > everything, but the nodes need to have the data. It relays once it has all of the transactions, and has done preliminary validation up to BLOCK_VALID_TRANSACTIONS. To finish validating the block, nodes of course will need to have all the transactions. But relay of the compact block doesn't need to be slowed down by nodes who don't have all transactions yet. Minimal validation (POW, header, merkleroot) should be sufficient for relay. > Of course the recipient's mining is also still delayed until > validation so even if not for the withholding issue it would only > reduce the hop by hop component. Which is the block propagation part. Right now, your miner won't receive the compact block until every node along whichever path reaches them first has all the transactions locally. Every node who was missing some of those transactions will slow down propagation. The miner could already have all the transactions locally, and still, they could be delayed. If they don't, it takes longer for them to even know that they're missing transactions. If we relay compact blocks before we have all the transactions locally, the miner gets the compact block without any missing TX delay. If they already have all transactions, they can finish validation and get to work no questions asked. If they don't, the only delay in building on the new block is because transactions were missing *from their own mempool*. Whether miners choose to start mining an empty block on top of this new block, which they haven't yet fully validated, or continue with existing work until validation completes is up to them. A decision they already have to make. > As the recipient would presumably not have the transaction either > with its relay blocked in the network and the transaction submitted > directly to the party that included. As full-RBF demonstrated, transaction relay doesn't require every node to have the same mempool policy. A small percentage of nodes running permissive policy can get transactions to miners. You don't need to try to force people to all use the same relay policy. Never mind that it's impossible. The transaction can, and will be able to reach miners via mempool relay by simply giving users more control over their own node's policy, and lobbying enough of them to choose more permissive relay policy. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/20250507165518.0B5037C0EEB%40smtp.postman.i2p.
