Open chjj opened 7 years ago
I think I'm leaning towards the first solution. The coinbase solution, while elegant, also may require even more modifications to getblocktemplate as well as upgrades to existing mining clients.
So,
cc @gasteve
@chjj perhaps you missed that but I explained why both solutions are not acceptable: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014124.html
tl;dr: when someone says "pay 1BTC to my address 1xyz", no one expects being paid by a mining output. This is a backward-incompatible softfork
Was coming here to write the same when I saw the article likening the proposal to segwit. https://medium.com/purse-essays/extension-block-commonly-asked-questions-dec3431b7d8d
There are numerous shortcomings extlblocks has to segregated witness, and this is just one of them, because segwit does not require 100-block clearing periods before funds can be withdrawn.
@jl2012, yeah, I don't think the coinbase is the right way to go. Another maturity for resolution outputs is probably better, but still has the edge case you mentioned. I think that edge case is acceptable. You mentioned before that an extra address type could be used for exits. I think this edge case could be mitigated by having wit v1 programs inside the extension block, and only allowing exits to v0 programs. This would increase the probability that wallets receiving these outputs would be aware of the new maturity rule. But this assumes mainchain segwit, which unfortunately may not happen.
@afk11, I agree. It has some shortcomings, but segwit as it exists isn't really on the table anymore. Every opportunity to get segwit activated was squandered due to poor communication, hostility, and general lack of social skills (i.e. calling miners "terrorists" isn't going to make them like your softfork). So, any complaint you have in relation to segwit isn't very relevant.
Extblk is a proposal that tries to be pragmatic given the current situation. It's not meant to be perfect as-is, which is also why we want deactivation built-in. Upgrading to a newer extension block, once an even more appealing ruleset has been developed is the endgame here. Or not, maybe people decide an extension block isn't the right way to go after a number of years. We'll see what happens if it ever gets to that point.
@chjj Agree the maturity rule is not a problem and wallets supporting extblk can easily handle the edge cases that may cause confusion but are at least in the cases we saw secure so like when miner should not spend the coinbase TX until has 100 confirmations we can manage it in the same way, users willing to deal with other users using extblk has to use wallets that support it, users dealing 100% inside canonical block can continue using regular wallets. As much I can see this softfork is backward compatible and can coexist with no problems with non upgraded nodes, miners and wallets.
Exiting outputs definitely need a maturity requirement. This was discussed on the ML: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013994.html
Johnson noted that legacy wallets will have trouble dealing with this, so I think we have two possible solutions. Quoting my post here:
First solution:
Second solution:
The first solution allows more flexibility with the maturity requirement, but is a bit more complex due to the extra mempool behavior.
The second solution is simpler, but sticks to a hard 100 block requirement.
I think I may implement the code for the first solution first, I like the idea of having more flexibility with the maturity requirement. But if we go that route, we need to decide on a reasonable maturity requirement. I think 20 would be pretty safe and reasonable. From a user perspective, it's a little under 3.5 hours for exited outputs to be spendable, and a 20 block reorg on mainnet is extremely unlikely unless something very strange is happening. Though, the longer it is, the more chance there may be fungibility concerns.
Thoughts?