📅 Original date posted:2023-08-21
🗒️ Summary of this message: Proof of secret key schemes are inefficient and costly. Encoding data in public keys or reusing k values can be used to encode data. Limiting storage of arbitrary data is difficult.
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
symphonicbtc [ARCHIVE] /
npub1tz…445mf
2023-08-22 14:20:56
in reply to nevent1q…9unr
Author Public Key
npub1tzuhwyatcrnucyyk70tf5qk3tg9n2uu94pxq9744epejuuzqf5rqw445mfPublished at
2023-08-22 14:20:56Event JSON
{
"id": "5af2384a7093cd69c1778cf708017662ac134a6128f819b6a36b30332cb6a457",
"pubkey": "58b97713abc0e7cc1096f3d69a02d15a0b357385a84c02fab5c8732e70404d06",
"created_at": 1692714056,
"kind": 1,
"tags": [
[
"e",
"1dcce36c3f1f07e22a2801eda4ce40171fdf489e9118c1097ec72143125caf49",
"",
"root"
],
[
"e",
"b987cb5d0e35403c2a7ec1be3dda3b608ae91613c7b7c74d9e809fbdc2ae5aac",
"",
"reply"
],
[
"p",
"90987bf5bbd810b5e334015b3d1655dc3021b9ae394eb8a72b7117aaa3308561"
]
],
"content": "📅 Original date posted:2023-08-21\n🗒️ Summary of this message: Proof of secret key schemes are inefficient and costly. Encoding data in public keys or reusing k values can be used to encode data. Limiting storage of arbitrary data is difficult.\n📝 Original message:\nIt 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.\n\nIt 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.\n\nSymphonic\n\n------- Original Message -------\nOn Monday, August 21st, 2023 at 4:28 PM, John Tromp via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\n\u003e \u003e If we ban \"arbitrary data\", however you want to define it, then actors will\n\u003e \u003e simply respond by encoding their data within sets of public keys. Public\n\u003e \u003e key data is indistinguishable from random data, and, unless we are willing\n\u003e \u003e to pad the blockchain with proof of knowledge of secret keys, there will be\n\u003e \u003e no way to tell a priori whether a given public key is really a public key\n\u003e \u003e or whether it is encoding an inscription or some other data.\n\u003e \n\u003e \n\u003e Note that in the Mimblewimble protocol, range proofs already prove\n\u003e knowledge of blinding factor in Pedersen commitments, and thus no\n\u003e additional padding is needed there to prevent the encoding of spam\n\u003e into cryptographic material. This makes pure MW blockchains the most\n\u003e inscription/spam resistant [1].\n\u003e \n\u003e [1] https://bitcointalk.org/index.php?topic=5437464.msg61980991#msg61980991\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "6765bb41a2b775cab8b6b3122146bb680ae37b6c842f8d28e03c92b80bcd014ac00a4c3fab7f77566ca27277a7d85d5fd0414e5d759cb974f5a267dc94691c8b"
}