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] 2015-09-24 #bitcoin-dev Weekly Development Meeting Minutes

Hello Daniel, On Thu, Sep 24, 2015 at 05:29:02PM -0700, Daniel Stadulis via bitcoin-dev wrote: > If you weren't able to attend the first, weekly development meeting, the > following are the minutes: Thanks for writing up the meeting minutes and posting them to the list! We should probably put

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] Weak block thoughts...

2015-09-27 21:50 GMT+02:00 Gregory Maxwell : > On Sun, Sep 27, 2015 at 3:10 PM, Kalle Rosenbaum via bitcoin-dev > wrote: > > I was mansplaining weak blocks to my wife. She asked a simple question: > > > > Why would I, as a miner, publish

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] Bitcoin mining idea

Don't solicit interest in advance of content, please. Share your idea first and if people find it cogent and interesting they will volunteer interest/assistance. On 27 September 2015 at 18:53, Neil Haran via bitcoin-dev wrote: > Hi, > > I have an idea for a

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 >