[bitcoin-dev] Proposal: Scheduled Activation with Potential Miner-Signaled Delay

[Efaula Prafbodous via bitcoin-dev]

Hello Bitcoin Protocol Discussion Mailing List,

The binary presented by "Lock on Timeout" or LOT; is inherently divisive.  
Hence, after taking some time to meditate; please consider the following as an 
overview, and a possible solution:

---

The lingering bad-taste from the drama surrounding the activation of SegWit 
(Using, BIP9, BIP91, and BIP148) lead to the development of the very reasonable 
activation protocol: BIP8.

The BIP8 protocol includes an optional feature, called "Lock on Timeout", that 
is essentially a technically improved version of the flag-day activation 
proposed in BIP148.

Many in the Bitcoin Community find the use of blind flag-day activations 
needlessly divisive and dangerous. In particular:

# A flag-day activation imposes itself on the network, without consideration of 
the deployment concerns that the miners may have when implementing the network 
upgrade on their unique infrastructure; and risks decreasing the good-will 
between users and miners.

# A flag-day activation proceeds, even if, before activation, a critical bug in 
the design is found in the process of doing the miner software upgrades. There 
is no back-out path for the community and miners alike.

# A flag-day activation can have wide-reaching damaging effects if activated 
with only a small amount of the miners in active support.

Others in the Bitcoin Community, however do not find these concerns weighty 
enough to override the certainty and reliability that a flag-day activation 
provides. Hence, this binary-option of using a flag-day activation, or not, is 
always going to be divisive for the community.

---

The activation procedure for new consensus rules should be empowering for both 
the users and the miners alike. It should respect the reality that the proposed 
network upgrade (Taproot: BIP340, 341, and 342) has already completed its 
consensus building process within the Bitcoin Community.

This proposal decides against using a blind flag-day activation; instead it 
uses a more nuanced approach. It allows a majority of the miners to block 
deployment (if they maintain consensus to postpone the deployment for at least 
half of the activation period) and it also allows a minority of the miners to 
temporarily delay the deployment.

Signaling "readiness" for a consensus change has been confused with implying 
political support of this change. This proposal addresses this confusion by 
inverting the meaning of the "Version Bit". Now miners will signal they are 
"not-ready", instead of the previously used behavior of signaling when they are 
"ready".

After a lengthy pre-starting period of 6 months, an upgrade may be further 
delayed, or be postponed by miners signaling. In the default case, where the 
vast majority of the miners have successfully upgraded within the pre-starting 
period, the first 2016 block period will lock-in the upgrade without any delay 
or postponement.

This is far more accurately resolving the primary worry of both the Bitcoin 
users and Bitcoin miners, that is to allow an upgrade to proceed too-quickly 
while some lag behind with difficulties. Miners who are having difficulties can 
explicitly notify the community through signaling their lack of readiness, and 
thus triggering a delay, or entirely postponing the deployment.

---

Please find following a rough, and incomplete, draft of the proposal written in 
BIP form. If the community finds this approach conceptually sound, this BIP 
will be completed to a high-standard and hopefully be considered to be used for 
the activation of Taproot.


Lovely Regards,
Efaula.



  BIP: scheduled-activation-delay
  Title: Scheduled Activation with Potential Miner-Signaled Delay
  Author: Efaula Prafbodous
  Created: 2021-02-26
  License: BSD-3-Clause
   CC0-1.0

==Abstract==

This document specifies an alternative to [[bip-0008.mediawiki|BIP8]], where 
the signalling intention is inverted, and the activation may be delayed a 
limited number of times, or postponed (and ultimately fail deployment).

Unlike previous proposals, where miners signaled that they are '''ready''' for 
the consensus change.  This proposal has miners signal that they are 
'''not-ready''', and proceeds with the upgrade in the default case.

The core assumption within this proposal is that it is far easier and faster 
for a miner to adjust the signaling within the blocks they produce, than to 
certify and validate new software that enforces advanced new consensus rules.  
Hence, miners will quickly signal they are '''not-ready''', and once upgraded; 
they will remove this signal; allowing the upgrade to proceed.

The authors of this proposal suggest this is more appropriate, as it directly 
focuses on the core issue: allowing miners to delay the activation of new 
consensus rules until they have solved their technological and validation 
issues.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
"SHOULD NOT", "RECOMMENDED", "MAY", 

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Eric Voskuil via bitcoin-dev]

I think it has been shown that an understanding of reasonableness is not 
universal, making any assertion about it as a collective goal kind of 
self-defeating. The question is what is achievable, not what is reasonable. I’m 
not making any value judgements here. Simply pointing out that anything other 
than a successful 51% attack will create a split.

e

> On Feb 28, 2021, at 12:25, Matt Corallo  wrote:
> 
> Glad you asked! Yes, your goal here is #4 on the list of goals I laid out at 
> [1], which I referenced and specifically addressed each of in the OP of this 
> thread.
> 
> [1] 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
> 
>> On 2/28/21 15:19, Eric Voskuil wrote:
>> In the attempt to change consensus rules there is a simple set of choices:
>> 1) hard fork: creates a chain split
>> 2) soft fork: creates a chain split
>> 3) 51% attack: does not create a chain split
>> The presumption being that one can never assume 100% explicit adoption of 
>> any rule change.
>> A 51% attack can of course fail. It is also possible that signaling can be 
>> untruthful. But miner signaling provides some level of assurance that it 
>> will be successful. This level of assurance is increased by adoption of a 
>> higher than majority threshold, as has been done in the past.
>> Most of the discussion I’ve seen has been focused on who is in charge. 
>> Bitcoin requires no identity; anyone can mine and/or accept bitcoin - nobody 
>> is in charge.
>> The majority of those who mine can choose to enforce censorship any time 
>> they want. They don’t need anyone’s permission. No power is given to them by 
>> developers or anyone else. They have that power based on their own capital 
>> invested.
>> Similarly, the economy (those who accept bitcoin) can enforce any rule 
>> change it wants to. And it can do so at any level of participation that 
>> wants to go along. Anyone can do this, it requires nobody’s permission. 
>> Furthermore, it is possible for the economy to signal its level of agreement 
>> in every transaction, as miners have done in blocks previously.
>> But if the objective is to produce a rule change while avoiding a chain 
>> split, 50% is a much lower bar than 100%. If there is some other objective, 
>> it’s not clear to me what it is.
>> e
 On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev 
  wrote:
>>> 
>>> 
>>> Miners still can generate invalid blocks as a result of SPV mining, and it 
>>> could be profitable to do "bad block enhanced selfish mining" to take 
>>> advantage of it.
>>> 
>>> 
>>> Hard to analyze exactly what that looks like, but...
>>> 
>>> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate 
>>> to mine bad blocks would mean 1/4th of the time you could make 20% of the 
>>> hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One 
>>> could analyze out that the lost hash rate for bad blocks only matters for 
>>> the first difficulty adjustment period you're doing this for too, as the 
>>> hashrate drop will be accounted for -- but then a miner can switch back to 
>>> mining valid chain, giving themselves a larger % of hashrate.
>>> 
>>> So it is still possible that an un-upgraded miner will fail part 3, and 
>>> attempting to accommodate un-upgraded miners leads to some nasty 
>>> oscillating hashrate being optimal.
>>> 
>>> 
>>> --
>>> @JeremyRubin 
>>> 
>>> 
>>> 
 On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo >>> > wrote:
>>> 
>>>Note further that mandatory signaling isn't "just" a flag day - unlike a 
>>> Taproot flag day (where miners running
>>>Bitcoin
>>>Core unmodified today will not generate invalid blocks), a mandatory 
>>> signaling flag day blatantly ignores goal (3)
>>>from
>>>my original post - it results in any miner who has not taken active 
>>> action (and ensured every part of their
>>>often-large
>>>infrastructure has been correctly reconfigured) generating invalid 
>>> blocks.
>>> 
>>>As for "Taproot" took too long, hey, at least if its locked in people 
>>> can just build things assuming it exists. Some
>>>already are, but once its clearly locked in, there's no reason to not 
>>> continue other work at the same time.
>>> 
>>>Matt
>>> 
On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
>>>> I agree with much of the logic presented by Matt here.
>>>>
>>>> BIP8 was intended to be simpler to agree on to maintain consensus, yet 
>>> we find ourselves in a situation where a
>>>"tiny"
>>>> parameter has the potential to cause great network disruption and 
>>> confusion (rationality is not too useful a
>>>concept
>>>> here given differing levels of sophistication and information). It is 
>>> therefore much simpler and more likely to be
>>>> universally understood by all network participants to just have a flag 
>>> day. 

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Eric Voskuil via bitcoin-dev]

In the attempt to change consensus rules there is a simple set of choices:

1) hard fork: creates a chain split
2) soft fork: creates a chain split
3) 51% attack: does not create a chain split

The presumption being that one can never assume 100% explicit adoption of any 
rule change.

A 51% attack can of course fail. It is also possible that signaling can be 
untruthful. But miner signaling provides some level of assurance that it will 
be successful. This level of assurance is increased by adoption of a higher 
than majority threshold, as has been done in the past.

Most of the discussion I’ve seen has been focused on who is in charge. Bitcoin 
requires no identity; anyone can mine and/or accept bitcoin - nobody is in 
charge.

The majority of those who mine can choose to enforce censorship any time they 
want. They don’t need anyone’s permission. No power is given to them by 
developers or anyone else. They have that power based on their own capital 
invested.

Similarly, the economy (those who accept bitcoin) can enforce any rule change 
it wants to. And it can do so at any level of participation that wants to go 
along. Anyone can do this, it requires nobody’s permission. Furthermore, it is 
possible for the economy to signal its level of agreement in every transaction, 
as miners have done in blocks previously.

But if the objective is to produce a rule change while avoiding a chain split, 
50% is a much lower bar than 100%. If there is some other objective, it’s not 
clear to me what it is.

e

> On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev 
>  wrote:
> 
> 
> Miners still can generate invalid blocks as a result of SPV mining, and it 
> could be profitable to do "bad block enhanced selfish mining" to take 
> advantage of it.
> 
> 
> Hard to analyze exactly what that looks like, but...
> 
> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to 
> mine bad blocks would mean 1/4th of the time you could make 20% of the 
> hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One 
> could analyze out that the lost hash rate for bad blocks only matters for the 
> first difficulty adjustment period you're doing this for too, as the hashrate 
> drop will be accounted for -- but then a miner can switch back to mining 
> valid chain, giving themselves a larger % of hashrate.
> 
> So it is still possible that an un-upgraded miner will fail part 3, and 
> attempting to accommodate un-upgraded miners leads to some nasty oscillating 
> hashrate being optimal.
> 
> 
> --
> @JeremyRubin
> 
> 
>> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo  
>> wrote:
>> Note further that mandatory signaling isn't "just" a flag day - unlike a 
>> Taproot flag day (where miners running Bitcoin 
>> Core unmodified today will not generate invalid blocks), a mandatory 
>> signaling flag day blatantly ignores goal (3) from 
>> my original post - it results in any miner who has not taken active action 
>> (and ensured every part of their often-large 
>> infrastructure has been correctly reconfigured) generating invalid blocks.
>> 
>> As for "Taproot" took too long, hey, at least if its locked in people can 
>> just build things assuming it exists. Some 
>> already are, but once its clearly locked in, there's no reason to not 
>> continue other work at the same time.
>> 
>> Matt
>> 
>> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
>> > I agree with much of the logic presented by Matt here.
>> > 
>> > BIP8 was intended to be simpler to agree on to maintain consensus, yet we 
>> > find ourselves in a situation where a "tiny" 
>> > parameter has the potential to cause great network disruption and 
>> > confusion (rationality is not too useful a concept 
>> > here given differing levels of sophistication and information). It is 
>> > therefore much simpler and more likely to be 
>> > universally understood by all network participants to just have a flag 
>> > day. It is easier to communicate what users 
>> > should do and when.
>> > 
>> > This is ultimately not coercive to users because the upgrade for Taproot 
>> > itself is provable and analyzable on its own, 
>> > but activation parameters based on what % of economically relevant nodes 
>> > are running an upgrade by a certain date are 
>> > not. Selecting these sorts of complicated consensus parameters may 
>> > ultimately present more opportunity for a cooptable 
>> > consensus process than something more straightforward.
>> > 
>> > 
>> > That said, a few points strike me as worth delving into.
>> > 
>> > 
>> > 1) Con: Mandatory signalling is no different than a flag day. Mandatory 
>> > signaling is effectively 2 flag days -- one for 
>> > the signaling rule, 1 for the taproot type. The reason for the 2 week gap 
>> > between flag day for signaling and flag day 
>> > for taproot rules is, more or less, so that nodes who aren't taproot ready 
>> > at the 1st flag day do not end up SPV mining 
>> > (using standardness rules in mempool prevents

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Matt Corallo via bitcoin-dev]

Glad you asked! Yes, your goal here is #4 on the list of goals I laid out at [1], which I referenced and specifically 
addressed each of in the OP of this thread.


[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html

On 2/28/21 15:19, Eric Voskuil wrote:

In the attempt to change consensus rules there is a simple set of choices:

1) hard fork: creates a chain split
2) soft fork: creates a chain split
3) 51% attack: does not create a chain split

The presumption being that one can never assume 100% explicit adoption of any 
rule change.

A 51% attack can of course fail. It is also possible that signaling can be untruthful. But miner signaling provides some 
level of assurance that it will be successful. This level of assurance is increased by adoption of a higher than 
majority threshold, as has been done in the past.


Most of the discussion I’ve seen has been focused on who is in charge. Bitcoin requires no identity; anyone can mine 
and/or accept bitcoin - nobody is in charge.


The majority of those who mine can choose to enforce censorship any time they want. They don’t need anyone’s permission. 
No power is given to them by developers or anyone else. They have that power based on their own capital invested.


Similarly, the economy (those who accept bitcoin) can enforce any rule change it wants to. And it can do so at any level 
of participation that wants to go along. Anyone can do this, it requires nobody’s permission. Furthermore, it is 
possible for the economy to signal its level of agreement in every transaction, as miners have done in blocks previously.


But if the objective is to produce a rule change while avoiding a chain split, 50% is a much lower bar than 100%. If 
there is some other objective, it’s not clear to me what it is.


e


On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev 
 wrote:


Miners still can generate invalid blocks as a result of SPV mining, and it could be profitable to do "bad block 
enhanced selfish mining" to take advantage of it.



Hard to analyze exactly what that looks like, but...

E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to mine bad blocks would mean 1/4th of the 
time you could make 20% of the hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One could analyze 
out that the lost hash rate for bad blocks only matters for the first difficulty adjustment period you're doing this 
for too, as the hashrate drop will be accounted for -- but then a miner can switch back to mining valid chain, giving 
themselves a larger % of hashrate.


So it is still possible that an un-upgraded miner will fail part 3, and attempting to accommodate un-upgraded miners 
leads to some nasty oscillating hashrate being optimal.



--
@JeremyRubin 


On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo mailto:lf-li...@mattcorallo.com>> wrote:

Note further that mandatory signaling isn't "just" a flag day - unlike a 
Taproot flag day (where miners running
Bitcoin
Core unmodified today will not generate invalid blocks), a mandatory 
signaling flag day blatantly ignores goal (3)
from
my original post - it results in any miner who has not taken active action 
(and ensured every part of their
often-large
infrastructure has been correctly reconfigured) generating invalid blocks.

As for "Taproot" took too long, hey, at least if its locked in people can 
just build things assuming it exists. Some
already are, but once its clearly locked in, there's no reason to not 
continue other work at the same time.

Matt

On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
> I agree with much of the logic presented by Matt here.
>
> BIP8 was intended to be simpler to agree on to maintain consensus, yet we 
find ourselves in a situation where a
"tiny"
> parameter has the potential to cause great network disruption and 
confusion (rationality is not too useful a
concept
> here given differing levels of sophistication and information). It is 
therefore much simpler and more likely to be
> universally understood by all network participants to just have a flag 
day. It is easier to communicate what users
> should do and when.
>
> This is ultimately not coercive to users because the upgrade for Taproot 
itself is provable and analyzable on
its own,
> but activation parameters based on what % of economically relevant nodes 
are running an upgrade by a certain
date are
> not. Selecting these sorts of complicated consensus parameters may 
ultimately present more opportunity for a
cooptable
> consensus process than something more straightforward.
>
>
> That said, a few points strike me as worth delving into.
>
>
> 1) Con: Mandatory signalling is no different than a flag day. Mandatory 
signaling is effectively 2 flag days --
one for
>

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Matt Corallo via bitcoin-dev]

SPV mining has been curtailed somewhat to only apply for a brief period of time (based on public statements) since the 
last time SPV mining caused a fork. Indeed, if you can make other miners mine on top of an invalid block, you can make 
money by reducing the difficulty, but that is true as much today as during a fork. Still, I think you've made my point - 
someone has to take an active, malicious action in order to mine a bad block, vs with forced signaling, someone only 
needs to forget to reconfigure one out of one hundred pool servers they operate.


Matt

On 2/28/21 15:02, Jeremy wrote:
Miners still can generate invalid blocks as a result of SPV mining, and it could be profitable to do "bad block enhanced 
selfish mining" to take advantage of it.



Hard to analyze exactly what that looks like, but...

E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to mine bad blocks would mean 1/4th of the 
time you could make 20% of the hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One could analyze 
out that the lost hash rate for bad blocks only matters for the first difficulty adjustment period you're doing this for 
too, as the hashrate drop will be accounted for -- but then a miner can switch back to mining valid chain, giving 
themselves a larger % of hashrate.


So it is still possible that an un-upgraded miner will fail part 3, and attempting to accommodate un-upgraded miners 
leads to some nasty oscillating hashrate being optimal.



--
@JeremyRubin 


On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo mailto:lf-li...@mattcorallo.com>> wrote:

Note further that mandatory signaling isn't "just" a flag day - unlike a 
Taproot flag day (where miners running Bitcoin
Core unmodified today will not generate invalid blocks), a mandatory 
signaling flag day blatantly ignores goal (3) from
my original post - it results in any miner who has not taken active action 
(and ensured every part of their often-large
infrastructure has been correctly reconfigured) generating invalid blocks.

As for "Taproot" took too long, hey, at least if its locked in people can 
just build things assuming it exists. Some
already are, but once its clearly locked in, there's no reason to not 
continue other work at the same time.

Matt

On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
 > I agree with much of the logic presented by Matt here.
 >
 > BIP8 was intended to be simpler to agree on to maintain consensus, yet 
we find ourselves in a situation where a
"tiny"
 > parameter has the potential to cause great network disruption and 
confusion (rationality is not too useful a concept
 > here given differing levels of sophistication and information). It is 
therefore much simpler and more likely to be
 > universally understood by all network participants to just have a flag 
day. It is easier to communicate what users
 > should do and when.
 >
 > This is ultimately not coercive to users because the upgrade for Taproot 
itself is provable and analyzable on its
own,
 > but activation parameters based on what % of economically relevant nodes 
are running an upgrade by a certain date
are
 > not. Selecting these sorts of complicated consensus parameters may 
ultimately present more opportunity for a
cooptable
 > consensus process than something more straightforward.
 >
 >
 > That said, a few points strike me as worth delving into.
 >
 >
 > 1) Con: Mandatory signalling is no different than a flag day. Mandatory 
signaling is effectively 2 flag days --
one for
 > the signaling rule, 1 for the taproot type. The reason for the 2 week 
gap between flag day for signaling and flag
day
 > for taproot rules is, more or less, so that nodes who aren't taproot 
ready at the 1st flag day do not end up SPV
mining
 > (using standardness rules in mempool prevents them from mining an 
invalid block on top of a valid tip, but does not
 > ensure the tip is valid).
 > 2) Con: Releasing a flag day without releasing the LOT=true code leading 
up to that flag day means that clients
would
 > not be fully compatible with an early activation that could be proposed 
before the flag day is reached. E.g.,
LOT=true
 > is a flag day that retains the possibility of being compatible with 
other BIP8 releases without changing software.
 > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm 
personally skeptical that early activation
is/was
 > ever a good idea. A fixed activation date may be largely superior for 
business purposes, software engineering
schedules,
 > etc. I think even with signaling BIP8, it would be possibly superior to 
activate rules at a fixed date (or a
quantized
 > set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).
  

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Jeremy via bitcoin-dev]

Miners still can generate invalid blocks as a result of SPV mining, and it
could be profitable to do "bad block enhanced selfish mining" to take
advantage of it.


Hard to analyze exactly what that looks like, but...

E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate
to mine bad blocks would mean 1/4th of the time you could make 20% of the
hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One
could analyze out that the lost hash rate for bad blocks only matters for
the first difficulty adjustment period you're doing this for too, as the
hashrate drop will be accounted for -- but then a miner can switch back to
mining valid chain, giving themselves a larger % of hashrate.

So it is still possible that an un-upgraded miner will fail part 3, and
attempting to accommodate un-upgraded miners leads to some nasty
oscillating hashrate being optimal.


--
@JeremyRubin 



On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo 
wrote:

> Note further that mandatory signaling isn't "just" a flag day - unlike a
> Taproot flag day (where miners running Bitcoin
> Core unmodified today will not generate invalid blocks), a mandatory
> signaling flag day blatantly ignores goal (3) from
> my original post - it results in any miner who has not taken active action
> (and ensured every part of their often-large
> infrastructure has been correctly reconfigured) generating invalid blocks.
>
> As for "Taproot" took too long, hey, at least if its locked in people can
> just build things assuming it exists. Some
> already are, but once its clearly locked in, there's no reason to not
> continue other work at the same time.
>
> Matt
>
> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
> > I agree with much of the logic presented by Matt here.
> >
> > BIP8 was intended to be simpler to agree on to maintain consensus, yet
> we find ourselves in a situation where a "tiny"
> > parameter has the potential to cause great network disruption and
> confusion (rationality is not too useful a concept
> > here given differing levels of sophistication and information). It is
> therefore much simpler and more likely to be
> > universally understood by all network participants to just have a flag
> day. It is easier to communicate what users
> > should do and when.
> >
> > This is ultimately not coercive to users because the upgrade for Taproot
> itself is provable and analyzable on its own,
> > but activation parameters based on what % of economically relevant nodes
> are running an upgrade by a certain date are
> > not. Selecting these sorts of complicated consensus parameters may
> ultimately present more opportunity for a cooptable
> > consensus process than something more straightforward.
> >
> >
> > That said, a few points strike me as worth delving into.
> >
> >
> > 1) Con: Mandatory signalling is no different than a flag day. Mandatory
> signaling is effectively 2 flag days -- one for
> > the signaling rule, 1 for the taproot type. The reason for the 2 week
> gap between flag day for signaling and flag day
> > for taproot rules is, more or less, so that nodes who aren't taproot
> ready at the 1st flag day do not end up SPV mining
> > (using standardness rules in mempool prevents them from mining an
> invalid block on top of a valid tip, but does not
> > ensure the tip is valid).
> > 2) Con: Releasing a flag day without releasing the LOT=true code leading
> up to that flag day means that clients would
> > not be fully compatible with an early activation that could be proposed
> before the flag day is reached. E.g., LOT=true
> > is a flag day that retains the possibility of being compatible with
> other BIP8 releases without changing software.
> > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm
> personally skeptical that early activation is/was
> > ever a good idea. A fixed activation date may be largely superior for
> business purposes, software engineering schedules,
> > etc. I think even with signaling BIP8, it would be possibly superior to
> activate rules at a fixed date (or a quantized
> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).
> > 4) Pro: part of the argument for BIP-8=false is that it is possible that
> the rule could not activate, if signaling does
> > not occur, providing additional stopgap against dev collusion and bugs.
> But BIP-8 can activate immediately (with start
> > times being proposed 1 month after release?) so we don't have certainty
> around how much time there is for that secondary
> > review process (read -- I think it isn't that valuable) and if there
> *is* a deadly bug discovered, we might want to
> > hard-fork to fix it even if it isn't yet signaled for (e.g., if the rule
> activates it enables more mining reward). So I
> > think that it's a healthier mindset to release a with definite deadline
> and not rule out having to do a hard fork if
> > there is a grave 

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Matt Corallo via bitcoin-dev]

Note further that mandatory signaling isn't "just" a flag day - unlike a Taproot flag day (where miners running Bitcoin 
Core unmodified today will not generate invalid blocks), a mandatory signaling flag day blatantly ignores goal (3) from 
my original post - it results in any miner who has not taken active action (and ensured every part of their often-large 
infrastructure has been correctly reconfigured) generating invalid blocks.


As for "Taproot" took too long, hey, at least if its locked in people can just build things assuming it exists. Some 
already are, but once its clearly locked in, there's no reason to not continue other work at the same time.


Matt

On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:

I agree with much of the logic presented by Matt here.

BIP8 was intended to be simpler to agree on to maintain consensus, yet we find ourselves in a situation where a "tiny" 
parameter has the potential to cause great network disruption and confusion (rationality is not too useful a concept 
here given differing levels of sophistication and information). It is therefore much simpler and more likely to be 
universally understood by all network participants to just have a flag day. It is easier to communicate what users 
should do and when.


This is ultimately not coercive to users because the upgrade for Taproot itself is provable and analyzable on its own, 
but activation parameters based on what % of economically relevant nodes are running an upgrade by a certain date are 
not. Selecting these sorts of complicated consensus parameters may ultimately present more opportunity for a cooptable 
consensus process than something more straightforward.



That said, a few points strike me as worth delving into.


1) Con: Mandatory signalling is no different than a flag day. Mandatory signaling is effectively 2 flag days -- one for 
the signaling rule, 1 for the taproot type. The reason for the 2 week gap between flag day for signaling and flag day 
for taproot rules is, more or less, so that nodes who aren't taproot ready at the 1st flag day do not end up SPV mining 
(using standardness rules in mempool prevents them from mining an invalid block on top of a valid tip, but does not 
ensure the tip is valid).
2) Con: Releasing a flag day without releasing the LOT=true code leading up to that flag day means that clients would 
not be fully compatible with an early activation that could be proposed before the flag day is reached. E.g., LOT=true 
is a flag day that retains the possibility of being compatible with other BIP8 releases without changing software.
3) Pro: BIP-8 is partially in service of "early activation" and . I'm personally skeptical that early activation is/was 
ever a good idea. A fixed activation date may be largely superior for business purposes, software engineering schedules, 
etc. I think even with signaling BIP8, it would be possibly superior to activate rules at a fixed date (or a quantized 
set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).
4) Pro: part of the argument for BIP-8=false is that it is possible that the rule could not activate, if signaling does 
not occur, providing additional stopgap against dev collusion and bugs. But BIP-8 can activate immediately (with start 
times being proposed 1 month after release?) so we don't have certainty around how much time there is for that secondary 
review process (read -- I think it isn't that valuable) and if there *is* a deadly bug discovered, we might want to 
hard-fork to fix it even if it isn't yet signaled for (e.g., if the rule activates it enables more mining reward). So I 
think that it's a healthier mindset to release a with definite deadline and not rule out having to do a hard fork if 
there is a grave issue (we shouldn't ever release a SF if we think this is at all likely, mind you).
5) Con: It's already taken so long for taproot, the schedule around taproot was based on the idea it could early 
activate, 2022 is now too far away. I don't know how to defray this other than, if your preferred idea is 1 year flag 
day, to do that via LOT=true so that taproot can still have early activation if desired.


Overall I agree with the point that all the contention around LOT, makes a flag day look not so bad. And something 
closer to a flag day might not be so bad either for future forks as well.


However, I think given the appetite for early activation, if a flag day is desired I think LOT=true is the best option 
at this time as it allows our flag day to remain compatible with such an early activation.


I think we can also clearly communicate that LOT=true for Taproot is not a precedent setting occurence for any future 
forks (hold me accountable to not using this as precedent this should I ever advocate for a SF with similar release 
parameters).



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

Re: [bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC

[Luke Dashjr via bitcoin-dev]

Answering the F1-F7 arguments for LOT=False...

> F1) The probability of Taproot not being activated by miners is small. This
> is not 2017, this is not SegWit, there is no need to worry.

While we believe miners have no reason to sabotage Taproot activation, this 
was also the belief leading up to Segwit’s activation in 2017, and regardless 
it is not desirable to create such a risk forcing the community to place 
extra trust in miners. Miners might very well not exploit an inflation bug, 
but that is no reason to purposefully add an inflation bug.

> F2) The worst case scenario is we have to wait over a year for Taproot to
> be activated. Even the worst case scenario is not a disaster.

While it is true that a second activation can be deployed in the event of the 
first one failing, doing so would not necessarily change the situation unless 
LOT were changed to true anyway - in which case, it might as well be true for 
the initial deployment as well. Furthermore, a re-deployment could create a 
situation where users believe they have already upgraded for Taproot, but do 
not enforce it due to not understanding the need to upgrade yet again.

> F3) If in the unlikely scenario miners did not activate Taproot for a year
> for no apparent reason we would never set LOT to false again for any
> potential future soft fork. If miners fail to activate Taproot despite
> pledging support and there being overwhelming community consensus for it,
> it would set a precedent that miners cannot be relied upon *at all* to
> activate soft forks.

Setting LOT=false with a threat to change it to true later is antagonistic 
against miners. With LOT=true, expectations are simply made clear and miners 
can simply cooperate by making valid blocks as they do day-to-day already.

> F4) If in the highly unlikely scenario that a bug or some problem with the
> Taproot implementation was found during the signaling period miners could
> choose not to activate it which is cleaner than needing an emergency Core
> release.

The risk that a bug in Taproot is discovered this late yet before activation, 
to warrant aborting the deployment, is extremely low (much lower than the 
risks created by LOT=false). Even if such a scenario occurred, and even with 
LOT=false, users would still need to upgrade to back out the deployment. In 
the best-case scenario, users would need to upgrade to deploy the fixed 
Taproot. So in the end, nothing is to be gained from relying on a miner abort 
for such scenarios.

> F5) LOT = false is more similar to what was done previously (unless you go
> way back to the earliest soft forks which were more similar to LOT = true)

The behaviour of LOT=false has proven problematic and caused failure of Segwit 
activation in 2017. LOT=true behaviour has a long history of success, and was 
used to resolve and activate Segwit in 2017 after LOT=false’s failure.

> F6) It is more important that no rules that harm users are deployed than it
> is that new useful rules are deployed quickly. If there is a choice between
> “faster” and “more clear that this isn’t a mechanism to force bad things on
> users” we should prefer the latter. Plenty of people just don’t like
> LOT=true very much absent evidence that miners are blocking deployment. To
> some it just feels needlessly antagonistic and distrusting towards part of
> our community.

Any deployment, or even status quo, can be falsely portrayed/spun in a way to 
harm Bitcoin. As such, only objective criteria should be considered.

BIP 8 makes it explicitly easy for people to reject the softfork if they don't 
like it, so any claim of being "forced" is a non-starter to an honest person.

> F7) defaulting to LOT=false makes non-activation possible even if people
> run the code that developers provide, meaning a successful
> activation proves that at least some people (e.g. miners or UASFers)
> voluntarily took actions that were well outside the scope of
> developer control.
>
> This makes it clear that developers don't control changes to the
> system.  There are other arguments that demonstrate that developers
> aren't in control[1], but they aren't as clear as simply pointing
> out that a rule change won't go into effect until at least several
> non-developers independently act of their own accord.
>
> Having such a clear argument that developers aren't in control
> bolsters the decentralized ethos of Bitcoin and reduces the chance
> that bad actors will pressure Bitcoin developers to attempt future
> unwanted changes.

Even if developers release software, it must still be accepted by the 
community in the form of actively choosing to run the software which includes 
the activation. So long as the activation is clearly and prominently 
documented, users have taken the action to accept the protocol change. 
Furthermore, the community has already demonstrated a clear and undisputed 
support for the activation of Taproot. If there wa

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Jeremy via bitcoin-dev]

I agree with much of the logic presented by Matt here.

BIP8 was intended to be simpler to agree on to maintain consensus, yet we
find ourselves in a situation where a "tiny" parameter has the potential to
cause great network disruption and confusion (rationality is not too useful
a concept here given differing levels of sophistication and information).
It is therefore much simpler and more likely to be universally understood
by all network participants to just have a flag day. It is easier to
communicate what users should do and when.

This is ultimately not coercive to users because the upgrade for Taproot
itself is provable and analyzable on its own, but activation parameters
based on what % of economically relevant nodes are running an upgrade by a
certain date are not. Selecting these sorts of complicated consensus
parameters may ultimately present more opportunity for a cooptable
consensus process than something more straightforward.


That said, a few points strike me as worth delving into.


1) Con: Mandatory signalling is no different than a flag day. Mandatory
signaling is effectively 2 flag days -- one for the signaling rule, 1 for
the taproot type. The reason for the 2 week gap between flag day for
signaling and flag day for taproot rules is, more or less, so that nodes
who aren't taproot ready at the 1st flag day do not end up SPV mining
(using standardness rules in mempool prevents them from mining an invalid
block on top of a valid tip, but does not ensure the tip is valid).
2) Con: Releasing a flag day without releasing the LOT=true code leading up
to that flag day means that clients would not be fully compatible with an
early activation that could be proposed before the flag day is reached.
E.g., LOT=true is a flag day that retains the possibility of being
compatible with other BIP8 releases without changing software.
3) Pro: BIP-8 is partially in service of "early activation" and . I'm
personally skeptical that early activation is/was ever a good idea. A fixed
activation date may be largely superior for business purposes, software
engineering schedules, etc. I think even with signaling BIP8, it would be
possibly superior to activate rules at a fixed date (or a quantized set of
fixed dates, e.g. guaranteeing at least 3 months but maybe more).
4) Pro: part of the argument for BIP-8=false is that it is possible that
the rule could not activate, if signaling does not occur, providing
additional stopgap against dev collusion and bugs. But BIP-8 can activate
immediately (with start times being proposed 1 month after release?) so we
don't have certainty around how much time there is for that secondary
review process (read -- I think it isn't that valuable) and if there *is* a
deadly bug discovered, we might want to hard-fork to fix it even if it
isn't yet signaled for (e.g., if the rule activates it enables more mining
reward). So I think that it's a healthier mindset to release a with
definite deadline and not rule out having to do a hard fork if there is a
grave issue (we shouldn't ever release a SF if we think this is at all
likely, mind you).
5) Con: It's already taken so long for taproot, the schedule around taproot
was based on the idea it could early activate, 2022 is now too far away. I
don't know how to defray this other than, if your preferred idea is 1 year
flag day, to do that via LOT=true so that taproot can still have early
activation if desired.

Overall I agree with the point that all the contention around LOT, makes a
flag day look not so bad. And something closer to a flag day might not be
so bad either for future forks as well.

However, I think given the appetite for early activation, if a flag day is
desired I think LOT=true is the best option at this time as it allows our
flag day to remain compatible with such an early activation.

I think we can also clearly communicate that LOT=true for Taproot is not a
precedent setting occurence for any future forks (hold me accountable to
not using this as precedent this should I ever advocate for a SF with
similar release parameters).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] LOT=False is dangerous and shouldn't be used

[Luke Dashjr via bitcoin-dev]

(Note: I am writing this as a general case against LOT=False, but using 
Taproot simply as an example softfork. Note that this is addressing 
activation under the assumption that the softfork is ethical and has 
sufficient community support. If those criteria have not been met, no 
activation should be deployed at all, of any type.)

As we saw in 2017 with BIP 9, coordinating activation by miner signal alone, 
despite its potential benefits, also leaves open the door to a miner veto. 
This was never the intended behaviour, and a bug, which took a rushed 
deployment of BIP148 to address. LOT=False would reintroduce that same bug.
It wouldn't be much different than adding back the inflation bug 
(CVE-2018-17144) and trusting miners not to exploit it.

Some have tried to spin LOT=True as some kind of punishment for miners or 
reactive "counter-attack". Rather, it is simply a fallback to avoid 
regression on this and other bugs. "Flag day" activation is not fundamentally 
flawed or dangerous, just slow since everyone needs time to upgrade.
BIP 8(LOT=True) combines the certainty of such a flag day, with the speed 
improvement of a MASF, so that softforks can be activated both reasonably 
quick and safely.

In the normal path, and that which BIP8(True) best incentivises, miners will 
simply upgrade and signal, and activation can occur as soon as the economic 
majority is expected to have had time to upgrade. In the worst-case path, the 
behaviour of LOT=True is the least-harmful result: unambiguous activation and 
enforcement by the economy, with miners either deciding to make an 
anti-Taproot(eg) altcoin, or continue mining Bitcoin. Even if ALL the miners 
revolt against the softfork, the LOT=True nodes are simply faced with a 
choice to hardfork (replacing the miners with a PoW change) or concede - they 
do not risk vulnerability or loss.

With LOT=False in the picture, however, things can get messy: some users will 
enforce Taproot(eg) (those running LOT=True), while others will not (those 
with LOT=False). Users with LOT=True will still get all the safety thereof, 
but those with LOT=False will (in the event of miners deciding to produce a 
chain split) face an unreliable chain, being replaced by the LOT=True chain 
every time it overtakes the LOT=False chain in work. For 2 weeks, users with 
LOT=False would not have a usable network. The only way to resolve this would 
be to upgrade to LOT=True or to produce a softfork that makes an activated 
chain invalid (thereby taking the anti-Taproot path). Even if nobody ran 
LOT=True (very unlikely), LOT=False would still fail because users would be 
faced with either accepting the loss of Taproot(eg), or re-deploying from 
scratch with LOT=True. It accomplishes nothing compared to just deploying 
LOT=True from the beginning. Furthermore, this process creates a lot of 
confusion for users ("Yep, I upgraded for Taproot(eg). Wait, you mean I have 
to do it AGAIN?"), and in some scenarios additional code may be needed to 
handle the subsequent upgrade cleanly.

To make matters worse for LOT=False, giving miners a veto also creates an 
incentive to second-guess the decision to activate and/or hold the activation 
hostage. This is a direct result of the bug giving them a power they weren't 
intended to have. Even if we trust miners to act ethically, that does not 
justify sustaining the bug creating both a possibility and incentive to 
behave unethically.

So in all possible scenarios, LOT=False puts users and the network at 
significant risk. In all possible scenarios, LOT=True minimises risk to 
everyone and has no risk to users running LOT=True.

The overall risk is maximally reduced by LOT=True being the only deployed 
parameter, and any introduction of LOT=False only increases risk probability 
and severity.

For all these reasons, I regret adding LOT as an option to BIP 8, and think it 
would be best to remove it entirely, with all deployments in the future 
behaving as LOT=True. I do also recognise that there is not yet consensus on 
this, and for that reason I have not taken action (nor intend to) to remove 
LOT from BIP 8. However, the fact remains that LOT=False should not be used, 
and it is best if every softfork is deployed with LOT=True.

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

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Matt Corallo via bitcoin-dev]

I think you may have misunderstood my proposal. I'm not suggesting some people run BIP 8(true), some run BIP8(false), 
and some run a client which has a flag day, I'm suggesting a flag day activation instead of any BIP8-based activation. 
Replies to your further points inline.


Matt

On 2/28/21 12:20, Luke Dashjr wrote:

On Sunday 28 February 2021 16:45:22 Matt Corallo via bitcoin-dev wrote:
Concept NACK. This still has the same problems BIP149 would have had, as I
just reminded in my last email to this ML:

1) Such a chain does not indicate activation at all, leaving it unresolved and
debatable whether activation has occurred or not.
2) As a result, it is also impractical to intentionally reject the softfork
should anyone decide to do so.

Signalling is important to activation.


Several people responded disagreeing, including myself. I'll paste my response 
here in case you missed it:

Forced-signaling, or any form of signaling, does not materially change whether a soft fork can be seen to be safe to 
use. Pieter wrote a great post[1] some time ago that goes into depth about the security of soft forks, but, while miners 
can help to avoid the risk of forks, they aren't the determining factor in whether use of a fork should be considered 
safe (ie the fork "has activated").


Not only that, but the signaling methods used in BIP 8/9 (ie the version field in the block header) do not imply 
anything about whether mining pools are running full nodes which enforce the soft fork at all, only whether the pool has 
configured their stratum software to signal or not.


Ultimately, forced-signaling, or signaling period, are not a substitute for having a broad set of upgraded nodes across 
the network, including an overwhelming majority of economically-active nodes, enforcing the rules of a new fork. As this 
can be difficult to measure, waiting some time after a fork and examining upgrade patterns across the network is important.


[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Luke Dashjr via bitcoin-dev]

On Sunday 28 February 2021 16:45:22 Matt Corallo via bitcoin-dev wrote:
> many individuals are committing themselves to running
> incompatible consensus rules.

Yet that is exactly what you propose herein...

> Given this, it seems one way to keep the network in consensus would be to
> simply activate taproot through a traditional, no-frills, flag-day (or
> -height) activation with a flag day of roughly August, 2022.

Concept NACK. This still has the same problems BIP149 would have had, as I 
just reminded in my last email to this ML:

1) Such a chain does not indicate activation at all, leaving it unresolved and 
debatable whether activation has occurred or not.
2) As a result, it is also impractical to intentionally reject the softfork 
should anyone decide to do so.

Signalling is important to activation.

> 2) The high node-level-adoption bar is one of the most critical goals, and
> the one most currently in jeopardy in a BIP 8 approach.

It is only jeopardized if people continue to push for a LOT=False deployment 
(or this new proposal of yours).

BIP 8 itself, with LOT=True, does not create such a risk at all.

> Users demanding alternative consensus rules (or, worse, configuration flags
> to change consensus rules on individual nodes with an expectation of use)
> makes this very complicated in the context of BIP 8.

Alternative consensus rules is exactly what you are proposing here.

More alternative rules to choose from just increase the risks. Two options is 
annoying, but adding a third for no reason is just absurd.

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

[bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Matt Corallo via bitcoin-dev]

As anyone reading this list is aware, there is significant debate around the activation method for the proposed Taproot 
soft fork. So much so, and with so much conviction, that many individuals are committing themselves to running 
incompatible consensus rules. Obviously, such commitments, were they to come to pass, and were a fork to occur as a 
result, would do more harm than any soft-fork does good. Further, such commitments and debate have likely delayed any 
possible release of a future Taproot activation while issues around locked-in activation are debated, instead of 
avoiding it as was the original intent of the "just ship BIP 8 LOT=false and we'll debate the rest if we need to" approach.


Given this, it seems one way to keep the network in consensus would be to simply activate taproot through a traditional, 
no-frills, flag-day (or -height) activation with a flag day of roughly August, 2022. Going back to my criteria laid out 
in [1],


1) I don't believe we have or will see significant, reasonable, and directed objection. This has largely always been the 
case, but it is also critical that the lack of such objection is demonstrable to outside observers. Ironically, the 
ongoing debate (and clear lack of consensus) around activation methods can be said to have had that effect, at least as 
far as the active Bitcoin Reddit/Twitter userbase is concerned. In addition, the public support for Taproot activation 
made by mining pool operators further shows public review and acceptance. Ideally, large Bitcoin business operators who 
previously took part in Bitcoin Optech's Taproot workshop [2] would publicly state something similar prior to release of 
Taproot activation parameters. Because this expectation is social, no technical solution exists, only public statements 
made in broad venues - something which I'd previously argued comes through soft fork activation parameter deployment, 
but which can also come from elsewhere.


2) The high node-level-adoption bar is one of the most critical goals, and the one most currently in jeopardy in a BIP 8 
approach. Users demanding alternative consensus rules (or, worse, configuration flags to change consensus rules on 
individual nodes with an expectation of use) makes this very complicated in the context of BIP 8. Instead of debating 
activation parameters and entrenching individuals into running their own consensus rules, a flag day activation changes 
the problem to one of simply encouraging upgrades, avoiding a lot of possibility for games. Of course in order to meet 
this goal we still need significant time to pass between activation parameter release and activation. Given the delays 
likely to result from debates around BIP 8 parameters, I don't think this is a huge loss. Capitalizing on current 
interest and demand for Taproot further implies a shortened timeline (eg a year and a half instead of two) may be merited.


3) The potential loss of hashpower is likely the biggest risk of this approach. It is derisked somewhat by the public 
commitment of pool operators to Taproot activation, and can be de-risked further by seeking more immediate commitment 
prior to release. Still, given the desire to push for a forced-signaling approach by many, there is more significant 
risk of loss of hashpower in today's approach. In an ideal world, we could do something more akin to BIP 9/BIP 8(false) 
to reduce risk of this further, but its increasingly likely that this is not possible. A flag-day which takes advantage 
of the nonstandardness of Taproot transactions in current Bitcoin Core releases may suffice.


4) Similar arguments apply as the above around the public commitment from pool operators to enforce the Taproot 
consensus rules.


5) Similar arguments apply as the discussion in (1).


Ultimately, the risk which is present in doing flag day activations (and the reason I've argued against them as a 
"default" in the past) are present as well in BIP 8(true), forced-signaling activations where community debate splits 
the consensus rules across nodes. While such a deployment could delay Taproot somewhat, it sidesteps a sufficient amount 
of debate and resulting delay that I wouldn't be surprised if it did not. Further, Taproot has been worked on for many 
years now with no apparent urgency from the many who are suddenly expressing activation urgency, making it more likely 
such urgency is artificial. Those who seek Taproot activation for Bitcoin market reasons should also rejoice - not only 
can the market celebrate the final release of Taproot, but it gets a second celebratory event in 2022 when the 
activation occurs.


Matt


[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
[2] https://bitcoinops.org/en/schorr-taproot-workshop/
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot NACK

[Ariel Lorenzo-Luaces via bitcoin-dev]

Hello LORD HIS EXCELLENCY JAMES HRMH

I find a striking dichotomy between your concern of increased privacy in 
bitcoin and your link to a bitcoin mixer in your signature www.go-overt.com

At first your concerns seemed genuine but after seeing your promotion of a 
bitcoin mixer I'm thinking your concerns may be more profit motivated? I can't 
tell since you failed to disclose your relationship with the mixer.

Could you please clarify your association with the bitcoin mixer and moving 
forward could you please always do proper disclosure any time you're publically 
talking about bitcoin transaction privacy. It's only fair to do so as to not 
mislead people in an attempt to manipulate at worst and just a courteous 
practice at best.

Cheers
Ariel Lorenzo-Luaces


On Feb 28, 2021, 4:36 AM, at 4:36 AM, LORD HIS EXCELLENCY JAMES HRMH via 
bitcoin-dev  wrote:
>Good Evening,
>
>Thank-you for your advice @JeremyRubin
>on the basis you advise, "Taproot does not enable monero-like privacy
>features", I am prepred to withdraw my NACK notably that the existing
>feeatures of Bitcoin MUST be maintained, and whereby the UTXO of a
>transaction is identifiable, the PayTo Address, and the amount all
>without any obfuscation.
>
>Lightning does not really provide obfuscation, it provides a result of
>a subset of transactions although the operation of the channel is
>observable to the parties.
>
>The reports I were reading concerning the supposed operation of Taproot
>published in a public media channel may have been speculation or
>misinformation nonetheless it is prudent to conditionally reply as you
>see that I have. It is important not to allow things to slip through
>the cracks. As you may believe may astute reviewers could make a full
>disclosure to this list it is not to be expected.
>
>KING JAMES HRMH
>Great British Empire
>
>Regards,
>The Australian
>LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>of Hougun Manor & Glencoe & British Empire
>MR. Damian A. James Williamson
>Wills
>
>et al.
>
>
>Willtech
>www.willtech.com.au
>www.go-overt.com
>and other projects
>
>earn.com/willtech
>linkedin.com/in/damianwilliamson
>
>
>m. 0487135719
>f. +61261470192
>
>
>This email does not constitute a general advice. Please disregard this
>email if misdelivered.
>
>From: Jeremy 
>Sent: Sunday, 28 February 2021 3:14 AM
>To: LORD HIS EXCELLENCY JAMES HRMH ; Bitcoin
>Protocol Discussion 
>Subject: Re: [bitcoin-dev] Taproot NACK
>
>I have good news for you: Taproot does not enable monero-like privacy
>features any moreso than already exist in Bitcoin today. At its core,
>taproot is a way to make transactions with embedded smart contracts
>less expensive, done so in a manner that may marginally improve privacy
>dependent on user behavior (but not in the monero-like way you
>mention). For example, it makes it possible for lightning channels to
>look structurally similar to single key wallets, but it does nothing
>inherently to obfuscate the transaction graph as in monero.
>
>Such "monero-like" transaction graph obfuscation may already exist in
>Bitcoin via other techniques (coinjoin, payjoin, coinswap, lightning,
>etc) with or without Taproot, so the point is further moot.
>
>Do you have a source on your reporting?
>
>You may wish to rescind your nack.
>
>
>--
>@JeremyRubin
>
>
>On Sat, Feb 27, 2021 at 5:46 AM LORD HIS EXCELLENCY JAMES HRMH via
>bitcoin-dev
>mailto:bitcoin-dev@lists.linuxfoundation.org>>
>wrote:
>Good Afternoon,
>
>It has been reported that Taproot will enable some Monero like features
>including the ability to hide transactions.
>
>If that is the case I offer a full NACK and let me explain.
>
>A part of the benefit of using Bitcoin is its honesty. The full
>transaction is published on the blockchain. If that were to change so
>that transactions may be obfuscated from scrutiny then any government
>would have unlimited impetus to ban Bitcoin, and speculation has that
>is the reason India has been reported to have banned cryptocurrencies
>already.
>
>I am in support of the expanded use case of Bitcoin without harming the
>established robust fairness and equal equity offered. The core
>functionality of Bitcoin, its values, must remain unaltered.
>
>KING JAMES HRMH
>Great British Empire
>
>Regards,
>The Australian
>LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>of Hougun Manor & Glencoe & British Empire
>MR. Damian A. James Williamson
>Wills
>
>et al.
>
>
>Willtech
>www.willtech.com.au
>www.go-overt.com
>and other projects
>
>earn.com/willtech
>linkedin.com/in/damianwilliamson
>
>
>m. 0487135719
>f. +61261470192
>
>
>This email does not constitute a general advice. Please disregard this
>email if misdelivered.
>___
>bitcoin-dev mailing list
>bitcoin

Re: [bitcoin-dev] Exploring alternative activation mechanisms: decreasing threshold

[Ryan Grant via bitcoin-dev]

On Sat, Feb 27, 2021 at 5:55 PM Luke Dashjr via bitcoin-dev
 wrote:
> This has the same problems BIP149 did: since there is no signalling, it is
> ambiguous whether the softfork has activated at all.

You only need to see one block in the heaviest valid chain to dissolve
that ambiguity.  There are a lot of volunteers in this space who would
(collectively) commit a few block's worth of hashrate, to know.

> Additionally, it loses the flexibility of BIP 8 to, after the initial
> deployment, move the timeoutheight sooner.

It doesn't interfere with concurrent UASFs using any combination of
timeoutheights.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot NACK

[LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev]

Good Evening,

Thank-you for your advice @JeremyRubin on the 
basis you advise, "Taproot does not enable monero-like privacy features", I am 
prepred to withdraw my NACK notably that the existing feeatures of Bitcoin MUST 
be maintained, and whereby the UTXO of a transaction is identifiable, the PayTo 
Address, and the amount all without any obfuscation.

Lightning does not really provide obfuscation, it provides a result of a subset 
of transactions although the operation of the channel is observable to the 
parties.

The reports I were reading concerning the supposed operation of Taproot 
published in a public media channel may have been speculation or misinformation 
nonetheless it is prudent to conditionally reply as you see that I have. It is 
important not to allow things to slip through the cracks. As you may believe 
may astute reviewers could make a full disclosure to this list it is not to be 
expected.

KING JAMES HRMH
Great British Empire

Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills

et al.


Willtech
www.willtech.com.au
www.go-overt.com
and other projects

earn.com/willtech
linkedin.com/in/damianwilliamson


m. 0487135719
f. +61261470192


This email does not constitute a general advice. Please disregard this email if 
misdelivered.

From: Jeremy 
Sent: Sunday, 28 February 2021 3:14 AM
To: LORD HIS EXCELLENCY JAMES HRMH ; Bitcoin Protocol 
Discussion 
Subject: Re: [bitcoin-dev] Taproot NACK

I have good news for you: Taproot does not enable monero-like privacy features 
any moreso than already exist in Bitcoin today. At its core, taproot is a way 
to make transactions with embedded smart contracts less expensive, done so in a 
manner that may marginally improve privacy dependent on user behavior (but not 
in the monero-like way you mention). For example, it makes it possible for 
lightning channels to look structurally similar to single key wallets, but it 
does nothing inherently to obfuscate the transaction graph as in monero.

Such "monero-like" transaction graph obfuscation may already exist in Bitcoin 
via other techniques (coinjoin, payjoin, coinswap, lightning, etc) with or 
without Taproot, so the point is further moot.

Do you have a source on your reporting?

You may wish to rescind your nack.


--
@JeremyRubin


On Sat, Feb 27, 2021 at 5:46 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev 
mailto:bitcoin-dev@lists.linuxfoundation.org>>
 wrote:
Good Afternoon,

It has been reported that Taproot will enable some Monero like features 
including the ability to hide transactions.

If that is the case I offer a full NACK and let me explain.

A part of the benefit of using Bitcoin is its honesty. The full transaction is 
published on the blockchain. If that were to change so that transactions may be 
obfuscated from scrutiny then any government would have unlimited impetus to 
ban Bitcoin, and speculation has that is the reason India has been reported to 
have banned cryptocurrencies already.

I am in support of the expanded use case of Bitcoin without harming the 
established robust fairness and equal equity offered. The core functionality of 
Bitcoin, its values, must remain unaltered.

KING JAMES HRMH
Great British Empire

Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills

et al.


Willtech
www.willtech.com.au
www.go-overt.com
and other projects

earn.com/willtech
linkedin.com/in/damianwilliamson


m. 0487135719
f. +61261470192


This email does not constitute a general advice. Please disregard this email if 
misdelivered.
___
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] A design for Probabilistic Partial Pruning

[Leo Wandersleb via bitcoin-dev]

Only headers need to be downloaded sequentially so downloading relevant blocks
from one node is totally possible with gaps in between.

On 2/27/21 4:10 AM, Igor Cota via bitcoin-dev wrote:
> Hi Keagan,
>
> I had a very similar idea. The only difference being for the node to decide on
> a range of blocks to keep beforehand, rather than making the decision
> block-by-block like you suggest.
>
> I felt the other nodes would be better served by ranges due to the sequential
> nature of IBD. Perhaps this would be computationally lighter as well.
>
> I also encourage you to read Ryosuke Abe's paper [1] that proposes a DHT
> scheme to solve this same problem.
>
> Cheers,
> Igor
>
> [1] https://arxiv.org/abs/1902.02174
>
> On Fri, 26 Feb 2021 at 21:57, Keagan McClelland via bitcoin-dev
>  > wrote:
>
> Hi all,
>
> I've been thinking for quite some time about the problem of pruned nodes
> and ongoing storage costs for full nodes. One of the things that strikes
> me as odd is that we only really have two settings.
>
> A. Prune everything except the most recent blocks, down to the cache size
> B. Keep everything since genesis
>
> From my observations and conversations with various folks in the
> community, they would like to be able to run a "partially" pruned node to
> help bear the load of bootstrapping other nodes and helping with data
> redundancy in the network, but would prefer to not dedicate hundreds of
> Gigabytes of storage space to the cause.
>
> This led me to the idea that a node could randomly prune some of the
> blocks from history if it passed some predicate. A rough sketch of this
> would look as follows.
>
> 1. At node startup, it would generate a random seed, this would be unique
> to the node but not necessary that it be cryptographically secure.
> 2. In the node configuration it would also carry a "threshold" expressed
> as some percentage of blocks it wanted to keep.
> 3. As IBD occurs, based off of the threshold, the block hash, and the
> node's unique seed, the node would either decide to prune the data or keep
> it. The uniqueness of the node's hash should ensure that no block is
> systematically overrepresented in the set of nodes choosing this storage
> scheme.
> 4. Once the node's IBD is complete it would advertise this as a peer
> service, advertising its seed and threshold, so that nodes could
> deterministically deduce which of its peers had which blocks.
>
> The goals are to increase data redundancy in a way that more uniformly
> shares the load across nodes, alleviating some of the pressure of full
> archive nodes on the IBD problem. I am working on a draft BIP for this
> proposal but figured I would submit it as a high level idea in case anyone
> had any feedback on the initial design before I go into specification
> levels of detail.
>
> If you have thoughts on
>
> A. The protocol design itself
> B. The barriers to put this kind of functionality into Core
>
> I would love to hear from you,
>
> Cheers,
> Keagan
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> -- 
> *Igor Cota*
> Codex Apertus d.o.o.
>
> ___
> 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