Remove Extra Coinbase Locktime about research-lab HOT 5 OPEN

It seems the coinbase lock time idea originated in Bitcoin (thanks to @SChernykh for the link). The rationale was to mitigate a situation where a reorg invalidates coinbase outputs and by extension all outputs created by transactions that depend on those coinbase outputs. Bitcoin went out of its way to add this rule because it can impact users interacting with completely honest funds, i.e. a reorg that does not double-spend any of the funds in some outputs' tx histories can still invalidate those outputs. There is no mandatory lock time on normal Bitcoin outputs because normal outputs in a reorged Bitcoin tx may not be invalidated if the tx's inputs are not double spent (and aren't part of a tx tree containing double-spent outputs), because those kinds of txs can be re-mined into the reorged chain.

In Monero, a reorg may invalidate a decoy ring member (either its index, or block it completely with a double spend), which would invalidate a normal transaction that's otherwise valid (i.e. because its real inputs are still on-chain). Since it is generally not safe to reference decoys that may be reorged away, it used to be the core wallet's policy to not select tx inputs or decoys from the most recent 10 blocks of the chain. Alternate wallet implementations could select inputs or decoys from that range if desired (and some did). Since selecting young inputs/decoys can't be a general wallet policy, it is privacy hole that was plugged up by mandating a 10-block lock time on normal outputs in v12 of the protocol. Reorgs invalidating decoy ring members and therefore invalidating honest txs is also a user-expectation problem, in the same way as coinbase outputs being invalidated.

The 10-block normal output lock and 60-block coinbase output lock were therefore implemented to mitigate the same problem - reorgs that invalidate txs without any of the direct participants performing a double spend. This begs the question, is there a reason for the mandatory locktime on those two output types to be different (aside from the conservative argument - don't change what isn't broken)?

from research-lab.

I've dug up some history and shared it on Matrix, but posting it here too for visibility.

In his initial 2014 bitmonero release forking bytecoin, thankful_for_today made the decision to increase the coinbase unlock time from 10 to 60 while simultaneously decreasing the block time from 2 minutes to 1 minute: monero-project/monero@1a8f5ce

When asked about it by a confused miner, he said "60 blocks unlock delay. This is much safer." with no further clarification: https://bitcointalk.org/index.php?topic=563821.msg6283927#msg6283927

from research-lab.

Bitcoin went out of its way to add this rule because it can impact users interacting with completely honest funds, i.e. a reorg that does not double-spend any of the funds in some outputs' tx histories can still invalidate those outputs.

Since we are assuming honesty, this could also just be enforced by the wallet instead of at the consensus layer.

from research-lab.

@ChristopherKing42 I'm pretty sure it's the other way around. You should be assuming hostile adversaries everywhere.
Don't trust, verify.

from research-lab.

With FCMPs, any reorg deeper than 10 blocks will always permanently invalidate all transactions. Therefore I suggest that the 60-block coinbase lock time be reduced to 10 blocks if/when FCMPs are implemented.

from research-lab.