From: Gregory Maxwell <gmaxwell@gmail•com>
To: Flavien Charlon <flavien.charlon@coinprism•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...
Date: Fri, 28 Nov 2014 12:03:52 +0000 [thread overview]
Message-ID: <CAAS2fgSeMqS9-jkqMR=hH5cLLne_u3iJDig3cTZfnnnZeuf_sQ@mail.gmail.com> (raw)
In-Reply-To: <CABbpET_VLEZ5W+gTJWYXhafTDWd-dqj79iXjPFkARwV0K3CJTg@mail.gmail.com>
On Fri, Nov 28, 2014 at 11:45 AM, Flavien Charlon
<flavien.charlon@coinprism•com> wrote:
>> This breaks existing invariants and would make the coins potentially less
>> fungible because they wouldn't be reorg safe.
>
> I'm not sure coins are ever reorg safe. All it takes is a double spend in
> the history of your coins for them to become invalid after a reorg. Because
> of that, there are already less fungible coins. This is why we recommend 6
> confirmations for important payments.
I used the word 'less' intentionally. A double spend requires an
active action. Roughly 1% of blocks are lost to reorganizations by
chance, longer otherwise harmless reorgs as we've had in the past
could forever destroy large chunks of coins if descendants had the
unwelcome properties of having additional constraints on them. Past
instances where the network had a dozen block reorganization which
were harmless and simply confirmed the same transactions likely would
have caused substantial losses if it reorganizations precluded the
recovery of many transactions which were valid when placed earlier in
the chain.
Additionally your '6 confirmations' is a uniform rule. The
recommendation is just a count, it's tidy. It's not a "traverse the
recent history of each coin you receive to determine if its script
conditions make it unusually fragile and subject to irrecoverable
loss", which is the space you can get into with layering violations
and transaction validity depending on arbitrary block data.
prev parent reply other threads:[~2014-11-28 12:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 22:56 Richard Moore
2014-11-27 23:46 ` Gregory Maxwell
2014-11-28 3:18 ` Peter Todd
2014-11-28 11:45 ` Flavien Charlon
2014-11-28 12:03 ` Gregory Maxwell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAS2fgSeMqS9-jkqMR=hH5cLLne_u3iJDig3cTZfnnnZeuf_sQ@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=flavien.charlon@coinprism$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox