Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
Hey Matt, OK, let's get started However, there hasnt been any discussion on this mailing list in several years as far as I can tell. Probably because this list is not a good place for making progress or reaching decisions. Those are triggered by pull requests (sometimes). If you're

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 12:59:13PM -0400, Gavin Andresen wrote: Fee dynamics seems to come up over and over again in these discussions, with lots of talk and theorizing. I hope some data on what is happening with fees right now might help, so I wrote another blog post (with graphs, which

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
The only answer to this that anyone with a clue should give is it will very, very likely be able to support at least 1MB blocks roughly every 10 minutes on average for the next eleven years, and it seems likely that a block size increase of some form will happen at some point in the next

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 3:31 PM, Alan Reiner etothe...@gmail.com wrote: (1) Blocks are essentially nearing full now. And by full he means that the reliability of the network (from the average user perspective) is about to be impacted in a very negative way Er, to be economically precise,

[Bitcoin-development] Fwd: Block Size Increase

2015-05-07 Thread Gavin Andresen
On Thu, May 7, 2015 at 1:26 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: I think this is a huge issue. You've been wandering around telling people that the blocksize will increase soon for months I think the strongest thing I've ever said is: There is consensus that the max block size

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Chris Wardell
Instead of raising the block size to another static number like 20MB, can we raise it dynamically? Make the max block size something like: pow(2, nHeight/10) * 1MB; //double every ~2 years -- One dashboard for

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Alex Mizrahi
Just to add to the noise, did you consider linear growth? Unlike exponential growth, it approximates diminishing returns (i.e. tech advances become slower with time). And unlike single step, it will give people time to adapt to new realities. E.g. 2 MB in 2016, 3 MB in 2017 and so on. So in 20

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 3:03 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: More generally, consider the situation we're in now. Gavin is going off pitching this idea to the general public (which, I agree, is an important step in pulling off a hardfork) while people who actually study the

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Matt Corallo
On 05/07/15 11:29, Mike Hearn wrote: Can you please elaborate on what terrible things will happen if we don't increase the block size by winter this year? I was referring to winter next year. 0.12 isn't scheduled until the end of the year, according to Wladimir. I explained where

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jérémie Dubois-Lacoste
Any proposal to switch to a new hardcorded value so we have time to *really* figure out later what's next and all implications, is a road to a gigantic issue later when we want to switch to that next. Sure we would have more time to think about, research all implications, simulate, discuss, etc.

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Bernard Rihn
It seems to me like some (maybe most) of the pressure is actually external from companies that might release something that dramatically increases adoption transaction rates (and that the data on historic rate of adoption slumps is somewhat disconnected from their interests in a quick roll-out)?

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Gavin Costin
Can anyone opposed to this proposal articulate in plain english the worst case scenario(s) if it goes ahead? Some people in the conversation appear to be uncomfortable, perturbed, defensive etc about the proposal Š. But I am not seeing specifics on why it is not a feasible plan. From: Mike

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 09:54 PM, Jeff Garzik wrote: By the time we get to fee pressure, in your scenario, our network node count is tiny and highly centralized. Again, this assertion requires proof. Simply saying things is not the same as them being true.

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jérémie Dubois-Lacoste
I have written up an explanation of what I think will happen if we run out of capacity: https://medium.com/@octskyward/crash-landing-f5cc19908e32 Looks like a solid description of what would happen. I fail to see how this description wouldn't be applicable also to a 20MB-network in some

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Btc Drak
On Thu, May 7, 2015 at 6:43 PM, Mike Hearn m...@plan99.net wrote: And I'll ask again. Do you have a *specific, credible alternative*? Because so far I'm not seeing one. I think you are rubbing against your own presupposition that people must find and alternative right now. Quite a lot here do

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Ross Nicoll
I'm presuming that schedule is just an example, as you'd end up with insanely large block sizes in a few years. Absolutely, yes, an increase schedule is an option if people agree on it, and I think the better option, as the current limit too low, but jumping straight to a value big enough for

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Alan Reiner
This *is* urgent and needs to be handled right now, and I believe Gavin has the best approach to this. I have heard Gavin's talks on increasing the block size, and the two most persuasive points to me were: (1) Blocks are essentially nearing full now. And by full he means that the reliability

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 6:59 PM, Gavin Andresen gavinandre...@gmail.com wrote: Fee dynamics seems to come up over and over again in these discussions, with lots of talk and theorizing. I hope some data on what is happening with fees right now might help, so I wrote another blog post (with

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
I think you are rubbing against your own presupposition that people must find and alternative right now. Quite a lot here do not believe there is any urgency, nor that there is an immanent problem that has to be solved before the sky falls in. I have explained why I believe there is some

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
These statements may even be true, but they're no logical conclusions even if they seem obvious to you. I don't think those claims are strictly true, specially because they involve predictions about what people will do. But if they're true they require some proof or at least some explanation.

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Ross Nicoll
Can I just add my own support for this - as has been stated elsewhere in this discussion, hard forks are difficult, and risky. The earlier we have a decision, and the earlier the change goes into the code, the easier that is. Even if the decision was the actual block size change is fine to

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Btc Drak
On Thu, May 7, 2015 at 7:40 PM, Gavin Costin slashdevn...@hotmail.com wrote: Can anyone opposed to this proposal articulate in plain english the worst case scenario(s) if it goes ahead? Some people in the conversation appear to be uncomfortable, perturbed, defensive etc about the proposal ….

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Matt Corallo
Replies inline. On 05/07/15 17:43, Mike Hearn wrote: The only answer to this that anyone with a clue should give is it will very, very likely be able to support at least 1MB blocks roughly every 10 minutes on average for the next eleven years, and it seems likely that a block

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
The appropriate method of doing any fork, that we seem to have been following for a long time, is to get consensus here and on IRC and on github and *then* go pitch to the general public So your concern is just about the ordering and process of things, and not about the change itself? I

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Btc Drak
On Thu, May 7, 2015 at 5:11 PM, Mike Hearn m...@plan99.net wrote: Right now there is this nice warm fuzzy notion that decisions in Bitcoin Core are made by consensus. Controversial changes are avoided. I am trying to show you that this is just marketing. Consensus is arrived when the people

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-07 Thread Joseph Poon
Hi Matt, I agree that starting discussion on how to approach this problem is necessary and it's difficult taking positions without details on what is being discussed. A simple hard 20-megabyte increase will likely create perverse incentives, perhaps a method can exist with some safe transition.

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Tom Harding
On 5/7/2015 12:54 PM, Jeff Garzik wrote: In the short term, blocks are bursty, with some on 1 minute intervals, some with 60 minute intervals. This does not change with larger blocks. I'm pretty sure Alan meant that blocks are already filling up after long inter-block intervals. 2)

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 10:02:09PM +, Matt Corallo wrote: OK, so lets do that. I've seen a lot of I'm not entirely comfortable with committing to this right now, but think we should eventually, but not much I'd be comfortable with committing to this when I see X. In the interest of

[Bitcoin-development] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY

2015-05-07 Thread Tier Nolan
One of the suggestions to avoid the problem of fees going to zero is assurance contracts. This lets users (perhaps large merchants or exchanges) pay to support the network. If insufficient people pay for the contract, then it fails. Mike Hearn suggests one way of achieving it, but it doesn't

[Bitcoin-development] Block Size Increase Requirements

2015-05-07 Thread Matt Corallo
OK, so lets do that. I've seen a lot of I'm not entirely comfortable with committing to this right now, but think we should eventually, but not much I'd be comfortable with committing to this when I see X. In the interest of ignoring debate and pushing people towards a consensus at all costs, ( ;)

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread 21E14
I am more fazed by PR 5288 and PR 5925 not getting merged in, than by this thread. So, casting my ballot in favor of the block size increase. Clearly, we're still rehearsing proper discourse, and that ain't gonna get fixed here and now. On Thu, May 7, 2015 at 9:29 PM, Matt Corallo

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Joel Joonatan Kaartinen
Having observed the customer support nightmare it tends to cause for a small exchange service when 100% full blocks happen, I've been thinking that the limit really should be dynamic and respond to demand and the amount of fees offered. It just doesn't feel right when it takes ages to burn through

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
Can you please elaborate on what terrible things will happen if we don't increase the block size by winter this year? I was referring to winter next year. 0.12 isn't scheduled until the end of the year, according to Wladimir. I explained where this figure comes from in this article:

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 1:29 PM, Mike Hearn m...@plan99.net wrote: I was referring to winter next year. 0.12 isn't scheduled until the end of the year, according to Wladimir. I explained where this figure comes from in this article:

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 11:25:04AM +0200, Mike Hearn wrote: Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase. I'm afraid I have come to disagree. I no longer believe this community can reach consensus

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Andrew
I'm mainly just an observer on this. I mostly agree with Pieter. Also, I think the main reason why people like Gavin and Mike Hearn are trying to rush this through is because they have some kind of apps that depend on zero conf instant transactions, so this would of course require more traffic on

Re: [Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Pieter Wuille
On May 7, 2015 3:08 PM, Roy Badami r...@gnomon.org.uk wrote: On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote: I would not modify my node if the change introduced a perpetual 100 BTC subsidy per block, even if 99% of miners went along with it. Surely, in that scenario Bitcoin

Re: [Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Cameron Garnham
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 While being in the Bitcoin community for a long time, I haven't been so directly involved in the development. However I wish to suggest a different pre-hard-fork soft-fork approach: Set a 'block size cap' in the similar same way as we set

Re: [Bitcoin-development] Solution for Block Size Increase

2015-05-07 Thread Thy Shizzle
Nicolas, can you think if there would be a problem with allowing blocks to be created faster instead of increasing block size? So say if difficulty was reduced to allow block creation every 2 minutes instead of 10 minutes, can you think of any bad outcome from this (I know this is different to

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Tom Harding
On 5/7/2015 7:09 PM, Jeff Garzik wrote: G proposed 20MB blocks, AFAIK - 140 tps A proposed 100MB blocks - 700 tps For ref, Paypal is around 115 tps VISA is around 2000 tps (perhaps 4000 tps peak) I ask again: where do we want to go? This is the existential question behind block size.

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 9:40 PM, Tom Harding t...@thinlink.com wrote: On 5/7/2015 12:54 PM, Jeff Garzik wrote: 2) Where do you want to go? Should bitcoin scale up to handle all the world's coffees? Alan was very clear. Right now, he wants to go exactly where Gavin's concrete proposal

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 03:31:46PM -0400, Alan Reiner wrote: We get asked all the time by corporate clients about scalability. A limit of 7 tps makes them uncomfortable that they are going to invest all this time into a system that has no chance of handling the economic activity that they

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Tom Harding
On 5/7/2015 6:40 AM, Jorge Timón wrote: Known: There's a major problem looming for miners at the next block reward halving. Many are already in a bad place and without meaningful fees then sans a 2x increase in the USD:BTC ratio then many will simply have to leave the network, increasing

Re: [Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Adam Back
Well this is all very extreme circumstances, and you'd have to assume no rational player with an interest in bitcoin would go there, but to play your analysis forward: users are also not powerless at the extreme: they could change the hash function rendering current deployed ASICs useless in

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jeff Garzik
I have a lot more written down, a WIP; here are the highlights. - The 1MB limit is an ancient anti-spam limit, and needs to go. - The 1MB limit is economically entrenched at this point, and cannot be removed at a whim. - This is a major change to the economics of a $3.2B system. This change

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Bryan Bishop
On Thu, May 7, 2015 at 9:05 AM, Mike Hearn m...@plan99.net wrote: Maybe you dislike that idea. It's so centralised. So let's say Gavin commits his patch, because his authority is equal to all other committers. Someone else rolls it back. Gavin sets up a cron job to keep committing the

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 04:05:41PM +0200, Mike Hearn wrote: Peter: your hypocrisy really is bottomless, isn't it? You constantly claim to be a Righteous Defender of Privacy, but don't even hesitate before publishing hacked private emails when it suits you. Satoshi's hacker had no illusions

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 1:55 PM, Dave Hudson d...@hashingit.com wrote: Known: There has been a steady trend towards the mean block size getting larger. See https://blockchain.info/charts/avg-block-size?timespan=allshowDataPoints=falsedaysAverageString=7show_header=truescale=0address= Looking at

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
If his explanation was I will change my mind after we increase block size, I guess the community should say then we will just ignore your nack because it makes no sense. Oh good! We can just kick anyone out of the consensus process if we think they make no sense. I guess that means me and

Re: [Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Pieter Wuille
I would not modify my node if the change introduced a perpetual 100 BTC subsidy per block, even if 99% of miners went along with it. A hardfork is safe when 100% of (economically relevant) users upgrade. If miners don't upgrade at that point, they just lose money. This is why a

[Bitcoin-development] Solution for Block Size Increase

2015-05-07 Thread Nicolas DORIER
Executive Summary: I explain the objectives that we should aim to reach agreement without drama, controversy, and relief the core devs from the central banker role. (As Jeff Garzik pointed out) Knowing the objectives, I propose a solution based on the objectives that can be agreed on tomorrow,

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Matt Corallo
On 05/07/15 19:34, Mike Hearn wrote: The appropriate method of doing any fork, that we seem to have been following for a long time, is to get consensus here and on IRC and on github and *then* go pitch to the general public So your concern is just about the ordering and

[Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Roy Badami
I'd love to have more discussion of exactly how a hard fork should be implemented. I think it might actually be of some value to have rough consensus on that before we get too bogged down with exactly what the proposed hard fork should do. After all, how can we debate whether a particular hard

Re: [Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Tier Nolan
In terms of miners, a strong supermajority is arguably sufficient, even 75% would be enough. The near total consensus required is merchants and users. If (almost) all merchants and users updated and only 75% of the miners updated, then that would give a successful hard-fork. On the other hand,

Re: [Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Roy Badami
On the other hand, if 99.99% of the miners updated and only 75% of merchants and 75% of users updated, then that would be a serioud split of the network. But is that a plausible scenario? Certainly *if* the concensus rules required a 99% supermajority of miners for the hard fork to go ahead,

Re: [Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Roy Badami
On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote: I would not modify my node if the change introduced a perpetual 100 BTC subsidy per block, even if 99% of miners went along with it. Surely, in that scenario Bitcoin is dead. If the fork you prefer has only 1% of the hash power it

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Alex Morcos
That strikes me as a dangerous path forward. I don't actually think there is anything wrong with this: everybody eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and we're left with the status quo What gives Bitcoin value aren't its technical merits but the fact that people

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
What gives Bitcoin value aren't its technical merits but the fact that people believe in it. Much of the belief in Bitcoin is that it has a bright future. Certainly the huge price spikes we've seen were not triggered by equally large spikes in usage - it's speculation on that future. I quite

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 05:04 PM, Jeff Garzik wrote: heh - I tend to think people here want bitcoin to succeed. My statement refers to picking winners and losers from within the existing bitcoin community stakeholders. Success is not a sufficiently

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 11:12 AM, Mike Hearn m...@plan99.net wrote: That's why I conclude the opposite - if there is no fork, then people's confidence in Bitcoin will be seriously damaged. Yes, that is a possibility. If it's impossible to do something as trivial as removing a temporary

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier justusranv...@riseup.net wrote: To be extremely specific: should Bitcoin development intenionally limit the network's capabilities to leave room for other projects, or should Bitcoin attempt to be the best system possible and let the other

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jeff Garzik
Yes - but you must recognize that is precisely 50% of the picture. Others have made different assumptions - taking the [1MB-constrained] market *as it exists today*, rather than in some projected future. Raising the block size limit then becomes a *human decision* to favor some users over

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jeff Garzik
Dear list, Apparently my emails are being marked as spam, despite being sent from GMail's web interface. I've pinged our sysadmin. Thanks for letting me know. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Btc Drak
On Thu, May 7, 2015 at 3:05 PM, Mike Hearn m...@plan99.net wrote: Maybe you dislike that idea. It's so centralised. So let's say Gavin commits his patch, because his authority is equal to all other committers. Someone else rolls it back. Gavin sets up a cron job to keep committing the

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 11:33 AM, Justus Ranvier justusranv...@riseup.net wrote: In summary, I asked a question neither you, nor Peter Todd, want to answer and want to actively discourage people from even asking at all. Incorrect; your question included built-in assumptions with which I

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 05:47 PM, Jeff Garzik wrote: Bitcoin needs to be the best it can be (Layer 1), but all solutions cannot and should not be implemented at Layer 1. I can provisionally agree with that statement as long as all solutions cannot and should

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Matthew Mitchell
In my personal opinion, this does make some sense to me, assuming I understood Gavin. I suppose it could be done with a new flag (like the P2SH flag) which displays miner support for larger blocks. The new rules would apply when a large majority of miners support the new rules by counting the

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
It is an argument against my admittedly vague definition of non-controversial change. If it's an argument against something you said, it's not a straw man, right ;) Consensus has to be defined as agreement between a group of people. Who are those people? If you don't know, it's impossible to

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
Dear list, Apparently my emails are being marked as spam, despite being sent from GMail's web interface. I've pinged our sysadmin. It's a problem with the mailing list software, not your setup. BitPay could disable the phishing protections but that seems like a poor solution. The only real

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 03:35 PM, Jeff Garzik wrote: Raising the block size limit then becomes a *human decision* to favor some users over others, a *human decision* to prevent an active and competitive free fee market developing at 1MB, a *human decision*

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen gavinandre...@gmail.com wrote: I would very much like to find some concrete course of action that we can come to consensus on. Some compromise so we can tell entrepreneurs THIS is how much transaction volume the main Bitcoin blockchain will be able

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 04:04 PM, Jeff Garzik wrote: - This is a major change to the economics of a $3.2B system. This change picks winners and losers. There is attendant moral hazard. This is exactly true. There are a number of projects which aren't

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 10:38 AM, Justus Ranvier justusranv...@riseup.net wrote: On 05/07/2015 04:04 PM, Jeff Garzik wrote: - This is a major change to the economics of a $3.2B system. This change picks winners and losers. There is attendant moral hazard. This is exactly true. There are

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 05:13:34PM +0200, Justus Ranvier wrote: On 05/07/2015 04:49 PM, Peter Todd wrote: I think we'll find an basic assumption of civility to be more productive, until proven otherwise. (e.g. NSA ties) I'm not sure why you'd construe my post as having anything to do

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jeff Garzik
100% agree, RE hard forks should be hard. However, it is the paradox of growth, morale and adoption that bitcoin might never reach the point where it is saturated expensive to the point where larger blocks are demanded by 95%+... simply because people and companies chose not to adopt bitcoin in

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 04:49 PM, Peter Todd wrote: I think we'll find an basic assumption of civility to be more productive, until proven otherwise. (e.g. NSA ties) I'm not sure why you'd construe my post as having anything to do with accusations like

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
It is a trivial *code* change. It is not a trivial change to the economics of a $3.2B system. Hmm - again I'd argue the opposite. Up until now Bitcoin has been unconstrained by the hard block size limit. If we raise it, Bitcoin will continue to be unconstrained by it. That's the default

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 10:04:21AM -0400, Jeff Garzik wrote: I have a lot more written down, a WIP; here are the highlights. - The 1MB limit is an ancient anti-spam limit, and needs to go. - The 1MB limit is economically entrenched at this point, and cannot be removed at a whim. - This

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 04:05:41PM +0200, Mike Hearn wrote: One thing is the Bitcoin core project where you could argue that the 5 committers decide (I don't know why Wladimir would have any more authority than the others). Because he is formally the maintainer. I quite liked

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 04:38:22PM +0200, Justus Ranvier wrote: On 05/07/2015 04:04 PM, Jeff Garzik wrote: - This is a major change to the economics of a $3.2B system. This change picks winners and losers. There is attendant moral hazard. This is exactly true. There are a number of

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Gavin Andresen
For reference: the blog post that (re)-started this debate, and which links to individual issues, is here: http://gavinandresen.ninja/time-to-roll-out-bigger-blocks In it, I asked people to email me objections I might have missed. I would still appreciate it if people do that; it is impossible

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 10:52:54AM -0400, Gavin Andresen wrote: I AM considering contributing some version of the bigger blocksize-limit hard-fork patch to the Bitcoin-Xt fork (probably target a hobbyist with a fast Internet connection, and assume Nelson's law to increase over time), and then

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 4:05 PM, Mike Hearn m...@plan99.net wrote: If his explanation was I will change my mind after we increase block size, I guess the community should say then we will just ignore your nack because it makes no sense. Oh good! We can just kick anyone out of the consensus

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 03:27 PM, Jeff Garzik wrote: On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier justusranv...@riseup.net wrote: To be extremely specific: should Bitcoin development intenionally limit the network's capabilities to leave room for

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread John Bodeen
If the worry about raising the block size will increase centralization, could not one could imagine an application which rewarded decentralized storage of block data? It could even be build aside or on top of the existing bitcoin protocol. See the Permacoin paper by Andrew Miller:

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Matthew Mitchell
One thing to add is that perhaps in a future version of Bitcoin Core, there could be an option for users to continue using the old consensus rules, or an option to support the new rules (an option when they update and an ability to change in the settings). Both types of user can benefit from the

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 6:11 PM, Mike Hearn m...@plan99.net wrote: It is an argument against my admittedly vague definition of non-controversial change. If it's an argument against something you said, it's not a straw man, right ;) Yes, but it was an argument against something I didn't said

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Gavin Andresen
Fee dynamics seems to come up over and over again in these discussions, with lots of talk and theorizing. I hope some data on what is happening with fees right now might help, so I wrote another blog post (with graphs, which can't be done in a mailing list post):

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Wladimir J. van der Laan
On Wed, May 06, 2015 at 10:12:14PM +, Matt Corallo wrote: Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Dave Hudson
On 7 May 2015, at 11:52, Jorge Timón jti...@jtimon.cc wrote: On Thu, May 7, 2015 at 11:25 AM, Mike Hearn m...@plan99.net wrote: I observed to Wladimir and Gavin in private that this timeline meant a change to the block size was unlikely to get into 0.11, leaving only 0.12, which would

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Eric Lombrozo
On May 7, 2015, at 4:20 AM, Wladimir J. van der Laan laa...@gmail.com wrote: For sake of brevity, this ignores the inherent practical and political issues in scheduling a hardfork. IMHO, these issues are the elephant in the room and the talk of block size increases is just a distraction.

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 01:29:44PM +0200, Mike Hearn wrote: What if Gavin popped up right now and said he disagreed with every current proposal, he disagreed with side chains too, and there would be no consensus on any of them until the block size limit was raised. Would you say, oh, OK,

Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 11:05:47AM +0930, Rusty Russell wrote: Peter Todd p...@petertodd.org writes: That said, if people have strong feelings about this, I would be willing to make OP_CLTV work as follows: nLockTime 1 OP_CLTV Where the 1 selects absolute mode, and all others act

Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?

2015-05-07 Thread Rusty Russell
Peter Todd p...@petertodd.org writes: That said, if people have strong feelings about this, I would be willing to make OP_CLTV work as follows: nLockTime 1 OP_CLTV Where the 1 selects absolute mode, and all others act as OP_NOP's. A future relative CLTV could then be a future soft-fork

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Matt Corallo
On 05/07/15 14:52, Gavin Andresen wrote: For reference: the blog post that (re)-started this debate, and which links to individual issues, is here: http://gavinandresen.ninja/time-to-roll-out-bigger-blocks In it, I asked people to email me objections I might have missed. I would still

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 06:21:50PM +0200, Jorge Timón wrote: On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen gavinandre...@gmail.com wrote: I would very much like to find some concrete course of action that we can come to consensus on. Some compromise so we can tell entrepreneurs THIS is