Why aren't transactions faster?

[amincd]

^ Yes there are solutions to get around the confirmation wait, like the one you noted. Another is to use the 'rapidly adjusted micropayment channel' that Mike Hearn and Matt Corallo developed in bitcoinj.

All things being equal however, having less time to first confirmation is still more convenient for the customer and merchant, as there will be situations when these special solutions to get around the block time wait will not be used for whatever reason. It's just that all things aren't equal, and other factors need to be considered in choosing a block time.

[1714795741]

1714795741

[1714795741]

1714795741

[Shawshank]

There is nothing you can do to provide significant protection except wait for a confirmation. Do not trust zero-confirmation transactions, ever*.

Wouldn't it be possible to have the top-10 pools state on their website they will not add double-spent transactions to the blockchain even if its fee is higher than the previous transaction? That would definitely give confidence on all kind of merchants by listening to the network for a few seconds and accept low to medium purchases online and in brick-and-mortar premises. It would also bring down the cost of insurance.

[StarfishPrime]

I agree that with the proper precautions (waiting a few seconds to see if there are double spend attempts, ensuring the transaction has a sufficient tx fee) 0-confs is enough for a point of sale transaction.

No, no, and no. None of those precautions you mention do anything to protect you against a double spend. There is nothing you can do to provide significant protection except wait for a confirmation. Do not trust zero-confirmation transactions, ever*.

(* Unless you are extending pre-existing trust you've placed in the person sending the coins, or have some mechanism for obtaining restitution in the case of a double-spend. Either way, that's side-stepping, not solving the problem.)

Depends completely on the context and the method of transaction. A coffee shop accepting 0-confirmation transactions using a protocol like OpenCXP will have virtually no chance of a double spend. Ever. Any risk of loss would be far, far lower than the 1-3% average fraud loss for card payments which retailers already accept today (over and above the guaranteed "loss" of 3-5% in fees!).

[maaku]

Once replace-with-fee is deployed, I could rip off that coffee shop with near 100% reliability, every time until they stop serving me coffee. Don't accept zero-conf transactions.

[dingrite]

What happens if a miner or miners working on the current block get one transaction and x time later get another transaction which is a double-spend of the first while the block is not yet completed? Do they discard both transactions? Or what?

And what happens if the double spend transaction comes a block later? 2 blocks? 3 blocks? etc...    - I assume in those instances the latter double-spend transaction is simply discarded?


Then what happens if one transaction gets into 1 block by miner A. The double spend transaction gets into 1 block by miner B. If the time difference is not large it's hard to believe either would surrender to the other and both will try to continue their block chain for the time being to try and earn extra 25 BTC.

Just some thoughts I have. The probability of this obviously decreases with every block radically especially because un-involved miners will just go the faster block so the stack is loaded against miner B after just 1 extra block (his chances become nill and he has to go with the herd).

[DeathAndTaxes]

Once replace-with-fee is deployed, I could rip off that coffee shop with near 100% reliability, every time until they stop serving me coffee. Don't accept zero-conf transactions.

The proposed replace with fee requires the same outputs.  Of course you could also rip off a coffee shop with counterfeit bills or a stolen credit card.  Would be kinda stupid to go to jail for stolen coffee though.

[StarfishPrime]

Once replace-with-fee is deployed, I could rip off that coffee shop with near 100% reliability, every time until they stop serving me coffee. Don't accept zero-conf transactions.

Except that you couldn't, at least not without a significant amount of effort, cost and luck - far disproportionate to any possible gain.

That's exactly the problem that OpenCXP solves.

[maaku]

OpenCXP does nothing and can do nothing to prevent a double-spend with higher fees from replacing the transaction you agreed upon once you walk out that door.

[DeathAndTaxes]

OpenCXP does nothing and can do nothing to prevent a double-spend with higher fees from replacing the transaction you agreed upon once you walk out that door.

No the client already handles that very well.  Every node will simply drop the double spend.  

[Peter Todd]

OpenCXP does nothing and can do nothing to prevent a double-spend with higher fees from replacing the transaction you agreed upon once you walk out that door.

No the client already handles that very well.  Every node will simply drop the double spend.  

Nodes do not and can-not drop blocks with the double-spend, which is what matters.

Also ironically the double-spend warning feature proposed for 0.9 will make it trivial for individual miners to choose to adopt replace-by-fee rules, because there is currently no way to prove that a double-spend exists other than by broadcasting the entire double-spend transaction.

[DeathAndTaxes]

OpenCXP does nothing and can do nothing to prevent a double-spend with higher fees from replacing the transaction you agreed upon once you walk out that door.

No the client already handles that very well.  Every node will simply drop the double spend. 

Nodes do not and can-not drop blocks with the double-spend, which is what matters.

Also ironically the double-spend warning feature proposed for 0.9 will make it trivial for individual miners to choose to adopt replace-by-fee rules, because there is currently no way to prove that a double-spend exists other than by broadcasting the entire double-spend transaction.

Well that is why I said tx not block.  Can miners conspire to defraud merchants and thus kill Bitcoin adoption and value and indirectly reduce the very value of the coins they are mining?  Of course.  Will they?  It remains to be seen but on low value txs I don't see the merits.

All forms of commerce CAN involve fraud.  One could counterfeit $1 bills just to steal a lifetime of sodas from soda machines.  It probably isn't worth the cost and risk though.   One could get free coffee from this hypothetical scenario by putting a gun in the face of the cashier and demanding not the money in the till but a free large espresso.  I don't see that happening either.

In time merchants will adopt the level of security vs convenience that they see necessary.  Much like how soda machines are wide open to attack by stolen credit cards and counterfeit bills yet have not taken more expensive and intrusive countermeasures there will be a place for 0-confirm transactions.  Note: nothing I said should be taken that all merchants should rush into accepting 0-confirm txs in all scenarios without understanding the risks.
 

[Peter Todd]

Well that is why I said tx not block.  Can miners conspire to defraud merchants and thus kill Bitcoin adoption and value and indirectly reduce the very value of the coins they are mining?  Of course.  Will they?  It remains to be seen but on low value txs I don't see the merits.

Some would argue they are defrauding merchants, others would argue they are staving off the kinds of ill-considered centralization that would apply anti-double-spend rules to blocks as well. (there's no way to do this without in effect lowering the block interval) Or they might point to the legal argument that miners may be held negligent in civil cases for failing to have "enough" bandwidth to avoid being "tricked" into accepting a double-spend rather than the "correct" transaction. Finally some would point to the replace-by-fee "scorched earth" strategy and say that allowing profit-driven double-spends is actually safer for eveyone.

In time merchants will adopt the level of security vs convenience that they see necessary.  Much like how soda machines are wide open to attack by stolen credit cards and counterfeit bills yet have not taken more expensive and intrusive countermeasures there will be a place for 0-confirm transactions.  Note: nothing I said should be taken that all merchants should rush into accepting 0-confirm txs in all scenarios without understanding the risks.

Bill acceptors in vending machines are actually quite expensive and complex pieces of technology to keep counterfeiters at bay; they are not easy to fool. Similarly stolen credit cards are a big concern and has driven the industry into pushing for smartcard-style credit cards that are significantly more difficult to counterfeit, although note how the concern there is less so than with counterfeit bills because you don't get change back when you pay by credit-card.

[StarfishPrime]

...

All forms of commerce CAN involve fraud.  One could counterfeit $1 bills just to steal a lifetime of sodas from soda machines.  It probably isn't worth the cost and risk though.   One could get free coffee from this hypothetical scenario by putting a gun in the face of the cashier and demanding not the money in the till but a free large espresso.  I don't see that happening either.

In time merchants will adopt the level of security vs convenience that they see necessary.  Much like how soda machines are wide open to attack by stolen credit cards and counterfeit bills yet have not taken more expensive and intrusive countermeasures there will be a place for 0-confirm transactions.  Note: nothing I said should be taken that all merchants should rush into accepting 0-confirm txs in all scenarios without understanding the risks.
 

^ This. Exactly. Merchants will manage their risks exactly like they do today with credit cards, cash, etc. Once adoption becomes more widespread, statistics will be available to to this.

In almost every case, risks and overall costs should prove to be much lower than existing payment networks. BitPay has reported that in their first 10K transactions, there wasn't a single case of fraud. Compare that with any credit card scenario online or in-person.

Satoshi actually included a very useful mechanism in the protocol specifications and data structures which hasn't been implemented in BitcoinQT but could basically solve the double-spend problem (at least regarding tx replacement) if it was:

Using the sequence and lock_time fields prevents a tx from being replaced by another tx after the specified time (or block number, or ever if sequence = UINT_MAX)

If/when the core devs ever implement this it would be a major step toward 'last mile' adoption of bitcoin in retail and we could finally get beyond the discussions of the (mostly hypothetical) double-spend "problem".

Any "replace-by-fee" mechanism that ignores the sequence and lock_time fields would be likely be considered broken by Satoshi.

[gmaxwell]

Satoshi actually included a very useful mechanism in the protocol specifications and data structures which hasn't been implemented in BitcoinQT but could basically solve the double-spend problem (at least regarding tx replacement) if it was:
Using the sequence and lock_time fields prevents a tx from being replaced by another tx after the specified time (or block number, or ever if sequence = UINT_MAX)
If/when the core devs ever implement this it would be a major step toward 'last mile' adoption of bitcoin in retail and we could finally get beyond the discussions of the (mostly hypothetical) double-spend "problem".
Any "replace-by-fee" mechanism that ignores the sequence and lock_time fields would be likely be considered broken by Satoshi.

Satoshi made a few serious mistakes, expecting sequence mediated replacement to be usable may have been one of them. Perhaps he realized that and thats why— unlike so many other things— he didn't actually implement it.

There are two major issues with sequence mediated replacement:

First is that it opens a major DOS vulnerability: I start issuing bunches of the largest transactions the network will tolerate, with high fees, locked so they are not going to be mined for the immediate future... but I'll never pay those fees because I'll replace them all before they become due. But until then I'm running every node out of memory pool storage. Any way that closes the DOS attack provides a way for an attacker to help them violate the sequence ratchet.

The second is that it demands all miners behave in a way that reduces their income, perhaps substantially. If I learn of an earlier sequence spend with an child transaction that pays a high fee, why should I continue to attempt to mine the higher sequenced spend?

Miners behaving in their own short term interests against the interests of (some of) the users is not hypothetical, its a reality today.

So far I've not seen or come up with any way of solving the DOS problem, nor any way of solving the incentives problem that works for non-trivial-valued transactions (for trivial valued transactions we could perhaps use the threat of increased orphan risk, but that stops being a solution for high values or if attackers start bribing many miners with chains of fees).

[maaku]

Satoshi actually included a very useful mechanism in the protocol specifications and data structures which hasn't been implemented in BitcoinQT but could basically solve the double-spend problem (at least regarding tx replacement) if it was:

Using the sequence and lock_time fields prevents a tx from being replaced by another tx after the specified time (or block number, or ever if sequence = UINT_MAX)

Beyond the valid points made by gmaxwell and Peter Todd, you are making one serious mistake in your reasoning: you are assuming that other clients will behave like your client does. The *only* transaction-selection behavior that is enforced by protocol is proof-of-work confirmation of transactions in blocks. You have no guarantees that any other node will handle double-spends the same way you or a future version of the reference bitcoin client does.

Example: a site like blockchain.info tries to connect to every single node on the bitcoin network, and keeps all transactions, including double-spends. If it were configured to forward transactions, or if miners scraped the bc.i update pages for transactions it hadn't seen (a not unlikely possibility), then it does not matter in the slightest what the default relay rules are of the rest of the network. Anyone can perform a double-spend by sending the transaction to bc.i, and one way or another a major mining pool with promiscuous replace-by-fee settings will accept it.

The bitcoin protocol offers absolutely no hard guarantees about consensus until a transaction finds its way into a valid block. Placing any trust in unenforced and unenforceable relay rules is a recipe for disaster.

[StarfishPrime]

...
There are two major issues with sequence mediated replacement:

First is that it opens a major DOS vulnerability: I start issuing bunches of the largest transactions the network will tolerate, with high fees, locked so they are not going to be mined for the immediate future... but I'll never pay those fees because I'll replace them all before they become due. But until then I'm running every node out of memory pool storage. Any way that closes the DOS attack provides a way for an attacker to help them violate the sequence ratchet.

Yes, agreed. I think the implementation of this would need to be constrained and certainly not be open-ended. This could so easily be exploited it must have already been seen as a vulnerability when the spec was drafted.

...
The second is that it demands all miners behave in a way that reduces their income, perhaps substantially. If I learn of an earlier sequence spend with an child transaction that pays a high fee, why should I continue to attempt to mine the higher sequenced spend?

Miners behaving in their own short term interests against the interests of (some of) the users is not hypothetical, its a reality today.

So far I've not seen or come up with any way of solving the DOS problem, nor any way of solving the incentives problem that works for non-trivial-valued transactions (for trivial valued transactions we could perhaps use the threat of increased orphan risk, but that stops being a solution for high values or if attackers start bribing many miners with chains of fees).

The following minor implemention would "fix" the double-spend by higher-fee-replacement scenario: If sequence == UINT_MAX, then the tx 'finality' would be respected (as originally intended per the spec) and the tx would not be replaced by any node - even if replace-by-fee was implemented and the fee was higher.

This would go a long way to reducing any chance of malicious double-spend success, while not increasing DOS vulnerability or affecting other situations where replacement-by-fee could be useful.  

[StarfishPrime]

...
The bitcoin protocol offers absolutely no hard guarantees about consensus until a transaction finds its way into a valid block. Placing any trust in unenforced and unenforceable relay rules is a recipe for disaster.

In an absolute sense, this is of course 100% accurate.
Back in the real-world of retail transactions however, there are no absolutes or guarantees. A 99% (or even 96%) certainty that a tx will eventually confirm is all that would be required to make bitcoin payments on par with existing networks (Visa, MC, or even cash) in terms of the cost/risk exposure profile (which is huge).

Perfect is the enemy of better.

[oakpacific]

What about asking customers to use only one-time addresses(could be several addresses with fixed denominations or just a round number which is larger than the purchase sum, changes will be sent back later to a designated address by the merchant), whose private keys will be submitted to the merchant at time of payment, so that if the buyer conducts any further foul plays, the merchant could do the same.

[callem]

What about asking customers to use only one-time addresses(could be several addresses with fixed denominations or just a round number which is larger than the purchase sum, changes will be sent back later to a designated address by the merchant), whose private keys will be submitted to the merchant at time of payment, so that if the buyer conducts any further foul plays, the merchant could do the same.

OpenCXP does similar to what you describe, sends back change to the customer and has control of both the fee amount and transaction broadcast latency time, greatly reducing the already very low risk of a successful double spend.

Any implementation of replace-by-fee that doesn't follow the bitcoin specification by respecting tx sequence is broken. This wasn't a mistake by Satoshi, it was his solution for entirely optional tx malleability.

A broken implementation would be disastrous for bitcoin. It would make fraud through double spending trivial by undermining tx irreversibility and damaging the already fragile confidence in bitcoin as a payment system.

Again - it would be disastrous. Remember, double spends are not a trivial peripheral issue. They are the very core issue that bitcoin solved.