Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Mon, Oct 12, 2015 at 12:02:51AM -0700, digitsu412 via bitcoin-dev wrote: > First I think your unsaid assumption about the fragility of a soft > fork showing incorrect confirmations is dependent on the percentage > of hash power that didn't upgrade.  If using your same numbers this > was only 5%

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Monday, October 5, 2015, Mike Hearn via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > As Greg explained to you repeatedly, a softfork won't cause a >> non-upgraded full node to start accepting blocks that create more >> subsidy than is valid. >> > > It was an example. Adam

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Tue, Sep 29, 2015 at 06:31:28PM +, Gregory Maxwell via bitcoin-dev wrote: > On Mon, Sep 28, 2015 at 10:48 AM, Mike Hearn via bitcoin-dev > wrote: > > There is no consensus on using a soft fork to deploy this feature. It will > > result in the same

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev wrote: > *But* a soft fork that only forbids transactions that would previously > not have been mined anyway should be the best of both worlds, as it > automatically reduces the liklihood of old

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Oct 7, 2015, at 9:02 AM, Eric Lombrozo wrote: > But a real hashpower supermajority would make such attacks hard to pull off > in practice. If you had a 99% hashpower supermajority on the new version, an attacker would still be able to perform this attack once per

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

You're right about the potential for 1 bad confirmation even with very low frequency...but with an overwhelming supermajority of hashpower, 2 bad confirmations become quite unlikely, n bad confirmations becomes exponentially unlikely in n. As part of such soft fork deployments, it's true that

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Wed, Oct 07, 2015 at 08:46:08AM -0700, Jonathan Toomim (Toomim Bros) via bitcoin-dev wrote: > On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev > wrote: > > *But* a soft fork that only forbids transactions that would previously > > not have been

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Hi Jorge, I'm glad we seem to be reaching agreement that hard forks aren't so bad really and can even have advantages. It seems the remaining area of disagreement is this rollout specifically. > a non-upgraded full node and an upgraded full will converge on what they > see: "the most-work valid

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

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"

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Oct 5, 2015 2:08 PM, "Clément Elbaz" wrote: > > 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 Given the assumptions above, only of

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

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 - Saying the pre-fork behaviour is defined and deterministic is true, but

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

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

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Mon, Oct 5, 2015 at 2:29 PM, Clément Elbaz wrote: > The problem is that some transactions that are meaningless to you are > actually meaningful to people using an upgraded Bitcoin software. > > Therefore during a softfork, while you can not miss the existence of a >

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

> > As Greg explained to you repeatedly, a softfork won't cause a > non-upgraded full node to start accepting blocks that create more > subsidy than is valid. > It was an example. Adam Back's extension blocks proposal would, in fact, allow for a soft forking change that creates more subsidy than

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On 9/30/2015 10:58 AM, Jorge Timón via bitcoin-dev wrote: > I don't think we need to wait for you to understand the advantages of > softforks to move forward with BIP65, just like we didn't need to wait > for every developer and user to understand BIP66 to deploy it. What a bad example. BIP66

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Reply-To: NotMike Hearn <not.mike.he...@gmail.com> Date: Friday, 2 October 2015 9:57 am To: <bitcoin-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev <bitcoin-dev@lists.linux

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev wrote: > There is no consensus on using a soft fork to deploy this feature. It will > result in the same problems as all the other soft forks - SPV wallets will > become less reliable during the

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Wed, Sep 30, 2015 at 1:11 PM, Mike Hearn via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Several people have asked several times now: given the very real and > widely acknowledged downsides that come with a soft fork, *what* is the > specific benefit to end users of doing

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On 30 September 2015 at 13:11, Mike Hearn via bitcoin-dev wrote: >> Have I missed a proposal to change BIP101 to be a real hardfork > > There's no such thing as a "real" hard fork - don't try and move the goal > posts. SPV clients do not need any changes to

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Wed, Sep 30, 2015 at 7:11 PM, Mike Hearn via bitcoin-dev wrote: > Several people have asked several times now: given the very real and widely > acknowledged downsides that come with a soft fork, what is the specific > benefit to end users of doing them?

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Two observations from a Bitcoin investor and non-programmer: 1) I think it's possible that those who are adamantly opposed to a soft fork may be largely (if not completely) correct on purely technical terms, but that they also may be underestimating the risk of a contentious hardfork. 2)

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

I think from discussion with Gavin sometime during the montreal scaling bitcoin workshop, XT maybe willing to make things easy and adapt what it's doing. For example in relation to versionBits Gavin said he'd be willing to update XT with an updated/improved versionBits, for example. It seems

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

> > Exactly, all those "mini divergences" eventually disappear > A miner that has accepted a newly invalid transaction into its memory pool and is trying to mine it, will keep producing invalid blocks forever until the owner shuts it down and upgrades. This was happening for weeks after P2SH

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

> > Field experience shows it successfully delivers new features to end users > without a global software upgrade. > The global upgrade is required for all full nodes in both types. If a full node doesn't upgrade then it no longer does what it was designed to do; if the user is OK with that, they

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Sep 30, 2015 9:56 PM, "Mike Hearn via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Jorge has said soft forks always lead to network convergence. No, they don't. You get constant mini divergences until everyone has upgraded, as opposed to a single divergence with a hard fork

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

tl;dr Nothing I have read here has changed my mind. There is still no consensus to deploy CLTV in this way. > Yes, your article contained numerous factual and logical inaccuracies > which I corrected > I responded to your response several times. It was not convincing, and I do not think you

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Wed, Sep 30, 2015 at 5:11 PM, Mike Hearn wrote: > Hi Gregory, > >> >> I'm surprised to see this response > > > Why? I have objected to the idea of soft forks many times. I wrote an entire > article about it in August. Yes, your article contained numerous factual and

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

> > I think from discussion with Gavin sometime during the montreal > scaling bitcoin workshop, XT maybe willing to make things easy and > adapt what it's doing. If Core ships CLTV as is, then XT will have to adopt it - such is the nature of a consensus system. This will not change the fact

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Wed, Sep 30, 2015 at 11:06 PM, Mike Hearn wrote: >> Exactly, all those "mini divergences" eventually disappear > > A miner that has accepted a newly invalid transaction into its memory pool > and is trying to mine it, will keep producing invalid blocks forever until > the

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Adam Back writes: > I think from discussion with Gavin sometime during the montreal > scaling bitcoin workshop, XT maybe willing to make things easy and > adapt what it's doing. For example in relation to versionBits Gavin > said he'd be willing to update XT with an

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Wed, Sep 30, 2015 at 10:17 PM, Jeff Garzik wrote: > It is correct that security is slightly reduced for full nodes that have not > upgraded. It is not correct that the choice is binary, full node or SPV. > > Any user running a not-upgraded full node still retains protection

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Wed, Sep 30, 2015 at 9:01 PM, Mike Hearn wrote: > I coined the term SPV so I know exactly what it means, and bitcoinj The term comes from the Bitcoin whitepaper. > On the other hand, full nodes all claim they run scripts. Users expect that > and may be relying on it. The

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Wed, Sep 30, 2015 at 3:56 PM, Mike Hearn wrote: > Field experience shows it successfully delivers new features to end users >> without a global software upgrade. >> > > The global upgrade is required for all full nodes in both types. If a full > node doesn't upgrade then

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Tue, Sep 29, 2015 at 2:07 PM, Mike Hearn wrote: > Hi Jorge, > >> Yes, there is a difference. Assuming the hashrate majority upgrades, in >> the case of a softfork [snip] .. In the case of a hardfork [snip] > > Yes, I know what the difference between them is at a

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Hi Gregory, > I'm surprised to see this response Why? I have objected to the idea of soft forks many times. I wrote an entire article about it in August. I also objected in April 2014, for instance, where Pieter agreed with me that soft forks can result in ugly hacks, and that they are "not

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

I was talking about the versionBits from Rusty's email (pasted below) and simplifying that by XT adopting the patch as Gavin had seemed agreeable to. Adam Rusty wrote: > Agreed. Unfortunately, a simple "block version >= 4" check is > insufficient, due to XT which sets version bits 001111. >

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Mike, Insults were not really my intention. Let's set aside our differences regarding SPV security and assume you understand the different implications for soft forks and hard forks. Other than the fact that doing this as a soft fork requires an extra OP_DROP, how would doing this as a hard

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Sep 28, 2015, at 7:43 AM, Peter Todd via bitcoin-dev wrote: > > Ok, so again, if that's your security criteria, what's the issue with > soft-forks? With soft-forks, the result of a SPV wallet following the > highest work chain is the same: eventually

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

> > Other than the fact that doing this as a soft fork requires an extra > OP_DROP, how would doing this as a hard fork make any difference to SPV > clients? If, as others have suggested, all clients warn the user on > unrecognized nVersion > All clients do *not* do this. Why would they? What

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Hi Jorge, Yes, there is a difference. Assuming the hashrate majority upgrades, in the > case of a softfork [snip] .. In the case of a hardfork [snip] > Yes, I know what the difference between them is at a technical level. You didn't explain why this would make any difference to how fast

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Jonathan Toomim (Toomim Bros) via bitcoin-dev 於 2015-09-29 09:30 寫到: SPV clients will appear to behave normally, and will continue to show new transactions and get confirmations in a timely fashion. However, they will be systematically susceptible to attack from double-spends that attempt to

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

"Wladimir J. van der Laan via bitcoin-dev" writes: > On Sun, Sep 27, 2015 at 02:50:31PM -0400, Peter Todd via bitcoin-dev wrote: > >> It's time to deploy BIP65 CHECKLOCKTIMEVERIFY. > > There appears to be common agreement on that. > > The only source of some

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, (see my remarks below) jl2012 via bitcoin-dev: > Jonathan Toomim (Toomim Bros) via bitcoin-dev 於 2015-09-29 09:30 寫 > 到: >> SPV clients will appear to behave normally, and will continue to >> show new transactions and get confirmations in a

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Sun, Sep 27, 2015 at 02:50:31PM -0400, Peter Todd via bitcoin-dev wrote: > It's time to deploy BIP65 CHECKLOCKTIMEVERIFY. There appears to be common agreement on that. The only source of some controversy is how to deploy: versionbits versus IsSuperMajority. I think the versionbits proposal

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Mike Hearn via bitcoin-dev 於 2015-09-28 11:38 寫到: My point about IsStandard is that miners can and do bypass it, without expecting that to carry financial consequences or lower the security of other users. By making it so a block which includes non-standard transactions can end up being seen as

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

> > Can you explain exactly how you think wallets will "know" how to ignore > the invalid chain? > I'm confused - I already said this. For a fork to work, hard or soft, there must be support from a majority of the hash power. Therefore, the usual SPV technique of following the highest work chain

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Mon, Sep 28, 2015 at 03:41:56PM +0200, Mike Hearn wrote: > > > > 1) Do you agree that CLTV should be added to the Bitcoin protocol? > > > > Ignoring the question how exactly it is added, hard-fork or soft-fork. > > > > The opcode definition seems OK. Good! > > 2) Will you add a

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Mon, Sep 28, 2015 at 09:43:42AM -0400, Gavin Andresen wrote: > On Mon, Sep 28, 2015 at 9:28 AM, Peter Todd wrote: > > > > 2) Mr. Todd (or somebody) needs to write up a risk/benefit security > > > tradeoff analysis doo-hickey document and publish it. I'm reasonably > > >

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Mon, Sep 28, 2015 at 04:33:23PM +0200, Mike Hearn wrote: > > > > SPV wallets can't detect hard-forks > > > They don't have to - they pick the highest work chain. Any miner who hasn't > upgraded makes blocks on the shorter chain that are then ignored (or > rather, stored for future reorgs).

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Perhaps Adam won't go into the rationale...but I think it is important we clarify this. For better or worse, the only "voting" system available to Bitcoin that cannot be trivially attacked is hashing power. Soft forks are essentially miner-enforced rule changes...rules they could have decided

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

My initial reaction is just HUH?!?!? Is this some sophisticated form of humor I'm just not getting? On September 28, 2015 3:48:57 AM PDT, Mike Hearn via bitcoin-dev wrote: >There is *no* consensus on using a soft fork to deploy this feature. It >will

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 +1 I was actually waiting for this. It makes 'smart contracts' simpler and better from many points of view. Pete I don't see anything about RCLTV in BIP65, was that a separate BIP? Which one is it and are we also deploying it via IsSuperMajority()?

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

There is *no* consensus on using a soft fork to deploy this feature. It will result in the same problems as all the other soft forks - SPV wallets will become less reliable during the rollout period. I am against that, as it's entirely avoidable. Make it a hard fork and my objection will be

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Why are they called soft forks when they are really hidden forks? Isn't the point of a soft fork to prevent old clients from rejecting what they don't have the code to validate? That seems dangerous. notplato On Mon, Sep 28, 2015 at 2:12 PM, odinn via bitcoin-dev <

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

I think three things need to happen: 1) Stop pretending that "everyone must agree to make consensus rule changes." "Rough consensus" is what we've always gone with, and is good enough. 2) Mr. Todd (or somebody) needs to write up a risk/benefit security tradeoff analysis doo-hickey document and

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Mon, Sep 28, 2015 at 12:48:57PM +0200, Mike Hearn wrote: > There is *no* consensus on using a soft fork to deploy this feature. It > will result in the same problems as all the other soft forks - SPV wallets > will become less reliable during the rollout period. I am against that, as > it's

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Mon, Sep 28, 2015 at 09:01:02AM -0400, Gavin Andresen wrote: > I think three things need to happen: > > 1) Stop pretending that "everyone must agree to make consensus rule > changes." "Rough consensus" is what we've always gone with, and is good > enough. > > 2) Mr. Todd (or somebody) needs

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

SPV wallets in their current form are inherently insecure. Moreover, while we at least have a soft fork mechanism that is not trivially exploitable (yes, it's got issues...but unlike SPV wallets, it isn't so easily exploitable), we have NO hard fork mechanism in place that isn't highly prone to

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Mon, Sep 28, 2015 at 11:48 AM, Mike Hearn via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 1) Drop the "everyone must agree to make changes" idea that people here > like to peddle, and do it loudly, so everyone in the community is correctly > informed > There never was a rule

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

> > 1) Do you agree that CLTV should be added to the Bitcoin protocol? > > Ignoring the question how exactly it is added, hard-fork or soft-fork. > The opcode definition seems OK. > 2) Will you add a IsSuperMajority() CLTV soft-fork to Bitcoin XT if it >is added to Bitcoin Core? > Yes. It

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Mon, Sep 28, 2015 at 9:28 AM, Peter Todd wrote: > > 2) Mr. Todd (or somebody) needs to write up a risk/benefit security > > tradeoff analysis doo-hickey document and publish it. I'm reasonably > > confident that the risks to SPV nodes can be mitigated (e.g. by deploying >

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Agree with all CLTV and nVersionBits points. We should deploy a lock-time soft-fork ASAP, using the tried and true IsSuperMajoirty test. However your information regarding BIPs 68 (sequence numbers), 112 (checksequenceverify) and 113 (median time past) is outdated. Debate regarding semantics has

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Sun, Sep 27, 2015 at 04:26:12PM -0400, jl2...@xbt.hk wrote: > +1 for deploying BIP65 immediately without further waiting. Agree > with all Peter's points. Thanks! > By the way, is there any chance to backport it to 0.9? In the > deployment of BIP66 some miners requested a backport to 0.9 and

[bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Summary --- It's time to deploy BIP65 CHECKLOCKTIMEVERIFY. I've backported the CLTV op-code and a IsSuperMajority() soft-fork to the v0.10 and v0.11 branches, pull-reqs #6706 and #6707 respectively. A pull-req for git HEAD for the soft-fork deployment has been open since June 28th, #6351 -

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

+1 for deploying BIP65 immediately without further waiting. Agree with all Peter's points. If BIP65 has to follow the 0.12 schedule, it will take almost 9 months from now to complete the softfork. I don't see any good reason to wait for that long. We have too much talk, too little action.

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Sun, Sep 27, 2015 at 7:50 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 10) Waiting for nVersion bits and CHECKSEQUENCEVERIFY will significantly > delay deployment of CLTV > > It's been proposed multiple times that we wait until we can do a single >