Pretty cool, although I’m not sure how the digital money scenario plays out. It seems like there needs to be a way to prevent double-spending, but I don’t see it. As I understand it, the same agent can sign two messages with the same sha1(sha1(key)).
Maybe I’m not understanding the article, but wouldn’t enforcing that the key be immutable and enforcing that the signed key == the key used to locate it in the DHT prevent this?
Okay - so relying on some mechanism in some DHT to prevent double writes? My knowledge is admittedly limited on the subject - I’m really only acquainted with kademlia, which I’m pretty sure wouldn’t be very good at this.
(I think kademlia nodes need a means of verifying that particular values are associated with particular keys. This is straightforward with bittorrent since everything is content-addressed. It’s straightforward with cryptographic signing too but I don’t know of a mechanism in a kademlia network that could prevent a keyholder from signing conflicting statements - like “sha1(sha1(key)): pay account A” and “sha1(sha1(key)): pay account B”.)
I haven’t spent much time exploring the DHT zoo, and I wish I were more acquainted with the options available. Do you happen to know of a DHT that’s not content addressable but which preserves immutability? If that’s the case then I could start to understand the digital money scenario.
I was also thinking that there’s no good way to resolve conflicts with a system like this when a network partition is resolved. You could potentially resolve conflicts by breaking immutability, but it’s not possible to resolve conflicts while maintaining immutability in a p2p system like kademlia.
Unless I’m missing something, but I just don’t see it.
Pretty cool, although I’m not sure how the digital money scenario plays out. It seems like there needs to be a way to prevent double-spending, but I don’t see it. As I understand it, the same agent can sign two messages with the same sha1(sha1(key)).
Maybe I’m not understanding the article, but wouldn’t enforcing that the key be immutable and enforcing that the signed key == the key used to locate it in the DHT prevent this?
Again, maybe I’m not understanding it.
Okay - so relying on some mechanism in some DHT to prevent double writes? My knowledge is admittedly limited on the subject - I’m really only acquainted with kademlia, which I’m pretty sure wouldn’t be very good at this.
(I think kademlia nodes need a means of verifying that particular values are associated with particular keys. This is straightforward with bittorrent since everything is content-addressed. It’s straightforward with cryptographic signing too but I don’t know of a mechanism in a kademlia network that could prevent a keyholder from signing conflicting statements - like “sha1(sha1(key)): pay account A” and “sha1(sha1(key)): pay account B”.)
I haven’t spent much time exploring the DHT zoo, and I wish I were more acquainted with the options available. Do you happen to know of a DHT that’s not content addressable but which preserves immutability? If that’s the case then I could start to understand the digital money scenario.
I think you’re right about this.
I was also thinking that there’s no good way to resolve conflicts with a system like this when a network partition is resolved. You could potentially resolve conflicts by breaking immutability, but it’s not possible to resolve conflicts while maintaining immutability in a p2p system like kademlia.
Unless I’m missing something, but I just don’t see it.