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

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