Noe: for A. Chow's upgrade to work, there obviously has to be an
effort to deliberately-blacklist unupgraded coins, say after 10-20
years of opportunity to upgrade, or something like that, as long as
the transition to quantum isn't so fast that there's no way to do
this.
On Mon, Mar 22, 2021 at
On Fri, 16 Apr 2021 at 13:47, ZmnSCPxj wrote:
> Good morning LL,
>
> > On Tue, 16 Mar 2021 at 11:25, David A. Harding via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > I curious about whether anyone informed about ECC and QC
> > > knows how to create output scripts with
Good morning LL,
> On Tue, 16 Mar 2021 at 11:25, David A. Harding via bitcoin-dev
> wrote:
>
> > I curious about whether anyone informed about ECC and QC
> > knows how to create output scripts with lower difficulty that could be
> > used to measure the progress of QC-based EC key cracking.
On Tue, 16 Mar 2021 at 11:25, David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I curious about whether anyone informed about ECC and QC
> knows how to create output scripts with lower difficulty that could be
> used to measure the progress of QC-based EC key
On Mon, 2021-03-22 at 10:24 -0400, Erik Aronesty via bitcoin-dev wrote:
>
> Does anyone think it would it be useful to write up a more official,
> and even partly functional plan for Bitcoin to use zero-knowledge
> proofs to transition to quantum resistance?
Yes, for sure. This is certainly
Erik,
> Does anyone think it would it be useful to write up a more official,
and even partly functional plan for Bitcoin to use zero-knowledge
proofs to transition to quantum resistance?
yes, this would be appreciated very much! Andrew Chow's write-up
gives already some high-level idea, but a
The argument that hashed public addresses provide meaningful quantum
resistance is flawed *when considered in the context*.of Bitcoin
itself.
This article by Andrew Chow is easy to read and makes a strong case
against the quantum utility of hashed public keys:
How do people in other non-English-speaking parts of the world use and
develop Bitcoin Core?
On Wed, Mar 17, 2021 at 1:24 AM Ryan Grant via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I enjoyed the reindexing using a distinct subject and I appreciate the
> new clarifications by
I enjoyed the reindexing using a distinct subject and I appreciate the
new clarifications by those whose instinct was to put effort into a
response. Although I try to keep up, some of the taproot QC
mitigations that are possible had escaped my attention thus far.
On 3/15/21 23:44, Luke Dashjr wrote:
(To reiterate: I do not intend any of this as a NACK of Taproot.)
Frankly, then why parrot arguments you don't agree with in an already-tense discussion? I'm really not sure what there
is to gain by dredging up years-old since-settled debates except to
Il 16/03/21 00:12, Andrew Poelstra via bitcoin-dev ha scritto:
Having exposed keys also lets you do ring signatures over outputs, creating the
ability to do private proof of funds via Provisions.
Hi! Sorry for the OT, could you provide some references to ring
signatures over/for/via
On Tue, Mar 16, 2021 at 03:44:25AM +, Luke Dashjr wrote:
> (To reiterate: I do not intend any of this as a NACK of Taproot.)
>
Thanks, although it's still somewhat frustrating to be rehashing this
discussion again after so many years.
> On Monday 15 March 2021 23:12:18 Andrew Poelstra
I agree with Matt.
The naked pubkey is required for some of the benefits being implemented
(snicker coinjoins).
Even with pubkey hashes, bitcoin could still be stolen because the pubkey is
published on spend. Regardless, QC needs to be fixed later on (decades), and
shouldn't be a reason to
On Tue, 16 Mar 2021 at 09:05, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> There have been many threads on this before, I'm not sure anything new has
> been brought up here.
>
> Matt
>
> On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:
> > I do not personally
(To reiterate: I do not intend any of this as a NACK of Taproot.)
On Monday 15 March 2021 22:05:45 Matt Corallo wrote:
> > First, so long as we have hash-based addresses as a best practice, we can
> > continue to shrink the percentage of bitcoins affected through social
> > efforts discouraging
Good morning aj,
> On Tue, Mar 16, 2021 at 08:01:47AM +0900, Karl-Johan Alm via bitcoin-dev
> wrote:
>
> > It may initially take months to break a single key.
>
> From what I understand, the constraint on using quantum techniques to
> break an ECC key is on the number of bits you can entangle
On Tue, Mar 16, 2021 at 08:01:47AM +0900, Karl-Johan Alm via bitcoin-dev wrote:
> It may initially take months to break a single key.
>From what I understand, the constraint on using quantum techniques to
break an ECC key is on the number of bits you can entangle and how long
you can keep them
On Mon, Mar 15, 2021 at 09:48:15PM +, Luke Dashjr via bitcoin-dev wrote:
> Note that in all circumstances, Bitcoin is endangered when QC becomes
> a reality [...] it could very well become an unrecoverable situation
> if QC go online prior to having a full quantum-safe solution.
The main
Right, totally. There was substantial debate on the likelihood of such a QC existing (ie a slow one) on the original
thread several years ago, but ignoring that, my broader point was about the address reuse issue. Given that, there's
just not much we can do with the existing hash-indirection.
On Mon, Mar 15, 2021 at 09:48:15PM +, Luke Dashjr via bitcoin-dev wrote:
> Also, what I didn't know myself until today, is that we do not actually gain
> anything from this: the features proposed to make use of the raw keys being
> public prior to spending can be implemented with hashed keys
On Tue, 16 Mar 2021 at 07:48, Matt Corallo via bitcoin-dev
wrote:
>
> Overall, the tradeoffs here seem ludicrous, given that any QC issues in
> Bitcoin need to be solved in another way, and
> can't practically be solved by just relying on the existing hash indirection.
The important distinction
Right, you can avoid the storage cost at the cost of significantly higher CPU usage, plus lack of ability to
batch-validate. As Robert pointed out in a neighboring mail, it also reduces ability to do other, fancier, protocols
using the fact that public keys are now a public part of a
I think Luke is pointing out that with the Signature and the Message you
should be able to recover the key.
if your address is H(P) and the message is H(H(P) || txn), then the you can
use the public H(P) and the signature to recover the PK and verify that
H(P) == P (I think you then don't even
There have been many threads on this before, I'm not sure anything new has been
brought up here.
Matt
On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:
I do not personally see this as a reason to NACK Taproot, but it has become
clear to me over the past week or so that many others are
I do not personally see this as a reason to NACK Taproot, but it has become
clear to me over the past week or so that many others are unaware of this
tradeoff, so I am sharing it here to ensure the wider community is aware of
it and can make their own judgements.
Mark Friedenbach explains on
25 matches
Mail list logo
