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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
Return-Path: <joost.jager@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3198AC0029
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Jun 2023 07:58:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id EB76D60C03
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Jun 2023 07:58:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EB76D60C03
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20221208 header.b=LWlwUitw
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DIET_1=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id EEWH_a51Sx_d
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Jun 2023 07:58:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 0B3EC6079E
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
[IPv6:2a00:1450:4864:20::630])
by smtp3.osuosl.org (Postfix) with ESMTPS id 0B3EC6079E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Jun 2023 07:58:23 +0000 (UTC)
Received: by mail-ej1-x630.google.com with SMTP id
a640c23a62f3a-9700219be87so706445766b.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 05 Jun 2023 00:58:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1685951902; x=1688543902;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=adglgTbPJsCjazExnLMNRDMzQnLCq3fzGpiBCBDZOxE=;
b=LWlwUitwIYglAHlar7P7fHaqLXc0fpxoQT3mcySZ4ddfUa+enPmnpGgc1ehYK6osaD
ebNkvA5OCqM0Om1rggiBpIs0494d9VwlEB7fFXRimJQzJp1KTO2YMLjU/PNTQzAToxe9
IRYx5hQjQMrnpn3i5ahd4geJR5zwi4qUNHkYI00B2QyJaCdh+qRDbUNlE1gGbrCZJ2sx
qevv0o1R6JZ236It1oosNuaMwIdT3Sh2IM41zgz0Vj8lqFcZRqo8SoPCRvDwDM1U+SUn
FxBZX77YnNqtMr8lksDAUo4QHYJ5oy4czmNhCv4MD+sQI11ZtKMagZkrEmdwvUonsn14
V4xQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1685951902; x=1688543902;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=adglgTbPJsCjazExnLMNRDMzQnLCq3fzGpiBCBDZOxE=;
b=Y6zm7nyfiASBnXLbTQfJnd2BZKM3GOR9smi2QbBLedx5CSZRnugxJZ7D1Y7uL9WkAK
C1EqDFgWem47xReZRoNA5JVZr2og+qSUjzEGNix6eDG1o8US3nbKAY8iOjM0OHfIckr/
2QtGC8l2cubipIzuBF1jBnAKRG7x/cwwvGeFtT2P8ziC1eQvVKN0zjmr0Kgwf2iMshJq
3S4qsIfuaJiPzVBmQu72DsEBiBIuEBfgeGnFVDvpbUWz2KKxIU3+8Pg2A+hJODeeQAX5
T2COYczh/VjW1qbM614QOomyzdRTDL4mVr3or2Ox8jFXArooQakICsVSQxxuFteyUoPn
plYg==
X-Gm-Message-State: AC+VfDxTaitHPQ+1pzGeCULVOQDbZvEZ+mybxBl03b4EpRAQLowDKw9B
DyTfb/FwCK5msqCupF1Ox/P13iyANlMJm0CMKoYG5Ld3ENI=
X-Google-Smtp-Source: ACHHUZ7MQGo8eX2lTN8PUi/VHyFyFp0U1AUxUy6povjvN8L0YaE7N6ldweFbqKOxBphlBCy79SdqnwQK/Ep2F2EKU3o=
X-Received: by 2002:a17:907:97d3:b0:96a:928c:d391 with SMTP id
js19-20020a17090797d300b0096a928cd391mr6508719ejc.4.1685951902075; Mon, 05
Jun 2023 00:58:22 -0700 (PDT)
MIME-Version: 1.0
From: Joost Jager <joost.jager@gmail.com>
Date: Mon, 5 Jun 2023 09:57:46 +0200
Message-ID: <CAJBJmV9_nvCveynxs8UXmXyx=OTCYqSEKk73cn-TLNHWgo1q-g@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003b506a05fd5d44c9"
X-Mailman-Approved-At: Mon, 05 Jun 2023 09:46:44 +0000
Subject: [bitcoin-dev] Conceptual package relay using taproot annex
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: Mon, 05 Jun 2023 07:58:25 -0000
--0000000000003b506a05fd5d44c9
Content-Type: text/plain; charset="UTF-8"
Hi,
Before starting, I would like to state that I do not necessarily support
the implementation of the idea I'm about to present, but I think it's worth
mentioning as it might inspire different use cases or provoke some debate.
I believe that out-of-band relay is a more preferable and efficient way to
get transaction packages to miners while p2p package relay is under
development.
Let's consider the situation where we have a parent transaction A that pays
0 sat/b (for example a lightning commitment transaction), and a fee bumping
child transaction B. These transactions currently cannot reach miners.
We can, however, conceive a workaround. Let's introduce a third transaction
C, crafted to contain the raw transactions A and B in a taproot annex. A
commit/reveal style inscription could also be used instead, but I think it
would be more complicated and less efficient.
To ensure propagation, transaction C would pay sufficient fees. Also it
would use at least one of the same fee contributing inputs as transaction
B, but obviously not any inputs from A.
Miners, upon receiving transaction C, could detect the embedded
transactions A and B in the annex and immediately submit them to their
mempool as a transaction package. This transaction package (A+B) would then
replace transaction C and could be included in a block for mining.
It's of course important to ensure that the combined package of A+B is more
attractive to miners than the C transaction. The extra weight of the
embedded transactions in C helps with this. Also it is worth noting that
the fees for C will never be paid because it has been replaced. Thus there
are no extra costs for using this package relay scheme, unless perhaps the
weight of A+B is very low and B needs to pay a higher fee rate than
necessary to ensure replacement of C.
If not all miners adopt this incentive-compatible replacement, there's a
chance transaction C ends up being mined. This is likely less probable if
the fee rate for C is kept to a minimum. If transaction C is indeed mined,
the operation can be retried with a modified B and C, though the fees paid
for the initial transaction C would be forfeited.
Joost
--0000000000003b506a05fd5d44c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>Before starting, I would like to state that I d=
o not necessarily support the implementation of the idea I'm about to p=
resent, but I think it's worth mentioning as it might inspire different=
use cases or provoke some debate. I believe that out-of-band relay is a mo=
re preferable and efficient way to get transaction packages to miners while=
p2p package relay is under development.<br><br>Let's consider the situ=
ation where we have a parent transaction A that pays 0 sat/b (for example a=
lightning commitment transaction), and a fee bumping child transaction B. =
These transactions currently cannot reach miners.<br><br>We can, however, c=
onceive a workaround. Let's introduce a third transaction C, crafted to=
contain the raw transactions A and B in a taproot annex. A commit/reveal s=
tyle inscription could also be used instead, but I think it would be more c=
omplicated and less efficient.<br><br>To ensure propagation, transaction C =
would pay sufficient fees. Also it would use at least one of the same fee c=
ontributing inputs as transaction B, but obviously not any inputs from A.<b=
r><br>Miners, upon receiving transaction C, could detect the embedded trans=
actions A and B in the annex and immediately submit them to their mempool a=
s a transaction package. This transaction package (A+B) would then replace =
transaction C and could be included in a block for mining.<div><br></div><d=
iv>It's of course important to ensure that the combined package of A+B =
is more attractive to miners than the C transaction. The extra weight of th=
e embedded transactions in C helps with this. Also it is worth noting that =
the fees for C will never be paid because it has been replaced. Thus there =
are no extra costs for using this package relay scheme, unless perhaps the =
weight of A+B is very low and B needs to pay a higher fee rate than necessa=
ry to ensure replacement of C.<br><br>If not all miners adopt this incentiv=
e-compatible replacement, there's a chance transaction C ends up being =
mined. This is likely less probable if the fee rate for C is kept to a mini=
mum. If transaction C is indeed mined, the operation can be retried with a =
modified B and C, though the fees paid for the initial transaction C would =
be forfeited.<br><div><br></div><div>Joost</div></div></div>
--0000000000003b506a05fd5d44c9--
|
