Concern about "Inscriptions"
11 messages, 18 Aug to 6 Sep 2023. Started by martl.chris.
martl.chris (2), vjudeu (2), Russell O'Connor, rot13maxi, John Tromp, symphonicbtc, GamedevAlice, Erik Aronesty, +1 more
It is already more than a half year since the probably mayor Bitcoin script exploit started.
These exploits are nothing new in the Bitcoin history and mostly are due to the loose flexibility of the system in regards of processing predicatives (Bitcoin script). The very first mayor bug; if you wish, vulnerability, was the CVE-2010-5141, which still engages us without end even after 14 years.
Subsequent Bitcoin historical events let to build more “improvements” upon this wobbly basis exposing even more ground for exploits.
As long as this loose flexibility is not modified in a way its exposure for exploits is eliminated remains nothing else than to pursue other strategies; and ones which are compatible with the current status quo and furthermore, with a permission-less system.
Here a strategy proposal:
Let’s name it: #Ordisrespector and #Ordislow.
Why #Ordisrespector and #Ordislow are compatible with a permission-less system.
#Ordisrespector gives the option to a regular Bitcoin node operator to opt-in or not to a self-defense of his/her storage property (and thus of his/her integrity); by giving a signal of dissatisfaction with the current affairs of aggression via insertion of arbitrary data into the witness structure. This dissatisfaction signal is manifested by not taking into the mempool and relaying transactions with inserted arbitrary data in the witness structure.
#Ordislow gives the option to a regular Bitcoin node operator to opt-in or not to a self-defense of his/her storage property (and thus of his/her integrity); by increasing the coercion cost of mining-entities relative to the cooperation cost of mining-entities due to the current affairs of aggression via insertion of arbitrary data into the witness structure. This coercion cost increment is manifested by not propagating a found block, unless a configurable or maximum delay has elapsed, which contains at least a transaction with inserted arbitrary data in the witness structure.
Chris
It's been said before, but I'll say it again:
If we ban "arbitrary data", however you want to define it, then actors will simply respond by encoding their data within sets of public keys. Public key data is indistinguishable from random data, and, unless we are willing to pad the blockchain with proof of knowledge of secret keys, there will be no way to tell a priori whether a given public key is really a public key or whether it is encoding an inscription or some other data.
When certain governments try to censor certain internet protocols, users respond by tunnelling their protocol through something that appears to be innocent HTTPS (see Tor bridge nodes). This works because, after a handshake, the remaining HTTPS stream, like public keys, is indistinguishable from random data, and can be used as a communications channel for arbitrary data. If we attempt to ban "arbitrary data", those users will simply respond by "tunneling" their data over innocent-looking public key data instead.
Please correct me if I'm wrong, but I believe Counterparty has, in the past, encoded their data within public key data, so this concern is not hypothetical.
On Sat, Aug 19, 2023 at 10:29 AM Chris Martl via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (55 lines)
> It is already more than a half year since the probably mayor Bitcoin > script exploit started. > > > These exploits are nothing new in the Bitcoin history and mostly are due > to the loose flexibility of the system in regards of processing > predicatives (Bitcoin script). The very first mayor bug; if you wish, > vulnerability, was the CVE-2010-5141, which still engages us without end > even after 14 years. > > > Subsequent Bitcoin historical events let to build more “improvements” upon > this wobbly basis exposing even more ground for exploits. > > > As long as this loose flexibility is not modified in a way its exposure > for exploits is eliminated remains nothing else than to pursue other > strategies; and ones which are compatible with the current status quo and > furthermore, with a permission-less system. > > > Here a strategy proposal: > > > Let’s name it: #Ordisrespector and #Ordislow. > > > Why #Ordisrespector and #Ordislow are compatible with a permission-less > system. > > > #Ordisrespector gives the option to a regular Bitcoin node operator to > opt-in or not to a self-defense of his/her storage property (and thus of > his/her integrity); by giving a signal of dissatisfaction with the current > affairs of aggression via insertion of arbitrary data into the witness > structure. This dissatisfaction signal is manifested by not taking into the > mempool and relaying transactions with inserted arbitrary data in the > witness structure. > > > #Ordislow gives the option to a regular Bitcoin node operator to opt-in or > not to a self-defense of his/her storage property (and thus of his/her > integrity); by increasing the coercion cost of mining-entities relative to > the cooperation cost of mining-entities due to the current affairs of > aggression via insertion of arbitrary data into the witness structure. This > coercion cost increment is manifested by not propagating a found block, > unless a configurable or maximum delay has elapsed, which contains at least > a transaction with inserted arbitrary data in the witness structure. > > > Chris_______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Good morning Russel and List,
That is correct. There is a counterparty-compatible project called STAMPS that breaks up image data into chunks and then embeds the chunks in bare multisig outputs. here is an example on one: https://mempool.space/tx/ee9ed76fa2318deb63a24082a8edc73e4ea39a5252bfb1c1e1c02bd02c52f95f This consumes more space and bloats the UTXO set compared to stuffing data in a witness.
There are schemes like Pay-to-Contact ([https://bitcoinops.org/en/topics/pay-to-contract-outputs/](https://bitcoinops.org/en/topics/pay-to-contract-outputs/#:~:text=Pay%2Dto%2Dcontract%20protocols%20allow,that%20commits%20to%20that%20text)) that could be used to tweak a pubkey with a small blob of data, in which case someone could produce a signature proving knowledge of the private key.
------- Original Message ------- On Monday, August 21st, 2023 at 10:47 AM, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (32 lines)
> It's been said before, but I'll say it again: > > If we ban "arbitrary data", however you want to define it, then actors will simply respond by encoding their data within sets of public keys. Public key data is indistinguishable from random data, and, unless we are willing to pad the blockchain with proof of knowledge of secret keys, there will be no way to tell a priori whether a given public key is really a public key or whether it is encoding an inscription or some other data. > > When certain governments try to censor certain internet protocols, users respond by tunnelling their protocol through something that appears to be innocent HTTPS (see Tor bridge nodes). This works because, after a handshake, the remaining HTTPS stream, like public keys, is indistinguishable from random data, and can be used as a communications channel for arbitrary data. If we attempt to ban "arbitrary data", those users will simply respond by "tunneling" their data over innocent-looking public key data instead. > > Please correct me if I'm wrong, but I believe Counterparty has, in the past, encoded their data within public key data, so this concern is not hypothetical. > > On Sat, Aug 19, 2023 at 10:29 AM Chris Martl via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote: > >> It is already more than a half year since the probably mayor Bitcoin script exploit started. >> >> These exploits are nothing new in the Bitcoin history and mostly are due to the loose flexibility of the system in regards of processing predicatives (Bitcoin script). The very first mayor bug; if you wish, vulnerability, was the CVE-2010-5141, which still engages us without end even after 14 years. >> >> Subsequent Bitcoin historical events let to build more “improvements” upon this wobbly basis exposing even more ground for exploits. >> >> As long as this loose flexibility is not modified in a way its exposure for exploits is eliminated remains nothing else than to pursue other strategies; and ones which are compatible with the current status quo and furthermore, with a permission-less system. >> >> Here a strategy proposal: >> >> Let’s name it: #Ordisrespector and #Ordislow. >> >> Why #Ordisrespector and #Ordislow are compatible with a permission-less system. >> >> #Ordisrespector gives the option to a regular Bitcoin node operator to opt-in or not to a self-defense of his/her storage property (and thus of his/her integrity); by giving a signal of dissatisfaction with the current affairs of aggression via insertion of arbitrary data into the witness structure. This dissatisfaction signal is manifested by not taking into the mempool and relaying transactions with inserted arbitrary data in the witness structure. >> >> #Ordislow gives the option to a regular Bitcoin node operator to opt-in or not to a self-defense of his/her storage property (and thus of his/her integrity); by increasing the coercion cost of mining-entities relative to the cooperation cost of mining-entities due to the current affairs of aggression via insertion of arbitrary data into the witness structure. This coercion cost increment is manifested by not propagating a found block, unless a configurable or maximum delay has elapsed, which contains at least a transaction with inserted arbitrary data in the witness structure. >> >> Chris_______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Quoted text (6 lines)
> If we ban "arbitrary data", however you want to define it, then actors will > simply respond by encoding their data within sets of public keys. Public > key data is indistinguishable from random data, and, unless we are willing > to pad the blockchain with proof of knowledge of secret keys, there will be > no way to tell a priori whether a given public key is really a public key > or whether it is encoding an inscription or some other data.
Note that in the Mimblewimble protocol, range proofs already prove knowledge of blinding factor in Pedersen commitments, and thus no additional padding is needed there to prevent the encoding of spam into cryptographic material. This makes pure MW blockchains the most inscription/spam resistant [1].
[1] https://bitcointalk.org/index.php?topic=5437464.msg61980991#msg61980991
It is important to also note that proof of secret key schemes are highly data inefficient and likely would have a higher cost for users than simply allowing arbitrary data to continue. In ECDSA, purposely re-using k values allows you to encode data in both k and the entire secret key, as both become computable. Or, one could bruteforce a k value to encode data in a sig, as is done in some compromised hardware key exfiltration attacks. Additionally, one can bruteforce keys in order to encode data in the public key.
It is very difficult and expensive to attempt to limit the storage of arbitrary data in a system where the security comes from secret keys being arbitrary data.
Symphonic
------- Original Message ------- On Monday, August 21st, 2023 at 4:28 PM, John Tromp via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (19 lines)
> > If we ban "arbitrary data", however you want to define it, then actors will > > simply respond by encoding their data within sets of public keys. Public > > key data is indistinguishable from random data, and, unless we are willing > > to pad the blockchain with proof of knowledge of secret keys, there will be > > no way to tell a priori whether a given public key is really a public key > > or whether it is encoding an inscription or some other data. > > > Note that in the Mimblewimble protocol, range proofs already prove > knowledge of blinding factor in Pedersen commitments, and thus no > additional padding is needed there to prevent the encoding of spam > into cryptographic material. This makes pure MW blockchains the most > inscription/spam resistant [1]. > > [1] https://bitcointalk.org/index.php?topic=5437464.msg61980991#msg61980991 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Good Morning List,
understanding the strategy wrongly or purposelydriving the interaction into a false framing doesn’t benefit Bitcoin. Mentioning <ban"arbitrary data"> or <governments try tocensor> distracts from the proposed strategy.
The strategy aims to increment the coercion cost of mining-entities relative to the cooperation cost of mining-entities in regards of arbitrary data insertion; it is not about banning or censoring.
Mentioning other ways or methods to insert arbitrary data should not be understood as a threat or menace, but much more as topics which each Bitcoin developer should have in mind to solve.
It is healthy to assume that arbitrary data insertions are nothing but innocent or negligible. The Bitcoin system is still in the struggle of two visions:
- One controlled by every node operator and highly decentralized. (Nobody alone controls)
or
- One controlled by a few very highly capitalized entity node operators and highly centralized. (A committee controls).
The best tactical way to reach the latter is via prohibitive cost increment for operating a regular Bitcoin node (aka. archival full node). That will reduce the network decentralization making it susceptible for central entity elimination or control acquisition; and not necessary by a national-state government.
Chris
------- Forwarded Message ------- Von: Russell O'Connor <roconnor@blockstream•com> Datum: Am Montag, 21. August 2023 um 16:47 Betreff: Re: [bitcoin-dev] Concern about "Inscriptions" An: martl.chris@proton•me <martl.chris@proton•me>, Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation•org>
Quoted text (32 lines)
> It's been said before, but I'll say it again: > > If we ban "arbitrary data", however you want to define it, then actors will simply respond by encoding their data within sets of public keys. Public key data is indistinguishable from random data, and, unless we are willing to pad the blockchain with proof of knowledge of secret keys, there will be no way to tell a priori whether a given public key is really a public key or whether it is encoding an inscription or some other data. > > When certain governments try to censor certain internet protocols, users respond by tunnelling their protocol through something that appears to be innocent HTTPS (see Tor bridge nodes). This works because, after a handshake, the remaining HTTPS stream, like public keys, is indistinguishable from random data, and can be used as a communications channel for arbitrary data. If we attempt to ban "arbitrary data", those users will simply respond by "tunneling" their data over innocent-looking public key data instead. > > Please correct me if I'm wrong, but I believe Counterparty has, in the past, encoded their data within public key data, so this concern is not hypothetical. > > On Sat, Aug 19, 2023 at 10:29 AM Chris Martl via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote: > >> It is already more than a half year since the probably mayor Bitcoin script exploit started. >> >> These exploits are nothing new in the Bitcoin history and mostly are due to the loose flexibility of the system in regards of processing predicatives (Bitcoin script). The very first mayor bug; if you wish, vulnerability, was the CVE-2010-5141, which still engages us without end even after 14 years. >> >> Subsequent Bitcoin historical events let to build more “improvements” upon this wobbly basis exposing even more ground for exploits. >> >> As long as this loose flexibility is not modified in a way its exposure for exploits is eliminated remains nothing else than to pursue other strategies; and ones which are compatible with the current status quo and furthermore, with a permission-less system. >> >> Here a strategy proposal: >> >> Let’s name it: #Ordisrespector and #Ordislow. >> >> Why #Ordisrespector and #Ordislow are compatible with a permission-less system. >> >> #Ordisrespector gives the option to a regular Bitcoin node operator to opt-in or not to a self-defense of his/her storage property (and thus of his/her integrity); by giving a signal of dissatisfaction with the current affairs of aggression via insertion of arbitrary data into the witness structure. This dissatisfaction signal is manifested by not taking into the mempool and relaying transactions with inserted arbitrary data in the witness structure. >> >> #Ordislow gives the option to a regular Bitcoin node operator to opt-in or not to a self-defense of his/her storage property (and thus of his/her integrity); by increasing the coercion cost of mining-entities relative to the cooperation cost of mining-entities due to the current affairs of aggression via insertion of arbitrary data into the witness structure. This coercion cost increment is manifested by not propagating a found block, unless a configurable or maximum delay has elapsed, which contains at least a transaction with inserted arbitrary data in the witness structure. >> >> Chris_______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
As I understand it, protecting against this is exactly the reason why a blocksize limit exists. Perhaps it should never have been increased in the first place.
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?
On Tue, Aug 22, 2023, 8:00 AM , < bitcoin-dev-request@lists•linuxfoundation•org> wrote:
Quoted text (98 lines)
> Send bitcoin-dev mailing list submissions to > bitcoin-dev@lists•linuxfoundation•org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > or, via email, send a message with subject or body 'help' to > bitcoin-dev-request@lists•linuxfoundation•org > > You can reach the person managing the list at > bitcoin-dev-owner@lists•linuxfoundation•org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bitcoin-dev digest..." > > > Today's Topics: > > 1. Re: Concern about "Inscriptions" (symphonicbtc) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 21 Aug 2023 22:34:03 +0000 > From: symphonicbtc <symphonicbtc@proton•me> > To: John Tromp <john.tromp@gmail•com> > Cc: Bitcoin Protocol Discussion > <bitcoin-dev@lists•linuxfoundation•org> > Subject: Re: [bitcoin-dev] Concern about "Inscriptions" > Message-ID: > > <UMOgM6dqQHqgxIoeyCE1ZzBDbU1c2H6oyUCVs4eTgUwozDphZwFdfO4qvnXUMZwYhfShzcaYqmLGN-XrfzyhYKWD8Q8IOD7EJAtdgbqMLe8=@ > proton.me> > > Content-Type: text/plain; charset=utf-8 > > It is important to also note that proof of secret key schemes are highly > data inefficient and likely would have a higher cost for users than simply > allowing arbitrary data to continue. In ECDSA, purposely re-using k values > allows you to encode data in both k and the entire secret key, as both > become computable. Or, one could bruteforce a k value to encode data in a > sig, as is done in some compromised hardware key exfiltration attacks. > Additionally, one can bruteforce keys in order to encode data in the public > key. > > It is very difficult and expensive to attempt to limit the storage of > arbitrary data in a system where the security comes from secret keys being > arbitrary data. > > Symphonic > > ------- Original Message ------- > On Monday, August 21st, 2023 at 4:28 PM, John Tromp via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > > > > > If we ban "arbitrary data", however you want to define it, then actors > will > > > simply respond by encoding their data within sets of public keys. > Public > > > key data is indistinguishable from random data, and, unless we are > willing > > > to pad the blockchain with proof of knowledge of secret keys, there > will be > > > no way to tell a priori whether a given public key is really a public > key > > > or whether it is encoding an inscription or some other data. > > > > > > Note that in the Mimblewimble protocol, range proofs already prove > > knowledge of blinding factor in Pedersen commitments, and thus no > > additional padding is needed there to prevent the encoding of spam > > into cryptographic material. This makes pure MW blockchains the most > > inscription/spam resistant [1]. > > > > [1] > https://bitcointalk.org/index.php?topic=5437464.msg61980991#msg61980991 > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > ------------------------------ > > End of bitcoin-dev Digest, Vol 99, Issue 43 > ******************************************* >
indeed, i once added a proof-of work requirement to public keys on an open relay server protocol, in additon to posk, in order to make it harder to roll new keys and access the network as a spammer/scammer. not hard to embed anything in a public key, but you can't embed too much, especially if you want mobile devices to be able to generate a new key in under a few minutes.
On Mon, Aug 21, 2023 at 6:46 PM symphonicbtc via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (50 lines)
> It is important to also note that proof of secret key schemes are highly > data inefficient and likely would have a higher cost for users than simply > allowing arbitrary data to continue. In ECDSA, purposely re-using k values > allows you to encode data in both k and the entire secret key, as both > become computable. Or, one could bruteforce a k value to encode data in a > sig, as is done in some compromised hardware key exfiltration attacks. > Additionally, one can bruteforce keys in order to encode data in the public > key. > > It is very difficult and expensive to attempt to limit the storage of > arbitrary data in a system where the security comes from secret keys being > arbitrary data. > > Symphonic > > ------- Original Message ------- > On Monday, August 21st, 2023 at 4:28 PM, John Tromp via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > > > > > If we ban "arbitrary data", however you want to define it, then actors > will > > > simply respond by encoding their data within sets of public keys. > Public > > > key data is indistinguishable from random data, and, unless we are > willing > > > to pad the blockchain with proof of knowledge of secret keys, there > will be > > > no way to tell a priori whether a given public key is really a public > key > > > or whether it is encoding an inscription or some other data. > > > > > > Note that in the Mimblewimble protocol, range proofs already prove > > knowledge of blinding factor in Pedersen commitments, and thus no > > additional padding is needed there to prevent the encoding of spam > > into cryptographic material. This makes pure MW blockchains the most > > inscription/spam resistant [1]. > > > > [1] > https://bitcointalk.org/index.php?topic=5437464.msg61980991#msg61980991 > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Quoted text (1 line)
> 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.
On 2023-08-25 10:44:41 user GamedevAlice via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote: As I understand it, protecting against this is exactly the reason why a blocksize limit exists. Perhaps it should never have been increased in the first place. 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?
On Tue, Aug 22, 2023, 8:00 AM , <bitcoin-dev-request@lists•linuxfoundation•org> wrote: Send bitcoin-dev mailing list submissions to bitcoin-dev@lists•linuxfoundation•org To subscribe or unsubscribe via the World Wide Web, visit https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev or, via email, send a message with subject or body 'help' to bitcoin-dev-request@lists•linuxfoundation•org You can reach the person managing the list at bitcoin-dev-owner@lists•linuxfoundation•org When replying, please edit your Subject line so it is more specific than "Re: Contents of bitcoin-dev digest..." Today's Topics: 1. Re: Concern about "Inscriptions" (symphonicbtc) ---------------------------------------------------------------------- Message: 1 Date: Mon, 21 Aug 2023 22:34:03 +0000 From: symphonicbtc <symphonicbtc@proton•me> To: John Tromp <john.tromp@gmail•com> Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation•org> Subject: Re: [bitcoin-dev] Concern about "Inscriptions" Message-ID: <UMOgM6dqQHqgxIoeyCE1ZzBDbU1c2H6oyUCVs4eTgUwozDphZwFdfO4qvnXUMZwYhfShzcaYqmLGN-XrfzyhYKWD8Q8IOD7EJAtdgbqMLe8=@proton.me> Content-Type: text/plain; charset=utf-8 It is important to also note that proof of secret key schemes are highly data inefficient and likely would have a higher cost for users than simply allowing arbitrary data to continue. In ECDSA, purposely re-using k values allows you to encode data in both k and the entire secret key, as both become computable. Or, one could bruteforce a k value to encode data in a sig, as is done in some compromised hardware key exfiltration attacks. Additionally, one can bruteforce keys in order to encode data in the public key. It is very difficult and expensive to attempt to limit the storage of arbitrary data in a system where the security comes from secret keys being arbitrary data. Symphonic ------- Original Message ------- On Monday, August 21st, 2023 at 4:28 PM, John Tromp via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (19 lines)
> > If we ban "arbitrary data", however you want to define it, then actors will > > simply respond by encoding their data within sets of public keys. Public > > key data is indistinguishable from random data, and, unless we are willing > > to pad the blockchain with proof of knowledge of secret keys, there will be > > no way to tell a priori whether a given public key is really a public key > > or whether it is encoding an inscription or some other data. > > > Note that in the Mimblewimble protocol, range proofs already prove > knowledge of blinding factor in Pedersen commitments, and thus no > additional padding is needed there to prevent the encoding of spam > into cryptographic material. This makes pure MW blockchains the most > inscription/spam resistant [1]. > > [1] https://bitcointalk.org/index.php?topic=5437464.msg61980991#msg61980991 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On Sun, Sep 03, 2023 at 06:01:02PM +0200, vjudeu via bitcoin-dev wrote:
Quoted text (5 lines)
> > 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.
Quoted text (1 line)
> 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