1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
|
Return-Path: <aj@erisian.com.au>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 94F09C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Jul 2022 00:55:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 7D21F424D9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Jul 2022 00:55:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7D21F424D9
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id k5-69wB1LntV
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Jul 2022 00:54:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 42395418D6
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp4.osuosl.org (Postfix) with ESMTPS id 42395418D6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Jul 2022 00:54:58 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1oBn81-0003T1-75; Thu, 14 Jul 2022 10:54:55 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Thu, 14 Jul 2022 10:54:48 +1000
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)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] Security problems with relying on transaction
fees for security
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jul 2022 00:55:00 -0000
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
|
