Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

[Luke Dashjr via bitcoin-dev]

(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 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?

> > Second, when/if quantum does compromise these coins, so long as they are
> > neglected or abandoned/lost coins (inherent in the current model), it can
> > be seen as equivalent to Bitcoin mining. At the end of the day, 37% of
> > supply minable by QCs is really no different than 37% minable by ASICs.
> > (We've seen far higher %s available for mining obviously.)
>
> 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.


On Monday 15 March 2021 23:01:47 Karl-Johan Alm via bitcoin-dev wrote:
> The important distinction here is that, with hashes, an attacker has
> to race against the spending transaction confirming, whereas with
> naked pubkeys, the attacker doesn't have to wait for a spend to occur,
> drastically increasing the available time to attack.

More importantly, once an attack is recognised, with hashes, people can simply 
stop sending transactions and await a fix, to protect their stash. Without 
hashes, there is no defense at all (other than sending bitcoins to a 
non-taproot address and hoping they evade the attack in time).


On Monday 15 March 2021 23:12:18 Andrew Poelstra wrote:
> "No gain" except to save significant CPU time and bandwidth?

The CPU time is localised to involved nodes, and (correct me if I'm wrong) 
trivial in comparison to what is required to run a full node in the first 
place. I'm not sure how it looks with bandwidth.

> Having exposed keys also lets you do ring signatures over outputs, creating
> the ability to do private proof of funds via Provisions.

But you can also do comparable proofs behind a hash with Bulletproofs, right?

> > Despite this, I still don't think it's a reason to NACK Taproot: it
> > should be fairly trivial to add a hash on top in an additional softfork
> > and fix this.
>
> This would make Bitcoin strictly worse.

How so? People could just not use it if they don't care, right?
The alternative (if people care enough) is that those concerned about quantum 
risk would be forced to forego the benefits of Taproot and stick to p2pkh or 
such, which seems like an artificial punishment.

> > In addition to the points made by Mark, I also want to add two more, in
> > response to Pieter's "you can't claim much security if 37% of the supply
> > is at risk" argument. This argument is based in part on the fact that
> > many people reuse Bitcoin invoice addresses.
>
> 37% is a dramatic understatement. Every address which is derived using
> BIP32 should be assumed compromised to a QC attacker because xpubs are not
> treated like secret key material and are trivial to e.g. extract from
> hardware wallets or PSBTs. I expect the real number is close to 100%.

xpubs should be treated like secret key material IMO.

A quantum attacker would need to compromise your PC to attack a hardware 
wallet, right?

> In any case, Taproot keys, when used according to the recommendation in
> BIP-0341, are already hashes of their internal keys, so (a) Taproot outputs
> actually have better quantum resistance than legacy outputs; and (b) adding
> another hash would be strictly redundant.

It not only stops the attacker from obtaining the original key, but also 
prevents creating a new private key that can spend the output?


On Tuesday 16 March 2021 02:38:55 ZmnSCPxj via bitcoin-dev wrote:
> From this point-of-view, it seems to me that the amount of energy to mount
> a "fast" attack may eventually approach the energy required by mining, in
> which case someone who possesses the ability to mount such an attack may
> very well find it easier to just 51% the network (since that can be done
> today without having to pour R satoshis into developing practical quantum
> computers).

Mining adapts its difficulty to the block rate, so it will slow you down up to 
4x each retarget. An attack on public keys would probably scale better. :)

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

[ZmnSCPxj via bitcoin-dev]

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 and how long
> you can keep them coherent -- but those are both essentially thresholds:
> you can't use two quantum computers that support a lower number of bits
> when you need a higher number, and you can't reuse the state you reached
> after you collapsed halfway through to make the next run shorter.
>
> I think that means having a break take a longer time means maintaining
> the quantum state for longer, which is harder than having it happen
> quicker...
>
> So I think the only way you get it taking substantial amounts of time to
> break a key is if your quantum attack works quickly but very unreliably:
> maybe it takes a minute to reset, and every attempt only has probability
> p of succeeding (ie, random probability of managing to maintain the
> quantum state until completion of the dlog algorithm), so over t minutes
> you end up with probability 1-(1-p)^t of success.
>
> For 50% odds after 1 month with 1 minute per attempt, you'd need a 0.0016%
> chance per attempt, for 50% odds after 1 day, you'd need 0.048% chance per
> attempt. But those odds assume you've only got one QC making the attempts
> -- if you've got 30, you can make a month's worth of attempts in a day;
> if you scale up to 720, you can make a month's worth of attempts in an
> hour, ie once you've got one, it's a fairly straightforward engineering
> challenge at that point.
>
> So a "slow" attack simply doesn't seem likely to me. YMMV, obviously.

What you describe seems to match mining in its behavior: probabilistic, and 
scalable by pushing more electricity into more devices.

>From this point-of-view, it seems to me that the amount of energy to mount a 
>"fast" attack may eventually approach the energy required by mining, in which 
>case someone who possesses the ability to mount such an attack may very well 
>find it easier to just 51% the network (since that can be done today without 
>having to pour R satoshis into developing practical quantum computers).

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot NACK

[ZmnSCPxj via bitcoin-dev]

Good morning JAMES,

> No-one has yet demonstrated that Conjoin or using Wasabi wallet is secure if 
> it relies on third-parties. Are the transaction not forwarded partially 
> signed as with an SPV wallet? So it is possible the SPV server cannot 
> redirect funds if dishonest? SPV wallets are secure producing fully signed 
> transactions. A ConJoin transaction signs for the UTXO and forwards it to be 
> included signed for in another larger transaction with many inputs and outputs

The above point was not answered, so let me answer this for elucidation of you 
and any readers.

A CoinJoin transaction is a single transaction with many inputs and many 
outputs.

Every input must be signed.

When used to obfuscate, each input has different actual entities owning the 
coin.

In order to prevent fraud, it is necessary that what total amount each entity 
puts into the transaction, that entity also gets out (in freshly-generated 
addresses, which I hope you do not object to) as an output.

When providing its signature, each entity verifies that its provided address 
exists in some output first before signing out its input.

The provided signature requires all the inputs and all the outputs to exist in 
the transaction.
Because of this, it is not possible to take a "partial" signature for this 
transaction, then change the transaction to redirect outputs elsewhere --- the 
signature of previous participants become invalid for the modified transaction..

Thus, the security of the CoinJoin cannot be damaged by a third party.

Third parties involved in popular implementations of CoinJoin (such as the 
coordinator in Wasabi) are nothing more than clerical actuaries that take 
signatures of an immutable document, and any attempt by that clerical actuary 
to change the document also destroys any signatures of that document, making 
the modified document (the transaction) invalid.

> . Also, none of those you mention is inherently a Privacy Technology. 
> Transparency is one of the key articles of value in Bitcoin because it 
> prevents fraud.

The prevention of fraud simply requires that all addition is validatable.
It does not require that the actual values involved are visible in cleartext.

Various cryptographic techniques already exist which allow the verifiable 
addition of encrypted values ("homomorphisms").
You can get 1 * G and 2 * G, add the resulting points, and compare it to 3 * G 
and see that you get the same point, yet if you did not know exactly what G was 
used, you would not know that you were checking the addition of 1 + 2 = 3.
That is the basis of a large number of privacy coins.

At the same time, if I wanted to *voluntarily* reveal this 1 + 2 = 3, I could 
reveal the numbers involved and the point G I used, and any validator 
(including, say, a government taxing authority) can check that the points 
recorded on the blockchain match with what I claimed.

For the prevention of fraud, we should strive to be as transparent as *little* 
as possible, while allowing users to *voluntarily* reveal information.


Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

[Anthony Towns via bitcoin-dev]

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 coherent -- but those are both essentially thresholds:
you can't use two quantum computers that support a lower number of bits
when you need a higher number, and you can't reuse the state you reached
after you collapsed halfway through to make the next run shorter.

I think that means having a break take a longer time means maintaining
the quantum state for longer, which is *harder* than having it happen
quicker...

So I think the only way you get it taking substantial amounts of time to
break a key is if your quantum attack works quickly but very unreliably:
maybe it takes a minute to reset, and every attempt only has probability
p of succeeding (ie, random probability of managing to maintain the
quantum state until completion of the dlog algorithm), so over t minutes
you end up with probability 1-(1-p)^t of success.

For 50% odds after 1 month with 1 minute per attempt, you'd need a 0.0016%
chance per attempt, for 50% odds after 1 day, you'd need 0.048% chance per
attempt. But those odds assume you've only got one QC making the attempts
-- if you've got 30, you can make a month's worth of attempts in a day;
if you scale up to 720, you can make a month's worth of attempts in an
hour, ie once you've got one, it's a fairly straightforward engineering
challenge at that point.

So a "slow" attack simply doesn't seem likely to me. YMMV, obviously.

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

[David A. Harding via bitcoin-dev]

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 concern seems to be someone developing, in secret, a quantum
computer with enough capacity to compromise millions of keys and then
deciding to use the most powerful and (probably) expensive computer ever
developed to steal coins that will almost immediately lose most or all
of their value.

That's certainly a threat we should consider, but like other "movie
plot" threats, I think we should weigh its unlikeliness in comparison
to the people who are losing smaller amounts of money on a regular basis
right now because we don't already have taproot---people who don't use
multisig, or contracts with threshold reduction timeout clauses, or
certain types of covenants because the contingencies these types of
scripts protect against come at too great a cost in fees for the typical
case where no contingencies are needed.

We have many ideas about how to mitigate the risk of effective quantum
computing attacks, from emergency protection to long-term solutions, so
it seems to me that the real risk in the movie plot scenario comes
entirely from *secret advances* in quantum computing.  Other similar
risks for Bitcoin exist, such as secret discoveries about how to
compromise the hash functions Bitcoin depends on.  One way to help
control those risks is to pay a public bounty to anyone who provably and
publicly discloses the secret advance (ideally while allowing the leaker
to remain anonymous).  Several years ago, Peter Todd created a series of
Bitcoin addresses that does exactly that.[1]

For example, if you pay 35Snmmy3uhaer2gTboc81ayCip4m9DT4ko, then
anyone[2] who can prove a collision attack against Bitcoin's primary
hash function, SHA256, will be able to claim the bitcoins you and other
people sent to that address.  Their claim of the funds will publicly
demonstrate that someone can create a SHA256 collision, which is an
attack we currently believe to be impractical.  This system was
demonstrated to work about four years ago[3] when the collision bounty
for the much weaker SHA1 function was claimed.[4]

We can already create an output script with a Nothing Up My Sleeve
(NUMS) point that would provide a trustless bounty to anyone proving the
capability to steal any P2PK-style output with secp256k1's 128-bit
security.  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.  E.g.,
NUMS-based ECDSA- or taproot-compatible scripts with a security strength
equivalent to 80, 96, and 112 bit security.

That way the people and businesses concerned about QC advances could
send a few BTC to those addresses to create a QC early warning system
that would allow us to continue confidently working on EC-based
protocols for now but also objectively alert us to when we need to shift
to working on post-QC protocols for the future.

Thank you,

-Dave

[1] https://bitcointalk.org/index.php?topic=293382.0

[2] Anyone claiming the reward may need to mine their own transaction to
protect it against rewriting.  In the worst case, they may need to
mine at a depth of several blocks or share their reward with miners
to prevent sniping reorgs.

[3] 
https://blockstream.info/tx/8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc

[4] To the best of my knowledge, nothing in Bitcoin ever depended
significantly on SHA1, and especially not on SHA1 collision
resistance, which was known to be weak even in 2009 when Nakamoto
first published the Bitcoin software.


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

[Matt Corallo via bitcoin-dev]

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.


Matt

On 3/15/21 19:01, Karl-Johan Alm via bitcoin-dev wrote:

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 here is that, with hashes, an attacker has
to race against the spending transaction confirming, whereas with
naked pubkeys, the attacker doesn't have to wait for a spend to occur,
drastically increasing the available time to attack.

It may initially take months to break a single key. In such a
scenario, anyone with a hashed pubkey would be completely safe* (even
at spend time), until that speeds up significantly, while Super Secure
Exchange X with an ultra-cold 38-of-38 multisig setup using Taproot
would have a timer ticking, since the attacker need only find a single
privkey like with any old P2PK output.

(* assuming no address reuse)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

[Andrew Poelstra via bitcoin-dev]

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 as well.
> It would use significantly more CPU time and bandwidth (between private 
> parties, not on-chain), but there should be no shortage of that for anyone 
> running a full node (indeed, CPU time is freed up by Taproot!); at worst, it 
> would create an incentive for more people to use their own full node, which 
> is a good thing!
> 

"No gain" except to save significant CPU time and bandwidth? As Matt points
out there is also a storage hit (unless you want to _really_ waste CPU time
by using pubkey recovery, eliminating any hope of batch validation while
introducing a new dependency on an algorithm with a very unclear patent
story).

Having exposed keys also lets you do ring signatures over outputs, creating the
ability to do private proof of funds via Provisions.

> Despite this, I still don't think it's a reason to NACK Taproot: it should be 
> fairly trivial to add a hash on top in an additional softfork and fix this.
> 

This would make Bitcoin strictly worse.

> In addition to the points made by Mark, I also want to add two more, in 
> response to Pieter's "you can't claim much security if 37% of the supply is 
> at risk" argument. This argument is based in part on the fact that many 
> people reuse Bitcoin invoice addresses.
> 

37% is a dramatic understatement. Every address which is derived using BIP32
should be assumed compromised to a QC attacker because xpubs are not treated
like secret key material and are trivial to e.g. extract from hardware wallets
or PSBTs. I expect the real number is close to 100%.


In any case, Taproot keys, when used according to the recommendation in
BIP-0341, are already hashes of their internal keys, so (a) Taproot outputs
actually have better quantum resistance than legacy outputs; and (b) adding
another hash would be strictly redundant.

-- 
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
-Justin Lewis-Webster



signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

[Karl-Johan Alm via bitcoin-dev]

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 here is that, with hashes, an attacker has
to race against the spending transaction confirming, whereas with
naked pubkeys, the attacker doesn't have to wait for a spend to occur,
drastically increasing the available time to attack.

It may initially take months to break a single key. In such a
scenario, anyone with a hashed pubkey would be completely safe* (even
at spend time), until that speeds up significantly, while Super Secure
Exchange X with an ultra-cold 38-of-38 multisig setup using Taproot
would have a timer ticking, since the attacker need only find a single
privkey like with any old P2PK output.

(* assuming no address reuse)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

[Matt Corallo via bitcoin-dev]

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 script_pubkey.


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.


Matt

On 3/15/21 18:40, Jeremy wrote:

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 have to check the signature after doing that).


Therefore there is no storage benefit.

For the script path case, you might have to pay a little bit extra though as you'd have to reveal P I think? But perhaps 
that can be avoided another way...

--
@JeremyRubin 


On Mon, Mar 15, 2021 at 3:06 PM Matt Corallo via bitcoin-dev > 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 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.

Note that this is most definitely *not* news to this list, eg, Anthony brought 
it up in "Schnorr and taproot (etc)
upgrade" and there was a whole thread on it in "Taproot: Privacy preserving 
switchable scripting". This issue has been
beaten to death, I'm not sure why we need to keep hitting the poor horse 
corpse.

 >
 > In short, Taproot loses an important safety protection against quantum.
 > Note that in all circumstances, Bitcoin is endangered when QC becomes a
 > reality, but pre-Taproot, it is possible for the network to "pause" 
while a
 > full quantum-safe fix is developed, and then resume transacting. With 
Taproot
 > as-is, it could very well become an unrecoverable situation if QC go 
online
 > prior to having a full quantum-safe solution.

This has been discussed ad nauseam, and it all seems to fall apart once its 
noted just how much Bitcoin could be stolen
by any QC-wielding attacker due to address reuse. Ultimately, no "pause" 
can solve this issue, and, if we learned about
a QC attacker overnight (instead of slowly over time), there isn't anything 
that a non-Taproot Bitcoin could do that a
Taproot Bitcoin couldn't.

 > 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 as well.
 > It would use significantly more CPU time and bandwidth (between private
 > parties, not on-chain), but there should be no shortage of that for 
anyone
 > running a full node (indeed, CPU time is freed up by Taproot!); at 
worst, it
 > would create an incentive for more people to use their own full node, 
which
 > is a good thing!

This is untrue. The storage space required for Taproot transactions is 
materially reduced by avoiding the hash
indirection.

 > Despite this, I still don't think it's a reason to NACK Taproot: it 
should be
 > fairly trivial to add a hash on top in an additional softfork and fix 
this.

For the reason stated above, i think such a fork is unlikely.

 > In addition to the points made by Mark, I also want to add two more, in
 > response to Pieter's "you can't claim much security if 37% of the supply 
is
 > at risk" argument. This argument is based in part on the fact that many
 > people reuse Bitcoin invoice addresses.
 >
 > 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.
Worse, there's a lot of old coins that are unlikely to move any time soon 
that are exposed whether we like it or not.

 > Second, when/if quantum does compromise these coins, so long as they are
 > neglected or abandoned/lost coins (inherent in the current model), it 
can be
 > seen as equivalent to Bitcoin mining. 

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

[Jeremy via bitcoin-dev]

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 have to check the signature after
doing that).

Therefore there is no storage benefit.

For the script path case, you might have to pay a little bit extra though
as you'd have to reveal P I think? But perhaps that can be avoided another
way...
--
@JeremyRubin 



On Mon, Mar 15, 2021 at 3:06 PM 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 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.
>
> Note that this is most definitely *not* news to this list, eg, Anthony
> brought it up in "Schnorr and taproot (etc)
> upgrade" and there was a whole thread on it in "Taproot: Privacy
> preserving switchable scripting". This issue has been
> beaten to death, I'm not sure why we need to keep hitting the poor horse
> corpse.
>
> >
> > In short, Taproot loses an important safety protection against quantum.
> > Note that in all circumstances, Bitcoin is endangered when QC becomes a
> > reality, but pre-Taproot, it is possible for the network to "pause"
> while a
> > full quantum-safe fix is developed, and then resume transacting. With
> Taproot
> > as-is, it could very well become an unrecoverable situation if QC go
> online
> > prior to having a full quantum-safe solution.
>
> This has been discussed ad nauseam, and it all seems to fall apart once
> its noted just how much Bitcoin could be stolen
> by any QC-wielding attacker due to address reuse. Ultimately, no "pause"
> can solve this issue, and, if we learned about
> a QC attacker overnight (instead of slowly over time), there isn't
> anything that a non-Taproot Bitcoin could do that a
> Taproot Bitcoin couldn't.
>
> > 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 as well.
> > It would use significantly more CPU time and bandwidth (between private
> > parties, not on-chain), but there should be no shortage of that for
> anyone
> > running a full node (indeed, CPU time is freed up by Taproot!); at
> worst, it
> > would create an incentive for more people to use their own full node,
> which
> > is a good thing!
>
> This is untrue. The storage space required for Taproot transactions is
> materially reduced by avoiding the hash indirection.
>
> > Despite this, I still don't think it's a reason to NACK Taproot: it
> should be
> > fairly trivial to add a hash on top in an additional softfork and fix
> this.
>
> For the reason stated above, i think such a fork is unlikely.
>
> > In addition to the points made by Mark, I also want to add two more, in
> > response to Pieter's "you can't claim much security if 37% of the supply
> is
> > at risk" argument. This argument is based in part on the fact that many
> > people reuse Bitcoin invoice addresses.
> >
> > 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.
> Worse, there's a lot of old coins that are unlikely to move any time soon
> that are exposed whether we like it or not.
>
> > Second, when/if quantum does compromise these coins, so long as they are
> > neglected or abandoned/lost coins (inherent in the current model), it
> can be
> > seen as equivalent to Bitcoin mining. At the end of the day, 37% of
> supply
> > minable by QCs is really no different than 37% minable by ASICs. (We've
> seen
> > far higher %s available for mining obviously.)
>
> 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.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

[Matt Corallo via bitcoin-dev]

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 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.


Note that this is most definitely *not* news to this list, eg, Anthony brought it up in "Schnorr and taproot (etc) 
upgrade" and there was a whole thread on it in "Taproot: Privacy preserving switchable scripting". This issue has been 
beaten to death, I'm not sure why we need to keep hitting the poor horse corpse.




In short, Taproot loses an important safety protection against quantum.
Note that in all circumstances, Bitcoin is endangered when QC becomes a
reality, but pre-Taproot, it is possible for the network to "pause" while a
full quantum-safe fix is developed, and then resume transacting. With Taproot
as-is, it could very well become an unrecoverable situation if QC go online
prior to having a full quantum-safe solution.


This has been discussed ad nauseam, and it all seems to fall apart once its noted just how much Bitcoin could be stolen 
by any QC-wielding attacker due to address reuse. Ultimately, no "pause" can solve this issue, and, if we learned about 
a QC attacker overnight (instead of slowly over time), there isn't anything that a non-Taproot Bitcoin could do that a 
Taproot Bitcoin couldn't.



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 as well.
It would use significantly more CPU time and bandwidth (between private
parties, not on-chain), but there should be no shortage of that for anyone
running a full node (indeed, CPU time is freed up by Taproot!); at worst, it
would create an incentive for more people to use their own full node, which
is a good thing!


This is untrue. The storage space required for Taproot transactions is 
materially reduced by avoiding the hash indirection.


Despite this, I still don't think it's a reason to NACK Taproot: it should be
fairly trivial to add a hash on top in an additional softfork and fix this.


For the reason stated above, i think such a fork is unlikely.


In addition to the points made by Mark, I also want to add two more, in
response to Pieter's "you can't claim much security if 37% of the supply is
at risk" argument. This argument is based in part on the fact that many
people reuse Bitcoin invoice addresses.

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. 
Worse, there's a lot of old coins that are unlikely to move any time soon that are exposed whether we like it or not.



Second, when/if quantum does compromise these coins, so long as they are
neglected or abandoned/lost coins (inherent in the current model), it can be
seen as equivalent to Bitcoin mining. At the end of the day, 37% of supply
minable by QCs is really no different than 37% minable by ASICs. (We've seen
far higher %s available for mining obviously.)


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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] PSA: Taproot loss of quantum protections

[Luke Dashjr via bitcoin-dev]

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 his blog:
https://freicoin.substack.com/p/why-im-against-taproot

In short, Taproot loses an important safety protection against quantum.
Note that in all circumstances, Bitcoin is endangered when QC becomes a 
reality, but pre-Taproot, it is possible for the network to "pause" while a 
full quantum-safe fix is developed, and then resume transacting. With Taproot 
as-is, it could very well become an unrecoverable situation if QC go online 
prior to having a full quantum-safe solution.

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 as well.
It would use significantly more CPU time and bandwidth (between private 
parties, not on-chain), but there should be no shortage of that for anyone 
running a full node (indeed, CPU time is freed up by Taproot!); at worst, it 
would create an incentive for more people to use their own full node, which 
is a good thing!

Despite this, I still don't think it's a reason to NACK Taproot: it should be 
fairly trivial to add a hash on top in an additional softfork and fix this.

In addition to the points made by Mark, I also want to add two more, in 
response to Pieter's "you can't claim much security if 37% of the supply is 
at risk" argument. This argument is based in part on the fact that many 
people reuse Bitcoin invoice addresses.

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.

Second, when/if quantum does compromise these coins, so long as they are 
neglected or abandoned/lost coins (inherent in the current model), it can be 
seen as equivalent to Bitcoin mining. At the end of the day, 37% of supply 
minable by QCs is really no different than 37% minable by ASICs. (We've seen 
far higher %s available for mining obviously.)

To conclude, I recommend anyone using Bitcoin to read Mark's article, my 
thoughts, and any other arguments on the topic; decide if this is a concern 
to you, and make your own post(s) accordingly. Mark has conceded the argument 
(AFAIK he doesn't have an interest in bitcoins anyway), and I do not consider 
it a showstopper - so if anyone else out there does, please make yourself 
known ASAP since Taproot has already moved on to the activation phase and it 
is likely software will be released within the next month or two as things 
stand.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

[Luke Dashjr via bitcoin-dev]

I am referring to the timeline and recommendation from the meeting on February 
16th, which has been slowly making progress toward a release:

https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102

The first period from height 693504-695520 here overlaps with the last period 
of AChow's ST pull request.

A release today is impossible of course. But 1 or 2 days late is nothing 
compared to waiting a week and not having even gotten started. :)
I expect/hope that there will be consensus to adapt around ST, shifting 
everything later, but I'm just one person.

roconnor pointed out that the best solution is probably to just enclose ST's 
timeline; something like this:

https://github.com/BitcoinActivation/BitcoinTaproot.org/pull/3/files#diff-e43ac101b32b6804209cfdf26da4d122e54b994eb7f1538d4378f6a508dab817L529

Luke



On Monday 15 March 2021 20:59:11 Jeremy wrote:
> Can you expand on the timeline issue? Which timelines are incompatible and
> why?
>
> It does seem like a release done *today* cannot happen anyways, so it
> sounds like it's already too late... or do you mean beginning the release
> process today?
> --
> @JeremyRubin 
> 
>
> On Mon, Mar 15, 2021 at 12:38 PM Luke Dashjr  wrote:
> > While I agree 24 hours is too short notice, if someone wishes to insist
> > on keeping the current timeline, software supporting it should be
> > released _today_. Putting the meeting off a week would almost necessarily
> > imply rejection of any desires to stick to the original plan.
> >
> > So for that reason, I think we need to at least try to have a meeting
> > tomorrow, at least to give anyone who won't agree to such a delay a
> > chance to
> > speak up before it's too late, and have his argument fairly considered.
> >
> > We can still have a meeting next week. The idea of having one every other
> > week
> > seems like a good idea to avoid this in the future, too.
> >
> > Luke
> >
> > On Monday 15 March 2021 19:14:02 Jeremy wrote:
> > > Please announce such meetings with more than ~24 hours notice -- this
> > > has happened several times and while I recognize the pace of
> > > development on this issue I think that slotting a consensus meeting
> > > with less than 24 hours is inappropriate.
> > >
> > > I think we should proactively postpone it a week so that there isn't an
> > > arbitrary "too low turnout" measure and instead anyone who really wants
> >
> > to
> >
> > > be present for the meeting can plan to be.
> > >
> > > So as not to lose momentum on having a discussion, I propose to plan to
> > > hold a general discussion tomorrow at that time and a meeting (with the
> > > intent of resolving issues in a more binding way) next week. It may be
> > > a good idea to hold the time slot every other week for the next while
> > > so
> >
> > that
> >
> > > we can avoid this 24 hour thing altogether.
> > >
> > > It sucks to lose another week but a precedent of 24 hour notice
> > > meetings for non urgent changes is very negative.
> > >
> > > (This isn't any comment on if ST is OK or not -- the schedules proposed
> >
> > for
> >
> > > ST thus far seem acceptable to me)
> > >
> > > Best,
> > >
> > > Jeremy
> > > --
> > > @JeremyRubin 
> > > 
> > >
> > >
> > > On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev <
> > >
> > > bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > > At the previous meeting, there was consensus for BIP8 activation
> > > > parameters
> > > > except for LOT, assuming a release around this time. Since then, a
> > > > release has not occurred, and the new idea of Speedy Trial has been
> > > > proposed to preempt the original/main activation plan.
> > > >
> > > > It's probably a good idea to meet up again to discuss these things
> > > > and adjust
> > > > accordingly.
> > > >
> > > > Agenda:
> > > >
> > > > - Speedy Trial: Can we get a comparable consensus on the proposal?
> > > >   (Note: current draft conflicts with original plan timeline)
> > > >
> > > > - Main activation, post ST: Moving startheight (and timeoutheight?)
> >
> > later
> >
> > > >   is probably a good idea at this point, both because too little
> >
> > progress
> >
> > > > has
> > > >   been made on it, and to avoid the conflict with the current ST
> > > > draft.
> > > >
> > > > - Making progress: To date, too few people have been involved in
> > > > materialising
> > > >   the main activation plan. If it's going to move forward, more
> > > > people need to
> > > >   get actively involved. This should not wait for ST to complete,
> >
> > unless
> >
> > > > we want another 4-5 month slip of the timeline.
> > > >
> > > > This meeting is tentatively scheduled for *tomorrow*, March 16th at
> > > > the usual
> > > > time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If
> > > > turnout
> > > > is too low, we can postpone it a week, but it'd be nice to get things
> > > > 

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

[Jeremy via bitcoin-dev]

Can you expand on the timeline issue? Which timelines are incompatible and
why?

It does seem like a release done *today* cannot happen anyways, so it
sounds like it's already too late... or do you mean beginning the release
process today?
--
@JeremyRubin 



On Mon, Mar 15, 2021 at 12:38 PM Luke Dashjr  wrote:

> While I agree 24 hours is too short notice, if someone wishes to insist on
> keeping the current timeline, software supporting it should be released
> _today_. Putting the meeting off a week would almost necessarily imply
> rejection of any desires to stick to the original plan.
>
> So for that reason, I think we need to at least try to have a meeting
> tomorrow, at least to give anyone who won't agree to such a delay a chance
> to
> speak up before it's too late, and have his argument fairly considered.
>
> We can still have a meeting next week. The idea of having one every other
> week
> seems like a good idea to avoid this in the future, too.
>
> Luke
>
>
> On Monday 15 March 2021 19:14:02 Jeremy wrote:
> > Please announce such meetings with more than ~24 hours notice -- this has
> > happened several times and while I recognize the pace of development on
> > this issue I think that slotting a consensus meeting with less than 24
> > hours is inappropriate.
> >
> > I think we should proactively postpone it a week so that there isn't an
> > arbitrary "too low turnout" measure and instead anyone who really wants
> to
> > be present for the meeting can plan to be.
> >
> > So as not to lose momentum on having a discussion, I propose to plan to
> > hold a general discussion tomorrow at that time and a meeting (with the
> > intent of resolving issues in a more binding way) next week. It may be a
> > good idea to hold the time slot every other week for the next while so
> that
> > we can avoid this 24 hour thing altogether.
> >
> > It sucks to lose another week but a precedent of 24 hour notice meetings
> > for non urgent changes is very negative.
> >
> > (This isn't any comment on if ST is OK or not -- the schedules proposed
> for
> > ST thus far seem acceptable to me)
> >
> > Best,
> >
> > Jeremy
> > --
> > @JeremyRubin 
> > 
> >
> >
> > On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev <
> >
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > At the previous meeting, there was consensus for BIP8 activation
> > > parameters
> > > except for LOT, assuming a release around this time. Since then, a
> > > release has not occurred, and the new idea of Speedy Trial has been
> > > proposed to preempt the original/main activation plan.
> > >
> > > It's probably a good idea to meet up again to discuss these things and
> > > adjust
> > > accordingly.
> > >
> > > Agenda:
> > >
> > > - Speedy Trial: Can we get a comparable consensus on the proposal?
> > >   (Note: current draft conflicts with original plan timeline)
> > >
> > > - Main activation, post ST: Moving startheight (and timeoutheight?)
> later
> > >   is probably a good idea at this point, both because too little
> progress
> > > has
> > >   been made on it, and to avoid the conflict with the current ST draft.
> > >
> > > - Making progress: To date, too few people have been involved in
> > > materialising
> > >   the main activation plan. If it's going to move forward, more people
> > > need to
> > >   get actively involved. This should not wait for ST to complete,
> unless
> > > we want another 4-5 month slip of the timeline.
> > >
> > > This meeting is tentatively scheduled for *tomorrow*, March 16th at the
> > > usual
> > > time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If
> > > turnout
> > > is too low, we can postpone it a week, but it'd be nice to get things
> > > resolved and moving sooner.
> > >
> > > As a reminder, the channel is also open for ongoing discussion 24/7,
> and
> > > there
> > > is a web chat client here:
> > >
> > > https://webchat.freenode.net/?channel=##taproot-activation
> > >
> > > Luke
> > > ___
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

[Luke Dashjr via bitcoin-dev]

While I agree 24 hours is too short notice, if someone wishes to insist on 
keeping the current timeline, software supporting it should be released 
_today_. Putting the meeting off a week would almost necessarily imply 
rejection of any desires to stick to the original plan.

So for that reason, I think we need to at least try to have a meeting 
tomorrow, at least to give anyone who won't agree to such a delay a chance to 
speak up before it's too late, and have his argument fairly considered.

We can still have a meeting next week. The idea of having one every other week 
seems like a good idea to avoid this in the future, too.

Luke


On Monday 15 March 2021 19:14:02 Jeremy wrote:
> Please announce such meetings with more than ~24 hours notice -- this has
> happened several times and while I recognize the pace of development on
> this issue I think that slotting a consensus meeting with less than 24
> hours is inappropriate.
>
> I think we should proactively postpone it a week so that there isn't an
> arbitrary "too low turnout" measure and instead anyone who really wants to
> be present for the meeting can plan to be.
>
> So as not to lose momentum on having a discussion, I propose to plan to
> hold a general discussion tomorrow at that time and a meeting (with the
> intent of resolving issues in a more binding way) next week. It may be a
> good idea to hold the time slot every other week for the next while so that
> we can avoid this 24 hour thing altogether.
>
> It sucks to lose another week but a precedent of 24 hour notice meetings
> for non urgent changes is very negative.
>
> (This isn't any comment on if ST is OK or not -- the schedules proposed for
> ST thus far seem acceptable to me)
>
> Best,
>
> Jeremy
> --
> @JeremyRubin 
> 
>
>
> On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev <
>
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > At the previous meeting, there was consensus for BIP8 activation
> > parameters
> > except for LOT, assuming a release around this time. Since then, a
> > release has not occurred, and the new idea of Speedy Trial has been
> > proposed to preempt the original/main activation plan.
> >
> > It's probably a good idea to meet up again to discuss these things and
> > adjust
> > accordingly.
> >
> > Agenda:
> >
> > - Speedy Trial: Can we get a comparable consensus on the proposal?
> >   (Note: current draft conflicts with original plan timeline)
> >
> > - Main activation, post ST: Moving startheight (and timeoutheight?) later
> >   is probably a good idea at this point, both because too little progress
> > has
> >   been made on it, and to avoid the conflict with the current ST draft.
> >
> > - Making progress: To date, too few people have been involved in
> > materialising
> >   the main activation plan. If it's going to move forward, more people
> > need to
> >   get actively involved. This should not wait for ST to complete, unless
> > we want another 4-5 month slip of the timeline.
> >
> > This meeting is tentatively scheduled for *tomorrow*, March 16th at the
> > usual
> > time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If
> > turnout
> > is too low, we can postpone it a week, but it'd be nice to get things
> > resolved and moving sooner.
> >
> > As a reminder, the channel is also open for ongoing discussion 24/7, and
> > there
> > is a web chat client here:
> >
> > https://webchat.freenode.net/?channel=##taproot-activation
> >
> > Luke
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

[Jeremy via bitcoin-dev]

Please announce such meetings with more than ~24 hours notice -- this has
happened several times and while I recognize the pace of development on
this issue I think that slotting a consensus meeting with less than 24
hours is inappropriate.

I think we should proactively postpone it a week so that there isn't an
arbitrary "too low turnout" measure and instead anyone who really wants to
be present for the meeting can plan to be.

So as not to lose momentum on having a discussion, I propose to plan to
hold a general discussion tomorrow at that time and a meeting (with the
intent of resolving issues in a more binding way) next week. It may be a
good idea to hold the time slot every other week for the next while so that
we can avoid this 24 hour thing altogether.

It sucks to lose another week but a precedent of 24 hour notice meetings
for non urgent changes is very negative.

(This isn't any comment on if ST is OK or not -- the schedules proposed for
ST thus far seem acceptable to me)

Best,

Jeremy
--
@JeremyRubin 



On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> At the previous meeting, there was consensus for BIP8 activation
> parameters
> except for LOT, assuming a release around this time. Since then, a release
> has not occurred, and the new idea of Speedy Trial has been proposed to
> preempt the original/main activation plan.
>
> It's probably a good idea to meet up again to discuss these things and
> adjust
> accordingly.
>
> Agenda:
>
> - Speedy Trial: Can we get a comparable consensus on the proposal?
>   (Note: current draft conflicts with original plan timeline)
>
> - Main activation, post ST: Moving startheight (and timeoutheight?) later
>   is probably a good idea at this point, both because too little progress
> has
>   been made on it, and to avoid the conflict with the current ST draft.
>
> - Making progress: To date, too few people have been involved in
> materialising
>   the main activation plan. If it's going to move forward, more people
> need to
>   get actively involved. This should not wait for ST to complete, unless we
>   want another 4-5 month slip of the timeline.
>
> This meeting is tentatively scheduled for *tomorrow*, March 16th at the
> usual
> time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If
> turnout
> is too low, we can postpone it a week, but it'd be nice to get things
> resolved and moving sooner.
>
> As a reminder, the channel is also open for ongoing discussion 24/7, and
> there
> is a web chat client here:
>
> https://webchat.freenode.net/?channel=##taproot-activation
>
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

[Luke Dashjr via bitcoin-dev]

At the previous meeting, there was consensus for BIP8 activation parameters 
except for LOT, assuming a release around this time. Since then, a release 
has not occurred, and the new idea of Speedy Trial has been proposed to 
preempt the original/main activation plan.

It's probably a good idea to meet up again to discuss these things and adjust 
accordingly.

Agenda:

- Speedy Trial: Can we get a comparable consensus on the proposal?
  (Note: current draft conflicts with original plan timeline)

- Main activation, post ST: Moving startheight (and timeoutheight?) later
  is probably a good idea at this point, both because too little progress has
  been made on it, and to avoid the conflict with the current ST draft.

- Making progress: To date, too few people have been involved in materialising
  the main activation plan. If it's going to move forward, more people need to
  get actively involved. This should not wait for ST to complete, unless we
  want another 4-5 month slip of the timeline.

This meeting is tentatively scheduled for *tomorrow*, March 16th at the usual 
time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If turnout 
is too low, we can postpone it a week, but it'd be nice to get things 
resolved and moving sooner.

As a reminder, the channel is also open for ongoing discussion 24/7, and there 
is a web chat client here:

https://webchat.freenode.net/?channel=##taproot-activation

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev