search

tothemoon-org / extension-blocks

Extension blocks soft-fork specification
40 stars 6 forks source link

Pick a deactivation strategy #11

Open chjj opened 7 years ago

chjj commented 7 years ago

We have two options: merkle proofs or anyone-can-spend. Both documented in the spec.

I'm more partial to the anyone-can-spend route. It sounds scary at first glance, but I don't think it would actually pose an issue in practice.

The merkle proof route requires a lot more engineering, and in reality would only permit exits back to the main chain. Assuming the ext. block UTXO set grows larger than the main chain UTXO set, this was cause a large backlog for exits. The original thought was to allow merkle proof importation directly into the new ext. block, but since we have no idea how future ext. blocks might behave, this is a bit tricky to implement now.

chjj commented 7 years ago

cc @josephpoon

jujumax commented 7 years ago

I think is nice to have a deactivation process, is hard to see for me the circumstances why deactivation is required but considering wish to include the feature the best is the simplest possible because to create an overcomplicated mechanism will increase the code compexity and increase future devs learning curve.