Exactly 600 seconds between blocks

[Come-from-Beyond]

Sometimes there is a 1 minute gap between blocks, sometimes a 1 hour one. But if we take 100 blocks and calculate average gap then it's supposed to be close to 10 minutes. 1000 blocks would give us a value that is even closer to 10 minutes.

What about such a trick: we adjust the difficulty to be 1000 times less and include transactions only into each 1000th block, all other 999 blocks should be "empty". I expect this would stabilize the average gap between "real" blocks. This looks like a trade-off between network bandwidth consumption and block time precision. Am I right?

[rumbitla]

What?

 

[itod]

What about such a trick: we adjust the difficulty to be 1000 times less and include transactions only into each 1000th block, all other 999 blocks should be "empty". I expect this would stabilize the average gap between "real" blocks. This looks like a trade-off between network bandwidth consumption and block time precision. Am I right?

Not sure if you were joking, but if you were not: Have you considered what would happen to payment confirmations if the transactions are placed in every 1000th block?

[Come-from-Beyond]

What about such a trick: we adjust the difficulty to be 1000 times less and include transactions only into each 1000th block, all other 999 blocks should be "empty". I expect this would stabilize the average gap between "real" blocks. This looks like a trade-off between network bandwidth consumption and block time precision. Am I right?

Not sure if you were joking, but if you were not: Have you considered what would happen to payment confirmations if the transactions are placed in every 1000th block?

In my scenario each block is mined every 600 millisecond, so each 1000th block is found every 10 minute.

[itod]

In my scenario each block is mined every 600 millisecond, so each 1000th block is found every 10 minute.

Ah, it was not clear from the opening post. What do you think is gained by extreme block time precision? You need several blocks to confirm transaction, so this averages the variance enough for practical purposes. Four blocks will have smaller relative error around 40 mins than one block around 10 mins.

[Come-from-Beyond]

In my scenario each block is mined every 600 millisecond, so each 1000th block is found every 10 minute.

Ah, it was not clear from the opening post. What do you think is gained by extreme block time precision? You need several blocks to confirm transaction, so this averages the variance enough for practical purposes. Four blocks will have smaller relative error around 40 mins than one block around 10 mins.

Well, maybe 1000 blocks is too extreme number, 60 seems to be enough. Now I don't use Bitcoin but in the past I recall at least 2 times when I made urgent transactions and had to wait around an hour for the block.

[TierNolan]

Well, maybe 1000 blocks is too extreme number, 60 seems to be enough. Now I don't use Bitcoin but in the past I recall at least 2 times when I made urgent transactions and had to wait around an hour for the block.

Sounds reasonable.  The minting rewards could be paid per mini-block too.  You would get 25/60 per mini-block.

I made similar suggestions to have an alt-chain, so that it was backwards compatible.

One issue is that miners can get a lot of the mint reward without actually producing the blocks.

[tgerring]

Block time of 600ms would result in so many orphan chains as to be unusable for at least a dozen confirms.

As it stands with the ASIC race, average block time has decreased to 7 or 8 minutes.

[itod]

Block time of 600ms would result in so many orphan chains as to be unusable for at least a dozen confirms.

Just out of curiosity: Which is minimal block time that would not have significant number of orphan chains, considering today's average client connectivity speed? Let's say that average connection on the world level is 3-4Mbps, doesn't have to be exactly accurate, but is a good guessing point. Also, what would be minimal block time for 20-100 Mbps connections?

[TierNolan]

Just out of curiosity: Which is minimal block time that would not have significant number of orphan chains, considering today's average client connectivity speed? Let's say that average connection on the world level is 3-4Mbps, doesn't have to be exactly accurate, but is a good guessing point. Also, what would be minimal block time for 20-100 Mbps connections?

You could probably handle 10 second blocks (so 5 - 15 seconds).  They key here is that only every 60th block would be "real", so the check would just be to check the hash for most of them.

Having said that, I think ASICs may have a minimum time to do 1 search.  They do lots of hashes in parallel.

[BombaUcigasa]

What about such a trick: we adjust the difficulty to be 1000 times less and include transactions only into each 1000th block, all other 999 blocks should be "empty". I expect this would stabilize the average gap between "real" blocks. This looks like a trade-off between network bandwidth consumption and block time precision. Am I right?

Not sure if you were joking, but if you were not: Have you considered what would happen to payment confirmations if the transactions are placed in every 1000th block?

In my scenario each block is mined every 600 millisecond, so each 1000th block is found every 10 minute.

The point of confirmation of payment is not number of blocks. It's time.

An hour is sufficiently large to prevent any blockchain forks that may allow for double-spending or reversals. The number of blocks in that hour is irrelevant.

You are basically saying we should dump 6000 blocks for no reason and have checkpoints every 6000 blocks while wasting probably more than 98% of the work done because the peer latency is higher than the block finding rate. Are you familiar with the term "network convergence"?

[TierNolan]

The point of confirmation of payment is not number of blocks. It's time.

That isn't true.  The issue is random reversals and malicious reversals.

In both cases, they depend purely on the number of blocks (unless the blocks are so fast that network latency is a problem).  Less than 1 second could be an issue, but 10-20 seconds would probably be ok (for hash only "blocks").

Another one would be paying for hashing power to reverse a specific transaction.  If you paid for 75% of the networking power, you could reverse a (very) large transaction.

You could achieve that by making a large payment to fee that double spends the transaction.

A: input to double spend
B: fee for miners who double spend
Output: 0

A mining pool which includes that block would inherently have to mine against the fork.

However, mining pools don't support this attack (for obvious reasons).

[Come-from-Beyond]

The point of confirmation of payment is not number of blocks. It's time.

An hour is sufficiently large to prevent any blockchain forks that may allow for double-spending or reversals. The number of blocks in that hour is irrelevant.

Agree, confidence that a transaction won't be "cancelled" ~~ time. Instead of 3 confirmations u will wait for 3000 ones which come in 30 min +/- 1 min, not 30 min +/- 60 min.

You are basically saying we should dump 6000 blocks for no reason and have checkpoints every 6000 blocks while wasting probably more than 98% of the work done because the peer latency is higher than the block finding rate. Are you familiar with the term "network convergence"?

Block finding rate could be adjusted to a reasonable value. Yes, I know about "convergence".

[BombaUcigasa]

Well, then my job here is done. Have you looked into altcoins that tried ridiculous fast block times? Or p2pool? Having 1000 empty blocks won't be much different than having 1000 real blocks, the network still has to sync and prepare for the 1000th block when it comes. There is also that feathercoin or something else that gets attacked by an ASIC farm here and there and messes up the trust and functionality for hours at a time because a miner can attack the network with little exposure and great preparations.

I'm not saying faster blocks aren't more helpful, especially if you suggest the confirmation requires 1000 blocks.

And what's your rationale for the 99.9% resource waste for that single important block? Sure, the same reward per time is available, but you just make the network 1000 times less secure and functional, and a bit more wasteful.

If you think you have something, you can always start a new altcoin, maybe testnet only, to see how your solution might work.

[cunicula]

I've suggested this before too. It is a good idea. An interesting property here is that the order in which intervening blocks are received doesn't matter. I was told that this is called an acyclic graph if i remember correctly.This likely makes latency issues unimportant (I.e. the empty spacer blocks can come very close together without causing problems). It might be better to slow things down gradually though so that everyone has time to catch up as you approach 1000 blocks (I.e the last 50 blocks come farther apart than the first 950 blocks).

A big advantage here is that you would no longer need 6 full blocks of txns to be secure against double spends. One block with a bunch of spacers built on top of it would suffice. Ask meni about this, he has studied the problem in detail.

[thezerg]

Of course, everybody would be mining alt-coins until the payoff block.  So you'd have to put a mining reward on those empty blocks.  And why make them empty?  If a txn is there, might as well include it... that way people can choose their risk vs. wait time. 

Yes, maybe it does make sense to reduce the bitcoin difficulty adjustment (and reward of course).  After all, that's all litecoin has going for it.

[grue]

This looks like a trade-off between network bandwidth consumption and block time precision. Am I right?

There's also orphan blocks. Decreased block time = tons of orphans. Just take a look at all the "fast" alt-coins that failed.

[cunicula]

This looks like a trade-off between network bandwidth consumption and block time precision. Am I right?

There's also orphan blocks. Decreased block time = tons of orphans. Just take a look at all the "fast" alt-coins that failed.

Since the, as I call them, spacer blocks have no ordering there is no orphan problem for these blocks. Orphans only occur for blocks that can contain txns. The spacer blocks can come a femtosecond apart, still no orphans are possible.  My chain might read CKON and yours might read KCNO. Both chains imply distribution of block reward to CKON, so there is no relevant difference between them. The orphan issue arises as you near the txn containing block. For this reason, it is probably best to slow the spacer blocks down.

Potentially helpful anslogy: a train always needs to slow down when it approaches a station to pick up passengers (these people are the txns). You can never confirm who has come on board until the frain leaves the station, people could jump on board and hop off before the train leaves (double spend txns). If the train reports the same passenger list after leaving the station, however, you can be sure that everyone is on board for good. There is no reason to slowdown for this report becase no one iscoming on board or leaving. The train just says "yup the psssenger manifest is the same one I reported at the station." This report provides full security against double-spending. Currently, the bitcoin train reports in only when it arrives at a station. This means you hav to wait for 6 full stations to secure a txn. Instead, the train could just check in 2000btimes between stations. Then you would only need to wait a few seconds to go from 1 confirmtion to 6 confirmations. You could also significantly decrease the spacing between stations because they would be approximately a constant time interval apart. This would allow you to go from waiting 5 minutes mean with huge variance for the first confirmation to waiting no more than than say 3 minutes for the first confirmation and at most 3 minutes 10 seconds for 6 confirmations.

Unfortunately, you still have to stop at the stations to synchronize passenger logs. Thus there is probably no way of squeezing any more benefit out of the system. Well there is one way, but it would require moving different colors of coins at each station (this stqtion is whites only, the next station is blacks only, every hundreth station is mixed race and coins can be whirewashed or blackfaced at mixed race stations). In this case the whites only stations act like spacer blocks for black passengers and the blacks only statiobs act as spacer blocks for the white stations. You need to aloow for periofic race switching to prevent discrimination and prevent the formation of ethnically segregated wallets.

 You can get additionl speedup factors this way this say, but it requires users to hold many different colors of coins simultaneously if they want to be able spend at any time. Essentially you get instantaneous confirmations, but you need $100 in your wallet to buy a $1 soda. If you want to spend the full $100 you need to break it up into 100 $1 txns spread over twenty minutes. It is not really a promising approch.

[BombaUcigasa]

Since the, as I call them, spacer blocks have no ordering there is no orphan problem for these blocks. Orphans only occur for blocks that can contain txns. The spacer blocks can come a femtosecond apart, still no orphans are possible.  

...

Unfortunately, you still have to stop at the stations to synchronize passenger logs. Thus there is probably no way of squeezing any more benefit out of the system.

So the problem of orphan blocks jumps to the transaction blocks. Some miners will try to drop the txn block after 1002 interval blocks with 3 orphans, some will try it at 1005 with 6 orphans, but because of network divergence, until the NEXT txn block is generated, miners will work on forked chains (some miners will see the 1002 blocks, some will see the 1005 blocks, each will add ontop of the last known block). Thus all their work from the last ~10 minutes will be useless. Should someone model this mathematically, this solution would create more forks and orphans than anything that ever existed in cryptocoins, reducing security and increasing upkeep costs. At the benefit of 3 magnitudes more precise block intervals.

[BombaUcigasa]

If you really want 600 seconds between blocks, a better idea is to generate some "difficulty transactions" that reuse the peer "diffculty transactions" and these can be based off time elapsed since the last block, or average blocks during the last n seconds. Once the network mathematically agrees that it should be really close to the 10 minutes mark, the base diffculty and the variable difficulty should offer a proof result of a smaller difficulty than needed, such that smaller difficulty shares can be accepted. The difficulty transactions could me merged mined or reused from lower difficulty block attempts, such that no work is wasted and the miner tries to get either a target difficulty block or provides statistical proof that it has been working sufficiently. (see p2pool)

The base difficulty would provide a safety net for attacks and the variable difficulty calculation could produce the desired precision.

And even in this case, there is the possibility of forks and orphans near the 10 minutes mark, when some miners will find various difficulty blocks or if the peers do not agree on the speed of time for some blocks and they are not universally accepted.

We propose a solution to the double-spending problem using a peer-to-peer network.The network timestamps transactions by hashing them into an ongoing chain ofhash-based proof-of-work, forming a record that cannot be changed without redoingthe proof-of-work. The longest chain not only serves as proof of the sequence ofevents witnessed, but proof that it came from the largest pool of CPU power. Aslong as a majority of CPU power is controlled by nodes that are not cooperating toattack the network, they'll generate the longest chain and outpace attackers.

[Come-from-Beyond]

If you really want 600 seconds between blocks, a better idea is to generate some "difficulty transactions" that reuse the peer "diffculty transactions" and these can be based off time elapsed since the last block, or average blocks during the last n seconds.

I like ur idea, it seems to be better.

[BombaUcigasa]

If you really want 600 seconds between blocks, a better idea is to generate some "difficulty transactions" that reuse the peer "diffculty transactions" and these can be based off time elapsed since the last block, or average blocks during the last n seconds.

I like ur idea, it seems to be better.

Again, there is still some security reduction (attack resilience, honest work) for the sake of human accessibility (predictable responsiveness). Someone should make an altcoin and test this.

Consider an attacker with an imaginary number of peers on his private network (a GPU farm for example), ignoring p2p nodes for a while and deciding by himself that his total hash power is sufficient for the whole network for a 10 minute block frequency. His private network nodes will "see" that everyone "else" is working hard and long to find the block, but the 10 minutes time period has elapsed. The private peers will then accept lower difficulty blocks as valid, and when one is found it will be sent to the public network.

This private miner can create blocks with lower difficulty than expected, how can the whole network accept them? Looking at the block, it is valid based on the previous blockchain, but the difficulty appears to be below the broadcast time rate. Obviously the network will discard this block. What if the network has two such miners?

What if a public node that works honestly finds a block but by the time it is broadcasted the network advances difficulty and someone else finds a block with a higher difficulty? Obviously the network will accept the higher blocks, but doesn't this cause orphans and lost efficiency? The idea of agreeing on honest work with unknown results but also ensuring a timely performance is pretty cool, but implementing a method that is both more efficient and more secure than what we have now could be impossible.

[BombaUcigasa]

You might also want to read this:
https://bitcointalk.org/index.php?topic=102355.0
https://bitcointalk.org/index.php?topic=260180.0

[TierNolan]

Since the, as I call them, spacer blocks have no ordering there is no orphan problem for these blocks.

You need some mechanism to merge chains, in order for the whole thing to work properly.  If you have 4 fast blocks between 2 full blocks, then you need some way to maintain ordering (between the slow blocks).

A -> a, b, c, d -> B

Looking at B, you can't tell if there were 4 fast blocks.

There would need to be a fast chain, with (at least) 2 inputs.

If b and c happened together, then the result is that d must merge the 2 chains.  It has 2 parents, rather than just 1.

A -> a -> (b, c) => d -> B

It should be allowed to merge "around" a full block.  The objective is just to allow PoW to be merged into a tree more efficiently.

Code:

+-------------------+
|                   |
V                   |
A -> a -> b -> d -> B 
     |
     +--> c

B is has a "slow" link back to A. 

The work that went into c is potentially wasted, but it could be merged back in.

Code:

+-------------------+
|                   |
V                   |
A -> a -> b -> d -> B -> e -> f
     |                   ^
     |                   |
     +--> c -------------+

Someone looking at f can trace back the entire tree starting at f.  Since c and e would be backwards links (and included in the header), c (and e) must have been created before f.

This allows all orphans to be merged back in, and so prevents wasting of PoW.