[bitcoin-dev] Security problems with relying on transaction fees for security

Russell O'Connor roconnor at blockstream.com
Tue Jul 12 00:21:40 UTC 2022


Oops, you are right.  We need the bribe to be the output of the coinbase,
but due to the maturity rule, it isn't really a bribe.

Too bad coinbases cannot take other coinbase outputs as inputs to bypass
the maturity rule.

I guess that means the bribe has to be by leaving transactions in the
mempool.

Also your point about centralization pressure is well taken.

On Mon, Jul 11, 2022 at 5:56 PM Peter Todd <pete at petertodd.org> wrote:

> On Mon, Jul 11, 2022 at 05:36:52PM -0400, Peter Todd via bitcoin-dev wrote:
> > On Mon, Jul 11, 2022 at 04:35:02PM -0400, Russell O'Connor via
> bitcoin-dev wrote:
> > > > What happens after that I'm not sure.
> > > >
> > >
> > > Miners will learn to create anyone-can-spend outputs to bribe other
> miners
> > > to build on their block rather than reorg it.  (Due to the coinbase
> > > maturity, this will require some amount of floating capital.)
> >
> > ...and that's a disaster for mining centralization, because the smaller
> miners
> > need to pay larger bribes than larger miners. Not to mention having to
> keep
> > capital around to do it.
>
> Also, note how from a practical point of view, we'll need to add a new
> type of
> tx that's only valid in a specific block, or other miners will just reorg
> those
> anyone-can-spend outputs to steal them. It's not all that trivial to
> actually
> do that... you'd have to have a signature that commits to the non-segwit
> part
> of the coinbase outputs. Ugh.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220711/2b9c824a/attachment.html>


More information about the bitcoin-dev mailing list