Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-31 Thread Gavin Andresen
On Sun, May 31, 2015 at 10:59 AM, Jorge Timón jti...@jtimon.cc wrote: Whatever...let's use the current subsidies, the same argument applies, it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B. Miner B would still go out of business, bigger blocks still mean more mining and

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-31 Thread Jorge Timón
On May 31, 2015 5:08 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Sun, May 31, 2015 at 10:59 AM, Jorge Timón jti...@jtimon.cc wrote: Whatever...let's use the current subsidies, the same argument applies, it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B. Miner B

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-31 Thread Gavin Andresen
On Sun, May 31, 2015 at 3:05 AM, Peter Todd p...@petertodd.org wrote: Yeah, I'm pretty surprised myself that Gavin never accepted the compromises offered by others in this space for a slow growth solution What compromise? I haven't seen a specific proposal that could be turned into a pull

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-31 Thread Gavin Andresen
On Sun, May 31, 2015 at 10:46 AM, Jorge Timón jti...@jtimon.cc wrote: Here's a thought experiment: Subsidy is gone, all the block reward comes from fees. I wrote about long-term hypotheticals and why I think it is a big mistake to waste time worrying about them here:

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-31 Thread Jorge Timón
Whatever...let's use the current subsidies, the same argument applies, it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B. Miner B would still go out of business, bigger blocks still mean more mining and validation centralization. The question is how far I we willing to go with

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-30 Thread Matt Corallo
On 05/29/15 23:48, Gavin Andresen wrote: On Fri, May 29, 2015 at 7:25 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: Sadly, this is very far from the whole story. The issue of miners optimizing for returns has been discussed several times during

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-30 Thread Alex Mizrahi
Stop trying to dictate block growth limits. Block size will be determined by competition between miners and availability of transactions, not through hard-coded limits. Do you even game theory, bro? It doesn't work that way. Mike Hearn described the problem in this article:

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-30 Thread Gavin Andresen
On Fri, May 29, 2015 at 7:42 PM, Chun Wang 1240...@gmail.com wrote: Hello. I am from F2Pool. We are currently mining the biggest blocks on the network. Thanks for giving your opinion! Bad miners could attack us and the network with artificial big blocks. How? I ran some simulations,

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-29 Thread Gavin Andresen
Matt brought this up on Twitter, I have no idea why I didn't respond weeks ago (busy writing blog posts, probably): On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: * Though there are many proposals floating around which could significantly decrease block

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-29 Thread Matt Corallo
On 05/29/15 22:36, Gavin Andresen wrote: Matt brought this up on Twitter, I have no idea why I didn't respond weeks ago (busy writing blog posts, probably): On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: * Though

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-29 Thread Chun Wang
Hello. I am from F2Pool. We are currently mining the biggest blocks on the network. So far top 100 biggest bitcoin blocks are all from us. We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. I know most blocks would not be 20 MB over night. But

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-16 Thread Tier Nolan
On Sat, May 9, 2015 at 4:08 AM, Peter Todd p...@petertodd.org wrote: I wonder if having a miner flag would be good for the network. Makes it trivial to find miners and DoS attack them - a huge risk to the network as a whole, as well as the miners. To mitigate against this, two chaintips

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-16 Thread Tier Nolan
On Sat, May 16, 2015 at 5:39 AM, Stephen stephencalebmo...@gmail.com wrote: I think this could be mitigated by counting confirmations differently. We should think of confirmations as only coming from blocks following the miners' more strict rule set. So if a merchant were to see payment for

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-15 Thread Stephen
Comments in line: On May 8, 2015, at 11:08 PM, Peter Todd p...@petertodd.org wrote: Makes it trivial to find miners and DoS attack them - a huge risk to the network as a whole, as well as the miners. Right now pools already get DoSed all the time through their work submission systems;

Re: [Bitcoin-development] Block Size Increase

2015-05-13 Thread Oliver Egginger
08.05.2015 at 5:49 Jeff Garzik wrote: To repeat, the very first point in my email reply was: Agree that 7 tps is too low For interbank trading that would maybe enough but I don't know. I'm not a developer but as a (former) user and computer scientist I'm also asking myself what is the core

Re: [Bitcoin-development] Block Size Increase

2015-05-13 Thread Angel Leon
Personally, for privacy reasons I do not want to leave a footprint in the blockchain for each pizza. And why should this expense be good for trivial things of everyday life? Then what's the point? Isn't this supposed to be an Open transactional network, it doesn't matter if you don't want that,

Re: [Bitcoin-development] Block Size Increase

2015-05-09 Thread Andrew
The nice thing about 1 MB is that you can store ALL bitcoin transactions relevant to your lifetime (~100 years) on one 5 TB hard drive (1*6*24*365*100=5256000). Any regular person can run a full node and store this 5 TB hard drive easily at their home. With 10 MB blocks you need a 50 TB drive just

Re: [Bitcoin-development] Block Size Increase

2015-05-09 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/2015 02:02 PM, Andrew wrote: The nice thing about 1 MB is that you can store ALL bitcoin transactions relevant to your lifetime (~100 years) on one 5 TB hard drive (1*6*24*365*100=5256000). Any regular person can run a full node and store

Re: [Bitcoin-development] Block Size Increase

2015-05-09 Thread Andrew
On Sat, May 9, 2015 at 12:53 PM, Justus Ranvier justusranv...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/2015 02:02 PM, Andrew wrote: The nice thing about 1 MB is that you can store ALL bitcoin transactions relevant to your lifetime (~100 years) on one 5 TB

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-08 Thread Arkady
] Block Size Increase Thanks Matt; I was actually really confused by this sudden push with not a word here or on Github--so much so that I responded on Reddit to people pointing to commits in Gavin's personal repository saying they were reading too much into it. I saw this. I was also pointing

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-08 Thread Mike Hearn
* Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. With a 20mb cap, miners still have the option of the soft limit. I would actually be quite surprised if there were no point along the road

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Mike Hearn
Alan argues that 7 tps is a couple orders of magnitude too low By the way, just to clear this up - the real limit at the moment is more like 3 tps, not 7. The 7 transactions/second figure comes from calculations I did years ago, in 2011. I did them a few months before the sendmany command was

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Alan Reiner
This isn't about everyone's coffee. This is about an absolute minimum amount of participation by people who wish to use the network. If our goal is really for bitcoin to really be a global, open transaction network that makes money fluid, then 7tps is already a failure. If even 5% of the

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Alan Reiner
On 05/08/2015 01:13 AM, Tom Harding wrote: 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) For reference, I'm not proposing 100 MB blocks

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Andrew
On Fri, May 8, 2015 at 2:59 PM, Alan Reiner etothe...@gmail.com wrote: This isn't about everyone's coffee. This is about an absolute minimum amount of participation by people who wish to use the network. If our goal is really for bitcoin to really be a global, open transaction network

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Jeff Garzik
On Fri, May 8, 2015 at 10:59 AM, Alan Reiner etothe...@gmail.com wrote: This isn't about everyone's coffee. This is about an absolute minimum amount of participation by people who wish to use the network. If our goal is really for bitcoin to really be a global, open transaction network

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-08 Thread Peter Todd
On Fri, May 08, 2015 at 12:03:04PM +0200, Mike Hearn wrote: * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. With a 20mb cap, miners still have the option of the soft limit. The

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-08 Thread Tier Nolan
On Fri, May 8, 2015 at 5:37 PM, Peter Todd p...@petertodd.org wrote: The soft-limit is there miners themselves produce smaller blocks; the soft-limit does not prevent other miners from producing larger blocks. I wonder if having a miner flag would be good for the network. Clients for general

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Alan Reiner
Actually I believe that side chains and off-main-chain transactions will be a critical part for the overall scalability of the network. I was actually trying to make the point that (insert some huge block size here) will be needed to even accommodate the reduced traffic. I believe that it is

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Raystonn
Replace by fee is what I was referencing.  End-users interpret the old transaction as expired.  Hence the nomenclature. An alternative is a new feature that operates in the reverse of time lock, expiring a transaction after a specific time. But time is a bit unreliable in the blockchain

Re: [Bitcoin-development] Block Size Increase (Raystonn)

2015-05-08 Thread Damian Gomez
Hello, I was reading some of the thread but can't say I read the entire thing. I think that it is realistic to cinsider a nlock sixe of 20MB for any block txn to occur. THis is an enormous amount of data (relatively for a netwkrk) in which the avergage rate of 10tps over 10 miniutes would allow

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Mark Friedenbach
Transactions don't expire. But if the wallet is online, it can periodically choose to release an already created transaction with a higher fee. This requires replace-by-fee to be sufficiently deployed, however. On Fri, May 8, 2015 at 1:38 PM, Raystonn . rayst...@hotmail.com wrote: I have a

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Raystonn
Replace by fee is the better approach. It will ultimately replace zombie transactions (due to insufficient fee) with potentially much higher fees as the feature takes hold in wallets throughout the network, and fee competition increases. However, this does not fix the problem of low tps. In fact,

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-08 Thread Peter Todd
On Fri, May 08, 2015 at 08:47:52PM +0100, Tier Nolan wrote: On Fri, May 8, 2015 at 5:37 PM, Peter Todd p...@petertodd.org wrote: The soft-limit is there miners themselves produce smaller blocks; the soft-limit does not prevent other miners from producing larger blocks. I wonder if

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Thomas Zander
On Wednesday 6. May 2015 21.49.52 Peter Todd wrote: I'm not sure if you've seen this, but a good paper on this topic was published recently: The Economics of Bitcoin Transaction Fees The obvious flaw in this paper is that it talks about a block size in todays (trivial) data-flow economy and

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Raystonn .
I have a proposal for wallets such as yours. How about creating all transactions with an expiration time starting with a low fee, then replacing with new transactions that have a higher fee as time passes. Users can pick the fee curve they desire based on the transaction priority they want to

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Mark Friedenbach
The problems with that are larger than time being unreliable. It is no longer reorg-safe as transactions can expire in the course of a reorg and any transaction built on the now expired transaction is invalidated. On Fri, May 8, 2015 at 1:51 PM, Raystonn rayst...@hotmail.com wrote: Replace by

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,

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
Hearn m...@plan99.net Date: Friday, 8 May, 2015 2:06 am To: Btc Drak btcd...@gmail.com Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Block Size Increase I think you are rubbing against your own presupposition that people must find and alternative

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

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

  1   2   >