public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo•com>
To: Luke Dashjr <luke@dashjr•org>, ZmnSCPxj <ZmnSCPxj@protonmail•com>,
	Karl-Johan Alm <karljohan-alm@garage•co.jp>,
	Andrew Poelstra <apoelstra@wpsoftware•net>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] PSA: Taproot loss of quantum protections
Date: Tue, 16 Mar 2021 13:25:40 -0400	[thread overview]
Message-ID: <98d63098-dabd-ba9f-38bc-1214631edb77@mattcorallo.com> (raw)
In-Reply-To: <202103160344.26299.luke@dashjr.org>



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 cause yet more delay and frustration.

> 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 address use. If the standard loses the hash, the
>>> situation cannot be improved, and will indeed only get worse.
>>
>> I truly wish this were the case, but we've been beating that drum for at
>> least nine years and still haven't solved it.
> 
> I think we've made progress over those 9 years, don't you?

Some, sure, but not anywhere near the amount of progress we'd need to make to have an impact on QC security of the 
overall system.

>> Except its not? One entity would be able to steal that entire block of
>> supply rather quickly (presumably over the course of a few days, at
>> maximum), instead of a slow process with significant upfront real-world
>> cost in the form of electricity.
> 
> My understanding is that at least initial successes would likely be very slow.
> Hopefully we would have a permanent solution before it got too out of hand.

There is a lot of debate on this point in the original thread which discussed this several years ago. But even if it 
were the case, it still doesn't make "let QC owners steal coins" somehow equivalent to mining. There are probably 
several blocks of coins that can be stolen to the tune of much greater rewards than a block reward, but, more broadly, 
what?! QC owners stealing coins from old outputs isn't somehow going to be seen as "OK", not to mention because many old 
outputs do have owners with the keys, they aren't all forgotten or lost.

Matt


  parent reply	other threads:[~2021-03-16 17:25 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 21:48 Luke Dashjr
2021-03-15 22:05 ` Matt Corallo
2021-03-15 22:30   ` Robert Spigler
2021-03-15 22:40   ` Jeremy
2021-03-15 22:48     ` Matt Corallo
2021-03-15 23:01       ` Karl-Johan Alm
2021-03-15 23:19         ` Matt Corallo
2021-03-15 23:46         ` Lloyd Fournier
2021-03-16  0:50         ` Anthony Towns
2021-03-16  2:38           ` ZmnSCPxj
2021-03-16  3:44   ` Luke Dashjr
2021-03-16 13:28     ` Andrew Poelstra
2021-03-16 17:25     ` Matt Corallo [this message]
2021-03-17  1:23       ` Ryan Grant
2021-03-17 11:56         ` Eoin McQuinn
2021-03-15 23:12 ` Andrew Poelstra
2021-03-16 14:10   ` Andrea
2021-03-16 15:15     ` [bitcoin-dev] Provisions (was: PSA: Taproot loss of quantum protections) Andrew Poelstra
2021-03-17  4:24       ` ZmnSCPxj
2021-03-17  8:29         ` Andrea
2021-03-20 16:31           ` Andrea Barontini
2021-03-16  0:24 ` [bitcoin-dev] PSA: Taproot loss of quantum protections David A. Harding
2021-04-05  0:27   ` Lloyd Fournier
2021-04-16  3:47     ` ZmnSCPxj
2021-04-16  5:00       ` Lloyd Fournier
2021-03-22 14:24 ` Erik Aronesty
2021-03-23  9:36   ` Martin Schwarz
2021-03-23 10:50   ` Tim Ruffing
2021-08-12 22:08   ` Erik Aronesty

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=98d63098-dabd-ba9f-38bc-1214631edb77@mattcorallo.com \
    --to=lf-lists@mattcorallo$(echo .)com \
    --cc=ZmnSCPxj@protonmail$(echo .)com \
    --cc=apoelstra@wpsoftware$(echo .)net \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=karljohan-alm@garage$(echo .)co.jp \
    --cc=luke@dashjr$(echo .)org \
    /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