From: Jose Storopoli <jose@storopoli•io>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] P2QRH / BIP-360 Update
Date: Wed, 12 Mar 2025 04:14:06 -0700 (PDT) [thread overview]
Message-ID: <77dbf51a-93aa-4d4a-87c0-b1303d83d5ccn@googlegroups.com> (raw)
In-Reply-To: <fac67bec-cbf3-4e49-b73d-f8057adca0aan@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 2550 bytes --]
I think that ECDSA was a mistake in Bitcoin (Schnorr patent expired in
2008; but I do understand its motives).
My fear is that this BIP will become a mistake in Bitcoin in 15 years or
less.
It adds orders of magnitude to public keys sizes and/or signature sizes;
and verification computation cost.
About the whole QR cryptography hype:
one thing is to do have key encapsulation QR schemes in symmetric-key
cryptography where we don't have tight constrains around storage,
like with TLS, or E2EE messaging apps.
Another thing is to add these huge public key and signature schemes to a
storage-restricted blockchain like Bitcoin.
QR lattice-based asymmetric-key cryptography is still in its infancy both
in standards and research; and we should wait.
If we are worried about quantum menaces, a much better approach would be
the P2TRH (Pay To Taproot Hash),
even with the loss of batch verification, combined with advising users to
not re-use address.
Address reuse should be treated the same as nonce reuse: you get pwned!
Or Matt Corallo's emergency disable of key path spends in P2TR;
Jose Storopoli
On Monday, March 3, 2025 at 6:55:19 PM UTC-3 Hunter Beast wrote:
> Hi, Jonas
>
> In order to spend the coins, a valid signature will need to be present in
> the attestation. Even if it's a 1/1024 multisig, a valid public key
> signature pair will need to be provided. The merkle path would then be how
> the arbitrary data could be encoded. In my mind this is a highly
> impractical scenario that gets exponentially more complex, and only works
> 32 bytes at a time.
>
> Does that make sense?
>
> Hunter
>
> On Wednesday, February 26, 2025 at 3:00:36 AM UTC-7 Jonas Nick wrote:
>
>> > it would require an extraordinary amount of computation to wind up with
>> enough
>> > to store arbitrary data.
>>
>> I have no idea why this would require extraordinary amount of
>> computation. In
>> the example I provided, arbitrary data can be included in the attestation
>> structure with zero additional computational cost, no elliptic curve
>> grinding or
>> hash collisions required.
>>
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/77dbf51a-93aa-4d4a-87c0-b1303d83d5ccn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3390 bytes --]
next prev parent reply other threads:[~2025-03-12 12:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-19 15:40 Hunter Beast
2025-02-19 17:23 ` Dustin Ray
2025-02-19 22:57 ` Hunter Beast
2025-02-20 22:11 ` Matt Corallo
2025-02-23 20:33 ` Hunter Beast
2025-02-26 19:02 ` Matt Corallo
2025-02-28 4:19 ` Dustin Ray
2025-03-03 20:57 ` Hunter Beast
2025-02-21 8:54 ` Jonas Nick
2025-02-23 20:58 ` Hunter Beast
2025-02-24 13:17 ` Jonas Nick
2025-02-25 18:03 ` Hunter Beast
2025-02-26 8:08 ` Jonas Nick
2025-03-03 21:00 ` Hunter Beast
2025-03-12 11:14 ` Jose Storopoli [this message]
2025-03-12 21:05 ` Hunter Beast
2025-02-24 16:12 ` Ian Quantum
2025-02-26 0:03 ` Tim Bratton
[not found] ` <CABfMNdKy6U+nLbq-nwK53_yiguxqanF1jexYHLGLMyef9cG1mw@mail.gmail.com>
2025-02-25 16:54 ` Hunter Beast
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=77dbf51a-93aa-4d4a-87c0-b1303d83d5ccn@googlegroups.com \
--to=jose@storopoli$(echo .)io \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox