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] Bitcoin Core 0.12.0 release schedule

On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via bitcoin-dev wrote: > 2015-12-01 > --- > - Feature freeze Where is "Consensus freeze"? Shouldn't this be put off until after the HK workshop in case a hardfork is decided on? Or have we de-coupled it from the

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] Bitcoin Core 0.12.0 release schedule

Yes, I believe consensus rule changes don't need to be couple with major releases, there's no problem that I can see in them being minor releases if they're not ready on time for a major release. On Wed, Sep 30, 2015 at 7:57 PM, Luke Dashjr via bitcoin-dev

Re: [bitcoin-dev] Design Competition

I've also got a competition where the object is to build a spaceship using only a watermelon, two donkeys, some duct tape, and a fire hydrant. -- Original Message -- From: "Richard Olsen via bitcoin-dev" To: "bitcoin-dev"

[bitcoin-dev] Design Competition

All, We are looking for participants in a Bitcoin related competition: the aim is to build a trading platform (initially for foreign exchange, other assets will follow) which lets participants settle their trades through the blockchain via coloured coins. To facilitate a quicker trade

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] Design Competition

On 9/30/2015 3:16 AM, Eric Lombrozo via bitcoin-dev wrote: I've also got a competition where the object is to build a spaceship using only a watermelon, two donkeys, some duct tape, and a fire hydrant. There are many people interested in starting new services and who are interested in hiring

Re: [bitcoin-dev] Design Competition

This sounds like a cool competition; it is also off-topic for this mailing list, which is focused on bitcoin protocol and reference implementation development. On Wed, Sep 30, 2015 at 2:37 AM, Richard Olsen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > All, > > We are

Re: [bitcoin-dev] Design Competition

Who is funding this? Why not fund Core development? On 30 Sep 2015 7:37 am, "Richard Olsen via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > All, > > We are looking for participants in a Bitcoin related competition: the aim > is to build a trading platform (initially for foreign

Re: [bitcoin-dev] Design Competition

Hi Richard, its great that people with a lot of experience in financial markets take interest in these topics. I don't think you will receive the best answers here. The Bitcointalk Altcoin section is currently the best place for such announcements. I believe there is room for a better board/list

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] [BIP Proposal] Version bits with timeout and delay.

On 9/29/2015 7:05 PM, Rusty Russell wrote: Tom Harding via bitcoin-dev writes: With a simple delay, you can have the embarrassing situation where support falls off during the delay period and there is far below threshold support just moments prior to

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

[bitcoin-dev] Pedantic note on the use of "eventual consistency" to describe Bitcoin [Was: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!]

On Wed, Sep 30, 2015 at 10:14 PM, Jorge Timón wrote: > reason you don't think guaranteed eventual consistency has any value Obligatory pedantic correction: In Bitcoin we don't actually achieve "eventual consistency" of the kind which is usually described in

Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.

I can go along with making it optional but recommended for the first deployment and making it mandatory later on. It would be purely informational for now...but it will give us valuable data. As has been said before, most of these BIP deployments will likely be accompanied by recommended

Re: [bitcoin-dev] Design Competition

I am waiting for the bitcoin (not bitcoin-dev) mailing list so that anyone who writes "That's off-topic" can also include a link to it. Someone else mentioned that they read all these emails in about 15 minutes. I'm a bit slower than that, but I'm reading the vitcoin-xt stuff too. It isn't too

Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.

Gregory Maxwell writes: > I can, however, argue it the other way (and probably have in the > past): The bit is easily checked by thin clients, so thin clients > could use it to reject potentially ill-fated blocks from non-upgraded > miners post switch (which otherwise they

Re: [bitcoin-dev] Design Competition

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Grosses me out that you have enforced KYC as part of what you are doing for anyone who would decide to get involved: https://wiki.lykkex.com/?id=start#lykke_citizens Good luck with that, I'm sure not going to be a part of it, and I recommend that

Re: [bitcoin-dev] Is it possible for there to be two chains after a hard fork?

Gavin, you assume that users must necessarily always follow the hashrate majority, but this is not true. In fact, it is the opposite: market forces make the hashrate follow the users. Not following the hashrate majority is not necessarily insane. If some users aren't happy with the new hardfork

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. >