The following content was written by satoshi on August 07, 2010, 04:28:17 PM in the thread latency and locality. All content is owned by the author of the bitcointalk.org post. (original)
Once you get away from a system where each node’s influence is proportional to their CPU power, then what else do you use to determine who is (approximately) one person?
The following content was written by knightmb on August 07, 2010, 04:57:42 PM in the thread latency and locality. All content is owned by the author of the bitcointalk.org post. (original)
Maybe we need a big technical chart that documents every single step about how BitCoin works and the next time someone starts a topic about why everything in bitcoin is done wrong, we can point to that chart and say “here’s how it works, document how your new process will work in detail and we will compare”
I think that would help to cut down on a lot of assumptions/disputes I see in topics every-time the issue of “this isn’t being done right” comes up in this forum.
Just saying….
The following content was written by Red on August 07, 2010, 05:15:08 PM in the thread latency and locality. All content is owned by the author of the bitcointalk.org post. (original)
The method I was referring to was in the earliest version of Freenet. It was designed before the trusted connections model was implemented. I’d need to review all the details to remember the specifics. But basically you the nodes you would connect to were picked (I forget the method of picking) Then you pick a random number and broadcast it to all those nodes. Each of those nodes picks a random number and broadcasts it back to you, and to the other nodes in the set. All of the numbers are mathematically combined (don’t remember the function) into your arbitrary ID. If you don’t answer to that consensus ID no one with talk to you.
Don’t sue me if I’ve got that wrong. That is from an obviously faulty memory.
The Sybil attack (named after the movie, I think) was a network segmentation attack. You create multiple personalities and try to surround a given node to deduce what they are storing. Obviously, that turned out to be possible for this method of ID generation. Hence the new friend-to-friend topography. The same limitation may be a weakness for bitcoin as well. But failures often provide the best guidance on new ways to proceed.
Forgetting the Freenet tangent for a moment…
The “Proof-of-work” technique may actually be applicable to address the ID generation problem you deftly pointed out. Instead of making it harder to generate the record of transactions, you could make it harder to generate new nodes and attach them to the network.
Suppose you (making this up as I go) required that nodes create a private key, then calculate a proof of work checksum on that key, and then the node ID became RIPE-160(SHA-256(POWCheckum(public key) + SHA-256(public key))). Or some such.
The intention being to slow node ID generation down enough for the attack to be untenable, but not so much that it makes it onerous for new nodes to join.
That combined with some last minute “salt” on the transactions, might get us most of the way there.
——-
By the way, I see what I overlooked in my previous conceptualization.
When a transaction is send to the DHT I was presuming would actually be stored on many (hopefully independent) nodes. 5 times related to each in-point and 5 times related to each out-point. Also once by the payer, and once by the payee. I guess that would be 17X redundant given 1 in and 2 outs.
Each of these places “could” resubmit the transaction back to the network if it went missing.
However, I failed to consider three things, 1) validators would only be using 5 of the 17 places for validation. 2) they have no way to query the other places of redundancy should the initial 5 locations be compromised. 3) the additional redundant places have no way of identifying the compromised nodes if they return targeted malicious lies.
Oops. But nice catch!
The following content was written by Red on August 07, 2010, 06:05:01 PM in the thread latency and locality. All content is owned by the author of the bitcointalk.org post. (original)
Once you get away from a system where each node’s influence is proportional to their CPU power, then what else do you use to determine who is (approximately) one person?
That is the key question of course. I think you need to make it harder to demonstrate you are a person/node. I posted some initial thoughts in the previous post.
