Hi My reply to the message I sent entitled "The Soft Fork Deception" was rejected and I was told to send to this list.
I sent the following message: Hi Thanks for the responses (although they don't quite answer my question about what the philosophy/reasoning was for those quite forceful soft forks we have made in the past). I spoke in some other channels, and it seems that the current state of segregated witness is not as bad as I feared. Apparently, segwit transactions will remain optional (even after a 95% vote lock in), and hard forks can only arise if miners take funds from the anyone-can-spend outputs without respecting that they may not be authorized to according to segwit. It's still a risk, just not as bad as I thought. But the next question is, why allow even this risk? What is the gain? You gain just small savings on the size, if all you care about is state of outputs without signatures. And if you care about both, you are actually increasing the amount of data needed per transaction: in the block, you store the state _plus_ links to the signatures, and in the segwit data, you store the signatures. So this may actually decrease the incentive for people to verify the signatures. I would propose an alternative: Don't use anyone-can-spend outputs, but instead use segwit only for complicated mulisig transactions (P2WPKH nested in BIP16 P2SH) and future transactions that may require huge signatures (like confidential transactions). That way, we don't create the opportunity for more hard forking events, and we still get a boost in capacity and choice of what parts to verify. Or even alternatively, you can keep the anyone-can-spend with special meaning for segwit, but use it a use-at-your own risk. Miners can steal the coins, but they don't have much of an incentive to (it would damage the value of Bitcoin), and these transaction can have less fees, since they take up a bit less space. If you want to be more safe, then use transactions with signed scriptSigs. If we really want to boost the capacity, then I would recommend other block extensions such as the Subchains proposal I made: https://bitcointalk.org/index.php?topic=1083345.0. Note that this is not the same as Peter R's subchains, and it is probably a form of "sharding"). Lightning will also help, obviously. I also think people should look at the big picture here. If we want a truly decentralized system, we need to get in the decentralized mindset. In the ideal case of perfect decentralization, every one is a miner. Everyone mines a little, everyone verifies a little, everyone signs a little, everyone relays a little. So when you soft fork and say you are giving more power to the validators and you are taking freedom away from the miners, this no longer makes sense once we have decentralization: taking freedom away from the miners will also mean taking freedom away from the validators i.e. all users. It will no longer be as easy as a phone call to two mining pool admins in order to resolve the hard fork (BIP 66). In a decentralized system, rules change fluidly, incrementally, smoothly, and not as step functions in the form of software releases at instants of time. Now, you may argue that the tightened rules we've made so far were essentially bug fixes, or just clearing up a vague idea that already existed. For example, I think nLockTime existed before OP_CHECKLOCKTIMEVERIFY. But still, we should be careful, since any extra rule is an extra hard fork attack vector waiting to happen. -- PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 _______________________________________________ bitcoin-discuss mailing list bitcoin-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
