Topic: The Slow transaction speed [confirms], solutions, discussion. Wide adoption (Read 4099 times)
May 16, 2013, 08:55:10 PM
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.
May 16, 2013, 08:09:14 PM
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
May 16, 2013, 07:20:48 PM
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.
May 16, 2013, 08:21:14 AM
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.
May 16, 2013, 01:58:29 AM
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.
May 16, 2013, 01:48:52 AM
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
May 14, 2013, 03:01:02 AM
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.
May 14, 2013, 02:57:40 AM
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.
May 14, 2013, 02:53:04 AM
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.
May 14, 2013, 02:50:01 AM
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).
May 14, 2013, 02:43:55 AM
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".
May 14, 2013, 02:41:59 AM
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.
May 14, 2013, 02:39:22 AM
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.
May 14, 2013, 02:37:02 AM
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.
May 14, 2013, 02:35:41 AM
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.
May 14, 2013, 02:34:51 AM
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?
May 14, 2013, 02:32:27 AM
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?
May 14, 2013, 02:11:46 AM
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.
May 13, 2013, 10:04:33 PM
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.
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
- https://bitcointalksearch.org/topic/initial-replace-by-fee-implementation-is-now-available-on-testnet-199947
Reminder: zero-conf is not safe; $1000USD reward posted for replace-by-fee patch
- https://bitcointalksearch.org/topic/reminder-zero-conf-is-not-safe-1000usd-reward-posted-for-replace-by-fee-patch-179612
May 13, 2013, 08:28:01 PM
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.
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.
Jump to: