| Thanks for your reply. I'm a fan of your work and consider myself to be a neutral observer in these debates. Regarding your first contestation, I think as another commenter said, you are cherry-picking. He explains soft forks well and isn't attempting to mislead. That's why I refer folks to the article. > This is why at present, Bitcoin Core nodes/wallets loudly warn you that unknown rules may be in effect... Hearn mentions this mechanism three times in the article. He even discusses the tradeoffs of ignoring this versus rejecting the block. Hardly misleading. > The soft-fork protocols used for upgrades are specifically designed to ensure nodes are not tricked into believing something is valid when it might actually not be... He said "essentially tricked", and I think his explanation is clear. Using segwit as an example, if my understanding is correct, there is an edge case where non-upgraded nodes may try to mine an invalid block, which will consequently be rejected by the majority of the network (assuming the majority is using segwit). Since segwit transactions look like an "anyone can spend" output, a non-segwit miner could be sent a transaction that spends the output to somewhere it's not supposed to go, and that would be considered invalid by segwit-supporting nodes. Therefore I think it's fair to say non-upgraded nodes are "essentially tricked", and it's a good way to explain the distinction between hard and soft forks. I don't know as much about replace-by-fee so won't attempt to counter you. But I will just add that this type of cherry-picking behavior has consistently been coming out of the "Core side", and I have rarely seen strong, clear counter-arguments from that side. Combine that with the very silly censorship stuff on Reddit, and one can understand why Hearn and others have become so frustrated. Again, I am a fan and a neutral observer. But unless I am looking in the wrong places, the only side being "widely condemned" is the Core side. Perhaps you could point me to the strong, clear counter-arguments from Core? I'll start with the link you posted and check out the rest of your site! --- EDIT: Corrected "reply-by-fee" to "replace-by-fee" |
Hearn mentions the nVersion mechanism? Specifically in https://medium.com/@octskyward/on-consensus-and-forks-c6a050... ?
Maybe I'm missing something, but I don't see any mention of the word "version"
> He said "essentially tricked", and I think his explanation is clear.
I think you're misunderstanding my point: everything you raised above is negated by the fact that the soft-fork mechanisms we use are designed to give warnings to users and miners who are not running the new(1) protocol. For example, in addition to the nVersion mechanism I mentioned, segwit transactions are intentionally designed to be not standard transactions, and thus non-segwit miners will reject them. This is an important feature to ensure that those miners don't unintentionally create invalid blocks.
1) I say "new" rather than "upgraded" to avoid making the claim that soft-forks are necessarily an upgrade.