Exit maturity

[chjj]

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:

Like you said, add a maturity requirement for exiting outputs. Likely lower than coinbase's 100 block requirement. To solve the issue of non-upgraded wallets not being aware of this rule and spending early, have upgraded mempool implementations accept/relay txs that contain early spends of exits, but not mine them until they are mature. This way non-upgraded wallets do not end up broadcasting transactions that are considered invalid to the rest of the network.

Depending on how wallets handle reorgs, a non-upgraded wallet may put reorg'd spend chains from exits back into an unconfirmed state, when in reality they should probably delete them or mark them conflicted in some way. This may be an acceptable compromise as the wallet will still see the funds as unconfirmed when they really don't exist anymore, but maybe unconfirmed is good enough. Users are pretty used to dropping non-confirming txs from their wallet, and this is much better than legacy wallets seeing there funds as confirmed when they could be permanently reorged out at any moment.

Second solution:

Move all exiting outputs to the coinbase. [The coinbase receives the extra funds it needs from the resolution transactions fee. The exiting value must be subtracted from the resolution output.] This will enforce a 100 block maturity requirement and non-upgraded wallets will be aware of this.

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?

[chjj]

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,

• Coinbase solution: no upgrades to wallets required, hard 100 block requirement, upgrades to GBT and mining clients required
• Resolution solution: upgrades to wallets (optional), flexible maturity requirement, some kind of "nursery" must be implemented for the mempool

[chjj]

cc @gasteve

[jl2012]

@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

[afk11]

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.

[chjj]

@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.

[jujumax]

@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.