Hi Dathon,<br /><br />Thanks for posting the updated draft, and the removal of the emergency activation path.<br /><br />I have a few questions/comments/suggestions. I'm guessing they fit better here than on github.<br /><br /><b>Rule Changes-</b><br />&gt;it takes pains to avoid causing problems for all known use cases.<br />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).<br /><br />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.<br /><br />Some ideas to include in the analysis are:<br />    What percentage of transactions/fees would be made invalid by a rule?<br />    Which major protocols or use cases could be affected by a rule?<br />    Feedback/concerns received on specific rules.<br />    Is there widespread agreement on any specific rules being less risky or zero risk? Or ones which have more concerns than others?<br />    Is there overlap with other proposals with any rules? Or conflicts with proposals that might activate during the 1 year period?<br /><br /><div><div><div><br /><b>Activation-</b><br />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.<br /><br />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.<br />https://bitcoinops.org/en/newsletters/2020/11/25/?utm_source=chatgpt.com<br /><br />In other words, it seems before the flag day was set, there was already a very strong guarantee it would have majority miner support.<br /><br />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.<br /><br />    <br /><b>Reference Implementation-</b><br />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.<br /><br />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".<br /><br /><br />   <br />Thank you,<br />onyxcoyote<div><br /></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/f14ac391-f85f-4af7-be11-d4c94ecc32d6n%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/f14ac391-f85f-4af7-be11-d4c94ecc32d6n%40googlegroups.com</a>.<br />