Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

[Mike Hearn <mike@plan99.net>]

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

>
> When you have a *bitcoin* TXn buried under 100 blocks you can be damn
>
sure that money is yours - but only because the rules for interpreting
> data in the blockchain are publicly documented and (hopefully)
> immutable. If they're mutable then the PoW alone gives me no confidence
> that the money is really mine, and we're left with a much less useful
> system. This should be more sacred than the 21m limit.


Well, I think we should avoid the term "sacred" - nothing is sacred because
we're not building a religion here, we're engineering a tool.

Consider a world in which 1 satoshi is too valuable to represent some kinds
of transactions, so those transactions stop happening even though we all
agree they're useful. The obvious solution is to change the rules so there
can be 210 million coins and 10x everyones UTXOs at some pre-agreed flag
day. We probably wouldn't phrase it like that, it's easier for people to
imagine what's happening if it's phrased as "adding more places after the
decimal point" or something, but at the protocol level coins are
represented using integers, so it'd have to be implemented as a multiply.

Would this be a violation of the social contract? A violation of all that
is sacred? I don't think so, it'd just be sensible engineering and there'd
be strong consensus for that exactly because 21 million *is* so arbitrary.
If all balances and prices multiply 100-fold overnight, no wealth is
reallocated which would be the *actual* violation of the social
contract: we just get more resolution for setting prices.

So. The thing that protects your money from confiscation is not proof of
work. PoW is just a database synchronisation mechanism. The thing that
protects your money from confiscation is a strong group consensus that
theft is bad. But that's a social rule, not a mathematical rule.

[-- Attachment #2: Type: text/html, Size: 2356 bytes --]