Date: Thu, 14 Jul 2022 10:54:48 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Russell O'Connor <roconnor@blockstream.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220714005448.GA24835@erisian.com.au>
References: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
 <CAMZUoKmN1Sj=C-asUKCB0hbe-V2fRMsFzNn6kcsJeigbnz3fgQ@mail.gmail.com>
 <YsyX9Hjz4LU5otaT@petertodd.org> <YsycpTbb3IYpQ2I7@petertodd.org>
 <CAMZUoKmsCjpcU323_Nbw2UBkcqTmBc9+yd9i=QBZvDX-gdH_hw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMZUoKmsCjpcU323_Nbw2UBkcqTmBc9+yd9i=QBZvDX-gdH_hw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Subject: Re: [bitcoin-dev] Security problems with relying on transaction
 fees for security
Precedence: list

On Mon, Jul 11, 2022 at 08:21:40PM -0400, Russell O'Connor via bitcoin-dev wrote:
> 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.

Sufficiently advanced tx introspection could be used for this; spend the
fees in the coinbase to address A, but also create a 0sat output via a
regular tx to the scriptPubKey "1 CSV". Note that tx's txid as B. The
next miner claims the bribe B, by spending the 0sat output to itself
with a 1-in, 1-out tx, with scriptPubKey C.

  nVersion = 1
  inputs = [txid=B, vout=0, scriptSig="", nSeq=1]
  outputs = [value=0, scriptPubKey=C]
  nLocktime = 0

Now we get back to A, and say that it's scriptPubKey uses a script that
takes "C" as input, has "B" hardcoded, calculates the txid of the tx
above, call it D, and then uses tx introspection to check that one of
the inputs of the tx has D as the txid.

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

You *could* make that work if you allow tx's to use the annex to commit
to a recent block.

That is, if you just mined block 740,000 and its hash was
00000000000000000005f28764680afdbd8375216ff8f30b17eeb26bd98aac63,
you construct a bribe tx paying to "OP_1", but when you sign it,
you add "50ee070b4aa0d98aac63" as the annex (tag=ee, length=07,
value[0:3]=height=0b4aa0=470k, value[3:]=d98aac63), and (via a soft fork)
nodes then only consider that tx valid if the block at "height" ends in
"d98aac63". There's then only a 1-in-4B chance that someone who extends
a competitor to your block could claim the bribe, at a cost of 11 extra
witness bytes.

But such txs (and anything that descends from them) would become invalid
with as little as a 1-block reorg, which would pretty much defeat the
entire purpose of the maturity delay...

Cheers,
aj