Topic: [Theory] The optimal confirmation time (Read 2352 times)

Network latency, bandwidth, block size, processor/memory/hard drive speed, geopolitical concerns, code efficiency, and fork convergence speed. Is there anything else?

If you can improve the factors above then you can avoid the forks and therefore avoid the loss of work incurred when reducing confirmation rate. My understanding is that the mempool has been highly optimized with a bloom filter, so I'm not sure what gains can be made there, but I'm also not a Bitcoin developer. I'm also skeptical.

Huh?

https://talk.vanillacoin.net/topic/142/version-0-2-8-beta-release/5

The developer of Vanillacoin claims that he has improved the
network communications to a degree that a single confirmation is sufficient, with
variable block interval of 80-200 seconds. I haven't looked at the source very
closely, but I think he has optimized the transaction message format somehow.

https://bitcointalksearch.org/topic/m.11370378

I'm a little skeptical about this, as even with fast transfer of messages,
any lags and connectivity problem on the user's end could lead to forking AFAICS.

But I'd be really interested in knowing whether the number of confirmations in Bitcoin is
merely a function of network propagation rate, or are there any deeper reasons
why the current implementation matters.

I wouldn't be so sure, it depends on how far the knowledge of a successful attack travels.  If the word drops like a stone hidden on page 15 of this mornings paper, then you'll likely not see a whole lot of movement of the market.

Conversely if it's front page news then a hard fork, miners recompile or change options to mine the correct chain in an attempt to orphan the attack.  Also note that the seller would offer incentives to the operators of the biggest pools, who should already be honor bound to ensuring that such an attack does not succeed.  After all that's why we've been paying them the big bucks.

I wouldn't count a price drop as something the miners would just ignore and a near-zero one at that is laughable.  It would effectively end their business and if it means mining one chain where the future worth of 25BTC is 0USD and mining another, the choice is clear.

Probabilistic speaking then, having the $50million split in multiples transactions sent out at different block levels would considerably lower the risk of a full transaction loss.

This entire rented hash rate would also need to be in place before that transaction is broadcasted.
Trying to re-mine, 'alone', at least 6 new blocks to build a chain long enough to take over the consensus, would bring the entire network to a long wait as new blocks are not broadcasted. This raises suspicion, and at the first complaint of a successful attack the price drops to near-zero, making the attack unprofitable in the end.

It's interesting to think that the economics required to attack the network successfully are made even worse if the attack succeeds.

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. 

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.

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?

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?

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.

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

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.

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.

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?

@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"?

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

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.

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?

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)?"

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?

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.