nathan-at-least
commented
8 years ago We had a discussion about this just now. There are some subtle user-facing impacts here:
Reorg-Triggered Invalidation: We already have a similar issue whenever re-orgs invalidate JoinSplit anchors, in which case the user experience is transaction reversal where funds are 'returned to original senders' at the reorg point. In the additional case that reorg > coinbase maturity, not only do some of the funds get returned to senders, but some 'evaporate' (although other miners have received a similar amount of funds). In some cases, such as the reversion of a single step of JS xfer, a friendly business may reissue a transfer to make some prior economic trade whole. In the case of longer chains, it's much less clear. I don't see the coinbase maturity making much of a difference compared to the invalidation of JoinSplits.
Wallclock Time as Security Parameter: The maturity level should not only be measured in blocks, because the wall-clock time has two crucial features:
- opportunity cost: if the wallclock time is X hours, this is X hours of opportunity cost to a malicious miner. An attack of X hours needs to be compared to the next best alternative which may be unrelated to how many blocks fit into X hours. Eg: a large RAM farm does protein folding for money. Diverting those resources for an attack for X hours is independent of blocks-per-time.
- community reaction time: if an anomaly is detected and the community reacts, if they can do so during the maturity interval, they can prevent widespread (non-young-anchor JoinSplit) txn invalidation.
Again, because JoinSplit invalidation exists, this complicates the utility of the coinbase maturity for me.
bitcartel
str4d
The longest Bitcoin reorg I know of was this six-hour one in 2012.