Zapcoin: distributed, no-trust altcoin that verifies in seconds

[Shatosi Makanoto]

It shouldn't be too hard to create the network.  I mean all that you are really doing is defining who you can connect to in a table.  Just create a look up table to the ip address of related nodes on the network.  The problem is always NAT translation.

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! 

[Fuserleer]

A nice incentive should sort that last problem out

[HuuHachu]

Seems you are trying to obtain a consensus between up to a million nodes ...

But with thousands of nodes and above, you will have to deal with instability (especially, at each round you will have nodes failing / not responding. Of course at each round you will also have nodes entering and leaving the network, but they should be easier to deal with)

Also, I have the feeling that latencies will be kind of "worse case" ... If a node somewhere is waiting for a neighbor, then this will be blocking the global consensus ...
And with increasing number of nodes and links, you will almost always have someone waiting for someone else.
(this is a feeling ... but probably worth investigating, especially as it could be done intentionally to stall / attack the network)

[HuuHachu]

Also, from my understanding, a node is allowed only one outgoing transaction per round ... (to prevent double-spending)

Should be ok for most individual users, but potentially prohibitive for businesses

[Shatosi Makanoto]

Seems you are trying to obtain a consensus between up to a million nodes ...

But with thousands of nodes and above, you will have to deal with instability (especially, at each round you will have nodes failing / not responding. Of course at each round you will also have nodes entering and leaving the network, but they should be easier to deal with)

Also, I have the feeling that latencies will be kind of "worse case" ... If a node somewhere is waiting for a neighbor, then this will be blocking the global consensus ...
And with increasing number of nodes and links, you will almost always have someone waiting for someone else.
(this is a feeling ... but probably worth investigating, especially as it could be done intentionally to stall / attack the network)

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.

[Shatosi Makanoto]

Also, from my understanding, a node is allowed only one outgoing transaction per round ... (to prevent double-spending)

Should be ok for most individual users, but potentially prohibitive for businesses

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

[HuuHachu]

Seems you are trying to obtain a consensus between up to a million nodes ...

But with thousands of nodes and above, you will have to deal with instability (especially, at each round you will have nodes failing / not responding. Of course at each round you will also have nodes entering and leaving the network, but they should be easier to deal with)

Also, I have the feeling that latencies will be kind of "worse case" ... If a node somewhere is waiting for a neighbor, then this will be blocking the global consensus ...
And with increasing number of nodes and links, you will almost always have someone waiting for someone else.
(this is a feeling ... but probably worth investigating, especially as it could be done intentionally to stall / attack the network)

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

Sorry, it was not very clear that my point was mainly on the consensus phase (with the counter to 6) ... Random latencies on those messages could add up to a lot (again, it's a feeling)

[Shatosi Makanoto]

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.

[Shatosi Makanoto]

Sorry, it was not very clear that my point was mainly on the consensus phase (with the counter to 6) ... Random latencies on those messages could add up to a lot (again, it's a feeling)

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.

[Etlase2]

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.

Didn't you say something like 124 nodes connected? That is 500 tx/s / 62 (124 / 2 if we assume half the network receives txes first on avg).

[Shatosi Makanoto]

Didn't you say something like 124 nodes connected? That is 500 tx/s / 62 (124 / 2 if we assume half the network receives txes first on avg).

Oops. you're right!

[HuuHachu]

bump ^^

(even if this work is far from complete, the author actually tried to explore new ideas and share them in a nice way)

two questions / remarks :

- for the consensus phase, even if a node has many links, if its physical link has a problem (or if this node is a malicious one), there will still be a lot of delay (all of its neighbors will be waiting for it)

- how to distribute addresses ? ... I have the feeling that we may have to resort to some centralization here (or a energy-consuming proof-of-work mechanism maybe)

[Shatosi Makanoto]

HuuHachu,

Sorry for not checking for feedback for so long.

- for the consensus phase, even if a node has many links, if its physical link has a problem (or if this node is a malicious one), there will still be a lot of delay (all of its neighbors will be waiting for it)

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.

- how to distribute addresses ? ... I have the feeling that we may have to resort to some centralization here (or a energy-consuming proof-of-work mechanism maybe)

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

[CryptoBullion]

<<<----- ALPHA TESTER

[KonstantinosM]

I like the idea, I have somewhat of an intermittent connection at times but since I'm a miner I deal with it.

I'm interested in a crypto without POW.

[Shatosi Makanoto]

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