From: Mike Hearn <mike@plan99•net>
To: Luke Dashjr <luke@dashjr•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>,
Flavien Charlon <flavien.charlon@coinprism•com>
Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
Date: Fri, 3 Oct 2014 22:58:28 +0200 [thread overview]
Message-ID: <CANEZrP1eGi-AHgciQiKUuUB7WwqKsMOyTjCQAAO=RWEkPC2Uiw@mail.gmail.com> (raw)
In-Reply-To: <201410031750.27323.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]
Alright. It seems there's no real disagreement about how the opcode
behaves. Perhaps a time limit would be appropriate to stop people creating
outputs locked for 100 years .... is bitcoin even likely to exist in 100
years? The entire history of computing is not even that old, seems hard to
imagine that it'd be good for anything beyond wasting space in the
database. But this is a minor point.
So I guess it's time to start the deployment discussion.
Bitcoin is a consensus system. It works best when everyone is following
exactly the same rules at the same time. A soft fork works against this
principle by allowing nodes to think they're following the majority
ruleset, even if they aren't, effectively downgrading them to something a
bit like SPV security without them realising.
A hard fork has multiple desirable properties. Most importantly, it means a
node can detect it's no longer in the consensus because it'll find its own
chain height has diverged significantly from its peers. Core already has
code that knows how to detect this condition and log errors about it as
well as running the alertnotify script i.e. emailing the admin. Ideally it
would also stop serving work so miners shut down or fail over, but this is
easily added to the CheckForkWarningConditions() function.
In other words, this gives the cleanest failure we can give, such that any
procedures a node operator has put in place to alert them of divergence
will be triggered. Any code which is waiting for confirmations will wait
forever at this point, thus minimising the risk of loss.
Additionally, forcing old peers to fall behind means SPV clients will pick
the right chain, and not end up downloading transactions or blocks that are
about to be doomed at the next re-org. They can easily choose to ignore
transactions relayed by peers that are too far behind and thus not end up
accepting transactions that are no longer valid according to the majority
(a scenario which can cause monetary loss).
I don't think hard forks should be scary. Mechanisms are in place to warn
people and they can be scheduled with plenty of time in advance. The main
stated justification for a soft fork is backwards compatibility, but in a
system like Bitcoin you really don't want to be running behind the
consensus and it's hard to imagine any node operator deliberately choosing
to stay on the wrong side of the fork. It's not like other software where
people can choose to skip an upgrade and things still work just like before.
[-- Attachment #2: Type: text/html, Size: 2985 bytes --]
next prev parent reply other threads:[~2014-10-03 20:58 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-01 13:08 Peter Todd
2014-10-01 15:01 ` Gavin Andresen
2014-10-02 1:06 ` Peter Todd
2014-10-01 15:29 ` Sergio Lerner
2014-10-01 17:06 ` Peter Todd
2014-10-01 18:23 ` Luke Dashjr
2014-10-01 20:58 ` Gavin Andresen
2014-10-01 21:04 ` Alan Reiner
2014-10-01 21:34 ` Gavin Andresen
2014-10-02 0:12 ` Peter Todd
2014-10-02 0:05 ` Peter Todd
2014-10-02 0:55 ` Luke Dashjr
2014-10-02 1:09 ` Peter Todd
2014-10-02 15:05 ` Flavien Charlon
2014-10-03 14:28 ` Matt Whitlock
2014-10-03 14:30 ` Matt Whitlock
2014-10-03 16:17 ` Gregory Maxwell
2014-10-03 17:50 ` Luke Dashjr
2014-10-03 20:58 ` Mike Hearn [this message]
2014-10-03 23:12 ` Jeff Garzik
2014-10-04 0:38 ` Peter Todd
2014-10-04 12:58 ` Mike Hearn
2014-10-07 15:50 ` Gavin Andresen
2014-10-07 16:08 ` Mike Hearn
2014-10-08 10:26 ` Wladimir
2014-10-09 3:13 ` Alan Reiner
2014-10-09 6:14 ` Adam Back
2014-10-09 6:28 ` Gregory Maxwell
2014-10-09 6:33 ` Peter Todd
2014-10-09 6:40 ` Gregory Maxwell
2014-10-08 4:07 ` Tom Harding
2014-10-08 10:15 ` Mike Hearn
2015-03-16 22:22 ` [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) Matt Corallo
2015-03-19 17:39 ` Zooko Wilcox-OHearn
2015-04-21 7:59 ` Peter Todd
2015-04-26 11:35 ` Jorge Timón
2015-04-26 12:20 ` Jorge Timón
2015-04-27 19:35 ` Peter Todd
2015-04-28 7:44 ` Jorge Timón
2015-05-04 2:15 ` Matt Corallo
2015-05-04 11:24 ` Jorge Timón
2015-05-05 0:41 ` Btc Drak
2015-05-05 19:19 ` Jorge Timón
2015-05-05 20:38 ` Tier Nolan
2015-05-06 7:37 ` Jorge Timón
2015-05-06 22:09 ` Tier Nolan
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='CANEZrP1eGi-AHgciQiKUuUB7WwqKsMOyTjCQAAO=RWEkPC2Uiw@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=flavien.charlon@coinprism$(echo .)com \
--cc=luke@dashjr$(echo .)org \
/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