Thanks to everyone for your replies... I can see that I was wrong.

Quite an education.

I think that if you look at my proposal closely, you will see that it is quite different from yours. In my proposal, miners do not broadcast anything until they have accumulated all ten successful hashes within a specified range window. These ten hashes will be found in an average of ten minutes, with a much tighter variance (standard deviation). Then, a new block is assembled that contains all ten hashes, and that is broadcast over the network.

A miner (or pool) with a larger hashing rate will only have an advantage proportional to its hash rate H, just as things are now, but finding ten successful hashes will have a much smaller deviation from ten minutes.

That's one reason I'm suggesting this. The reason that the block size is an urgent issue is because of the extreme variability in block creation time.

In addition, it would be wonderful for a host of other reasons to have the block creation time more constant.

It seems to me that my proposal would reduce the standard deviation in the Poisson distribution of the solution sets, so that solutions would be found in a much tighter range around the ten minute period.

To take an extreme example, consider if a solution set must contain a million successful hashes within a specified window. Then, successful hashes would be streaming out of the generator at a high rate, and the algorithm would be watching a sliding window of hashes to see if a million of them were contained within a specified-size range. This means that there are a million times as many opportunities for the hashes to achieve the range requirement, and the likelihood of any individual hash being the successful millionth hash would be smaller. The time would still average out to ten minutes, but the individual times would be very close to the average (i.e., the standard deviation would be much smaller).

Compare this to gas molecules in a box. Suppose we have only one molecule in the box, and success is defined as finding that single molecule in a tiny corner of the box. The corner size could be adjusted so that, on average, it took ten minutes before that molecule encountered the corner. The time that it took on any given attempt would vary over a range as described by a Poisson distribution (http://en.wikipedia.org/wiki/Poisson_distribution). If, however, X molecules are in the box and we require that the same-size corner be encountered X times, the standard deviation in the time that it takes for those X events to occur would be much smaller than the standard deviation for the single molecule.

Here is a calculation to demonstrate what the difficulty would have to be if the ten solutions had to be sequential:

Currently, the hash rate (https://blockchain.info/charts/hash-rate) is 350 terahash/sec, or 350 * 10¹². A solution should be found in 10 minutes, or 600 seconds, average. So currently, it takes 210 exahash, or 210 * 10¹⁵ hashes to find a solution. In order to find ten solutions in a row, each solution would have to be found in the tenth root of 210 * 10¹⁵ which is a mere 54. This is obviously far too small to be practical, since the mining program would have to keep track of all these solutions as it is generating billions or trillions of hashes per second.

This can be corrected by allowing the solutions to be contained in a range, instead of requiring them to be strictly sequential. For example, the ten solutions could be required to be such that the difference between the lowest and highest nonce values is no more than, say, 100 or 1000. The larger the range is, the more difficult it can be made to find each successful hash. I would say that the range should be adjusted so that a successful hash requires something like a billion attempts to find.

I'm working on determining how to set the range to achieve this...

One of the characteristics of bitcoin's mining algorithm that exacerbates the block size problem is the fact that the time that it takes to "discover" a new block exhibits a Poisson distribution, which means that although the average time will be ten minutes, sometimes it will be 30 seconds and other times it will be an hour. It is the long times that are problematic, since they "load up" the block.

What if the mining algorithm were modified, so that instead of rewarding a block to the first miner that discovers a hash at difficulty D, the reward is awarded to the first miner to discover ten hashes at difficulty D/10? This would tighten up the window by a factor of ten, and alleviate some of the pressure on the block size.

The two disadvantages I see are:

    The ten hashes would have to be recorded in the new block. This would increase the block size, but since hashes are only 32 bytes (or 64 bytes, I don't remember which) each, this would be a trivial overhead.
    The ten hashes would have to be calculated by anyone wishing to verify the block's validity. Once again, I don't think this would be significant.

This would have other important benefits. The greatest benefit would be that the time required to wait for validation of the transaction by the sender and receiver would be much, much closer to ten minutes, almost all the time.

I chose the number ten arbitrarily, for purposes of discussion. Perhaps the optimum value would be 5, 20, or 200: let's discuss.

You may respond that this technique does not guarantee that there won't be hour-long waits, and that's true. But when this method sees an hour-long wait, the wait under the current algorithm would be ten hours!

Your thoughts?

[EDIT] I think that there is a problem with this algorithm as stated above. Pools and individuals with greater hashing power would have a tremendous advantage. The likelihood of finding the ten solutions would not be proportional to the miner/pool's hashing power H, but to H¹⁰. Let me see if any way can be found to remove that advantage (help me out if you can).

[EDIT #2] Is this a solution? A further restriction can be placed on the ten hashes that comprise the winning set: all ten must be generated sequentially (or within a specific range); that is, their nonces must be ten sequential integers (or ten integers that are all within a specific range), with no changes in the rest of the block (of course, the difficulty D would have to be adjusted accordingly). This would eliminate the exponential advantage that larger pools have and make the larger pool have an advantage that is proportional to its hashing power H, just as it currently is.

Here are more details about the protocol:

• In order to prevent the network from splitting into two networks that both think they are the valid network (thus allowing double spending), the network must be aware of its size (number of nodes) after every round. If the size ever drops by one-half or more in a single round, every genuine node will know to drop off the network and renegotiate onto the correct network. Since there can be at most one fragment that retains over half the nodes after experiencing a rip in the network fabric, this prevents multiple simultaneous subnets from developing. If none of the subnets retain more than half of the nodes, all nodes will drop out and the network will require restarting (I haven't worked out the details as to how that would be done). This would be catastrophic, but at least no corruption would occur to the Ledger. Ripping large portions off of the network fabric would be extremely difficult to do, but could occur if a large-scale internet breakdown occurs (neutron bomb event, severing of all intercontinental internet transatlantic cables, etc.)
• In order for the nodes to accept a transaction, both the sender and the receiver must digitally sign the order. Of course, the sender must sign it to authorize the funds withdrawal from his account. But having the receiver also authorize the transaction totally prevents misdirected funds transfers.

-- Shatosi

HuuHachu,

Sorry for not checking for feedback for so long.


If a link has a problem, there is no way to know when (if ever) a response will arrive; therefore, a deadline time must be defined system-wide, and if a response is not received by this time, the link is deemed to be down. Other links will be expected to maintain the node's connectivity. The question is, what is a reasonable time to wait? I think that only a trial system can determine this, and this is the main contributor to total Round time delay.


I actually think that all business can be handled in a distributed manner, including node address assignment. The only issue I see is: how does a new account find an entrance point into the network? I think that bitcoin and any file-sharing network has the same issue. There must be some well-known place to go to find an access point, and this becomes a point of vulnerability to governmental or DDoS shutdown. Any ideas? How does bitcoin do it, or is this also a bitcoin vulnerability?

Over the summer I have been putting together a client for this idea. I hope to unveil it soon and request volunteers to alpha test it.

-- Shatosi

Oops. you're right!

Remember that the consensus phase, like the transmission phase, has literally hundreds of thousands of links trying to pass data only a half-dozen hops. Even though the nodes are scattered all over the world, they are only a distance of four (six) max hops apart. As I was hatching this topology, it took me a while to appreciate just how many alternate paths exist and how close the nodes are in the network.

I should have discussed bandwidth in the paper:

I think that a round should take perhaps 6 seconds to complete, mainly because the network should allow, say, five seconds for distribution, and a single timeout period on the end of, say, a second. In that five seconds, every transaction must traverse every link in one direction or the other, and links that choke will be closed down. A transaction consists of about 50 bytes. How many 50-byte packets can be passed in five seconds? That number, divided by six (to include timeout), sets the transaction rate. An internet connection is usually biased toward downstream, so upstream will be the bottleneck. If we set a minimum acceptable upstream bandwidth at 600 kb/s, the network could handle around 500 transactions per second. Considering that Bitcoin is currently doing less than one transaction per second, that's not bad.

A node with a slow internet link will just continuously fall out of the network. This scheme  requires a certain bandwidth, because all participating nodes must continuously stay in sync with one another.

Yes, but businesses (merchants) are typically receiving payments, not making them, and there's no restriction on that.

For nodes making lots of payments, there's always the next round...

Right, some poor schmuck node is going to be the last to get it. But remember that the node is linked to hundreds of neighbors. If the delay is elsewhere, the transaction will find a way through. But if the delay is right there at the node (slow/intermittent internet connection), it may never get through. For this, a timeout needs to occur (the equivalent of nodes setting their consensus counts to six as they each time out) which will say, "enough is enough!" and snip off the errant node(s).

It remains to be seen, but it may be that hundreds of nodes will get snipped in any given round for one reason or another. But the network is such that it doesn't rely on any given node(s) , and they can simply rejoin, subject to any measures taken regarding "suspicious" nodes.

True. And then there needs to be code that goes through the rounds, and something to generate traffic (pretty straightforward so far). Finally, I need to convince a few hundred thousand people to install the client and watch it heavily load down their internet connection! 

Copied from an edit I made above, so no one misses it:

I'm looking for a coding expert who can generate a proof-of-concept client.

True. sorry.

"And I would think you'd have to come up with a currency distribution scheme somehow?" -- Etlase2

I have, but I don't think that this issue is central to the robustness of the protocol, so I didn't discuss it here. I have an idea that should incentivize people to populate the nodes in a matter of days, I think.

I think that any altcoin that wants quick adoption should give coins to present Bitcoin holders, coin-for-coin. Otherwise, those heavily invested in Bitcoin (myself included) will have reason to resist adoption, even if a pretty significant improvement exists.

I would like to see immediate deployment of Zapcoin for two reasons: We won't know how fast it can execute rounds until a fully-populated network is in place, and we won't know if unforeseen issues (network latency, data corruption, failing links) could be show-stoppers till then either. My biggest concern is whether nodes connected by low-bit-rate internet connections can drag down the whole net.

If people could be incentivized to join and maintain a network that doesn't involve money (i.e., a sandbox) for proof-of-concept, that would be great. If a serious problem arises, no-one will panic because he loses his life savings. But a fully-populated network can't be realized without many people distributed globally participating, and this scheme puts a heavy load on the internet connection.

"The only problem i have with that system is that since there's no incentive for anyone to keep a full history there's a potential for sections of that history to disappear entirely." -- The_Catman

True, but I don't see any problem with that. In fact, if a node doesn't care to stay up-to-date on the Ledger's contents, it could not maintain a ledger at all, and happily execute rounds for everyone else. But why? the ledger is not difficult to set up or maintain. If you wanted to force every node to maintain the ledger, simply require an additional consensus round on the ledger's hash (I mentioned this in the paper, but dismissed it as unnecessary).

"correct me if I"m wrong OP, its a small block chain that only keeps track of the most recent transactions.  historical chain resides locally on each node in the network and can be reconstructed on the fly.  This makes the blockchain lightweight and fast. It's the network that is really the most interesting part.  It is placing the peer to peer UDP style fire and forget system to one where each node or more reliably interconnected with others." -- anderl

Yes, the network topology is the significant departure. It allows every node to maintain an identical copy of the Ledger, in real time. This is why it can prevent double-spending. Double-spending would be like trying to use the same dollar to buy a pack of gum twice at the local convenience store. You can't, because the entire transaction occurs in real time.