Re: [bitcoin-dev] Build: win64: Package 'mingw-w64-dev' has no installation candidate

Ah, I didn't notice, thanks! On Mon, Sep 28, 2015 at 7:23 PM, Joseph Bisch wrote: > Hi Roy, > > It looks like your TeamCity setup is using Ubuntu Trusty to perform > the build. Travis CI is using Ubuntu Precise instead[0]. The > mingw-w64-dev package is only available in

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] libconsensus and bitcoin development process

There seemed to be some agreement on IRC - after a bit of haranguing by myself :) -- that large refactors should (a) occur over a small window of time and (b) have a written plan beforehand. On Tue, Sep 22, 2015 at 7:49 PM, Dave Scotese wrote: > If I'm reading this

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

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

I keep seeing statements like this: On Tue, Sep 29, 2015 at 9:30 AM, Jonathan Toomim (Toomim Bros) via bitcoin-dev wrote: > As a further benefit to hard forks, anybody who is ideologically opposed > to the change can continue to use the old version

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

[bitcoin-dev] Why soft-forks? was: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

> So I'll repeat the question that I posed before - given that there are clear, > explicit downsides, > what is the purpose of doing things this way? Where is the gain for ordinary > Bitcoin users? +1 for a direct answer to this question. ___

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

You don't need to appeal to human psychology. At 75% threshold, it takes only 25.01% of the hashpower to report but not actually enforce the fork to cause the majority hashpower to remain on the old chain, but for upgraded clients to start rejecting the old chain. With 95% the same problem exists

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

At the 95% threshold, I don't think it would happen unless there was a very strong motivating factor, like a small group believing that CLTV was a conspiracy run by the NSA agent John Titor to contaminate our precious bodily fluids with time-traveling traveler's cheques. At the 75% threshold,

[bitcoin-dev] On bitcoin-dev list admin and list noise

This was discussed in IRC, but (did I miss it?) never made it to the list outside of being buried in a longer summary. There is a common complain that bitcoin-dev is too noisy. The response plan is to narrow the focus of the list to near term technical changes to the bitcoin protocol and its

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] On bitcoin-dev list admin and list noise

This mailing list was never meant to be a place "to hold the bitcoin development community accountable for its actions [sic]." I know other developers that have switched to digest-only or unsubscribed. I know if this became a channel for PR and populist venting as you describe, I would leave as

Re: [bitcoin-dev] Bitcoin mining idea

On Tue, Sep 29, 2015 at 7:16 PM, Milly Bitcoin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 9/29/2015 7:02 PM, Jonathan Toomim (Toomim Bros) wrote: > >> Making statements about a developer's personal character is also >> off-topic for this list. >> > > If that were true

Re: [bitcoin-dev] Bitcoin mining idea

Since 2011 and bitcoin-development, the list was always intended to focus on the highly technical bits of the core software, and avoid wandering into never-ending philosophical discussions. Example: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2011-June/thread.html What happened

Re: [bitcoin-dev] Bitcoin mining idea

On 9/29/2015 5:07 PM, Jeff Garzik via bitcoin-dev wrote: This is off-topic for this list. You like to go around pretending you are in charge and telling people what to do. You have no such authority and your time is probably better spent reviewing your company's Bitcoin handling and

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule

ACK On Thu, Sep 24, 2015 at 7:25 AM, Wladimir J. van der Laan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello all, > > The next major release of Bitcoin Core, 0.12.0 is planned for the end of > the year. Let's propose a more detailed schedule: > > 2015-11-01 >

Re: [bitcoin-dev] Bitcoin mining idea

Making statements about a developer's personal character is also off-topic for this list. On Sep 29, 2015, at 3:58 PM, Milly Bitcoin via bitcoin-dev wrote: > On 9/29/2015 5:07 PM, Jeff Garzik via bitcoin-dev wrote: >> This is off-topic for this list. >

Re: [bitcoin-dev] Bitcoin mining idea

On 9/29/2015 7:02 PM, Jonathan Toomim (Toomim Bros) wrote: Making statements about a developer's personal character is also off-topic for this list. If that were true then probably 20-30% of the posting here would be off-topic. lol. Russ ___

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

Hi all, Pieter and Eric pointed out that the current BIP has miners turning off the bit as soon as it's locked in (75% testnet / 95% mainnet). It's better for them to keep setting the bit until activation (2016 blocks later), so network adoption is visible. I'm not proposing another

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

On Wed, Sep 30, 2015 at 2:30 AM, Rusty Russell wrote: > Hi all, > > Pieter and Eric pointed out that the current BIP has miners > turning off the bit as soon as it's locked in (75% testnet / 95% > mainnet). It's better for them to keep setting the bit until

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

While I would like to get some form of explicit acknowledgment from miners that a new rule is in effect, the truth of the matter is we still lack a means to determine whether or not miners are actually enforcing these rules...unless someone happens to mine a block that breaks the new rule.

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

Tom Harding via bitcoin-dev writes: > On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote: >> '''Success: Activation Delay''' >> The consensus rules related to ''locked-in'' soft fork will be enforced in >> the second retarget period; ie. there is a

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] Versionbits BIP (009) minor revision proposal.

Good points, Greg. The way I see it, this mechanism isn't really about "voting" - it's about deployment of fairly uncontroversial changes with the minimum amount of negative disruption. If we have reason to believe a particular BIP stands little chance of hitting the 95% mark relatively

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

>A dishonest miner majority can commit fraud against you, they can mine only empty blocks, they can do various other things that render your money worthless. Mining empty blocks is not fraud. If you want to use terms like "honest miners" and "fraud", please define them so we can at least be on

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

We really shouldn't have to go over "Bitcoin 101" on this mailing list, and this discussion should move to the not-yet-created more general discussion list. I started this thread as a sanity check on myself, because I keep seeing smart people saying that two chains could persist for more than a

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

> > Mining empty blocks is not fraud. > I didn't say it was, sorry, the comma was separating two list items. By "fraud" I meant double spending. Mining only empty blocks would be a DoS attack rather than double spending. ___ bitcoin-dev mailing list

Re: [bitcoin-dev] On bitcoin-dev list admin and list noise

> On 29 Sep 2015, at 19:29, Mike Hearn via bitcoin-dev > wrote: > > There's a simple way to cut down on "noise" that doesn't involve people > shouting OFFTOPIC at each other: the maintainer needs to resolve discussions > by making decisions and saying,

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

>If you start with the premise that more than half of Bitcoin miners would do something crazy that would either destroy Bitcoin or would be completely unacceptable to you, personally... then maybe you should look for some other system that you might trust more, because Bitcoin's basic security

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

On Tue, Sep 29, 2015 at 1:24 PM, Allen Piscitello < allen.piscite...@gmail.com> wrote: > I fail to see how always following a majority of miners no matter what > their actions somehow equates to insanity. Ok, I have a hidden assumption: I assume most miners are also not completely insane. I

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

>I started this thread as a sanity check on myself, because I keep seeing smart people saying that two chains could persist for more than a few days after a hard fork, and I still don't see how that would possibly work. When you start with the assumption that anyone who disagrees with you is

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

[bitcoin-dev] Are 'soft forks' misnamed? [was: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!]

On Mon, Sep 28, 2015 at 10:16 PM, Dave Scotese via bitcoin-dev wrote: > 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?