The Slow transaction speed [confirms], solutions, discussion. Wide adoption

[jubalix]

I would really really like to use bitcoins every day, for every day purchases, and as a merchant. Many talk of wide adoption.

But transactions are SLOW.

[EDIT WDC 15 Second confirms!!! loss of safety I know but people love it]

What is the solution to this?

I can only really see a system that accepts an amount of risk, or you have to send bitcoins to a merchant and then they issue a value card.

but how to overcome the slow confirms, you can't just stand in line for that long, or is bitcoin going to be a reserve currency, for buying houses and such like?

over to your views/solutions

EDIT: one of the the current advantages of Fiat is that it exists in electronic and physical forms, which means it is used for small quick OTC purchases and big purchases like houses. This give people a feel for what they are spending, ultimate speed and keeps them every day in the Grip of Fiat. True there are less "cash transactions", however for wide scale adoption it maybe that bitcoin has to enter the physical, ala Cassius like coins, or something like it from trusted vendors

Stored value card systems like the Octo in HK may also point to an alternative.

[1714905842]

1714905842

[1714905842]

1714905842

[1714905842]

1714905842

[1714905842]

1714905842

[oakpacific]

My thought is the merchants should just warn the customers that they will not deliver for bitcoins coming from addresses with unconfirmed transactions, this should be enough to prevent race attacks, for anything worth enough for a Finney attack, it's recommended to just wait for several confirmations.

[joecascio]

The confirmation process does take time, but the acknowledgement of an issued transaction by the miner network takes only seconds. Given the practical impossibility of double-spending, the presentation of the transaction to the network is a pretty good indication that it will be confirmed. What the confirmation really does is enable the recipient to "spend" the btc received.

This assumes that most transactions are not attempts to double-spend. Does anyone have stats on how many transactions are rejected as double-spend attempts?

Consider that a credit-card approval is also only provisional. It can be reversed for many days after being received. Once a btc transaction is confirmed, it cannot be reversed.

[solex]

I would really really like to use bitcoins every day, for every day purchases, and as a merchant.

What is the solution to this?

I can only really see an system that accepts an amout of risk, or you have to send bitcoins to a merchant and then they issue a value card.

but how to overcome the slow confirms, you can't just stand in line for that long, or is bitcoin going to be a reserve currency, for buying houses and such like?

over to your views/solutions

Consider that there are two types of transactions:

a) Wait for confirm. Where the merchant can wait for n confirms, based upon their appetite for risk, and size of transaction, before delivering goods. This works for most on-line purchases.

b) Can't wait for confirm. Where the wait time can't be any longer than existing fiat systems, say 10 seconds, such as when buying petrol or paying a restaurant. These are usually face-to-face. Zero confirms seems acceptable for small value transactions, less than $20 perhaps, but might be unacceptable for anything larger.

So your problem comes down to face-to-face transaction confirmation where product delivery needs to be immediate.

The best solution I see is improved merchant-version Bitcoin client software which connects to a lot of nodes in order to detect a double-spend attempt as fast as possible. At the moment nodes silently ignore double-spends so that they don't go into blocks, but perhaps this could be changed so that they are propagated for a short time, but flagged as double-spends. Merchant nodes will detect these more reliably.

The other solution is a personal bitcoin guarantee card up to a limit. Might be a continued role for banks in a Bitcoin economy. Banks would need a fee for insuring against fraud when these cards are used.

[Come-from-Beyond]

What is the solution to this?

There is no a solution based on blockchain+PoW combo. Other currencies use smaller gap between confirmations but they r less secure. The risk of double-spending is in inverse proportion to time of waiting, no matter how many confirmations u get.

U could pay attention to cryptocoins based on other approaches:
1. Ripple (in beta stage)
2. Qubic (in alpha stage)
3. Decrits (in concept stage)

[Come-from-Beyond]

The best solution I see is improved merchant-version Bitcoin client software which connects to a lot of nodes in order to detect a double-spend attempt as fast as possible.

This won't help against a Finney attack.

[Operatr]

I would really really like to use bitcoins every day, for every day purchases, and as a merchant. Many talk of wide adoption.

But transactions are SLOW.

What is the solution to this?

I can only really see a system that accepts an amount of risk, or you have to send bitcoins to a merchant and then they issue a value card.

but how to overcome the slow confirms, you can't just stand in line for that long, or is bitcoin going to be a reserve currency, for buying houses and such like?

over to your views/solutions

At some point BTC will only be suitable for very large transactions, which is where Litecoin (or one of the 10 or so derivitive coins) would step in to fill the need for micro-transactions.

[tuliplover]

Far from perfect, but works:

You deposit bitcoins into your online wallet hosted on a reputable site, you only keep small amounts here for quick transactions like buying gas.
When you buy your stuff, the intermediary site issues an IOU to the merchant, which will be settled on the same day or something.

You risk only small amounts, merchant risks the last few transactions  if the intermediary goes down, not a big deal. It's similar to how
things are today with credit cards, but still faster (for the merchant) and cheaper.

[franky1]

as some people are now realising sending out 2 transactions is easy, but getting them confirmed 10 minutes+ later is the 'near' impossible part. so accepting 0 confirms is definitely a risk as you never fully know until the 10th minute (first confirm) if its a double spend or not.

even if they get rejected at the 10th minute, because double spends are theoretically hard to achieve. that's still only provable at the 10th minute.

however the option of a payment service which accepts coin to get pre-confirmed, to then use later throughout the day. such as a loyalty/value card system for small daily lifestyle amounts of value would totally eradicate this risk.

much like how MTGOX use to pre-confirm funds to then allow MTGox codes to transfer bitcoin balances between members instantly/risk free.

i would happily put 0.1BTC into a service while i take a shower in the morning, knowing by the time i get to starbucks or want a morning breakfast in a cafe i can spend it instantly without question.

MTGOX missed out on a key feature for their merchant gateway by removing the gox codes. but then again i would not suggest MTGOX for merchant services due to the lack of support/current issues.

[amincd]

The best solution I see is improved merchant-version Bitcoin client software which connects to a lot of nodes in order to detect a double-spend attempt as fast as possible. At the moment nodes silently ignore double-spends so that they don't go into blocks, but perhaps this could be changed so that they are propagated for a short time, but flagged as double-spends. Merchant nodes will detect these more reliably.

+1

There's also the option of shortening the block time in bitcoin in the next hard fork. It would just be a parameter tweak so possibly acceptable to the majority.

[franky1]

The best solution I see is improved merchant-version Bitcoin client software which connects to a lot of nodes in order to detect a double-spend attempt as fast as possible. At the moment nodes silently ignore double-spends so that they don't go into blocks, but perhaps this could be changed so that they are propagated for a short time, but flagged as double-spends. Merchant nodes will detect these more reliably.

+1

There's also the option of shortening the block time in bitcoin in the next hard fork. It would just be a parameter tweak so possibly acceptable to the majority.

shortening the blocktime is not just a tweak. it also involves OBVIOUSLY messing with the reward pay out. because if there are only going to be 5.25million coins produced in the next 4 years. at a rate of 3600 a day. then shortening the blocktime will mess with the maths of rewards and difficulty, etc etc.

so a 10 minute estimate for 25 coins would need to become 12.5 coins for 5 minute estimate. just to stay on track for the 5.25mill coins by 2017. which makes it less profitable for NON-asic miners as they have to push even harder to solve the block in half the time for half the reward. the ripple effect of messing with the block timings is a silly fools errand that will cause more issues then solve

[BTC Books]

I would really really like to use bitcoins every day, for every day purchases, and as a merchant. Many talk of wide adoption.

But transactions are SLOW.

What is the solution to this?

I can only really see a system that accepts an amount of risk, or you have to send bitcoins to a merchant and then they issue a value card.

but how to overcome the slow confirms, you can't just stand in line for that long, or is bitcoin going to be a reserve currency, for buying houses and such like?

over to your views/solutions

Have you looked at Bridgewalker?

https://www.bridgewalkerapp.com/

It deals with accepting the risk, and minute-by-minute pricing anomalies as well.  For a merchant dealing with sub-$100 transactions - down to pennies - it's something to look at if you want instant settlement.

[grue]

the slow confirms is caused by spam transactions which clog up the unconfirmed list. block satoshidice and other "on the chain" gambling sites and the problem is solved.

[bg002h]

I don't see this being a big deal. Merchants take checks which suffer from the confirmation problem, right? The difference with a check is that you know who wrote it. If someone wants to pay with Bitcoins and skip confirmation, then perhaps knowing who they are and where they live would solve the problem?

[franky1]

I don't see this being a big deal. Merchants take checks which suffer from the confirmation problem, right? The difference with a check is that you know who wrote it. If someone wants to pay with Bitcoins and skip confirmation, then perhaps knowing who they are and where they live would solve the problem?

accepting checks (cheques) is not the same risk as an unconfirmed bitcoin, the closest comparison would be a fake bank note and not having a UV lamp handy to verify its legitimacy for atleast 10 minutes.

this is why vending machines have coin/note checkers built into them, even for small priced items. as fraud is a big thing

[stslimited]

I would really really like to use bitcoins every day, for every day purchases, and as a merchant. Many talk of wide adoption.

But transactions are SLOW.

What is the solution to this?

I can only really see a system that accepts an amount of risk, or you have to send bitcoins to a merchant and then they issue a value card.

but how to overcome the slow confirms, you can't just stand in line for that long, or is bitcoin going to be a reserve currency, for buying houses and such like?

over to your views/solutions

Ripple, right now

[evoorhees]

the slow confirms is caused by spam transactions which clog up the unconfirmed list. block satoshidice and other "on the chain" gambling sites and the problem is solved.

Yes, the way to make Bitcoin successful is to block sites that use it in ways you dislike.

Most often, slow confirms are caused by the sender not attaching a mining fee. Pay the tiny fee, and the transactions is very likely to be confirmed in the next block.

[bg002h]

Most often, slow confirms are caused by the sender not attaching a mining fee. Pay the tiny fee, and the transactions is very likely to be confirmed in the next block.

I don't frequently send amounts less than ฿1 around, but, I've never had to pay a transaction fee. I mean, it would be awesome if sending 10¢ could be free (computationally and fee wise), but, the technology simply isn't there yet for that. Thus, the fee.

The miners set the fee that they are willing to accept. The nodes bear the storage costs, but they have no say on the fee process. The default relay settings for dust is the only defense of storage costs and we have been trying to make fees so this job. Hopefully dust reduction (combined with fee reduction) will help push the lower limit on ฿ transaction value down a bit and speed up confirms. 

[jubalix]

I would really really like to use bitcoins every day, for every day purchases, and as a merchant. Many talk of wide adoption.

But transactions are SLOW.

What is the solution to this?

I can only really see a system that accepts an amount of risk, or you have to send bitcoins to a merchant and then they issue a value card.

but how to overcome the slow confirms, you can't just stand in line for that long, or is bitcoin going to be a reserve currency, for buying houses and such like?

over to your views/solutions

At some point BTC will only be suitable for very large transactions, which is where Litecoin (or one of the 10 or so derivitive coins) would step in to fill the need for micro-transactions.

This is also one of my views

[jubalix]

the slow confirms is caused by spam transactions which clog up the unconfirmed list. block satoshidice and other "on the chain" gambling sites and the problem is solved.

but this is more like real world larger adoption....so good demonstration

[Cryptoman]

Whatever happened to the green address idea?

[franky1]

the slow confirms is caused by spam transactions which clog up the unconfirmed list. block satoshidice and other "on the chain" gambling sites and the problem is solved.

but this is more like real world larger adoption....so good demonstration

exactly, when bitcoin is $1000 a piece and someone just wants to buy a can of pepsi for under 1$ they would love to be able to send a transaction of 0.001BTC without a fee and without a 10 minute wait. so the solution maybe that the blockchain is used as a ledger for large movements of $10 or more and all other transactions have to use a payment system 'off the chain' which allows merchants to withdraw once they reach $10 or more on their balance.

[jubalix]

the slow confirms is caused by spam transactions which clog up the unconfirmed list. block satoshidice and other "on the chain" gambling sites and the problem is solved.

but this is more like real world larger adoption....so good demonstration

exactly, when bitcoin is $1000 a piece and someone just wants to buy a can of pepsi for under 1$ they would love to be able to send a transaction of 0.001BTC without a fee and without a 10 minute wait. so the solution maybe that the blockchain is used as a ledger for large movements of $10 or more and all other transactions have to use a payment system 'off the chain' which allows merchants to withdraw once they reach $10 or more on their balance.

and while all those small amounts accumulate....double spend, eg order a lot from merchant, then double spend.....

[amincd]

+1

There's also the option of shortening the block time in bitcoin in the next hard fork. It would just be a parameter tweak so possibly acceptable to the majority.

shortening the blocktime is not just a tweak. it also involves OBVIOUSLY messing with the reward pay out. because if there are only going to be 5.25million coins produced in the next 4 years. at a rate of 3600 a day. then shortening the blocktime will mess with the maths of rewards and difficulty, etc etc.

Yes it involves reducing the per block reward pay out and increasing the number of blocks between each reward halving to maintain the current issuance schedule. All of these things can be done without making changes to any thing essential about how Bitcoin works (will remain decentralized, only 21 million bitcoin will ever be issued, etc).

so a 10 minute estimate for 25 coins would need to become 12.5 coins for 5 minute estimate. just to stay on track for the 5.25mill coins by 2017. which makes it less profitable for NON-asic miners as they have to push even harder to solve the block in half the time for half the reward. the ripple effect of messing with the block timings is a silly fools errand that will cause more issues then solve

Can you explain why it would make it less profitable for non-ASIC miners? Their probability of solving a block will be the same regardless of the block time. Their reward for each block will be less, but given the number of blocks will increase so that the same number of coins are generated in a given span of time, the number of blocks they discover will increase exactly enough to maintain their current average earnings.

[vokain]

The confirmation process does take time, but the acknowledgement of an issued transaction by the miner network takes only seconds. Given the practical impossibility of double-spending, the presentation of the transaction to the network is a pretty good indication that it will be confirmed. What the confirmation really does is enable the recipient to "spend" the btc received.

This assumes that most transactions are not attempts to double-spend. Does anyone have stats on how many transactions are rejected as double-spend attempts?

Consider that a credit-card approval is also only provisional. It can be reversed for many days after being received. Once a btc transaction is confirmed, it cannot be reversed.

what if we got a free (or nearly) man-in-the-middle escrow service/app to make it so you can't doublespend from said app's wallet? Kinda like a wallet that you'd load like a giftcard, ie, once a tx is commenced, there is no irreversibility possible because of some special protocol, and that 10 minute no-blocks window doesn't matter anymore? I'd rather trust a reputable man in the middle (a la John K) than leave myself open to the possibility of a double-spend from someone anonymous/you may never see again after walking out the stoer

[BTC Books]

The confirmation process does take time, but the acknowledgement of an issued transaction by the miner network takes only seconds. Given the practical impossibility of double-spending, the presentation of the transaction to the network is a pretty good indication that it will be confirmed. What the confirmation really does is enable the recipient to "spend" the btc received.

This assumes that most transactions are not attempts to double-spend. Does anyone have stats on how many transactions are rejected as double-spend attempts?

Consider that a credit-card approval is also only provisional. It can be reversed for many days after being received. Once a btc transaction is confirmed, it cannot be reversed.

what if we got a free (or nearly) man-in-the-middle escrow service/app to make it so you can't doublespend from said app's wallet? Kinda like a wallet that you'd load like a giftcard, ie, once a tx is commenced, there is no irreversibility possible because of some special protocol, and that 10 minute no-blocks window doesn't matter anymore? I'd rather trust a reputable man in the middle (a la John K) than leave myself open to the possibility of a double-spend from someone anonymous/you may never see again after walking out the stoer

You've pretty much described Bridgewalker.

[jubalix]

I would really really like to use bitcoins every day, for every day purchases, and as a merchant. Many talk of wide adoption.

But transactions are SLOW.

What is the solution to this?

I can only really see a system that accepts an amount of risk, or you have to send bitcoins to a merchant and then they issue a value card.

but how to overcome the slow confirms, you can't just stand in line for that long, or is bitcoin going to be a reserve currency, for buying houses and such like?

over to your views/solutions

At some point BTC will only be suitable for very large transactions, which is where Litecoin (or one of the 10 or so derivitive coins) would step in to fill the need for micro-transactions.

some maths please for your position

This is also one of my views

*Cough cough*

There is no a solution based on blockchain+PoW combo. Other currencies use smaller gap between confirmations but they r less secure. The risk of double-spending is in inverse proportion to time of waiting, no matter how many confirmations u get.

[Come-from-Beyond]

Let's compare two cryptocoins. Coin A has 10 mins between blocks, coin B has 2.5 mins between blocks. We assume they use the same hashing algo.

Let coin A has difficulty = 2000, it means that in average it's necessary to do 1000 hashing cycles to find a block. Hence, difficulty of coin B = 500 (250 cycles to find a block).

Case A

Alice makes a payment in coin A. Bob waits for 2 confirmations which should take 20 mins. Alice owns 150% of hashing power (she doesn't use it for legit blockchain though). When Alice starts to hash she will get 60% of the total hashrate

Code:

150 / (100 + 150) = 150 / 250 = 60%

Odds that Alice will find 2 block in a row to fork the blockchain after Bob sees 2 confirmations

Code:

60% * 60% = 36%

Case B

Alice makes a payment in coin B. Bob waits for 8 confirmations which should take 20 mins. Alice owns 150% of hashing power (she doesn't use it for legit blockchain though).

Odds that Alice will find 8 block in a row to fork the blockchain after Bob sees 8 confirmations

Code:

60% * 60% * 60% * 60% * 60% * 60% * 60% * 60% = 4.6656%

Now we could say 36% =/= 4.6656%! But wait, Alice is not so stupid to hash together with legit miners. She searches for blocks in her own fork, so in reality things will go another way. Once again...

Case A

To find 2 blocks Alice have to do

Code:

2 blocks * 1000 cycles/block = 2000 cycles.

Case B

To find 8 blocks Alice have to do

Code:

8 blocks * 250 cycles/block = 2000 cycles.

So, what do we see?

The risk of double-spending is in inverse proportion to time of waiting, no matter how many confirmations u get.

[solex]

Yes. But surely that's basically theoretical.
No one can realistically have 150% the hashing power of the Bitcoin network. Yes, the risk of double-spend never goes away completely, but it gets vanishingly small very quickly. The merchant is more likely to have a fatal accident with the fridge door than have a double-spend problem after a few confirms.

[luv2drnkbr]

could you re-do the example with percentages that aren't above 100% please

[Come-from-Beyond]

could you re-do the example with percentages that aren't above 100% please

No need. In this case risk drops to almost zero right after the 1st confirmation.

[solex]

could you re-do the example with percentages that aren't above 100% please

No need. In this case risk drops to almost zero right after the 1st confirmation.

Excellent info.
Do you have a handle on what the risk is like if the transactions are, say 5 minutes apart, but no block has been hashed yet?

[Come-from-Beyond]

could you re-do the example with percentages that aren't above 100% please

No need. In this case risk drops to almost zero right after the 1st confirmation.

Excellent info.
Do you have a handle on what the risk is like if the transactions are, say 5 minutes apart, but no block has been hashed yet?

Only Satoshi knows.

[kokojie]

Solution: Litecoin

ur welcome

[amincd]

^ The solution is not to switch to a new blockchain that resets every one's holdings to zero every time there is a minor protocol improvement. The solution is to upgrade BTC.

The block time of BTC can be changed to something like 1 minute if we decide more frequent block generation provides an advantage.

[mccorvic]

Solution: Litecoin

ur welcome

Thanks for the joke I guess?

[Come-from-Beyond]

^ The solution is not to switch to a new blockchain that resets every one's holdings to zero every time there is a minor protocol improvement. The solution is to upgrade BTC.

The block time of BTC can be changed to something like 1 minute if we decide more frequent block generation provides an advantage.

1 minute is still too much.

[amincd]

It's not enough for POS, but in certain scenarios it would still be useful, like depositing BTC at an exchange or e-wallet that requires 1 confirmation to guard against Finney attacks.

[mgio]

The best solution I see is improved merchant-version Bitcoin client software which connects to a lot of nodes in order to detect a double-spend attempt as fast as possible.

This won't help against a Finney attack.

Finney attacks are getting harder and harder as the hash rate goes.

Pretty much no one solo mines anymore and even for those who do, they actually mine a block so infrequently.

And when you do find one, you have an average of less than 10 minutes to go spend that money and then submit it to the block chain.

And if you are late, you will lose your ~$3000 mining reward. Who would risk $3000 just for the change they could double spend some small amount of money??

[solex]

The best solution I see is improved merchant-version Bitcoin client software which connects to a lot of nodes in order to detect a double-spend attempt as fast as possible.

This won't help against a Finney attack.

Finney attacks are getting harder and harder as the hash rate goes.

Pretty much no one solo mines anymore and even for those who do, they actually mine a block so infrequently.

And when you do find one, you have an average of less than 10 minutes to go spend that money and then submit it to the block chain.

And if you are late, you will lose your ~$3000 mining reward. Who would risk $3000 just for the change they could double spend some small amount of money??

Exactly. So merchant software improvements are enough and block frequency (whether 10 minutes or 2.5 minutes) is unimportant in a mature network.
Problem solved.

[amincd]

Finney attacks are getting harder and harder as the hash rate goes.

True. The real reason exchanges/e-wallet operators would want to wait 1 or more confirmations is the risk that corrupt miners will permit tx replacement for a fee. This would allow unlimited attempts at 0-conf double spends at almost no cost in situations when coins sent in a double spend failure are refundable.

[jdbtracker]

so we got Bitcoin, superhard to falsify per block, once it's in the chain it is irrefutable, but it gives the network 10 minutes to propagate.

litecoin is perfect for intermediate transactions, 2.5 confirmations, by the time you are up to a minute it is well on it's way around the world.

so what would happen if we made a 1 second miner? considering the speed of the network... I figure it would get across north america in that time, but the hash
to confirm the transaction would be a bit higher than 1 second.

so... the case would be the same for bitcoin, you just wait for a few confirmations, maybe even setup your own miner in the store to begin the verification process,
hook it up to some super fast nodes(ASICs connected on a VPN) and boom you just decreased your confirmation time.

You know what would really be useful? if using a barcode the merchant Bitcoin client, automatically adds a transaction fee to the customers bill, so the business sets the speed of the confirmation.

The transaction is instant, it's gone, once you get enough nodes accepting the transaction over a trusted VPN connected to the businesses ASIC it's done, no need to wait 10 minutes, the confirmation would zoom past and get into the next block seconds before it's closed.

[Stephen Gornick]

Once a btc transaction is confirmed, it cannot be reversed.

There word "confirm" is used incorrectly sometimes.  I'm assuming you mean confirmed as having six confirmations.   Sometimes I see reference to a transaction with a single confirmation as being confirmed.   A transaction with one confirmation can be reversed and that has been seen on the bitcoin network occasionally in the past.

I would really really like to use bitcoins every day, for every day purchases, and as a merchant. Many talk of wide adoption.

But transactions are SLOW.

Incidentally, any discussion of accepting zero confirmation (0/unconfirmed) transactions should be aware of then potential for miners to begin using this on the production Bitcoin network:

Initial replace-by-fee implementation is now available on testnet
 - http://bitcointalk.org/index.php?topic=199947.0

Reminder: zero-conf is not safe; $1000USD reward posted for replace-by-fee patch
 - http://bitcointalk.org/index.php?topic=179612.0

[Come-from-Beyond]

Guys, don't forget that Bitcoin has eventual consistency. And there is no way to circumvent CAP theorem. So there is no a solution to the slow confirmations problem.

[Ares]

What would be the negative implications of 30-second blocks with a reward per block that would keep the same creation rate we currently have?

[oakpacific]

What would be the negative implications of 30-second blocks with a reward per block that would keep the same creation rate we currently have?

Too many orphaned blocks?

[solex]

Guys, don't forget that Bitcoin has eventual consistency. And there is no way to circumvent CAP theorem. So there is no a solution to the slow confirmations problem.

It doesn't matter.

Every business has a small overhead from transaction errors, counterfeit fiat money, bad debt or theft which result in net losses. These losses are absorbed by raising the average product price paid by all customers of each business.

A business suffering a loss from a rare Bitcoin double-spend will have to absorb such a loss, or insure against them if it decides that is the best approach. However, it seems likely that double-spend losses will be smaller overall than those seen with bad fiat transactions.

[oakpacific]

Guys, don't forget that Bitcoin has eventual consistency. And there is no way to circumvent CAP theorem. So there is no a solution to the slow confirmations problem.

It doesn't matter.

Every business has a small overhead from transaction errors, counterfeit fiat money, bad debt or theft which result in net losses. These losses are absorbed by raising the average product price paid by all customers of each business.

A business suffering a loss from a rare Bitcoin double-spend will have to absorb such a loss, or insure against them if it decides that is the best approach. However, it seems likely that double-spend losses will be smaller overall than those seen with bad fiat transactions.

Why not just refuse to deliver for people using addresses with unconfirmed transactions in it? And for anything valuable enough to use Finney attack it's reasonable to wait a bit longer.

[Come-from-Beyond]

Guys, don't forget that Bitcoin has eventual consistency. And there is no way to circumvent CAP theorem. So there is no a solution to the slow confirmations problem.

It doesn't matter.

Every business has a small overhead from transaction errors, counterfeit fiat money, bad debt or theft which result in net losses. These losses are absorbed by raising the average product price paid by all customers of each business.

A business suffering a loss from a rare Bitcoin double-spend will have to absorb such a loss, or insure against them if it decides that is the best approach. However, it seems likely that double-spend losses will be smaller overall than those seen with bad fiat transactions.

Someone can't create a lot of counterfeit banknotes, coz high-quality fakes require a lot of resources. But if someone manages to do double-spending, he can replicate this a million times. IMO.

[Ares]

What would be the negative implications of 30-second blocks with a reward per block that would keep the same creation rate we currently have?

Too many orphaned blocks?

Build more orphanages.

[oakpacific]

What would be the negative implications of 30-second blocks with a reward per block that would keep the same creation rate we currently have?

Too many orphaned blocks?

Build more orphanages.

https://github.com/litecoin-project/litecoin/wiki/Comparison-between-Bitcoin-and-Litecoin
See the "Cons" part under "Faster transaction time".

[solex]

Why not just refuse to deliver for people using addresses with unconfirmed transactions in it?

Absolutely. I mentioned this in the post just after the OP. The only transactions which are a problem are those where delivery is made first (such as buying petrol, or after a restaurant meal). Fiat transactions of this type are done quickly and the customer is gone.

Someone can't create a lot of counterfeit banknotes, coz high-quality fakes require a lot of resources. But if someone manages to do double-spending, he can replicate this a million times. IMO.

You are happy to present math to demonstrate an improbable situation where someone has 150% the hashing power of the network, but will you provide any math which shows the probability of the success of a double-spend when the 1st transaction precedes the 2nd by 10 seconds? (Because 10 seconds is a viable wait time for face-to-face transactions).

[Come-from-Beyond]

You are happy to present math to demonstrate an improbable situation where someone has 150% the hashing power of the network, but will you provide any math which shows the probability of the success of a double-spend when the 1st transaction precedes the 2nd by 10 seconds? (Because 10 seconds is a viable wait time for face-to-face transactions).

No, I won't.

[oakpacific]

Why not just refuse to deliver for people using addresses with unconfirmed transactions in it?

Absolutely. I mentioned this in the post just after the OP. The only transactions which are a problem are those where delivery is made first (such as buying petrol, or after a restaurant meal). Fiat transactions of this type are done quickly and the customer is gone.

I had an idea: what about just spending bitcoins like physical coins, with fixed denominations? This should not be too difficult to implement on a client: the client creates several hundred addresses in a batch(like when you are asleep), and fill them with bitcoins in fixed denominations, 5 BTCs, 2 BTCs, 1BTC, 0.5 BTC..... whenever the user needs to spend, the client chooses a number of addresses with just enough BTCs in them(no more than 15 for a price with three digits after the dot I guess), and generate a transaction with all these addresses as inputs. The merchant can then just check if all of the address are "fresh" to decide if he will accept the payment. Each address will be used only once, and the client will periodically check the number of remaining unused addresses to determine if another round of creation is required.

[solex]

Why not just refuse to deliver for people using addresses with unconfirmed transactions in it?

Absolutely. I mentioned this in the post just after the OP. The only transactions which are a problem are those where delivery is made first (such as buying petrol, or after a restaurant meal). Fiat transactions of this type are done quickly and the customer is gone.

I had an idea: what about just spending bitcoins like physical coins, with fixed denominations? This should not be too difficult to implement on a client: the client creates several hundred addresses in a batch(like when you are asleep), and fill them with bitcoins in fixed denominations, 5 BTCs, 2 BTCs, 1BTC, 0.5 BTC..... whenever the user needs to spend, the client chooses a number of addresses with just enough BTCs in them(no more than 15 for a price with three digits after the dot I guess), and generate a transaction with all these addresses as inputs. Each address will be used only once, and the client will periodically check the number of remaining unused addresses to determine if another round of creation is required.

I need to think about that, however,

Your link has led to this helpful gem:

https://en.bitcoin.it/wiki/Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation

It confirm's what I was thinking, which is that accepting zero-confirms for low value transactions is very low risk, especially when using merchant software which listens to a lot of nodes and customers wait around for 10 seconds so that any double-spend can be alerted to the merchant during that time.

[vokain]

what if we got a free (or nearly) man-in-the-middle escrow service/app to make it so you can't doublespend from said app's wallet? Kinda like a wallet that you'd load like a giftcard, ie, once a tx is commenced, there is no irreversibility possible because of some special protocol, and that 10 minute no-blocks window doesn't matter anymore? I'd rather trust a reputable man in the middle (a la John K) than leave myself open to the possibility of a double-spend from someone anonymous/you may never see again after walking out the stoer

You've pretty much described Bridgewalker.

Wow, thank you for bringing my attention to the service. It's even better

[SGExodus]

the slow confirms is caused by spam transactions which clog up the unconfirmed list. block satoshidice and other "on the chain" gambling sites and the problem is solved.

Since Bitcoin is designed to be divisible by 10 million, sending 1 satoshi is a totally valid transaction in the network.  Unless you go around and create a fork so that Bitcoin can only be divisible by 1000 instead.

[dogie]

Erm, you guys do realise that those 'instant' transactions in supermarkets and places like Mcdonalds are NOT confirmed. They're insured against the transaction not actually completing, and merely take the details of the card. It is then processed after the customer has taken the card out.

[amincd]

What would be the negative implications of 30-second blocks with a reward per block that would keep the same creation rate we currently have?

There would be more honest work lost to latency (I believe about 20% versus the current 1%), making a >50% attack easier. There are some bitcoin-alts that are using 30 second block times so that will be an useful experiment to watch.

I personally think 30 seconds is too radical for an established network like BTC to adopt, but 1 minute would be appropriate.

[jubalix]

What would be the negative implications of 30-second blocks with a reward per block that would keep the same creation rate we currently have?

There would be more honest work lost to latency (I believe about 20% versus the current 1%), making a >50% attack easier. There are some bitcoin-alts that are using 30 second block times so that will be an useful experiment to watch.

I personally think 30 seconds is too radical for an established network like BTC to adopt, but 1 minute would be appropriate.

yeah maybe for BTC\

WDC is trying 15 secons

[amincd]

Exactly, the BTC-alts have little to lose as they have few people and businesses relying on them, so can afford to try something that's unproven. BTC should be conservative with protocol changes. Even changing to a one minute block time would be seen as too drastic and risky by some.