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
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id D3396C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Sep 2023 08:01:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 9E59541927
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Sep 2023 08:01:11 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9E59541927
Authentication-Results: smtp4.osuosl.org;
dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl
header.a=rsa-sha256 header.s=2013 header.b=rne+Y/e4
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, 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,
RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
SPF_PASS=-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 ciDfYpxQTGUM
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Sep 2023 08:01:05 +0000 (UTC)
Received: from smtpa39.poczta.onet.pl (smtpa39.poczta.onet.pl [213.180.142.39])
by smtp4.osuosl.org (Postfix) with ESMTPS id 3CA7E41925
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Sep 2023 08:01:03 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 3CA7E41925
Received: from pmq7v.m5r2.onet (pmq7v.m5r2.onet [10.174.35.192])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4RgZYz0T0GzlgN2D;
Wed, 6 Sep 2023 10:00:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1693987255; bh=cMBguiIul2bX4K98p097ddkf206yP5wfZ8GmkQILFts=;
h=From:Cc:To:Date:Subject:From;
b=rne+Y/e4p+K9cArbXcblVjBzJpHEv5QKilecuF7oC+rApT7RwZz0loAMD+G4dAUNC
2nruB7p5w4mRyGiHYKR3AX96iBFoTbrT+OlLE++cj2Lu0lCHyuKmrTNgx46fiDGhq1
FviMh/IEt/zUhNv3PscVtwfY5eDDnlSGG5aR/CJc=
Content-Type: multipart/alternative;
boundary="===============5920357817581320662=="
MIME-Version: 1.0
Received: from [194.5.15.194] by pmq7v.m5r2.onet via HTTP id ;
Wed, 06 Sep 2023 10:00:55 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Wed, 06 Sep 2023 10:00:53 +0200
Message-Id: <190339336-6f25cc7bcdad38e568613dcec5ff1039@pmq7v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;194.5.15.194;;3
X-Mailman-Approved-At: Wed, 06 Sep 2023 08:57:49 +0000
Cc: GamedevAlice <gamedevalice256@gmail.com>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions"
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: Wed, 06 Sep 2023 08:01:11 -0000
This is a multi-part message in MIME format.
--===============5920357817581320662==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
> that does not change the fact that Alice -> Bob -> Zack was mined in the =
blockchain, and those transactions exist
=C2=A0
If you use it in that way, then cut-through is pointless. The whole point o=
f using it is scaling. If you have only "Alice -> Zack" transaction, that i=
s included in some block, then cut-through is really useful. In other cases=
, if you include all transactions anyway, and create only a proof for some =
nodes, then it doesn't scale, because you have to always process those tran=
sactions in the middle, while there is no need to do so. It is needed only =
during batching, to prevent double-spending, but if it is deeply confirmed,=
then who needs something that doesn't scale?
=C2=A0
Also, going in that direction is a natural consequence of enabling full-RBF=
: transactions will be replaced, which means mempool-level-batching (ideall=
y non-interactive, done automatically by nodes) will be next, sooner or lat=
er.
=C2=A0
On 2023-09-05 19:49:51 user Peter Todd <pete@petertodd.org> wrote:
On Sun, Sep 03, 2023 at 06:01:02PM +0200, vjudeu via bitcoin-dev wrote: > >=
Given the current concerns with blockchain size increases due to inscripti=
ons, and now that the lightning network is starting to gain more traction, =
perhaps people are now more willing to consider a smaller blocksize in favo=
r of pushing more activity to lightning? > =C2=A0 > People will not agree t=
o shrink the maximum block size. However, if you want to kill inscriptions,=
there is another approach, that could be used to force them into second la=
yers: it is called cut-through, and was described in this topic: https://bi=
tcointalk.org/index.php?topic=3D281848.0 > =C2=A0 > Then, if you have "Alic=
e -> Bob -> ... -> Zack" transaction chain, and for example some inscriptio=
ns were created in "Alice -> Bob" transaction, then cut-through could remov=
e those inscriptions, while leaving the payment unaffected, because the pro=
per amount of coins will be received by Zack, as it should be. You are inco=
rrect: cut-through transactions will not meaningfully affect inscriptions. =
While it is true that with fancy cryptography we can prove the Alice -> ...=
-> Zack chain, that does not change the fact that Alice -> Bob -> Zack was=
mined in the blockchain, and those transactions exist. Anyone running a fu=
ll archival node will still have those transactions, and can provide them (=
and all their inscription data) to anyone who needs it. This is not unlike =
how in Bitcoin right now many people run pruned nodes that do not have any =
archival inscription data. Them running those nodes does not prevent others=
from running full archival nodes that do make that data available. -- http=
s://petertodd.org 'peter'[:-1]@petertodd.org
--===============5920357817581320662==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
<div>
<div>> that does not change the fact that Alice -> Bob -> Zack was=
mined in the blockchain, and those transactions exist</div>
<div> </div>
<div>If you use it in that way, then cut-through is pointless. The whole po=
int of using it is scaling. If you have only "Alice -> Zack" transaction=
, that is included in some block, then cut-through is really useful. In oth=
er cases, if you include all transactions anyway, and create only a proof f=
or some nodes, then it doesn't scale, because you have to always process th=
ose transactions in the middle, while there is no need to do so. It is need=
ed only during batching, to prevent double-spending, but if it is deeply co=
nfirmed, then who needs something that doesn't scale?</div>
<div> </div>
<div>Also, going in that direction is a natural consequence of enabling ful=
l-RBF: transactions will be replaced, which means mempool-level-batching (i=
deally non-interactive, done automatically by nodes) will be next, sooner o=
r later.</div>
</div>
<div> </div>
<div>On 2023-09-05 19:49:51 user Peter Todd <pete@petertodd.org> wrot=
e:</div>
<blockquote style=3D"margin-right: 0; margin-left: 7px; border-left: 2px so=
lid orange; padding-left: 8px;">
<pre>On Sun, Sep 03, 2023 at 06:01:02PM +0200, vjudeu via bitcoin-dev wrote:
> > Given the current concerns with blockchain size increases due to =
inscriptions, and now that the lightning network is starting to gain more t=
raction, perhaps people are now more willing to consider a smaller blocksiz=
e in favor of pushing more activity to lightning?
>
> People will not agree to shrink the maximum block size. However, if yo=
u want to kill inscriptions, there is another approach, that could be used =
to force them into second layers: it is called cut-through, and was describ=
ed in this topic: <a href=3D"https://bitcointalk.org/index.php?topic=3D2818=
48.0" target=3D"_blank" rel=3D"noopener">https://bitcointalk.org/index.php?=
topic=3D281848.0</a>
>
> Then, if you have "Alice -> Bob -> ... -> Zack" transaction c=
hain, and for example some inscriptions were created in "Alice -> Bob" t=
ransaction, then cut-through could remove those inscriptions, while leaving=
the payment unaffected, because the proper amount of coins will be receive=
d by Zack, as it should be.
You are incorrect: cut-through transactions will not meaningfully affect
inscriptions. While it is true that with fancy cryptography we can prove the
Alice -> ... -> Zack chain, that does not change the fact that Alice =
-> Bob ->
Zack was mined in the blockchain, and those transactions exist. Anyone runn=
ing
a full archival node will still have those transactions, and can provide th=
em
(and all their inscription data) to anyone who needs it.
This is not unlike how in Bitcoin right now many people run pruned nodes th=
at
do not have any archival inscription data. Them running those nodes does not
prevent others from running full archival nodes that do make that data
available.
-- =
<a href=3D"https://petertodd.org" target=3D"_blank" rel=3D"noopener">https:=
//petertodd.org</a> 'peter'[:-1]@petertodd.org
</pre>
</blockquote>
--===============5920357817581320662==--
|
