Shatosi Makanoto (OP)
Newbie
Offline
Activity: 28
Merit: 0
|
|
June 27, 2013, 03:11:27 PM |
|
|
|
|
|
anderl
|
|
June 27, 2013, 03:26:36 PM |
|
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".
|
|
|
|
Shatosi Makanoto (OP)
Newbie
Offline
Activity: 28
Merit: 0
|
|
June 27, 2013, 03:39:24 PM |
|
Yes, that's what I'd call it too.
|
|
|
|
jasonslow
|
|
June 27, 2013, 03:42:49 PM |
|
Reserved
|
|
|
|
The_Catman
Full Member
Offline
Activity: 168
Merit: 100
Captain Jack Fenderson
|
|
June 27, 2013, 04:10:41 PM Last edit: June 27, 2013, 04:27:43 PM by The_Catman |
|
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?
|
|
|
|
anderl
|
|
June 27, 2013, 04:15:32 PM |
|
hmm, interesting. Sounds like a PoS system with a fancy new blockchain?
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.
|
|
|
|
Shatosi Makanoto (OP)
Newbie
Offline
Activity: 28
Merit: 0
|
|
June 27, 2013, 04:28:31 PM |
|
"... 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
|
|
|
|
The_Catman
Full Member
Offline
Activity: 168
Merit: 100
Captain Jack Fenderson
|
|
June 27, 2013, 04:35:20 PM |
|
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.
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. "... 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
Yeah, I corrected that.
|
|
|
|
Shatosi Makanoto (OP)
Newbie
Offline
Activity: 28
Merit: 0
|
|
June 27, 2013, 04:36:12 PM Last edit: June 27, 2013, 07:10:10 PM by Shatosi Makanoto |
|
"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.
|
|
|
|
Etlase2
|
|
June 27, 2013, 04:38:15 PM |
|
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?
|
|
|
|
Shatosi Makanoto (OP)
Newbie
Offline
Activity: 28
Merit: 0
|
|
June 27, 2013, 04:44:23 PM |
|
"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).
|
|
|
|
Shatosi Makanoto (OP)
Newbie
Offline
Activity: 28
Merit: 0
|
|
June 27, 2013, 04:48:40 PM Last edit: June 27, 2013, 05:15:43 PM by Shatosi Makanoto |
|
"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_Catman
Full Member
Offline
Activity: 168
Merit: 100
Captain Jack Fenderson
|
|
June 27, 2013, 04:53:53 PM |
|
"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).
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. 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.
|
|
|
|
Shatosi Makanoto (OP)
Newbie
Offline
Activity: 28
Merit: 0
|
|
June 27, 2013, 05:00:15 PM |
|
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.
|
|
|
|
Fuserleer
Legendary
Offline
Activity: 1064
Merit: 1020
|
|
June 27, 2013, 05:08:48 PM |
|
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?
|
|
|
|
Shatosi Makanoto (OP)
Newbie
Offline
Activity: 28
Merit: 0
|
|
June 27, 2013, 05:18:55 PM |
|
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.
|
|
|
|
billotronic
Legendary
Offline
Activity: 1610
Merit: 1000
Crackpot Idealist
|
|
June 27, 2013, 05:22:33 PM |
|
Talk to Fuserleer, he is an amazing coder.
oh wait...
|
|
|
|
Shatosi Makanoto (OP)
Newbie
Offline
Activity: 28
Merit: 0
|
|
June 27, 2013, 05:24:00 PM |
|
Copied from an edit I made above, so no one misses it: 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.
|
|
|
|
mrvegad
|
|
June 27, 2013, 05:24:46 PM |
|
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. Maybe when fuserleer is done with eMunie he can help u out
|
|
|
|
anderl
|
|
June 27, 2013, 05:36:13 PM |
|
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. 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.
|
|
|
|
|