How merchant will behave when there is hard fork & they are not sure who win?

[twolifeinexile]

There is a in depth discussion about the block size limit right now and all focus on its impact IF implemented, but in case of a hard fork, how merchant will behave - merchants who do not care philosophies but their bottom line?

In the event of a hard fork, and in the phase that there is no clear winner , I think merchant would choose to have asking clients paid in both networks in the same amount, this is natural choice and no matter who wins, they still keep their bottom line. Unless transaction cost differential between the two become very extreme, isn't that people will who buy from merchant would agree to do so?

Then no matter how miners behave, how long term impact different fork could be, in the end, the one with the bottleneck would still dominate "bitcoin" properties, and in this way, new hard fork would in a way, not relevant (effetive)?

So as time goes by, the hard fork seems should not win the "classical" fork.

[1715492318]

1715492318

[1715492318]

1715492318

[1715492318]

1715492318

[Sukrim]

Then no matter how miners behave, [...]

If a lot of miners leave to a different fork, you're into 51%ing trouble. A lot of it (especially with ASICs around).

[Gavin Andresen]

A hard fork won't happen unless the vast super-majority of miners support it.

E.g. from my "how to handle upgrades" gist https://gist.github.com/gavinandresen/2355445

Example: increasing MAX_BLOCK_SIZE (a 'hard' blockchain split change)

Increasing the maximum block size beyond the current 1MB per block (perhaps changing it to a floating limit based on a multiple of the median size of the last few hundred blocks) is a likely future change to accomodate more transactions per block. A new maximum block size rule might be rolled out by:

New software creates blocks with a new block.version
Allow greater-than-MAX_BLOCK_SIZE blocks if their version is the new block.version or greater and 100% of the last 1000 blocks are new blocks. (51% of the last 100 blocks if on testnet)
100% of the last 1000 blocks is a straw-man; the actual criteria would probably be different (maybe something like block.timestamp is after 1-Jan-2015 and 99% of the last 2000 blocks are new-version), since this change means the first valid greater-than-MAX_BLOCK_SIZE-block immediately kicks anybody running old software off the main block chain.

[Technomage]

I wouldn't worry about this. A hard fork won't be performed at all if there is not at least a rough concensus. The block size limit issue is controversial and a full concensus possibly can't be reached, but having major services behind it (Gox, Blockchain, Coinbase, BitPay etc) and a large majority of miners and users would probably be enough.

It's a change that has to be done if we want to give Bitcoin any chance of scaling up to a larger amount of transactions, so it will most likely be done in some way. What the exact change and implementation is, and when it will be done, is obviously still unknown and it will take a while to figure that out.

If even a rough concensus can't be reached, then Bitcoin as it is now is completely doomed. So doomed in fact, that all day to day payments would be done with other cryptocurrencies (superior cryptocurrencies, as I see it) or through completely centralized services. It would also make Bitcoin look extremely bad from a media standpoint.

Centralized services handling a larger amount of payments has another drawback that hasn't been discussed much, it's the fact that using a fractional reserve would become much easier. As long as the blockchain itself is the dominant transaction platform, widespread use of fractional reserve is impossible.

[twolifeinexile]

I wouldn't worry about this. A hard fork won't be performed at all if there is not at least a rough concensus. The block size limit issue is controversial and a full concensus possibly can't be reached, but having major services behind it (Gox, Blockchain, Coinbase, BitPay etc) and a large majority of miners and users would probably be enough.

It's a change that has to be done if we want to give Bitcoin any chance of scaling up to a larger amount of transactions, so it will most likely be done in some way. What the exact change and implementation is, and when it will be done, is obviously still unknown and it will take a while to figure that out.

If even a rough concensus can't be reached, then Bitcoin as it is now is completely doomed. So doomed in fact, that all day to day payments would be done with other cryptocurrencies (superior cryptocurrencies, as I see it) or through completely centralized services. It would also make Bitcoin look extremely bad from a media standpoint.

Centralized services handling a larger amount of payments has another drawback that hasn't been discussed much, it's the fact that using a fractional reserve would become much easier. As long as the blockchain itself is the dominant transaction platform, widespread use of fractional reserve is impossible.

Applaud for the excellent analysis, yes I agree it is the centralized services (reserve) that enabled fractional reserve.

[ArticMine]

A hard fork won't happen unless the vast super-majority of miners support it.

E.g. from my "how to handle upgrades" gist https://gist.github.com/gavinandresen/2355445

Example: increasing MAX_BLOCK_SIZE (a 'hard' blockchain split change)

Increasing the maximum block size beyond the current 1MB per block (perhaps changing it to a floating limit based on a multiple of the median size of the last few hundred blocks) is a likely future change to accomodate more transactions per block. A new maximum block size rule might be rolled out by:

New software creates blocks with a new block.version
Allow greater-than-MAX_BLOCK_SIZE blocks if their version is the new block.version or greater and 100% of the last 1000 blocks are new blocks. (51% of the last 100 blocks if on testnet)
100% of the last 1000 blocks is a straw-man; the actual criteria would probably be different (maybe something like block.timestamp is after 1-Jan-2015 and 99% of the last 2000 blocks are new-version), since this change means the first valid greater-than-MAX_BLOCK_SIZE-block immediately kicks anybody running old software off the main block chain.

This is an excellent approach to roll out an increase MAX_BLOCK_SIZE; however for it to work properly it needs considerable lead time.  My question is: Is there an estimate as to when we will hit the soft 250KB limit and hard 1MB limit?

The ability for Bitcoin to be able to continue process small transactions with a value in the range of say 0.05 USD to say 20.00 USD is crucial in my mind since this is an area where Bitcoin truly shines.

[BradZimdack]

The firm I work for, which has made substantial investment into Bitcoin, has already thought quite a bit about this.  This is what we're doing and thinking:

* While this block size issue remains such a big uncertainty, we have drastically slowed our pace of investment and we've shelved some start-ups that were already in progress.  We're not stopping or backing out, but we're proceeding much slower and more cautiously until a clearer resolution to this problem appears.

* If we approach the 1MB limit and a solution does not appear forthcoming, we'll cease all new investment.

* If we pass the 1MB limit without a solution, seeing even the slightest hint that Bitcoin's competitive advantages over the conventional banking and payment systems are being eroded due to an inability to scale, we'll dump all our bitcoin assets and holdings.

* If a controversial solution is proposed, with fierce arguments on multiple sides, we will follow Gavin's fork, even if it's not ideal, on all our sites that accept BTC.

* If the fork hits, and there's even the slightest uncertainty as to which will survive, we will immediately dump all our bitcoin assets and holdings.  We will remove Bitcoin from all of our sites that accept multiple payment methods -- at least while we wait to see how things play out.

* If one fork kills off the other, we'll adopt that one and go back to business as usual.

* If both forks survive, with both being widely accepted (for example if Mt.Gox begins accepting Bitcoin-A and Bitcoin-B), we'll accept neither, dump everything, and write off blockchain based currencies and too risky and too unstable.

What we really hope to see is a nice, smooth transition to a system that scales, which very large majority of the network, including major service providers, agree to.

[twolifeinexile]

Then no matter how miners behave, [...]

If a lot of miners leave to a different fork, you're into 51%ing trouble. A lot of it (especially with ASICs around).

But you just ask the guy pay you in both chains (same amount), how could you lose? The guy who pay doesn't care either, since now matter who wins, he spend the same BTC.

The firm I work for, which has made substantial investment into Bitcoin, has already thought quite a bit about this.  This is what we're doing and thinking:

* While this block size issue remains such a big uncertainty, we have drastically slowed our pace of investment and we've shelved some start-ups that were already in progress.  We're not stopping or backing out, but we're proceeding much slower and more cautiously until a clearer resolution to this problem appears.

* If we approach the 1MB limit and a solution does not appear forthcoming, we'll cease all new investment.

* If we pass the 1MB limit without a solution, seeing even the slightest hint that Bitcoin's competitive advantages over the conventional banking and payment systems are being eroded due to an inability to scale, we'll dump all our bitcoin assets and holdings.

* If a controversial solution is proposed, with fierce arguments on multiple sides, we will follow Gavin's fork, even if it's not ideal, on all our sites that accept BTC.

* If the fork hits, and there's even the slightest uncertainty as to which will survive, we will immediately dump all our bitcoin assets and holdings.  We will remove Bitcoin from all of our sites that accept multiple payment methods -- at least while we wait to see how things play out.

* If one fork kills off the other, we'll adopt that one and go back to business as usual.

* If both forks survive, with both being widely accepted (for example if Mt.Gox begins accepting Bitcoin-A and Bitcoin-B), we'll accept neither, dump everything, and write off blockchain based currencies and too risky and too unstable.

What we really hope to see is a nice, smooth transition to a system that scales, which very large majority of the network, including major service providers, agree to.

Thanks, this is a real plan of a merchant facing hard fork uncertainty, can I ask why not accepting both Bitcoin-A and Bitcoin-B in the same amount (except you are losing confidence on crytocurrency concept as a whole)?

[ArticMine]

The firm I work for, which has made substantial investment into Bitcoin, has already thought quite a bit about this.  This is what we're doing and thinking:

* While this block size issue remains such a big uncertainty, we have drastically slowed our pace of investment and we've shelved some start-ups that were already in progress.  We're not stopping or backing out, but we're proceeding much slower and more cautiously until a clearer resolution to this problem appears.

* If we approach the 1MB limit and a solution does not appear forthcoming, we'll cease all new investment.

* If we pass the 1MB limit without a solution, seeing even the slightest hint that Bitcoin's competitive advantages over the conventional banking and payment systems are being eroded due to an inability to scale, we'll dump all our bitcoin assets and holdings.

* If a controversial solution is proposed, with fierce arguments on multiple sides, we will follow Gavin's fork, even if it's not ideal, on all our sites that accept BTC.

* If the fork hits, and there's even the slightest uncertainty as to which will survive, we will immediately dump all our bitcoin assets and holdings.  We will remove Bitcoin from all of our sites that accept multiple payment methods -- at least while we wait to see how things play out.

* If one fork kills off the other, we'll adopt that one and go back to business as usual.

* If both forks survive, with both being widely accepted (for example if Mt.Gox begins accepting Bitcoin-A and Bitcoin-B), we'll accept neither, dump everything, and write off blockchain based currencies and too risky and too unstable.

What we really hope to see is a nice, smooth transition to a system that scales, which very large majority of the network, including major service providers, agree to.

Thanks for your post. I hope that this is a warning to the community that uncertainty over this issue is already having a negative impact on Bitcoin.

[notig]

Mike Hearn -I think there are some things we can all agree on.

We're all keen to see efficient protocols built on top of Bitcoin for things like micropayment channels (which allow lots of fast repetitive satoshi-sized payments without impacting the block chain), or trusted computing (which allows offline transactions to be carried around in long chains until final resolution). Also the payment protocol should eliminate the most absurd abuses of micropayments like SDs messaging system. These things fall into the class of "no brainers" and were discussed for a long time already.

Other more exotic ideas like Ripple-style networks of payment routers using contracts don't seem against the spirit of Bitcoin if they keep the low trust aspects of the system.

At the same time, as evidenced by the disagreement on this thread, there are too many unknown variables for us to figure out what will happen ahead of time. The only way to really find out is to try it and see what happens. If Bitcoin does fail to scale then the end result will be a smaller number of full nodes but lots of people using the system - this is still better than Bitcoin being deliberately crippled so it never gets popular because even if the number of full nodes collapses down to less than 1000, unknown future advances in technology might make it cheap enough for everyone to run a full node again. In the absence of a hard-coded limit the number of full nodes can flex up and down as supply and demand change. But with a hard-coded limit Bitcoin will fail to achieve popularity amongst ordinary people and will eventually be forgotten.

"But with a hard-coded limit Bitcoin will fail to achieve popularity amongst ordinary people and will eventually be forgotten"  .

Just for the record... I spent money and ordered an ASIC last month because I wanted to be a miner for this very reason...  I'll be supporting a raise on the limit because I don't want bitcoin to fail. Other people seem to want it to fail and I can only guess it's because........ well they are mining other alternative currencies at the moment.

[acoindr]

A hard fork won't happen unless the vast super-majority of miners support it.

E.g. from my "how to handle upgrades" gist https://gist.github.com/gavinandresen/2355445

Example: increasing MAX_BLOCK_SIZE (a 'hard' blockchain split change)

Increasing the maximum block size beyond the current 1MB per block (perhaps changing it to a floating limit based on a multiple of the median size of the last few hundred blocks) is a likely future change to accomodate more transactions per block. A new maximum block size rule might be rolled out by:

New software creates blocks with a new block.version
Allow greater-than-MAX_BLOCK_SIZE blocks if their version is the new block.version or greater and 100% of the last 1000 blocks are new blocks. (51% of the last 100 blocks if on testnet)
100% of the last 1000 blocks is a straw-man; the actual criteria would probably be different (maybe something like block.timestamp is after 1-Jan-2015 and 99% of the last 2000 blocks are new-version), since this change means the first valid greater-than-MAX_BLOCK_SIZE-block immediately kicks anybody running old software off the main block chain.

Glad you're taking this approach, Gavin, rather than pushing ahead one ideology and risking a likely fork, as with your influence you could. This at least ensures large consensus for change.

Still, we're left with the problem of how to solve this together. I'm thinking on it but right now my brain is throbbing a bit from catching up reading all the threads on the topic 

[BradZimdack]

Thanks, this is a real plan of a merchant facing hard fork uncertainty, can I ask why not accepting both Bitcoin-A and Bitcoin-B in the same amount (except you are losing confidence on crytocurrency concept as a whole)?

There are several reasons why we wouldn't accept multiple strains of crypto-currency.  Here are the main ones:

* Losing confidence in the concept as a whole is the primary reason.  If there can be two, why not ten?  If they can come and go on a whim, then how solid can this magic internet money really be?  We don't want to be playing Frogger with our money (the old arcade game where you jump from one sinking log to another).

* It's counter-intuitive, but giving the customer more payment options reduces sales.  It makes your sales process more complex, requires the customer to make more decisions, and thus reduces overall conversion rate.

* All the back-end overhead to manage not one, but two, different crypo-currencies would add additional expense.  The exchange rates would likely be different, we'd have to deal with twice the maintenance and technical upkeep, our accounting would be more complicated, we'd lose economies of scale if we need to convert currencies, etc.  Do we pay our employees in Bitcoin-A or Bitcoin-B?  If some want A and others want B, but we have different amounts of each, then what?  All the extra support that goes into accepting the current Bitcoin is enough of a cost given its extremely low volume as it is.

[Technomage]

I completely agree with BradZimdack. Bitcoin has the potential to be a universal currency and it's exactly this potential that is its greatest feature. The inefficiencies of being forced to use multiple cryptocurrencies are massive, and that would actually destroy the promise of a currency that kills currency exchange (the great inefficiency we're so used to). We should do everything possible to create a Bitcoin that works for day to day payments, and works well.

I would understand the problem if the problems with this were actually insurmountable. All they appear to be are fears that everyone can't run a full node (newsflash: not everyone can do it now either) and some highly questionable scenarios of how evil miners take over everything and we have one mega miner controlling everything.

There are also ways to make the change so that scarcity is still a factor in the blocks. That is actually necessary since mining itself will be more and more dependent on fees, which are incentivized by scarcity. Too much scarcity however, is simply us paying fees for mining that is not needed.

[acoindr]

There are several reasons why we wouldn't accept multiple strains of crypto-currency.  Here are the main ones:

* Losing confidence in the concept as a whole is the primary reason.  If there can be two, why not ten?  If they can come and go on a whim, then how solid can this magic internet money really be?  We don't want to be playing Frogger with our money (the old arcade game where you jump from one sinking log to another).

* It's counter-intuitive, but giving the customer more payment options reduces sales.  It makes your sales process more complex, requires the customer to make more decisions, and thus reduces overall conversion rate.

* All the back-end overhead to manage not one, but two, different crypo-currencies would add additional expense.  The exchange rates would likely be different, we'd have to deal with twice the maintenance and technical upkeep, our accounting would be more complicated, we'd lose economies of scale if we need to convert currencies, etc.  Do we pay our employees in Bitcoin-A or Bitcoin-B?  If some want A and others want B, but we have different amounts of each, then what?  All the extra support that goes into accepting the current Bitcoin is enough of a cost given its extremely low volume as it is.

The only one of those that might hold water is #1.

Point #2 is patently false. Yes, it sounds counter-intuitive because it's not true. Giving the customer more payment options always increases sales, because it expands who can be a customer. If some product is desired at all then having maximum options to pay for it is a bonus/benefit, not a drawback.

Point #3 is understandable, but still arguable. It depends who you are, or, rather, how technical you are, and what technology is available. The back-end overhead to manage one crypto-currency or multiple crypto-currencies is not all that different because everything is software. You don't have to re-secure a server to hold more than one crypto-currency. The server is either secure or it's not. Conversion of currencies would be more the issue, but even that could be handled smoothly as, again, everything is software; it's just bits, bits which can move around the world in seconds for free. Giving employees choice of payment? Again, more choice is always better for some things, and money is one of those things. Lastly, about the presently low volume, that isn't expected to always be the case.

[twolifeinexile]

Thanks, this is a real plan of a merchant facing hard fork uncertainty, can I ask why not accepting both Bitcoin-A and Bitcoin-B in the same amount (except you are losing confidence on crytocurrency concept as a whole)?

There are several reasons why we wouldn't accept multiple strains of crypto-currency.  Here are the main ones:

* Losing confidence in the concept as a whole is the primary reason.  If there can be two, why not ten?  If they can come and go on a whim, then how solid can this magic internet money really be?  We don't want to be playing Frogger with our money (the old arcade game where you jump from one sinking log to another).

* It's counter-intuitive, but giving the customer more payment options reduces sales.  It makes your sales process more complex, requires the customer to make more decisions, and thus reduces overall conversion rate.

* All the back-end overhead to manage not one, but two, different crypo-currencies would add additional expense.  The exchange rates would likely be different, we'd have to deal with twice the maintenance and technical upkeep, our accounting would be more complicated, we'd lose economies of scale if we need to convert currencies, etc.  Do we pay our employees in Bitcoin-A or Bitcoin-B?  If some want A and others want B, but we have different amounts of each, then what?  All the extra support that goes into accepting the current Bitcoin is enough of a cost given its extremely low volume as it is.

All concerns are well-thought, I am persuaded. But I think I didn't point out clearly when I say pay same amount using both chains, what I mean here is that you do not know which chain will ultimately win, so you ask your client to pay you in both chain at the same time. ( Since except for newest mined blocks, people have the same bitcoin in both chain, so they are not paying twice, they are just paying same amount in "alternate universe", when things settles and one chain wins, you and client are settled with exactly same transaction. )

[justusranvier]

Point #2 is patently false. Yes, it sounds counter-intuitive because it's not true. Giving the customer more payment options always increases sales, because it expands who can be a customer. If some product is desired at all then having maximum options to pay for it is a bonus/benefit, not a drawback.

Do you know that because you've actually looked at data and measured it or are you just assuming, because the person you're quoting likely has.

[meanig]

Point #2 is patently false. Yes, it sounds counter-intuitive because it's not true. Giving the customer more payment options always increases sales, because it expands who can be a customer. If some product is desired at all then having maximum options to pay for it is a bonus/benefit, not a drawback.

Do you know that because you've actually looked at data and measured it or are you just assuming, because the person you're quoting likely has.

It's known as overchoice in the consumer field.

http://en.wikipedia.org/wiki/Overchoice

Having more choices, on the surface, appears to be a positive development; however it hides an underlying problem: faced with too many choices, consumers have trouble making optimal choices, and thus as a result can be indecisive, unhappy, and even refrain from making the choice (purchase) at all.

[acoindr]

Point #2 is patently false. Yes, it sounds counter-intuitive because it's not true. Giving the customer more payment options always increases sales, because it expands who can be a customer. If some product is desired at all then having maximum options to pay for it is a bonus/benefit, not a drawback.

Do you know that because you've actually looked at data and measured it or are you just assuming, because the person you're quoting likely has.

There is no need too look at data. It's common sense. Whatever the checkout procedure is there doesn't have to be every payment option displayed at once.

The checkout procedure for one option (say a check for USD in mail) can look the exact same as a checkout procedure for multiple options, with one difference being a link or similar which says "other payment options". Now, if you're telling me you'll lose sales because of the presence of that link, then you've surprised the hell out of me.

(Note I'm not talking about heavily psychology based products like "work-at-home-and-get-rich-if-ordered-now!" landing pages where every word said makes a difference.)

[acoindr]

It's known as overchoice in the consumer field.

http://en.wikipedia.org/wiki/Overchoice

Having more choices, on the surface, appears to be a positive development; however it hides an underlying problem: faced with too many choices, consumers have trouble making optimal choices, and thus as a result can be indecisive, unhappy, and even refrain from making the choice (purchase) at all.

That page talks about too many choices of products, not payment options.

[BradZimdack]

* It's counter-intuitive, but giving the customer more payment options reduces sales.  It makes your sales process more complex, requires the customer to make more decisions, and thus reduces overall conversion rate.

We look at the data on everything, so I do know this to be true (at least for the services we've tested).  Our tests have been conducted using various payment options such as Paypal, Bitcoin, and net-30 terms.  Of course every business is different, so I can't say for certain that our results would be externally valid for every business out there.  Different target markets might behave differently.  (We have seen a similar effect in other areas of choice, for example if a product comes in multiple colors, there can be a statistically significant conversion rate increase by actually eliminating some of those choices.)

Regardless of whether these results would apply to all business types, it remains a reason that we will not be supporting more than one crypto-currency, and the one that we do support must have sufficiently large usage to justify providing the option.

[acoindr]

* It's counter-intuitive, but giving the customer more payment options reduces sales.  It makes your sales process more complex, requires the customer to make more decisions, and thus reduces overall conversion rate.

We look at the data on everything, so I do know this to be true (at least for the services we've tested).  Our tests have been conducted using various payment options such as Paypal, Bitcoin, and net-30 terms.  Of course every business is different, so I can't say for certain that our results would be externally valid for every business out there.  Different target markets might behave differently.  (We have seen a similar effect in other areas of choice, for example if a product comes in multiple colors, there can be a statistically significant conversion rate increase by actually eliminating some of those choices.)

Regardless of whether these results would apply to all business types, it remains a reason that we will not be supporting more than one crypto-currency, and the one that we do support must have sufficiently large usage to justify providing the option.

Well, I think the wording would be more accurate if it said:

* It's counter-intuitive, but [displaying] more payment options reduces sales [in tests we've done using our methods].

[BradZimdack]

Well, I think the wording would be more accurate if it said:

* It's counter-intuitive, but [displaying] more payment options reduces sales [in tests we've done using our methods].

Agreed.  My original wording implied knowledge of broad external validity that I do not have statistical proof of.

Still, to return to the thread's topic, a Bitcoin civil war would be a very, very bad thing for my firm's position on Bitcoin.  As it is, this block size stuff is making us really nervous.  I hope the brilliant minds at work on a solution can figure this out (preferably sooner than later).

[Sukrim]

There were hard forks in the past already and Bitcoin will get over this one (if there even is going to be one, but it's likely at least...) as well.

[twolifeinexile]

There were hard forks in the past already and Bitcoin will get over this one (if there even is going to be one, but it's likely at least...) as well.

Isn't it that last time is due to a bug, this time it is about protocol. They are two different things I believe.

[markm]

Hmm, the one I remember was about enabling multiple-signature transactions, which judging by the apparent lack of the ability to do such transacti apparent lack of clents that secure you wallet by requring two signatures to spend from any of its addresses (the idea being you have one signing key on one device, one on another, to accomplish two-factor auth), seems like it was not afterall anywhere near as urgent as it was made out to be.

This block size thing is a slam-dunk, the only question really is how many of our hard-hoarded bitcoins are we going to have to blow on shiny new hardware to stay a full node or is the jump in size going to be too vast for any reasonable such expenditure to be "worth the candle". (Maybe just saying good-bye to bitcoin, leaving those hard earned coins to grow on their own in a cold wallet until one's retirement years, is a better play than playing at being involved in some way in the bitcoin space? Or maybe even cashing it out given the inability to ever actually verify its operation?)

So I am mostly concerned that the bigger is better, bigger is more exclusive, bigger decreases the number of competitors type of enthusiasm for sheer size for the sake of sheer size is going to slam dunk the max size way up into the only the Googles of the world can play scale, which it seems likely right now it is the plan to actually do. (Since no limit and infinite max size are basically equivalent. "Junk expands to fill all available space" or "junk multiplies to cover all available surfaces" is kind of a classic old saw, isn't it? Not sure it even comes from the housework field, which I think is where I first came across it.)

-MarkM-

[johnyj]

Limit those transaction heavy apps like satoshi-dice

[misterbigg]

Limit those transaction heavy apps like satoshi-dice

The current one megabyte limit will cause SatoshiDice transactions to peter out once we start hitting that limit. Fees will go up too.

[cypherdoc]

i agree with the points made by Technomage and BradZim.

too many options confuses the marketplace.  everything possible should be done to maintain Bitcoin's leadership role while satisfying small as well as large players. 

i for one, will always want to keep a full node running; heck i have 4 running now.  decentralization needs to be maintained while continuing to make mining profitable.

i'm not concerned at all.  the fact that all these discussions are taking place now, well before the problem has hit, gives me great faith that a viable solution will evolve.  this is open source at work.  the fact that some players are becoming nervous and pausing is good too. 

great accomplishments don't come easy and if everyone could see them coming there wouldn't be a marketplace of disagreement and tension.

[mobile4ever]

It's a change that has to be done if we want to give Bitcoin any chance of scaling up to a larger amount of transactions, so it will most likely be done in some way. What the exact change and implementation is, and when it will be done, is obviously still unknown and it will take a while to figure that out.

Big ideas bring big results. I believe that thinking in "dual mode" limits us. That is, to remain thinking like "black/white", "hot/cold", "up/down" severely limits what man can achieve. There are ideas created that are designed to make sharing bitcoin with your neighbor a "natural thing".

If even a rough concensus can't be reached, then Bitcoin as it is now is completely doomed. So doomed in fact, that all day to day payments would be done with other cryptocurrencies (superior cryptocurrencies, as I see it) or through completely centralized services. It would also make Bitcoin look extremely bad from a media standpoint.

It takes a 15 to 18 percent adoption of bitcoin for it to "take off" (become worldwide consensus). We are currently in the "early adopter" phase. Huge growth is coming, no doubt, but how will it take place? Facilitating that is important RIGHT NOW. People have heard of that "fiscal cliff" and the dollar is fixing to go to wherever dead currencies go when they die.

Centralized services handling a larger amount of payments has another drawback that hasn't been discussed much, it's the fact that using a fractional reserve would become much easier. As long as the blockchain itself is the dominant transaction platform, widespread use of fractional reserve is impossible.

For me, this is crux of the problem. Centralization is what has happened with currencies ever since gold stopped becoming the world's money, right? That has got to stop and can never be allowed to happen with bitcoin or bitcoin markets.

[twolifeinexile]

So far only BradZimdack presented some thoughts from a merchant's perspective, we can have opinions, ideologies but what ultimately merchents think about bitcoin would drive its adoption. So it would be great if there are more thoughts on the mechant side is considered.

[markm]

When selling stuff on the web in an automated way, as in not by just telling the visitor to get in contact with me but hving automation accept payment and, usually, deliver the goods (as, usually, they are virtual goods) all my wonderful programming and sysadmin and website making skills do not lead me to process the payment myself. Quite the opposite, I paste in an Adult Patrol or Adult Age or whatever "get money from the visitor for me before letting him in to see my content" form, or a Paypal onetime or subscription payment form, that kind of stuff.

So right now, if I wanted to accept bitcoins, I would be looking for a "get bitcoins for me" Ripple system form to paste in, so that I won't even have to care what the heck currency the visitor actually has, I will get my bitcoins.

-MarkM-

[cypherdoc]

i guess i'm a merchant for my newsletter.

i would hate to have to deal in more than one cryptocurrency.  i don't have the time quite frankly nor the desire.

[mobile4ever]

So right now, if I wanted to accept bitcoins, I would be looking for a "get bitcoins for me" Ripple system form to paste in, so that I won't even have to care what the heck currency the visitor actually has, I will get my bitcoins.

-MarkM-

Doesnt coinbase do that as well? Heck, we can even order pizza:

https://twitter.com/PizzaForCoins

with bitcoin.

[Maged]

The firm I work for, which has made substantial investment into Bitcoin, has already thought quite a bit about this.  This is what we're doing and thinking:

* While this block size issue remains such a big uncertainty, we have drastically slowed our pace of investment and we've shelved some start-ups that were already in progress.  We're not stopping or backing out, but we're proceeding much slower and more cautiously until a clearer resolution to this problem appears.

* If we approach the 1MB limit and a solution does not appear forthcoming, we'll cease all new investment.

* If we pass the 1MB limit without a solution, seeing even the slightest hint that Bitcoin's competitive advantages over the conventional banking and payment systems are being eroded due to an inability to scale, we'll dump all our bitcoin assets and holdings.

* If a controversial solution is proposed, with fierce arguments on multiple sides, we will follow Gavin's fork, even if it's not ideal, on all our sites that accept BTC.

* If the fork hits, and there's even the slightest uncertainty as to which will survive, we will immediately dump all our bitcoin assets and holdings.  We will remove Bitcoin from all of our sites that accept multiple payment methods -- at least while we wait to see how things play out.

* If one fork kills off the other, we'll adopt that one and go back to business as usual.

* If both forks survive, with both being widely accepted (for example if Mt.Gox begins accepting Bitcoin-A and Bitcoin-B), we'll accept neither, dump everything, and write off blockchain based currencies and too risky and too unstable.

What we really hope to see is a nice, smooth transition to a system that scales, which very large majority of the network, including major service providers, agree to.

Thanks for your post. I hope that this is a warning to the community that uncertainty over this issue is already having a negative impact on Bitcoin.

Exactly. In fact, BradZimdack's thoughts are exactly same thoughts that I had a few days ago, except my thoughts were on an individual level. So, let me be clear: what set me into panic mode was not the discussions about how the limit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning. I can understand not liking Gavin's plan of just allowing the blocksize to be unlimited and having the market sort things out (I don't, either), but I'm sorry, it takes a special kind of stupid to say that no hard forks can happen ever because you "subscribed to the constants" instead of the spirit of Bitcoin like the rest of us did.

If you are arguing for staying at 1 MB/block because that is the constant you would choose today if you pretend that we could reset the constant to whatever we wanted to (whether that be another constant or an algorithm), that's fine. It's a valid choice. I'd be interested to know why you prefer specifically that number over the other options. But to argue that we should keep the limit there because all change is evil is both irrational and stupid. Whatever we decide to do, it's not going to be something that we rush into. Also, you'll notice that in these discussions not a single supporter for this change has even proposed changing the important constants like the total final money supply, so the slippery-slope argument does not apply. Stop trying to kill Bitcoin.

[solex]

Exactly. In fact, BradZimdack's thoughts are exactly same thoughts that I had a few days ago, except my thoughts were on an individual level. So, let me be clear: what set me into panic mode was not the discussions about how the limit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning. I can understand not liking Gavin's plan of just allowing the blocksize to be unlimited and having the market sort things out (I don't, either), but I'm sorry, it takes a special kind of stupid to say that no hard forks can happen ever because you "subscribed to the constants" instead of the spirit of Bitcoin like the rest of us did.

If you are arguing for staying at 1 MB/block because that is the constant you would choose today if you pretend that we could reset the constant to whatever we wanted to (whether that be another constant or an algorithm), that's fine. It's a valid choice. I'd be interested to know why you prefer specifically that number over the other options. But to argue that we should keep the limit there because all change is evil is both irrational and stupid. Whatever we decide to do, it's not going to be something that we rush into. Also, you'll notice that in these discussions not a single supporter for this change has even proposed changing the important constants like the total final money supply, so the slippery-slope argument does not apply.

+1 I fully agree.

Also, we should turn the max block size problem into an opportunity. As many posters have already said: it is an opportunity to replace it with an algorithm which provides an incentive for users to add fees to their transactions, maintaining an element of block-space scarcity enhancing miner revenue.

[Maged]

Exactly. In fact, BradZimdack's thoughts are exactly same thoughts that I had a few days ago, except my thoughts were on an individual level. So, let me be clear: what set me into panic mode was not the discussions about how the limit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning. I can understand not liking Gavin's plan of just allowing the blocksize to be unlimited and having the market sort things out (I don't, either), but I'm sorry, it takes a special kind of stupid to say that no hard forks can happen ever because you "subscribed to the constants" instead of the spirit of Bitcoin like the rest of us did.

If you are arguing for staying at 1 MB/block because that is the constant you would choose today if you pretend that we could reset the constant to whatever we wanted to (whether that be another constant or an algorithm), that's fine. It's a valid choice. I'd be interested to know why you prefer specifically that number over the other options. But to argue that we should keep the limit there because all change is evil is both irrational and stupid. Whatever we decide to do, it's not going to be something that we rush into. Also, you'll notice that in these discussions not a single supporter for this change has even proposed changing the important constants like the total final money supply, so the slippery-slope argument does not apply.

+1 I fully agree.

Also, we should turn the max block size problem into an opportunity. As many posters have already said: it is an opportunity to replace it with an algorithm which provides an incentive for users to add fees to their transactions, maintaining an element of block-space scarcity enhancing miner revenue.

Yup, and there's a pretty good start on how to do that already.

Now, just to illustrate what the people who are against this hard fork are like, consider the BIP 16/17 debate (assuming you were around to see that shit-storm). These people are like the people who said that we shouldn't have either. Even Luke-jr was stunned to hear that. Sure, that's not the best example since we still don't use it much today (but that's mainly because a UI and payment protocol don't exist), but you can see the point I'm trying to make.

[tvbcof]

...mit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning. ...

Do you have anything by way of actual evidence of this?  Not that I do or don't believe it, but it is easy and common on this forum for people to pull shit like this right out of their ass.

Why did the limit get set as it is knowing that it was going to be a nightmare if/when it ever was to be changed (if you have any real clue?)

---

BTW, as far as I am concerned, Brad and his company can go fuck themselves.

[justusranvier]

So, let me be clear: what set me into panic mode was not the discussions about how the limit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning.

Even worse, we have prominent devs playing fast and loose with the truth, claiming that raising the limit was never the plan when they posted in the same threads in which it is made clear that it was the plan.

[tvbcof]

So, let me be clear: what set me into panic mode was not the discussions about how the limit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning.

Even worse, we have prominent devs playing fast and loose with the truth, claiming that raising the limit was never the plan when they posted in the same threads in which it is made clear that it was the plan.

Jeff's input on this topic and his actions and statements on other topics is giving me a lot of hope for Bitcoin.

A while ago I was scanning some older conversations which occurred after Satoshi exited.  Seemed like certain of the main devs (Gavin and Mike I think) were sort of scratching their heads and shrugging at Satoshi's fixation on retaining a light weight system.  Clearly there have been differences which probably go back to day one.

I find it neither surprising nor unhealthy that the various primary developers have different ideas about what is important.  Like I said in the conversations about the Bitcoin Foundation, it is important to me as a community member to have visibility into the workings of the 'core team' such that I can take actions which are appropriate for me as situations arise.

[Zangelbert Bingledack]

No hard fork will be introduced unless it's clear who will win. It's extremely unlikely that we'd come to a point where anything close enough to an exact split would happen. As long as there's even a 60-40 majority, once the fork happens most people would abandon the smaller fork, though it might live on as a tiny alt-coin (even if that alt-coin is technically the original protocol).

The holdouts would call the losing fork the "true Bitcoin" and have some other name for the majority fork, and the rest of the world would carry on as if nothing, after a few hickups and probably a medium-term price crash while people learned to stop thinking in terms of "Bitcoin" but instead in terms of "the de facto standard currency protocol of the internet."

[acoindr]

...

I find it neither surprising nor unhealthy that the various primary developers have different ideas about what is important.  
...

I agree. I call it free market forces check and balance.

No hard fork will be introduced unless it's clear who will win.
...

Yes, that appears to be the case. I like Gavin's approach to upgrading:

A hard fork won't happen unless the vast super-majority of miners support it.

E.g. from my "how to handle upgrades" gist https://gist.github.com/gavinandresen/2355445

Example: increasing MAX_BLOCK_SIZE (a 'hard' blockchain split change)

Increasing the maximum block size beyond the current 1MB per block (perhaps changing it to a floating limit based on a multiple of the median size of the last few hundred blocks) is a likely future change to accomodate more transactions per block. A new maximum block size rule might be rolled out by:

New software creates blocks with a new block.version
Allow greater-than-MAX_BLOCK_SIZE blocks if their version is the new block.version or greater and 100% of the last 1000 blocks are new blocks. (51% of the last 100 blocks if on testnet)
100% of the last 1000 blocks is a straw-man; the actual criteria would probably be different (maybe something like block.timestamp is after 1-Jan-2015 and 99% of the last 2000 blocks are new-version), since this change means the first valid greater-than-MAX_BLOCK_SIZE-block immediately kicks anybody running old software off the main block chain.

This ensures consensus vote from the field.

[twolifeinexile]

...
I find it neither surprising nor unhealthy that the various primary developers have different ideas about what is important.  
...

I agree. I call it free market forces check and balance.

No hard fork will be introduced unless it's clear who will win.
...

Yes, that appears to be the case. I like Gavin's approach to upgrading:

A hard fork won't happen unless the vast super-majority of miners support it.

E.g. from my "how to handle upgrades" gist https://gist.github.com/gavinandresen/2355445

Example: increasing MAX_BLOCK_SIZE (a 'hard' blockchain split change)

Increasing the maximum block size beyond the current 1MB per block (perhaps changing it to a floating limit based on a multiple of the median size of the last few hundred blocks) is a likely future change to accomodate more transactions per block. A new maximum block size rule might be rolled out by:

New software creates blocks with a new block.version
Allow greater-than-MAX_BLOCK_SIZE blocks if their version is the new block.version or greater and 100% of the last 1000 blocks are new blocks. (51% of the last 100 blocks if on testnet)
100% of the last 1000 blocks is a straw-man; the actual criteria would probably be different (maybe something like block.timestamp is after 1-Jan-2015 and 99% of the last 2000 blocks are new-version), since this change means the first valid greater-than-MAX_BLOCK_SIZE-block immediately kicks anybody running old software off the main block chain.

This ensures consensus vote from the field.

If the approeach as described by Gavin, some concensus of 10%%~99% of the hashing power, then it should be able to maintain the confidence.
To me, the size itself is not the problem, it is the confidence that is the problem.

[Maged]

...mit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning. ...

Do you have anything by way of actual evidence of this?  Not that I do or don't believe it, but it is easy and common on this forum for people to pull shit like this right out of their ass.

Why did the limit get set as it is knowing that it was going to be a nightmare if/when it ever was to be changed (if you have any real clue?)

That realization about the impossibility of raising the maximum block size via a hard fork worried me enough to the point where I actually think that my statement that it would require a hard fork might be wrong. 

But seriously, I think that I've come up with a soft-fork version of accomplishing the same thing. A soft-fork would allow us to deploy the rules for increasing the maximum block size in less then a month instead of several years, assuming it was coded ahead of time and it was considered extremely high priority. It's a terrible hack job, but to the users it would be fairly seamless. Not to give too much away just yet, but it'll be fully backwards compatible functionality wise down to version 0.6.0. I'll post the technical details in the next few days.

[twolifeinexile]

...mit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning. ...

Do you have anything by way of actual evidence of this?  Not that I do or don't believe it, but it is easy and common on this forum for people to pull shit like this right out of their ass.

Why did the limit get set as it is knowing that it was going to be a nightmare if/when it ever was to be changed (if you have any real clue?)

That realization about the impossibility of raising the maximum block size via a hard fork worried me enough to the point where I actually think that my statement that it would require a hard fork might be wrong. 

But seriously, I think that I've come up with a soft-fork version of accomplishing the same thing. A soft-fork would allow us to deploy the rules for increasing the maximum block size in less then a month instead of several years, assuming it was coded ahead of time and it was considered extremely high priority. It's a terrible hack job, but to the users it would be fairly seamless. Not to give too much away just yet, but it'll be fully backwards compatible functionality wise down to version 0.6.0. I'll post the technical details in the next few days.

How? Old version reject block bigger than the limit, you new version generate one and ask older version to accept? You discovered a vulnerability/bug in the old version?

[tvbcof]

...mit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning. ...

Do you have anything by way of actual evidence of this?  Not that I do or don't believe it, but it is easy and common on this forum for people to pull shit like this right out of their ass.

Why did the limit get set as it is knowing that it was going to be a nightmare if/when it ever was to be changed (if you have any real clue?)

That realization about the impossibility of raising the maximum block size via a hard fork worried me enough to the point where I actually think that my statement that it would require a hard fork might be wrong. 

But seriously, I think that I've come up with a soft-fork version of accomplishing the same thing. A soft-fork would allow us to deploy the rules for increasing the maximum block size in less then a month instead of several years, assuming it was coded ahead of time and it was considered extremely high priority. It's a terrible hack job, but to the users it would be fairly seamless. Not to give too much away just yet, but it'll be fully backwards compatible functionality wise down to version 0.6.0. I'll post the technical details in the next few days.

Awsome!  A 'terrible hack job' to accomplish something I desperately don't want.  What's not to love?

I believe my bitcoind build pre-dates 0.6 so I'll be anxiously awaiting your details.

[Maged]

...mit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning. ...

Do you have anything by way of actual evidence of this?  Not that I do or don't believe it, but it is easy and common on this forum for people to pull shit like this right out of their ass.

Why did the limit get set as it is knowing that it was going to be a nightmare if/when it ever was to be changed (if you have any real clue?)

That realization about the impossibility of raising the maximum block size via a hard fork worried me enough to the point where I actually think that my statement that it would require a hard fork might be wrong. 

But seriously, I think that I've come up with a soft-fork version of accomplishing the same thing. A soft-fork would allow us to deploy the rules for increasing the maximum block size in less then a month instead of several years, assuming it was coded ahead of time and it was considered extremely high priority. It's a terrible hack job, but to the users it would be fairly seamless. Not to give too much away just yet, but it'll be fully backwards compatible functionality wise down to version 0.6.0. I'll post the technical details in the next few days.

How? Old version reject block bigger than the limit, you new version generate one and ask older version to accept? You discovered a vulnerability/bug in the old version?

I'll put up a post about it in Development & Technical Discussion sometime this week when I have a few spare hours to answer the inevitable questions. For now, I just want people to realize that there may be other ways to go about this.

[jl2012]

...mit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning. ...

Do you have anything by way of actual evidence of this?  Not that I do or don't believe it, but it is easy and common on this forum for people to pull shit like this right out of their ass.

Why did the limit get set as it is knowing that it was going to be a nightmare if/when it ever was to be changed (if you have any real clue?)

That realization about the impossibility of raising the maximum block size via a hard fork worried me enough to the point where I actually think that my statement that it would require a hard fork might be wrong. 

But seriously, I think that I've come up with a soft-fork version of accomplishing the same thing. A soft-fork would allow us to deploy the rules for increasing the maximum block size in less then a month instead of several years, assuming it was coded ahead of time and it was considered extremely high priority. It's a terrible hack job, but to the users it would be fairly seamless. Not to give too much away just yet, but it'll be fully backwards compatible functionality wise down to version 0.6.0. I'll post the technical details in the next few days.

How? Old version reject block bigger than the limit, you new version generate one and ask older version to accept? You discovered a vulnerability/bug in the old version?

I'll put up a post about it in Development & Technical Discussion sometime this week when I have a few spare hours to answer the inevitable questions. For now, I just want people to realize that there may be other ways to go about this.

Very interesting.... It sounds like an exploit. Can't wait to see it