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.

[1714616213]

1714616213

[1714616213]

1714616213

[1714616213]

1714616213

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