From: Mike Hearn <mike@plan99•net>
To: Gavin Andresen <gavinandresen@gmail•com>
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: Tue, 7 Oct 2014 18:08:13 +0200 [thread overview]
Message-ID: <CANEZrP2Xp7ene+KDw_L_YnNW=hDt9K-UigvZ6PLb3oUviOr_Tw@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T0Q8g9KYRbAvCV=35x5Rb5HFnrNkrwwMZ=Mv-namMEPpg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]
>
> That is easy to change; I'll submit a pull request.
>
That's certainly a useful improvement. It won't help the existing userbase
though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major
release. If there's going to be an intermediate release (6 months?) which
lays the groundwork for future rule changes, it helps more.
It would be good if getblocktemplate was updated at the same time to serve
errors if the fork warning is active. I'd hope miners have some way to
automatically handle IBD/getting forked off the chain, but I guess some
(newer) pools might not, and refusing to serve work should be the safest
option that shuts them down.
I don't have any opinion on the hard- versus soft- fork debate. I think
> either can work.
>
P2SH was a soft fork and the sky did not fall, but miners did lose money
and waste electricity mining blocks on the wrong side of the chain:
https://bitcointalk.org/index.php?topic=75294.0
Presumably they didn't notice for longer because it looked like a run of
unusually bad orphaning luck. It seems safer to have a clean fork, with
alerts telling people during the lockin period before new rule enforcement
starts (and possibly automated termination if there's no upgrade by the
flag day?). Miners who ignore it would still risk losing money, but
merchants who wait for a block at least would not be at risk.
One open question is how can you actually trigger a hard fork? Coinbase
scriptSigs are not executed, so putting some ignored but failing opcode
sequence there wouldn't work. One possibility would be to have a special
invalid tx in the block that marks the start of new rule enforcement. New
nodes would know to ignore it. But this risks corrupting block explorers.
Alternatively the coinbase outpoint structure could have its hash set to 1
instead of 0.
[-- Attachment #2: Type: text/html, Size: 2765 bytes --]
next prev parent reply other threads:[~2014-10-07 16:08 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
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 [this message]
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='CANEZrP2Xp7ene+KDw_L_YnNW=hDt9K-UigvZ6PLb3oUviOr_Tw@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=flavien.charlon@coinprism$(echo .)com \
--cc=gavinandresen@gmail$(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