[bitcoin-dev] Simple step one for quantum

[bitcoin-dev] Simple step one for quantum

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

First step could be just implementing a similar address type
(secp26k1+NTRU) and associated validation as a soft fork

https://www.openssh.com/releasenotes.html#9.0

Then people can opt-in to quantum safe addresses

Still should work with schnorr and other things

It's a lot of work to fold this in and it's a some extra validation work
for nodes

Adding a fee premium for using these addresses in order to address that
concern seems reasonable

I'm not saying I endorse any action at all.  Personally I think this is
putting the cart like six and a half miles in front of the horse.

But if there's a lot of people that are like yeah please do this, I'd be
happy to make an NTRU bip or something.

[-- Attachment #2: Type: text/html, Size: 1264 bytes --]

Re: [bitcoin-dev] Simple step one for quantum

[Christopher Allen]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

On Fri, Apr 8, 2022 at 2:36 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I'm not saying I endorse any action at all.  Personally I think this is
> putting the cart like six and a half miles in front of the horse.
>
I have to agree that practical quantum-attacks are like fusion, human-level
AI, and nanotechnology — always 20 years away. In addition, several
reported approaches to quantum-attack resistance have fallen, and more will
fall in the next “20 years”.

That being said, it is interesting research. Here is the best link about
this particular approach:

https://ntruprime.cr.yp.to/software.html

Blockchain Commons can’t offer to fully fund this research, but if others
do we’d be glad to contribute a small grant.

— Christopher Allen

[-- Attachment #2: Type: text/html, Size: 2631 bytes --]

Re: [bitcoin-dev] Simple step one for quantum

[Christopher Allen]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

On Fri, Apr 8, 2022 at 4:33 PM Christopher Allen <
ChristopherA@lifewithalacrity.com> wrote:

> That being said, it is interesting research. Here is the best link about
> this particular approach:
>
> https://ntruprime.cr.yp.to/software.html
>

Also I think this is the original academic paper:

https://eprint.iacr.org/2021/826.pdf

<https://ntruprime.cr.yp.to/software.html>
>
— Christopher Allen

[-- Attachment #2: Type: text/html, Size: 1782 bytes --]

Re: [bitcoin-dev] Simple step one for quantum

[Lloyd Fournier]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

Hey all,

A good first step might be to express this as a research problem on
bitcoinproblems.org! I've had in mind creating a problem page on how to
design a PQ TR commitment in each key so that if QC were to become a
reality we could softfork to enable that spend (and disable normal key path
spends):
https://github.com/bitcoin-problems/bitcoin-problems.github.io/issues/4

Becoming the author/maintainer of this problem is as simple as making a PR
to the repo. The problem doesn't have to be focused on a TR solution but
could be a general description of the problem with that and others as a
potential solution direction.

Cheers,

LL

On Sat, 9 Apr 2022 at 18:39, Christopher Allen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On Fri, Apr 8, 2022 at 4:33 PM Christopher Allen <
> ChristopherA@lifewithalacrity.com> wrote:
>
>> That being said, it is interesting research. Here is the best link about
>> this particular approach:
>>
>> https://ntruprime.cr.yp.to/software.html
>>
>
> Also I think this is the original academic paper:
>
> https://eprint.iacr.org/2021/826.pdf
>
> <https://ntruprime.cr.yp.to/software.html>
>>
> — Christopher Allen _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3391 bytes --]

Re: [bitcoin-dev] Simple step one for quantum

[Olaoluwa Osuntokun]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

The NIST Post-Quantum Cryptography competition [1] results should be
published "soon":
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/fvnhyQ25jUg/m/-pYN2nshBgAJ
.

The last reply on that thread promised results by the end of March, but
since that has come and gone, I think it's safe to expect results by the end
of this month (April). FWIW, NTRU and NTRU Prime both made it to round 3 for
the public key encryption/exchange and digital signature categories, but
both of them seem to be mired in some sort of patent controversy atm...

-- Laolu

[1]: https://csrc.nist.gov/Projects/post-quantum-cryptography

On Fri, Apr 8, 2022 at 5:36 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> First step could be just implementing a similar address type
> (secp26k1+NTRU) and associated validation as a soft fork
>
> https://www.openssh.com/releasenotes.html#9.0
>
> Then people can opt-in to quantum safe addresses
>
> Still should work with schnorr and other things
>
> It's a lot of work to fold this in and it's a some extra validation work
> for nodes
>
> Adding a fee premium for using these addresses in order to address that
> concern seems reasonable
>
> I'm not saying I endorse any action at all.  Personally I think this is
> putting the cart like six and a half miles in front of the horse.
>
> But if there's a lot of people that are like yeah please do this, I'd be
> happy to make an NTRU bip or something.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2910 bytes --]

Re: [bitcoin-dev] Simple step one for quantum

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]

FWICT: Streamlined NTRU Prime (sntrup) has no known patent issues.

Should be fine.

Regardless, a "double-wrapped bitcoin address of some kind" can be
specified, coded up and the relevant module replaced whenever the dust
settles.

I know Bitcoin doesn't (yet) have fee "weights", but i still think these
addresses should be called "heavier" if they are at al significantly slower
to validate.

On Mon, Apr 11, 2022 at 2:07 PM Olaoluwa Osuntokun <laolu32@gmail.com>
wrote:

> The NIST Post-Quantum Cryptography competition [1] results should be
> published "soon":
>
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/fvnhyQ25jUg/m/-pYN2nshBgAJ
> .
>
> The last reply on that thread promised results by the end of March, but
> since that has come and gone, I think it's safe to expect results by the
> end
> of this month (April). FWIW, NTRU and NTRU Prime both made it to round 3
> for
> the public key encryption/exchange and digital signature categories, but
> both of them seem to be mired in some sort of patent controversy atm...
>
> -- Laolu
>
> [1]: https://csrc.nist.gov/Projects/post-quantum-cryptography
>
> On Fri, Apr 8, 2022 at 5:36 PM Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> First step could be just implementing a similar address type
>> (secp26k1+NTRU) and associated validation as a soft fork
>>
>> https://www.openssh.com/releasenotes.html#9.0
>>
>> Then people can opt-in to quantum safe addresses
>>
>> Still should work with schnorr and other things
>>
>> It's a lot of work to fold this in and it's a some extra validation work
>> for nodes
>>
>> Adding a fee premium for using these addresses in order to address that
>> concern seems reasonable
>>
>> I'm not saying I endorse any action at all.  Personally I think this is
>> putting the cart like six and a half miles in front of the horse.
>>
>> But if there's a lot of people that are like yeah please do this, I'd be
>> happy to make an NTRU bip or something.
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

[-- Attachment #2: Type: text/html, Size: 3986 bytes --]