Post
Topic
Board Development & Technical Discussion
Re: Dynamic block frequency
by
nybble41
on 11/05/2012, 18:45:18 UTC
As someone that knows a little bit about CPUs and digital logic, I can promise you that the right shift operation is not done by divide-and-round, it is done in dedicated hardware called a shifter that literally shifts bits.  It might be harder for laymen to understand, but programmers (and CPUs) understand shift very literally.
Look, we're not going to get anywhere if you keep misinterpreting what I say. Of course how a CPU physically does a bit shift is completely different from how it does integer division. That's why I said it's faster.
Actually, they're not implemented all that differently. True, shifts are not implemented via division; it's the other way around. Division can be implemented in hardware as a series of right-shift and subtract operations (a naive binary version of long division), and division by two reduces to a simple right-shift, though there may be some wasted cycles. For that reason, any decent optimizing compiler will generate the opcode for a right-shift operation rather than integer division when the code specifies integer division by a fixed power of two. As you said, it's exactly the same mathematical operation. The compiler is just unrolling the loop implied by the division algorithm.

Your proposal is interesting, and I agree the confirmation time is definitely a point of some friction. I like litecoin's 2.5 minute target, but even that could get unrealistically large for things like high frequency trading.
The system isn't going to do any magic. Too frequent blocks will cause excessive forking, so some things will just have to be done with layers on top of Bitcoin.
Would it be possible to re-integrate the forks instead, provided there are no conflicting transactions? It should be rare to have forks which cannot be reconciled. Example:

Chain 1: A(t1, t2) -> B(t3, t4)
Chain 2: A(t1, t2) -> C(t3, t5, t6)
Next: A(t1, t2) -> {B(t3, t4), C(t3, t5, t6)} -> D(t7)


Instead of a single parent, Block D would list the heads of all the chains its compatible with. The height would be the maximum along any path from the genesis block (i.e. height(D) = height(A) + max(difficulty(B, C))). In the event of conflicting transactions, it would be up to the miner of block D to choose a non-conflicting subset of the available chains.