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:
> 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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
