[Theory] The optimal confirmation time

[monsterer]

Just thinking out loud about the ideal blockchain here.

Is the ideal confirmation time for a transaction the time it takes to propagate to >50% of the network?

You can define 'the network' as hashing power, stake, or some other comparable metric.

[virtualx]

Just thinking out loud about the ideal blockchain here.

Is the ideal confirmation time for a transaction the time it takes to propagate to >50% of the network?

You can define 'the network' as hashing power, stake, or some other comparable metric.

6 confirmations is considered a standard amount of time required for any Bitcoin-like crypto currency to ensure a transaction will not be reversed. The time to generate a Block will not change without changing the protocol, so one would still require an hour to generate those 6 confirmations. The confirmation time is fine. There are alts with shorter confirmation time but at the cost of security.

[monsterer]

6 confirmations is considered a standard amount of time required for any Bitcoin-like crypto currency to ensure a transaction will not be reversed. The time to generate a Block will not change without changing the protocol, so one would still require an hour to generate those 6 confirmations. The confirmation time is fine. There are alts with shorter confirmation time but at the cost of security.

I'm thinking far outside the box here - pure theory, disregarding existing blockchain designs. Theoretically speaking, a confirmed transaction should be one that >half the network has 'signed off' on?

[Jakesy]

A ‘confirmation’ is when a transaction exists in a block.  Each subsequent block further confirms that transaction.  6 confirmations means that the transaction exists in a mined block and 5 other blocks were found thereafter.  Remember, each block references the previous which makes this chain stronger.  It’s mathematically sound to allow for

• 0 confirmation purchases under $20,
• 1 confirmation <$100,
• 2 confirmations for a nice TV,
• 3 confirmations for a vacation package,
• 4 confirmations for a car,
• 5 confirmations for a house, and
• 6 confirmations for a fighter jet.  

A double spender would have to computationally create new blocks to create the longest chain – it would be more expensive to try to double spend this way.

A ‘confirmed transaction’ is one in which the ENTIRE network has signed off on by including it in a block.  0 confirmations just means the transaction has been broadcast and miners should include it while trying to find the next block.

[DumbFruit]

Ideally confirmation times would be instantaneous, but since finding hashes is stochastic, the internet is heterogeneous, and information can't travel faster than the speed of light, it is physically impossible to achieve this ideal.

Agencies or currencies that don't rely on global consensus need not concern themselves with any of that, for the most part. So the Bitcoin protocol itself can't compete in confirmed transaction times.

The reason the Bitcoin community has gravitated to the somewhat arbitrary 6 confirmation number is because this represents an amount of work to achieve that no agency on Earth could conceivably reverse (aliens notwithstanding). So if confirmation times were reduced, the amount of confirmations to achieve the same level of confidence would go up, netting us zero benefit.

I'm avoiding the central issue here; How short should confirmation times be where orphan blocks are minimal and the status of the internet is taken into consideration? I'm avoiding it for two reasons;

1.) I'm lazy, and I don't want to go through the calculations that have been done before and look at the graphs and see if Bitcoin's current confirmation time is reasonable. Bitcoin itself demonstrates convincingly that the 10 minute mark works fine.

2.) There is a wide range of confirmation times that are "good enough" and the benefits of reducing confirmation times are minimal while running the greater risk of damaging the consensus mechanism of the cryptocurrency.

[monsterer]

Maybe I'm not stating my question correctly.

This is entirely a theoretical question, so imagine there are no blocks, but we still do have hashing power on the network (or stake, for a POS chain) in order to be able to reach some kind of consensus.

Under these broad assumptions, is the optimal confirmation time (fastest possible time to form a robust consensus) simply the time it takes for >50% of the hashing power/stake to agree on any given transaction, or is it more complicated than that?

[DumbFruit]

I don't want to sound too harsh, but it doesn't seem like you know what hashing in Bitcoin does exactly.

https://en.bitcoin.it/wiki/Proof_of_work

Edit:
To be more specific. You're talking about getting consensus over some abstract data while using "hashes" without a blockchain. The reason this doesn't make sense is because consensus is about the ordering of transactions over time, so when you remove the blockchain you're just talking about a piece of data you're spreading around and hashing "it" doesn't do anything for us.

It's like saying, "If I send an email to 100 people, how many hashes do they need to perform before we have consensus that they received the email (or that the email is correct)?"

[Jakesy]

Maybe I'm not stating my question correctly.

This is entirely a theoretical question, so imagine there are no blocks, but we still do have hashing power on the network (or stake, for a POS chain) in order to be able to reach some kind of consensus.

Under these broad assumptions, is the optimal confirmation time (fastest possible time to form a robust consensus) simply the time it takes for >50% of the hashing power/stake to agree on any given transaction, or is it more complicated than that?

I think you're confusing the term 'verification' with 'confirmation.'

Hashing power is used for finding the block by including transactions and iterating through a random number (nonce) in order to change the hash output to be less than a target value (0x000000000000blahblahblah).  We can then verify quickly that the proof-of-work is true (yay math!) so that other miners will accept this block and move onto the next block.

We can't "imagine there are no blocks" without there being a basis for "consensus".  From the 0 (genesis block) to the current block we believe all the information to be true because we can openly (and quickly) verify it - that's your consensus.

What I think you may be asking is... the time it takes one miner to find a block and broadcasts it to the network - the time it takes for all nodes to receive this broadcast and verify it so that they may move on to the next block, would the optimum time be for the target value to adjust to >50% of this broadcast/verify time?  

Let's say it takes 30 seconds for all miners to receive the broadcast and verify the proof-of-work.  Should we adjust the target value so that a block is found every >15 seconds?  Is this what you're asking?

[monsterer]

I don't want to sound too harsh, but it doesn't seem like you know what hashing in Bitcoin does exactly.

https://en.bitcoin.it/wiki/Proof_of_work

I thinking in more abstract terms here than purely the computation of hashes; hashing power can be thought of like stake, in that the more hashing power you have, the more invested you are in the network and the more control over the consensus you have.

[Jakesy]

I don't want to sound too harsh, but it doesn't seem like you know what hashing in Bitcoin does exactly.

https://en.bitcoin.it/wiki/Proof_of_work

I thinking in more abstract terms here than purely the computation of hashes; hashing power can be thought of like stake, in that the more hashing power you have, the more invested you are in the network and the more control over the consensus you have.

You see that is centralization, right?  The gov't has more control of the monetary network today, they control the "consensus" of inflation.

[DumbFruit]

@Monsterer
Ok, you're glazing over the chasm of difference between Proof of Work and "Proof" of Stake, but whatever. What does this have to do with "optimal confirmation time"?

[monsterer]

@Monsterer
Ok, you're glazing over the chasm of difference between Proof of Work and "Proof" of Stake, but whatever. What does this have to do with "optimal confirmation time"?

There is a fair amount of glazing going on here, yes, but for the purposes of the question I think the equivalence assumption is ok.

I'm trying to establish how the idealised, trustless crypto-currency would perform. Is the limiting factor in optimal confirmation time simply the time it takes a transaction to reach 50% network consensus?

[DumbFruit]

@Monsterer
Ok, you're glazing over the chasm of difference between Proof of Work and "Proof" of Stake, but whatever. What does this have to do with "optimal confirmation time"?

There is a fair amount of glazing going on here, yes, but for the purposes of the question I think the equivalence assumption is ok.

I'm trying to establish how the idealised, trustless crypto-currency would perform. Is the limiting factor in optimal confirmation time simply the time it takes a transaction to reach 50% network consensus?

No, a block is first confirmed even if it's only one miner that's confirmed it. A block in Bitcoin is confirmed the moment the correct hash is found for it. However, that's no guarantee that it won't be an orphan block. Even when 100% of the network has accepted the block there is no guarantee it won't be orphaned.

So if I'm understanding you correctly, the amount of time it takes to reach 50% of the nodes is not the only limiting factor to optimal confirmation time. Also, the Bitcoin blockchain can't be reversed by a single party unless they control >50% of the hashrate, that's very different from saying it's irreversible once 50% of the network has reached consensus.

[TierNolan]

A ‘confirmation’ is when a transaction exists in a block.  Each subsequent block further confirms that transaction.  6 confirmations means that the transaction exists in a mined block and 5 other blocks were found thereafter.  Remember, each block references the previous which makes this chain stronger.  It’s mathematically sound to allow for

A ‘confirmed transaction’ is one in which the ENTIRE network has signed off on by including it in a block.  0 confirmations just means the transaction has been broadcast and miners should include it while trying to find the next block.

You can reverse a block with 25BTC worth of hashing power.  That means each block costs around $6000 to reverse.  You can't actually buy enough hashing power to do the reversal, but a rule of thumb would be that you need (value of item / $6000) in confirmations but at least 6 blocks to be very secure.  For a "fighter jet" at $20 million, you would need 3-4 thousand blocks so that the value of the hashes securing the transaction was worth more than the transaction.

[person]

You can reverse a block with 25BTC worth of hashing power.  That means each block costs around $6000 to reverse.

Not sure where you got this from... but to effectively reverse a block, you need to create a longer chain, faster than the one with the block you want to reverse.
Last time I've checked the global hashrate, 51% of the network costs much more than $6000...

[cheako]

You can reverse a block with 25BTC worth of hashing power.  That means each block costs around $6000 to reverse.

Not sure where you got this from... but to effectively reverse a block, you need to create a longer chain, faster than the one with the block you want to reverse.
Last time I've checked the global hashrate, 51% of the network costs much more than $6000...

51% isn't even correct, that'd be what on average you'd need to beat a zero confirmed transaction.  Even that is assuming you posted the tx around the time the last block was created.

[Peter R]

You can reverse a block with 25BTC worth of hashing power.  That means each block costs around $6000 to reverse.  You can't actually buy enough hashing power to do the reversal, but a rule of thumb would be that you need (value of item / $6000) in confirmations but at least 6 blocks to be very secure.  For a "fighter jet" at $20 million, you would need 3-4 thousand blocks so that the value of the hashes securing the transaction was worth more than the transaction.

Is this really a valid way to look at the problem?

Meni Rosenfeld works out how many confirmations you should wait depending on how large the transaction is in addition to the attacker's hash rate here, but I guess this table doesn't address the problem of an attacker temporarily renting hashing power to carry out the attack?

[monsterer]

Ok, so I guess the general consensus here is that the optimal confirmation time in an idealised cryptocurrency is the time it takes for a transaction to become reversible at a loss to the attacker?

[virtualx]

Ok, so I guess the general consensus here is that the optimal confirmation time in an idealised cryptocurrency is the time it takes for a transaction to become reversible at a loss to the attacker?

Correct, finding this 'sweet spot', fast and non-reversible is the optimal confirmation time. I don't know how much better 6 confirmations as opposed to 5 but 3 confirmations is a lot better than 1.

If the system uses a blockchain there should be enough time for consensus. This is required to prevent different versions of the same chain in the network.

[TierNolan]

Not sure where you got this from... but to effectively reverse a block, you need to create a longer chain, faster than the one with the block you want to reverse.
Last time I've checked the global hashrate, 51% of the network costs much more than $6000...

That is the price to rent, rather than buy the hash rate.  The network pays out 25BTC per block, so that is market price ($6000).

If you paid more than that, you could rent it.  At least in theory.  In practice, miners aren't renting out their hashing power on a sufficiently liquid market.  Mining pools "buy" hashing power, but 51% isn't available to rent.  It would take so long to get people to re-target to your "pool" and many would leave once they saw what you are doing.

The point I was making is that it is an estimate of the lower bound on security.  You shouldn't assume that a transaction worth $50 million is safe after 6 confirms. 

3 months of blocks are worth $80.  It would be an interesting experiment.  A "pool" could announce that they are giving a special 10% reward for the next 3 months.  You get paid (share difficulty) / (block difficulty) * 27.5 BTC.  This gives 10% more than the expected value. 

The pool can then forward those shares to another pool.  This will cost around $8 million to fund the extra payout.  It would be interesting what percentage of the hashing power that pool would end up with.  Other pools could forward shares to them though, so they would have to add some kind of signature into their headers.