Bitcoin Forum

Please comment (and be kind): https://sites.google.com/site/shatosimakanoto/zapcoin (https://sites.google.com/site/shatosimakanoto/zapcoin)

I have to digest your paper tonight.  So far your design for the network topology is interesting.  Your requirement for "minimum balance" sounds somewhat like "proof of stake".

Yes, that's what I'd call it too.

Reserved

hmm, interesting. Sounds like a PoS system with a fancy new blockchain?

*or rather, a lack of a blockchain in favour of a fancy ledger.

I just woke up so the wall of text is a bit much to decipher atm, but i think that was basically the gist of it, yeah?

correct me if I"m wrong OP, its a small block chain 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.

"... with a fancy new blockchain?" -- TheCatman

I wouldn't classify it as a blockchain at all -- rather, it is a true ledger, which simply records the current balance in all accounts. For example, in Bitcoin, determining the balance in an "account" requires a complete rescan of the entire blockchain. In Zapcoin, one simply reads the balance. -- Shatosi

I think he calls it a "ledger" (i corrected my previous comment). I've heard the idea before, it's like having a book (or ledger) that you write down accounts and amounts and scratch out the old values when new transactions happen.

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. It shouldn't have an effect on the system, and i suppose that makes coins more anonymous, but it can make the "ledger" appear less reliable to some people, therefore preventing the currency from taking off well.


Yeah, I corrected that.

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

You may be interested in my decrits ideas (see sig). I use a large deposit as a requirement for becoming one of the central nodes, and they create the timeline of the network. Not sure why you're limiting the number of accounts so heavily. I skimmed a few parts, I'll read a little more deeply later. And I would think you'd have to come up with a currency distribution scheme somehow?

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

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

Well yeah, I said as much in the rest of that statement, right before I stated specifically why, in spite of that, it may still be an issue.

True. sorry.

Nice idea, similar in a few ways to how we are doing it, different in others.

One note, you are using a balance system, we are "kinda".

Historical records are stored always, we need them for other services we plan to roll out to ours, but we use a top-down balance calculation of the latest transaction to ensure that transaction is fund-able.  If the difference between received and sent funds > than the transaction value, its refused.  This happens across multiple transaction chains (or blockchains as you call it here) simultaneously so you can have many many concurrent transactions happening at any one time yet still ensure that verification of funds is possible.

No double spend possible, if you try it, quite quickly a node somewhere in the system will throw up that you have tried a -balance spend and that transaction (and your account for a period of time) is then rejected around the network.

Are you going to develop this, or is it more an academic idea that you have put out into the wild?

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

Talk to Fuserleer, he is an amazing coder.

oh wait...

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

Maybe when fuserleer is done with eMunie he can help u out :)

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!  :'(

A nice incentive should sort that last problem out ;)

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)

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

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.

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

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)

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.

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.

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!

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)

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

<<<----- ALPHA TESTER

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.

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