rot13maxi [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-21 🗒️ Summary of this message: A project ...
đź“… Original date posted:2023-08-21
🗒️ Summary of this message: A project called STAMPS embeds image data into multisig outputs, while schemes like Pay-to-Contact allow tweaking a pubkey with data. Banning arbitrary data may lead to encoding data within public keys.
đź“ť Original message:
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 at lists.linuxfoundation.org> wrote:
> 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230821/24e41428/attachment-0001.html>;
🗒️ Summary of this message: A project called STAMPS embeds image data into multisig outputs, while schemes like Pay-to-Contact allow tweaking a pubkey with data. Banning arbitrary data may lead to encoding data within public keys.
đź“ť Original message:
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 at lists.linuxfoundation.org> wrote:
> 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230821/24e41428/attachment-0001.html>;