From: "Clément Elbaz" <clem.ds@gmail.com>
To: "Jorge Timón" <jtimon@jtimon.cc>, "Mike Hearn" <hearn@vinumeris.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Date: Mon, 05 Oct 2015 12:08:27 +0000 [thread overview]
Message-ID: <CAP63atY+yH5BinWYAyxkqER5wA9Lj6pFC0LritSDLcDuBVbXrg@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDp1r78OtM=MfHqvV17-6N=nCG+hFOwqL0R6DHz9SjLmsg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]
It will get correct results about :
- the existence every block
- the existence of every transaction
It will get incorrect results :
- about the *nature* of some transactions
- and therefore, about the balances of some wallets.
I fully agree with Mike here.
Le lun. 5 oct. 2015 à 14:04, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
> On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > Well, let's agree to disagree on these two things:
> >
> > - I define "working" for a full node as verifying everything; if a node
> starts skipping bits then I'd say it's not really "working" according to
> its original design goals
>
> But assuming the hashrate majority has upgraded (and we're using 95% as
> the miner upgrade confirmation threshold to start activation, so that
> assumption seems pretty safe), a non-upgraded full node and an upgraded
> full will converge on what they see: "the most-work valid chain" will be
> the same for both. A non-upgraded full node wallet waiting for several
> confirmations (for example, 6 confirmations) will be just as safe as an
> upgraded one. In that sense, it keeps working. On top of that, nodes (of
> any kind) can use unknown block version numbers to notify the user or even
> stop working (the same notification mechanism you would use with hardforks).
>
> I agree that hardforks are necessary and we should deploy a hardfork asap
> to show the world they are indeed possible (bip99 proposes a likely
> uncontroversial one), but I still believe that is clear that softfork
> deployment is preferrable in many cases like this one.
>
> Are you going to produce a bip65 hardfork alternative to try to convince
> people of its advantages over bip65 (it is not clear to me how you include
> a new script operand via hardfork)?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2779 bytes --]
next prev parent reply other threads:[~2015-10-05 12:08 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-02 1:57 [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! NotMike Hearn
2015-10-02 2:12 ` GC
2015-10-05 10:59 ` Mike Hearn
2015-10-05 11:23 ` Jeff Garzik
2015-10-05 11:28 ` Mike Hearn
2015-10-05 12:04 ` Jorge Timón
2015-10-05 12:08 ` Clément Elbaz [this message]
2015-10-05 12:16 ` Jorge Timón
2015-10-05 12:29 ` Clément Elbaz
2015-10-05 15:42 ` Jorge Timón
2015-10-05 12:10 ` Mike Hearn
2015-10-05 15:33 ` Jorge Timón
2015-10-05 16:46 ` Mike Hearn
2015-10-06 6:20 ` Anthony Towns
2015-10-07 6:13 ` Micha Bailey
2015-10-05 13:29 ` Jorge Timón
2015-10-05 13:24 ` Jorge Timón
-- strict thread matches above, loose matches on Subject: below --
2015-09-27 18:50 Peter Todd
2015-09-27 20:26 ` jl2012
2015-09-27 20:27 ` Peter Todd
2015-09-27 20:27 ` Mark Friedenbach
2015-09-27 20:41 ` Btc Drak
2015-09-28 10:10 ` s7r
2015-09-28 10:48 ` Mike Hearn
2015-09-28 11:00 ` Adam Back
2015-09-28 11:40 ` Mike Hearn
2015-09-28 12:20 ` Eric Lombrozo
2015-09-28 12:26 ` Mike Hearn
2015-09-28 12:44 ` Eric Lombrozo
2015-09-28 12:54 ` Mike Hearn
2015-09-29 6:17 ` Eric Lombrozo
2015-09-29 12:02 ` Mike Hearn
2015-09-28 14:05 ` Btc Drak
2015-09-28 14:17 ` Mike Hearn
2015-09-28 21:12 ` odinn
2015-09-28 22:16 ` Dave Scotese
2015-09-28 11:04 ` Eric Lombrozo
2015-09-28 12:47 ` Tier Nolan
2015-09-28 13:01 ` Gavin Andresen
2015-09-28 13:28 ` Peter Todd
2015-09-28 13:43 ` Gavin Andresen
2015-09-28 14:14 ` Peter Todd
2015-09-28 13:21 ` Peter Todd
2015-09-28 13:41 ` Mike Hearn
2015-09-28 14:29 ` Peter Todd
2015-09-28 14:33 ` Mike Hearn
2015-09-28 14:43 ` Peter Todd
2015-09-28 14:51 ` Mike Hearn
2015-09-28 15:05 ` Peter Todd
2015-09-28 15:38 ` Mike Hearn
2015-09-28 16:52 ` jl2012
2015-09-28 17:14 ` Mike Hearn
2015-09-28 23:17 ` Jorge Timón
2015-09-29 12:07 ` Mike Hearn
2015-09-29 13:30 ` Jonathan Toomim (Toomim Bros)
2015-09-29 15:59 ` jl2012
2015-09-29 19:54 ` odinn
2015-09-29 18:31 ` Gregory Maxwell
2015-09-30 17:11 ` Mike Hearn
2015-09-30 17:58 ` Jorge Timón
2015-10-01 14:23 ` Tom Harding
2015-09-30 18:15 ` Adam Back
2015-09-30 19:26 ` Jeff Garzik
2015-09-30 19:56 ` Mike Hearn
2015-09-30 20:37 ` Jorge Timón
2015-09-30 21:06 ` Mike Hearn
2015-09-30 22:14 ` Jorge Timón
2015-10-01 0:11 ` Jorge Timón
2015-09-30 22:17 ` Jeff Garzik
2015-09-30 23:25 ` Gregory Maxwell
2015-09-30 20:15 ` Gregory Maxwell
2015-09-30 21:01 ` Mike Hearn
2015-09-30 22:59 ` Gregory Maxwell
2015-10-07 15:00 ` Anthony Towns
2015-10-07 15:46 ` Jonathan Toomim (Toomim Bros)
2015-10-07 16:02 ` Eric Lombrozo
2015-10-07 16:25 ` Eric Lombrozo
2015-10-07 16:26 ` Jonathan Toomim (Toomim Bros)
2015-10-07 16:38 ` Anthony Towns
2015-10-10 7:23 ` Anthony Towns
2015-10-12 7:02 ` digitsu
2015-10-12 16:33 ` Anthony Towns
2015-10-12 17:06 ` Anthony Towns
2015-10-13 0:08 ` digitsu
2015-09-29 20:03 ` Wladimir J. van der Laan
2015-09-30 4:05 ` Rusty Russell
2015-09-30 6:19 ` Adam Back
2015-09-30 12:30 ` Mike Hearn
2015-09-30 15:55 ` Jorge Timón
2015-09-30 19:17 ` John Winslow
2015-10-01 0:06 ` Rusty Russell
2015-09-30 17:14 ` Adam Back
2015-10-01 0:04 ` Rusty Russell
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=CAP63atY+yH5BinWYAyxkqER5wA9Lj6pFC0LritSDLcDuBVbXrg@mail.gmail.com \
--to=clem.ds@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=hearn@vinumeris.com \
--cc=jtimon@jtimon.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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