Hi Dathon,

Thanks for posting the updated draft, and the removal of the emergency 
activation path.

I have a few questions/comments/suggestions. I'm guessing they fit better 
here than on github.

*Rule Changes-*
>it takes pains to avoid causing problems for all known use cases.
Regarding the 7 rule changes, confiscation risks, etc. I am suggesting you 
to publish an analysis of each rule (or using a github repo for 
collaboration on the same).

I am suggesting this in part because I don't have a deep understanding of 
the potential use cases affected by each rule change. Having that 
information in one place would be helpful for me and possibly other people 
who are looking at this to give input or determine what risks exist.

Some ideas to include in the analysis are:
    What percentage of transactions/fees would be made invalid by a rule?
    Which major protocols or use cases could be affected by a rule?
    Feedback/concerns received on specific rules.
    Is there widespread agreement on any specific rules being less risky or 
zero risk? Or ones which have more concerns than others?
    Is there overlap with other proposals with any rules? Or conflicts with 
proposals that might activate during the 1 year period?


*Activation-*
Many of my original comments about activation from github are still 
relevant. But to keep it brief, there is one big disconnect I'm seeing on 
the email chain here which is that there is an assumption about what 
percent of miners/network would activate. I don't think that is a safe 
assumption to make, especially with a flag day.

In trying to find a relevant comparison, I found this optech article which 
states that mining pools, consisting of over 50% of hash rate, announced 
support for taproot 4 months before the activation code was merged.
https://bitcoinops.org/en/newsletters/2020/11/25/?utm_source=chatgpt.com

In other words, it seems before the flag day was set, there was already a 
very strong guarantee it would have majority miner support.

With that in mind, it also makes the proposed timeline seem quite short. 
Does the timeline provide enough time to communicate, test, gain miner 
consensus, etc.

    
*Reference Implementation-*
Thanks for sharing the reference implementation. I do have one concern... 
that individuals might start running the reference code before it is 
finalized or with varying start heights. I thought I was being overly 
cautious, however, some individuals have already stated they intend to do 
an emergency activation regardless of whether this proposal includes it.

I suggest adding a warning on the code, something like "running this code 
before it has been finalized / without majority miner support would likely 
result in incompatibility with the Bitcoin network and possible loss of 
funds".


   
Thank you,
onyxcoyote

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/f14ac391-f85f-4af7-be11-d4c94ecc32d6n%40googlegroups.com.