Block Spacing And Security

[Willisius]

I believe I read on the wiki that Satoshi chose 10 minute target spacing for blocks because there's enough time for everyone to know the current block and start working on it. I see altcoins, such as Litecoin, with 2.5 minute block spacing. Some even go as low as less than a minute. Are these blockchains less secure because of this? The orphan rate is probably a lot higher, I know. But I'd like to know the other implications of having such short spacing.

[jl2012]

Orphaned blocks are wasted having power, so the network becomes less secure

[chris.capossela]

Orphaned blocks are wasted having power, so the network becomes less secure

For more detail, I'll try to present a few numbers.
I referred to the bitcoinmagazine article: http://bitcoinmagazine.com/8972/quarkcoin-noble-intentions-wrong-approach/

Assuming it takes about twelve seconds for the block to propagate through the network...

Bitcoin (10min): 2% work wasted = 2% less secure
Litecoin (2.5min): 8% work wasted = 8% less secure
Primecoin (1min): 20% work wasted = 20% less secure (than all of the work dedicated).

[leemar]

The problem is 2-20% less secure than what? The same hashing power as is being used now?

If useability restricts real growth of the network, the price and then hashing rate will start to fall at some point.

If we don't believe that some blocks getting hashed in over an hour, as has just happened, is not a real issue for useability I think we are kidding ourselves.

I am sure far smarter people than me have made very cogent arguments about why block resolution rates shouldn't be lower but we need to acknowledge what is being lost with long confirmation times.

[DeathAndTaxes]

The problem is 8% less secure than what? The same hashing power as is being used now

If x% of the honest miners efforts are wasted on duplicated work (orphans) than the cost to an attack is x% lower.  Put another way if a network is secured by 100 TH/s but it has a 20% orphan rate then it could be 51% attacked with just 80 TH/s.  The 100 TH/s is an illusion as only the hashes spent on extending the longest chain contribute to the effective security.  The attack isn't going to be affected by orphans as the attacker is always going to extend his own chain until the attack either succeeds or he falls so far behind it is improbable he will catch up (only applies when attacking with a minority of the hashrate).

Anything below 10% orphaned is probably "good enough" but the numbers is the article assume a block propagation time of 12 seconds.   How will these networks react when tx volume is increased 10x, 100x, 10,000x?  Satoshi chose 10 minutes as a very conservative knowing that predicting future propagation of a network which may be thousands of times larger would be very difficult.  It may turn out that at some point even 10 minutes will be "too fast".  I think that is unlikely as it would require a huge tx volume, and block propagation delays (on a per tx basis) should decline due to improvements in hardware, bandwidth/latency, and protocol efficiency but it could happen.

[leemar]

Thanks DeathAndTaxes

This is obviously in exercise guessing optimisation depending on variable use cases.  My fear is that that adoption will be held back and hence the rate of network propagation will not be an issue for a very long time.  I suspect even 2.5 minute confirmations would help (not litecoin obviously) for only an 8% decline in security where the hash rate seems to increase by more than that on a month by month basis.

Out of curiosity what constitutes a fully “propagate” message what does 12s quoted above relate to and is this likely to be subject to infrastructural improvements if block sizes rise substantially.  I believe processors like Bitpay “listen” to specific nodes for near instant confirmation to mitigate double spend risk.

[nanonano]

My fear is that that adoption will be held back and hence the rate of network propagation will not be an issue for a very long time.

What kind of adoption is held back with 10min block time versus 2.5 minute block time?

• everyday in-shop purchases shops can accept non-confirmed transactions -- the risk when handled properly is minimal compared to things like counterfeit cash or credit back claims
• web shops can always wait for confirmations if they want -- 10 minutes will not affect a two-day delivery
• Waiting for a confirmation on a major purchase you only make every few years (say, a car or a house) is not a big deal

I can't think of a use case where waiting 2.5 minutes is acceptable but ten minutes isn't. What did you have in mind?

[cypherblock]

What kind of adoption is held back with 10min block time versus 2.5 minute block time?

• everyday in-shop purchases shops can accept non-confirmed transactions -- the risk when handled properly is minimal compared to things like counterfeit cash or credit back claims
  

Let's say you are buying $250 at grocery store. Really they are going to accept 0 or 1 confirmation? Chances are they will want 6 or more. It is a definite issue in my mind.

Best solution I've seen is to use trusted 3rd parties using 2 of 2 multisig transactions (greenaddress.it is rolling this out now I think). This then allows merchant to accept 0 confirmation transactions and trusts that the 3rd party won't double spend. Both merchant and customer have to be using the same 3rd party though, so that is a drawback but merchants could accept payments from multiple 3rd parties.

Steps:

• Customer can send funds in advance to a multisig address requiring their signature and 3rd party sig.
• At payment time, customer and 3rd party both sign a transaction spending the multisig transaction and sending payment to the merchant.
• Merchant is trusting 3rd party not to double spend.
• Merchant gets sent copy of transaction presumably using payment protocol, so they don't even wait for it to get propagated through the bitcoin network.

[jl2012]

What kind of adoption is held back with 10min block time versus 2.5 minute block time?

• everyday in-shop purchases shops can accept non-confirmed transactions -- the risk when handled properly is minimal compared to things like counterfeit cash or credit back claims
  

Let's say you are buying $250 at grocery store. Really they are going to accept 0 or 1 confirmation? Chances are they will want 6 or more. It is a definite issue in my mind.

Best solution I've seen is to use trusted 3rd parties using 2 of 2 multisig transactions (greenaddress.it is rolling this out now I think). This then allows merchant to accept 0 confirmation transactions and trusts that the 3rd party won't double spend. Both merchant and customer have to be using the same 3rd party though, so that is a drawback but merchants could accept payments from multiple 3rd parties.

Steps:

• Customer can send funds in advance to a multisig address requiring their signature and 3rd party sig.
• At payment time, customer and 3rd party both sign a transaction spending the multisig transaction and sending payment to the merchant.
• Merchant is trusting 3rd party not to double spend.
• Merchant gets sent copy of transaction presumably using payment protocol, so they don't even wait for it to get propagated through the bitcoin network.

If the grocery store requires 6 confirmations, even 6*2.5=15 minutes is absolutely not acceptable, as VISA takes only 15 seconds

To compete with VISA, the block space has to be something like 2.5 seconds, which obviously won't work.

Yes, the 3rd party green address is the best solution.

[nanonano]

Let's say you are buying $250 at grocery store. Really they are going to accept 0 or 1 confirmation? Chances are they will want 6 or more. It is a definite issue in my mind.

I'm guessing you've not seen the cash flow of a small item store? There's a significant percentage of money you end up "losing", regardless of payment system. Actual counterfeit bills, con artists confusing clerks to give wrong change, credit card companies pulling back payments even weeks after the fact, even debit payments can be denied if the store didn't check the signature... It's useful to realize that bitcoin isn't competing with perfect systems: all of them have these hidden costs, and so far the costs related to bitcoin seem small in comparison. I have no idea if bitcoin will be used in day-to-day shopping at some point but this issue does not seem relevant to me.

As to your example: doing a double spend attack on a $250 purchase (that is handled by a competent payment processor) is just not financially sane. So yes, I absolutely believe a store that handles such small amounts will accept 0 confirmations. The tiny risk might be taken by the payment processor or the store, that remains to be seen.

[cypherblock]

As to your example: doing a double spend attack on a $250 purchase (that is handled by a competent payment processor) is just not financially sane. So yes, I absolutely believe a store that handles such small amounts will accept 0 confirmations. The tiny risk might be taken by the payment processor or the store, that remains to be seen.

Why is it not financially sane to do a double spend attack? If merchant is taking 0 confirmations, then there's probably like a 50% chance that my double spend will work. At checkout my evil wallet software simultaneously sends the bitcoins to the merchant address and does a separate transaction sending them to me. These are broadcast to the bitcoin network at the same time. One of these transactions will get added inside the block chain.

From https://en.bitcoin.it/wiki/Double-spending

Traders and merchants who accept a payment immediately on seeing "0/unconfirmed" are exposed to a double-spend occurring if there was a fraudulent attempt that successfully communicated one transaction to the merchant yet communicated a different transaction that spends the same coin that was first to eventually make it into the block chain.

[DeathAndTaxes]

Why is it not financially sane to do a double spend attack? If merchant is taking 0 confirmations, then there's probably like a 50% chance that my double spend will work. At checkout my evil wallet software simultaneously sends the bitcoins to the merchant address and does a separate transaction sending them to me. These are broadcast to the bitcoin network at the same time. One of these transactions will get added inside the block chain.

That type of doublespend is trivial to detect.  Merchant waits 10 seconds and merchant (or payment processor) has a dozen listnening nodes geolocated around the world.  Within the 10 seconds either merchants tx propogates the entire network or your double spend hits one of the listening nodes.  If double spend is detected POS terminal reports "payment declined" and cashier asks you for payment in another method.

This isn't to say 0-confirm is safe but it will require a dishonest miner.  Either one you pay for that service or mining power you control directly.   This way the double spend is never propogated on the bitcoin network and there is nothing to detect.  Of course if you are hiring 5% of the hashing power there is a 95% chance the real tx will go through.  Of course a smart merchant before letting you pay by Bitcoins the first time will ask for a CC or check and then charge you the cost of the purchase plus $50 failed payment fee when your double spend works.

[cypherblock]

That type of doublespend is trivial to detect.  Merchant waits 10 seconds and merchant (or payment processor) has a dozen listnening nodes geolocated around the world.  Within the 10 seconds either merchants tx propogates the entire network or your double spend hits one of the listening nodes.  If double spend is detected POS terminal reports "payment declined" and cashier asks you for payment in another method.

Well that is a good point, although I'm not aware of any feature like this in standard bitcoin core to report double spend transactions (but I saw some discussions proposing that, were any implemented??), so they would have to have their own customized node software to report the double spend attempt, but that probably wouldn't be too hard since much of it is open source. You are correct that 3rd party services can and probably will implement this as a feature (and perhaps they are doing this already). In fact I'm sort of surprised I haven't heard of it already being offered.

What I have seen is the green address technique, which can use 2 of 2 multi-sig transactions and a trusted 3rd party for instant 0-conf payments with double spend protection (assuming 3rd party is trust worthy).

But why isn't everyone adopting your proposed technique? It really isn't being done yet is it? Or if it is, post links to services offering this.

References:
https://github.com/bitcoin/bitcoin/issues/1034

http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/519AC3A8.1020306%40quinnharris.me/#msg30873782

[DeathAndTaxes]

But why isn't everyone adopting your proposed technique? It really isn't being done yet is it? Or if it is, post links to services offering this.

I don't know any third party services which do this but internally we use that general technique to monitor a lot of conditions which overall I call "bitcoin network health".   As for why is nobody offering a double spend detection service?  Well one reason is double spends are incredibly rare, the fear far outweighs the reality.  The other reason is most merchants wait for at least one confirmation so they don't need to look for 0-confirm doubles.  It is important to understand that this type of network monitoring can't detect a double spend attempt when the double spend is not transmitted over the bitcoin network.  If an attacker has a deal with a "bad" miner to include his double spends in blocks for a share of the profit that will be undetectable until the block is published so even if you monitor the network you could be double spent.

0-confirm is not suitable for all businesses and one shouldn't naively assume they are safe but the reality is NO payment system is immune to fraud.  CC, checks, ACH, even good ole cash can be fraudulent.  Bitcoin doesn't need to be achieve a zero fraud rate, it just needs to be better than the alternatives.  For low value in person transactions 0-confirm is probably sufficient.  For donations, and digital goods which can be revoked (think steam games) 0-confirm works equally fine, for any product that is a subscription 0-confirm also works.  If you are selling gold bullion by the metric ton you probably should be waiting for confirmations (even 6 might not be enough security).

[cypherblock]

 Well one reason is double spends are incredibly rare, the fear far outweighs the reality.  The other reason is most merchants wait for at least one confirmation...

Right, double spends attempts are rare because few merchants are using 0-conf. So if 0-conf became more popular then I'm sure double spend attempts at those places would be much more common.

So I do think 0-conf is needed at brick and mortar shops and protection is needed there especially. Just for peace of mind, businesses need to know that there is some protections for them. Detecting double spends like you mention should be standard and built into all wallets/services.