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>&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==--