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

From: "Russell O'Connor" <roconnor@blockstream•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Security problems with relying on transaction fees for security
Date: Mon, 11 Jul 2022 20:21:40 -0400	[thread overview]
Message-ID: <CAMZUoKmsCjpcU323_Nbw2UBkcqTmBc9+yd9i=QBZvDX-gdH_hw@mail.gmail.com> (raw)
In-Reply-To: <YsycpTbb3IYpQ2I7@petertodd.org>

[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

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@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
>

[-- Attachment #2: Type: text/html, Size: 2182 bytes --]