Content-Type: multipart/alternative;
 boundary="===============5920357817581320662=="
MIME-Version: 1.0
From: vjudeu@gazeta.pl
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>
Cc: GamedevAlice <gamedevalice256@gmail.com>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions"
Precedence: list

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>&gt; that does not change the fact that Alice -&gt; Bob -&gt; Zack was=
 mined in the blockchain, and those transactions exist</div>
<div>&nbsp;</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 -&gt; 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>&nbsp;</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>&nbsp;</div>
<div>On 2023-09-05 19:49:51 user Peter Todd &lt;pete@petertodd.org&gt; 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:
&gt; &gt; 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?
&gt; &nbsp;
&gt; 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>
&gt; &nbsp;
&gt; Then, if you have "Alice -&gt; Bob -&gt; ... -&gt; Zack" transaction c=
hain, and for example some inscriptions were created in "Alice -&gt; 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 -&gt; ... -&gt; Zack chain, that does not change the fact that Alice =
-&gt; Bob -&gt;
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==--