đź“… Original date posted:2023-08-21
🗒️ Summary of this message: Banning arbitrary data will lead to actors encoding their data within public keys, making it indistinguishable from random data. Users will find ways to tunnel their data through innocent-looking public key data. Counterparty has previously encoded their data within public key data.
đź“ť Original message:
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/9f2cda38/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-08-22 14:20:55
in reply to nevent1q…8jzx
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwSeen on
wss://relay.noswhere.comPublished at
2023-08-22 14:20:55Event JSON
{
"id": "3ca5a17794a71ad73c589aa11ea526a3223e13e73462b81940a73e04bfedfc8b",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1692714055,
"kind": 1,
"tags": [
[
"e",
"1dcce36c3f1f07e22a2801eda4ce40171fdf489e9118c1097ec72143125caf49",
"",
"root"
],
[
"e",
"d59b08a4fca9db4253d254b5f8eb23593632ec8d7f9f39cf0af3967f899d84e5",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2023-08-21\n🗒️ Summary of this message: Banning arbitrary data will lead to actors encoding their data within public keys, making it indistinguishable from random data. Users will find ways to tunnel their data through innocent-looking public key data. Counterparty has previously encoded their data within public key data.\n📝 Original message:\nIt's been said before, but I'll say it again:\n\nIf we ban \"arbitrary data\", however you want to define it, then actors will\nsimply respond by encoding their data within sets of public keys. Public\nkey data is indistinguishable from random data, and, unless we are willing\nto pad the blockchain with proof of knowledge of secret keys, there will be\nno way to tell a priori whether a given public key is really a public key\nor whether it is encoding an inscription or some other data.\n\nWhen certain governments try to censor certain internet protocols, users\nrespond by tunnelling their protocol through something that appears to be\ninnocent HTTPS (see Tor bridge nodes). This works because, after a\nhandshake, the remaining HTTPS stream, like public keys, is\nindistinguishable from random data, and can be used as a communications\nchannel for arbitrary data. If we attempt to ban \"arbitrary data\", those\nusers will simply respond by \"tunneling\" their data over innocent-looking\npublic key data instead.\n\nPlease correct me if I'm wrong, but I believe Counterparty has, in the\npast, encoded their data within public key data, so this concern is not\nhypothetical.\n\nOn Sat, Aug 19, 2023 at 10:29 AM Chris Martl via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e It is already more than a half year since the probably mayor Bitcoin\n\u003e script exploit started.\n\u003e\n\u003e\n\u003e These exploits are nothing new in the Bitcoin history and mostly are due\n\u003e to the loose flexibility of the system in regards of processing\n\u003e predicatives (Bitcoin script). The very first mayor bug; if you wish,\n\u003e vulnerability, was the CVE-2010-5141, which still engages us without end\n\u003e even after 14 years.\n\u003e\n\u003e\n\u003e Subsequent Bitcoin historical events let to build more “improvements” upon\n\u003e this wobbly basis exposing even more ground for exploits.\n\u003e\n\u003e\n\u003e As long as this loose flexibility is not modified in a way its exposure\n\u003e for exploits is eliminated remains nothing else than to pursue other\n\u003e strategies; and ones which are compatible with the current status quo and\n\u003e furthermore, with a permission-less system.\n\u003e\n\u003e\n\u003e Here a strategy proposal:\n\u003e\n\u003e\n\u003e Let’s name it: #Ordisrespector and #Ordislow.\n\u003e\n\u003e\n\u003e Why #Ordisrespector and #Ordislow are compatible with a permission-less\n\u003e system.\n\u003e\n\u003e\n\u003e #Ordisrespector gives the option to a regular Bitcoin node operator to\n\u003e opt-in or not to a self-defense of his/her storage property (and thus of\n\u003e his/her integrity); by giving a signal of dissatisfaction with the current\n\u003e affairs of aggression via insertion of arbitrary data into the witness\n\u003e structure. This dissatisfaction signal is manifested by not taking into the\n\u003e mempool and relaying transactions with inserted arbitrary data in the\n\u003e witness structure.\n\u003e\n\u003e\n\u003e #Ordislow gives the option to a regular Bitcoin node operator to opt-in or\n\u003e not to a self-defense of his/her storage property (and thus of his/her\n\u003e integrity); by increasing the coercion cost of mining-entities relative to\n\u003e the cooperation cost of mining-entities due to the current affairs of\n\u003e aggression via insertion of arbitrary data into the witness structure. This\n\u003e coercion cost increment is manifested by not propagating a found block,\n\u003e unless a configurable or maximum delay has elapsed, which contains at least\n\u003e a transaction with inserted arbitrary data in the witness structure.\n\u003e\n\u003e\n\u003e Chris_______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230821/9f2cda38/attachment.html\u003e",
"sig": "9140bb8b70041ba0cefa2a841b11415d34db336a2c4754c640595f9a8068f34928014cd333b8c7ea09dab0fa8bf35e4a92e4c2cfe738a166cb069911a51f0893"
}