Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-23 🗒️ Summary of this message: Adding a ...
📅 Original date posted:2023-08-23
🗒️ Summary of this message: Adding a proof-of-work requirement to public keys on an open relay server protocol can make it harder for spammers/scammers to access the network.
📝 Original message:
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 at lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> 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/20230823/5c0013ce/attachment.html>;
🗒️ Summary of this message: Adding a proof-of-work requirement to public keys on an open relay server protocol can make it harder for spammers/scammers to access the network.
📝 Original message:
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 at lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> 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/20230823/5c0013ce/attachment.html>;