From: Peter Todd <pete@petertodd.org>
To: vjudeu@gazeta.pl,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Cc: GamedevAlice <gamedevalice256@gmail.com>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions"
Date: Tue, 5 Sep 2023 17:49:43 +0000 [thread overview]
Message-ID: <ZPdqNxf2BsESnpIa@petertodd.org> (raw)
In-Reply-To: <98009035-ac19029087479e992d1f7eccdc9eb0ab@pmq6v.m5r2.onet>
[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]
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 traction, perhaps people are now more willing to consider a smaller blocksize in favor of pushing more activity to lightning?
>
> People will not agree to 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 layers: it is called cut-through, and was described in this topic: https://bitcointalk.org/index.php?topic=281848.0
>
> Then, if you have "Alice -> Bob -> ... -> Zack" transaction chain, and for example some inscriptions were created in "Alice -> Bob" transaction, then cut-through could remove those inscriptions, while leaving the payment unaffected, because the proper amount of coins will be received 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 running
a full 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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-09-05 17:49 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-03 16:01 [bitcoin-dev] Concern about "Inscriptions" vjudeu
2023-09-05 17:49 ` Peter Todd [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-09-06 8:00 vjudeu
[not found] <mailman.11.1692705603.26941.bitcoin-dev@lists.linuxfoundation.org>
2023-08-22 14:18 ` GamedevAlice
[not found] <mailman.134025.1692632811.956.bitcoin-dev@lists.linuxfoundation.org>
2023-08-21 16:28 ` John Tromp
2023-08-21 22:34 ` symphonicbtc
2023-08-23 17:34 ` Erik Aronesty
2023-08-18 20:43 martl.chris
2023-08-21 14:47 ` Russell O'Connor
2023-08-21 14:58 ` rot13maxi
2023-08-22 5:15 ` martl.chris
2023-08-03 13:33 GamedevAlice
2023-08-03 16:03 ` leohaf
2023-08-02 11:07 GamedevAlice
2023-08-02 15:46 ` Luke Dashjr
2023-07-27 19:03 Léo Haf
2023-07-30 18:34 ` rot13maxi
2023-07-27 5:10 vjudeu
2023-07-26 5:30 vjudeu
2023-07-26 9:46 ` leohaf
2023-07-25 14:11 leohaf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZPdqNxf2BsESnpIa@petertodd.org \
--to=pete@petertodd.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=gamedevalice256@gmail.com \
--cc=vjudeu@gazeta.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox