1. 16
  1.  

  2. 2

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

    1. 2

      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.

      1. 2

        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.

        1. 2

          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.