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
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
Return-Path: <roconnor@blockstream.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4C58FC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Feb 2022 20:24:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 8BE2440236
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Feb 2022 20:24:43 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key)
header.d=blockstream-com.20210112.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id AY6W9zxbOZ-F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Feb 2022 20:24:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com
[IPv6:2607:f8b0:4864:20::830])
by smtp2.osuosl.org (Postfix) with ESMTPS id 610A04017C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Feb 2022 20:24:42 +0000 (UTC)
Received: by mail-qt1-x830.google.com with SMTP id x5so19708155qtw.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Feb 2022 12:24:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-com.20210112.gappssmtp.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=KYPQbQ4/9Lc6PwiEGam7jTTxXNUPMmDY2Zk/vt4Eq84=;
b=vNoD9WaRJFYzosxnrzXfPHS+TIuuQm3oCLEEEUjRK5mVxoXTKDKpXucyOykuzc0+ee
jmcfIOj3b5DCoeM0W/eyoPOripki5crYZ53rX8hgMNLpMZ7SFOIvtdngh1Q7uxg5pgSx
+iK9mcliZ1Smzrd92tskvBR5iKem7r9TgUUMP+5V09z3uCDxrtG146UD3mwI03StxY44
2YTvH8C3+7JAk5ZX9QN9nQfhB8gBVKJf2qJGvpctslE2vjSFe5Ur5Gu4OIWDvCGHMD4I
/lI4aAOqOk1DQ9afKlNqQEeTbUNlazx18nQ3oc1rz6Pcsc1IOH26UH7822ygWo3qVlss
CQOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=KYPQbQ4/9Lc6PwiEGam7jTTxXNUPMmDY2Zk/vt4Eq84=;
b=mUqQosRS7Vn4KPLYqpBZ7D+ghH6f0cwfUKp/YWDESfaS7Gf6pFfngaTN9Zw2SSFeqn
dZEUFFKRSpxsBUG4KB23Wi99teFPFd5JomzkbDfRUSrYYBi8f7lLb5xluHXB7ndFMxA6
3Bit4Ymcabac5nd2aWjyIt8ywydtbO04/gzUIeF41Y6WNeQsoAOKbJX66JawtFsK8N5j
T9EVqYDUXey+q7uY5dcPiaoX3pIEkg6EHCmbO61v8D9Q03JnKbo3aBoR9CM6YPg5NK30
mkmR5LVS/EgfEWujsihzAawJBIsnPBTtdMAqGaRKKst9WkT01hXphNv90NDBAQNGE5/J
eKyA==
X-Gm-Message-State: AOAM533PRDaV2264tNzQ+1X8DhorsdOAPIb2r4kyTHSWbOLJo4NCynd9
jE1uvD7AjagRMtZCC9BFatbzfxXEiejHx9M+wmZB1z5c2qQ=
X-Google-Smtp-Source: ABdhPJwcJT/e3Lw56qPx1VCSWVM5ARVi+WN82um7rhVwEFr2fx3r5zXnoAW5zFS+VacVUxAKf7IYMjHcOrodf8FMeBs=
X-Received: by 2002:a05:622a:5ce:: with SMTP id
d14mr690727qtb.642.1644956681096;
Tue, 15 Feb 2022 12:24:41 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
<CALZpt+FwZTXEYYiJ=1XTXbDVECW41e9rNq8rn8AYr6m3yLAkPA@mail.gmail.com>
<CAPfvXfJN9zeJDYka8BycU102xGdwQ2O9=Khgjag-eYLmXRdsdA@mail.gmail.com>
<CALZpt+G0uXL04onty2N++6tWeX7Y=5KWw3x8-A0MvyUgZR-4Xw@mail.gmail.com>
<CAGpPWDaZ=Qx_phzjFJXzQc0ePWfuJmGKsPrsvj9X1pBTBrRgWA@mail.gmail.com>
In-Reply-To: <CAGpPWDaZ=Qx_phzjFJXzQc0ePWfuJmGKsPrsvj9X1pBTBrRgWA@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Tue, 15 Feb 2022 15:24:29 -0500
Message-ID: <CAMZUoKnhyzJ=6W-=hxpmCyjiPyYMuS=eKjLN+bu5cuLRQ42nxA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a5e02b05d81452ae"
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
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: Tue, 15 Feb 2022 20:24:44 -0000
--000000000000a5e02b05d81452ae
Content-Type: text/plain; charset="UTF-8"
> >> 2. (from Suhas) "once a valid transaction is created, it should not
> become invalid later on unless the inputs are double-spent."
> > This doesn't seem like a huge concern to me
>
> I agree that this shouldn't be a concern. In fact, I've asked numerous
> people in numerous places what practical downside there is to transactions
> that become invalid, and I've heard basically radio silence other than one
> off hand remark by satoshi at the dawn of time which didn't seem to me to
> have good reasoning. I haven't seen any downside whatsoever of transactions
> that can become invalid for anyone waiting the standard 6 confirmations -
> the reorg risks only exists for people not waiting for standard
> finalization. So I don't think we should consider that aspect of a
> sponsorship transaction that can only be mined with the transaction it
> sponsors to be a problem unless a specific practical problem case can be
> identified. Even if a significant such case was identified, an easy
> solution would be to simply allow sponsorship transactions to be mined on
> or after the sponsored transaction is mined.
>
The downside is that in a 6 block reorg any transaction that is moved past
its expiration date becomes invalid and all its descendants become invalid
too.
The current consensus threshold for transactions to become invalid is a 100
block reorg, and I see no reason to change this threshold. I promise to
personally build a wallet that always creates transactions on the verge of
becoming invalid should anyone ever implement a feature that violates this
tx validity principle.
--000000000000a5e02b05d81452ae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>>> 2. (from=
Suhas) "once a valid transaction is created, it should not become inv=
alid later on unless the inputs are double-spent."</div>> This does=
n't seem like a huge concern to me=C2=A0<div><br></div><div>I agree tha=
t this shouldn't be a concern. In fact, I've asked numerous people =
in numerous places what practical downside there is to transactions that be=
come invalid, and I've heard basically radio silence other than one off=
hand remark by satoshi at the dawn of time which didn't seem to me to =
have good reasoning. I haven't seen any downside whatsoever of transact=
ions that can become invalid for anyone waiting the standard 6 confirmation=
s - the reorg risks only exists for people not waiting for standard finaliz=
ation. So I don't think we should consider that aspect of a sponsorship=
transaction that can only be mined with the transaction it sponsors to be =
a problem unless a specific=C2=A0practical problem case can be identified. =
Even if a significant such=C2=A0case was identified, an easy solution would=
be to simply allow sponsorship transactions to be mined on or after the sp=
onsored transaction is mined. <br></div></div></blockquote><div><br></div><=
div>The downside is that in a 6 block reorg any transaction that is moved p=
ast its expiration date becomes invalid and all its descendants become inva=
lid too.<br></div><div><br></div><div>The current consensus threshold for t=
ransactions to become invalid is a 100 block reorg, and I see no reason to =
change this threshold.=C2=A0 I promise to personally build a wallet that al=
ways creates transactions on the verge of becoming invalid should anyone ev=
er implement a feature that violates this tx validity principle.<br></div><=
/div></div>
--000000000000a5e02b05d81452ae--
|
