Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions

[pithosian <pithosian@i2pmail.org>]

On Wed,  7 May 2025 12:11:09 +0000 (UTC)
Greg Maxwell <gmaxwell@gmail.com> 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/20250507165518.0B5037C0EEB%40smtp.postman.i2p.