Re: [Bitcoin-development] Block Size Increase Requirements

On May 31, 2015 5:08 PM, "Gavin Andresen" wrote: > > On Sun, May 31, 2015 at 10:59 AM, Jorge Timón 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,

Re: [Bitcoin-development] Block Size Increase Requirements

On Sun, May 31, 2015 at 10:59 AM, Jorge Timón 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 validation c

Re: [Bitcoin-development] Block Size Increase Requirements

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

On Sun, May 31, 2015 at 10:46 AM, Jorge Timón 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: http://gavinandresen.ninja/when-the

Re: [Bitcoin-development] Block Size Increase Requirements

On May 30, 2015 10:38 PM, "Gavin Andresen" wrote: > > Mining is a competitive business, the marginal miner will ALWAYS be going out of business. > > That is completely independent of the block size, block subsidy, or transaction fees. No, the later determines who can be profitable. Here's a thoug

Re: [Bitcoin-development] Block Size Increase Requirements

On Sun, May 31, 2015 at 3:05 AM, Peter Todd 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 request. > Some

Re: [Bitcoin-development] Block Size Increase Requirements

On Sat, May 30, 2015 at 07:42:16AM +0800, Chun Wang wrote: > 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 r

Re: [Bitcoin-development] Block Size Increase Requirements

Linear growth is indeed the 'simplest' model for growth so removes concerns of complexity using such a growth model. Seems like it might be a safe compromise between exponential growth, zero growth and buys some time to observe the longer term scale network behaviour. A simple linear growth 'hard

Re: [Bitcoin-development] Block Size Increase Requirements

> > 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: https://medi

Re: [Bitcoin-development] Block Size Increase Requirements

> Why 20 MB? Do you anticipate 20x transaction count growth in 2016? > > Do you anticipate linear growth? > It's safe to say that absolutely nobody can predict the actual growth with any degree of an accuracy. I believe that linear growth compares very favorably to other alternatives: 1. Exponent

Re: [Bitcoin-development] Block Size Increase Requirements

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.  I see now the temporary 1MB limit was a mistake.  It should have gone in as a dynamic limit that scales with average block size.

Re: [Bitcoin-development] Block Size Increase Requirements

> Why 20 MB? Do you anticipate 20x transaction count growth in 2016? Do you anticipate linear growth? > On May 30, 2015, at 6:05 PM, Alex Mizrahi wrote: > > >> Why 2 MB ? > > Why 20 MB? Do you anticipate 20x transaction count growth in 2016? > > Why not grow it by 1 MB per year? > This is

Re: [Bitcoin-development] Block Size Increase Requirements

> Why 2 MB ? > Why 20 MB? Do you anticipate 20x transaction count growth in 2016? Why not grow it by 1 MB per year? This is a safer option, I don't think that anybody claims that 2 MB blocks will be a problem. And in 10 years when we get to 10 MB we'll get more evidence as to whether network can

Re: [Bitcoin-development] Block Size Increase Requirements

On Sat, May 30, 2015 at 3:32 PM, Matt Corallo wrote: > If, for example, the majority of miners are in China (they are), and > there is really poor connectivity in and out of China (there is) and a > miner naively optimizes for profit, they will create blocks which are > large and take a while to

Re: [Bitcoin-development] Block Size Increase Requirements

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

Re: [Bitcoin-development] Block Size Increase Requirements

On Sat, May 30, 2015 at 9:57 PM, Gavin Andresen wrote: > 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

Re: [Bitcoin-development] Block Size Increase Requirements

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 simulatio

Re: [Bitcoin-development] Block Size Increase Requirements

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 onl

Re: [Bitcoin-development] Block Size Increase Requirements

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 > wrote: > > > > * Though there are many pro

Re: [Bitcoin-development] Block Size Increase Requirements

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 wrote: > > > * Though there are many proposals floating around which could > significantly decrease block propagation latency, none of

Re: [Bitcoin-development] Block Size Increase Requirements

On Sat, May 16, 2015 at 5:39 AM, Stephen 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 the > first time in a block

Re: [Bitcoin-development] Block Size Increase Requirements

On Sat, May 9, 2015 at 4:08 AM, Peter Todd 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 could be trac

Re: [Bitcoin-development] Block Size Increase Requirements

Comments in line: > On May 8, 2015, at 11:08 PM, Peter Todd 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; getting DoS at

Re: [Bitcoin-development] Block Size Increase

> 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

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 cor

Re: [Bitcoin-development] Block Size Increase

On Sat, May 9, 2015 at 12:53 PM, Justus Ranvier 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 > > hard drive (1*

Re: [Bitcoin-development] Block Size Increase

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

Re: [Bitcoin-development] Block Size Increase

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 Requirements

On Fri, May 08, 2015 at 08:47:52PM +0100, Tier Nolan wrote: > On Fri, May 8, 2015 at 5:37 PM, Peter Todd 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 "min

Re: [Bitcoin-development] Block Size Increase

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 (Raystonn)

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 f

Re: [Bitcoin-development] Block Size Increase

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 . wrote: > I have a proposal for wallets suc

Re: [Bitcoin-development] Block Size Increase

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 wrote: > Replace by fee is what I was ref

Re: [Bitcoin-development] Block Size Increase

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

Re: [Bitcoin-development] Block Size Increase

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 adv

Re: [Bitcoin-development] Block Size Increase

As the author of a popular SPV wallet, I wanted to weigh in, in support of the Gavin's 20Mb block proposal. The best argument I've heard against raising the limit is that we need fee pressure. I agree that fee pressure is the right way to economize on scarce resources. Placing hard limits on bloc

Re: [Bitcoin-development] Block Size Increase Requirements

On Fri, May 8, 2015 at 5:37 PM, Peter Todd 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 users and mer

Re: [Bitcoin-development] Block Size Increase

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 defi

Re: [Bitcoin-development] Block Size Increase

On Fri, May 8, 2015 at 2:59 PM, Alan Reiner 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 > that makes money

Re: [Bitcoin-development] Block Size Increase Requirements

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.

Re: [Bitcoin-development] Block Size Increase

On Fri, May 8, 2015 at 10:59 AM, Alan Reiner 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 > that makes mone

Re: [Bitcoin-development] Block Size Increase

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

Re: [Bitcoin-development] Block Size Increase

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 wor

Re: [Bitcoin-development] Block Size Increase

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 an

Re: [Bitcoin-development] Block Size Increase Requirements

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

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

Re: [Bitcoin-development] Block Size Increase Requirements

--[remove this line and above]-- On Thu, 7 May 2015, Gregory Maxwell wrote: > Date: Thu, 7 May 2015 00:37:54 + > From: Gregory Maxwell > To: Matt Corallo > Cc: Bitcoin Dev > Subject: Re: [Bitcoin-development] Block Size Increase > > Thanks Matt; I was actually re

Re: [Bitcoin-development] Block Size Increase

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

Re: [Bitcoin-development] Block Size Increase

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, increasin

Re: [Bitcoin-development] Block Size Increase

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

On Thu, May 7, 2015 at 9:40 PM, Tom Harding 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 suggests. >

Re: [Bitcoin-development] Block Size Increase

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

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

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

Re: [Bitcoin-development] Block Size Increase Requirements

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

Re: [Bitcoin-development] Block Size Increase

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 wrote: > > > O

[Bitcoin-development] Block Size Increase Requirements

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

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

> 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

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

Re: [Bitcoin-development] Block Size Increase

-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

On Thu, May 7, 2015 at 5:11 PM, Mike Hearn 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 who are

Re: [Bitcoin-development] Block Size Increase

On Thu, May 7, 2015 at 3:31 PM, Alan Reiner 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, "full" just me

Re: [Bitcoin-development] Block Size Increase

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

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

Re: [Bitcoin-development] Block Size Increase

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

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 reliabilit

Re: [Bitcoin-development] Block Size Increase

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 wh

Re: [Bitcoin-development] Block Size Increase

On Thu, May 7, 2015 at 3:03 PM, Matt Corallo 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 issues are left wonderin

Re: [Bitcoin-development] Block Size Increase

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 bl

Re: [Bitcoin-development] Block Size Increase

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

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 ye

Re: [Bitcoin-development] Block Size Increase

On Thu, May 7, 2015 at 7:40 PM, Gavin Costin 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 …. But I am not seeing

Re: [Bitcoin-development] Block Size Increase

Hearn Date: Friday, 8 May, 2015 2:06 am To: Btc Drak Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Block Size Increase > 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 > urg

Re: [Bitcoin-development] Block Size Increase

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 lea

Re: [Bitcoin-development] Block Size Increase

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 servers

Re: [Bitcoin-development] Block Size Increase

On Thu, May 7, 2015 at 6:59 PM, 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 can't be

Re: [Bitcoin-development] Block Size Increase

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

Re: [Bitcoin-development] Block Size Increase

On Thu, May 7, 2015 at 6:43 PM, Mike Hearn 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 not believe

Re: [Bitcoin-development] Block Size Increase

> 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

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

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

Re: [Bitcoin-development] Block Size Increase

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 st

Re: [Bitcoin-development] Block Size Increase

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): http://gavinandresen.ninja/the-

Re: [Bitcoin-development] Block Size Increase

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: http://cs.umd.ed

Re: [Bitcoin-development] Block Size Increase

On Thu, May 7, 2015 at 6:11 PM, Mike Hearn 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

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 so

Re: [Bitcoin-development] Block Size Increase

On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen 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 to > support over t

Re: [Bitcoin-development] Block Size Increase

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

Re: [Bitcoin-development] Block Size Increase

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

Re: [Bitcoin-development] Block Size Increase

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

Re: [Bitcoin-development] Block Size Increase

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 numb

Re: [Bitcoin-development] Block Size Increase

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

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

Re: [Bitcoin-development] Block Size Increase

On Thu, May 7, 2015 at 11:33 AM, Justus Ranvier 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 disagree. Bitcoin needs to

Re: [Bitcoin-development] Block Size Increase

On Thu, May 7, 2015 at 3:05 PM, Mike Hearn 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 > patch. Game o

Re: [Bitcoin-development] Block Size Increase

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 others,

Re: [Bitcoin-development] Block Size Increase

On Thu, May 7, 2015 at 4:05 PM, Mike Hearn 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 pr

Re: [Bitcoin-development] Block Size Increase

-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 > wrote: > >> To be extremely specific: should Bitcoin development >> intenionally limit the network's capabilities to leave room for >> other projects, or s

Re: [Bitcoin-development] Block Size Increase

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

  1   2   >