From: vjudeu@gazeta•pl
To: Peter Todd <pete@petertodd•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: GamedevAlice <gamedevalice256@gmail•com>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions"
Date: Wed, 06 Sep 2023 10:00:53 +0200 [thread overview]
Message-ID: <190339336-6f25cc7bcdad38e568613dcec5ff1039@pmq7v.m5r2.onet> (raw)
[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]
> that does not change the fact that Alice -> Bob -> Zack was mined in the blockchain, and those transactions exist
If you use it in that way, then cut-through is pointless. The whole point 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 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 transactions 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?
Also, going in that direction is a natural consequence of enabling full-RBF: transactions will be replaced, which means mempool-level-batching (ideally non-interactive, done automatically by nodes) will be next, sooner or later.
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 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: Type: text/html, Size: 3177 bytes --]
next reply other threads:[~2023-09-06 8:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-06 8:00 vjudeu [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-09-03 16:01 vjudeu
2023-09-05 17:49 ` Peter Todd
[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=190339336-6f25cc7bcdad38e568613dcec5ff1039@pmq7v.m5r2.onet \
--to=vjudeu@gazeta$(echo .)pl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gamedevalice256@gmail$(echo .)com \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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