Quote
Andrew <[email protected]> Sat, Oct 29, 2016 at 8:08 AM UTC
To: Andrew C <[email protected]>
Cc: Bitcoin Protocol Discussion <[email protected]>
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://bitcointalksearch.org/topic/scaling-bitcoin-with-subchains-1083345. 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.
To: Andrew C <[email protected]>
Cc: Bitcoin Protocol Discussion <[email protected]>
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://bitcointalksearch.org/topic/scaling-bitcoin-with-subchains-1083345. 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.
I believe I made a mistake by saying that P2WPKH nested in BIP16 P2SH can be enforced without risking a hard fork, because there are no actual signatures in the scriptSig (actually meant to say P2WSH nested in BIP16 P2SH. Right?
But can anyone comment on what they think about restricting segwit only to P2WSH nested in BIP16 P2SH, which means complicated transactions such as multi-sig transactions, smart contracts, confidential transactions. This will help to reduce the attack surface of a hard fork, and really, seg wit seems to only be useful for these larger types of transactions. As I mentioned in my reply, if you are fully validating, segwit actually increases the amount of space required per transaction, and also creates more of an incentive to not fully validate and simply look at the state of the ouputs rather than also checking the signatures.
Any other comments welcome also.
