DAG transactions

[orthecreedence]

I'm not sure if this makes sense yet, need to find pros and cons. The concept though is that instead of an identity being a singular object, it's rather the transactions that make it up, each one signed by the highest-level key required for that transaction. Each transaction would also sign the transaction(s) before it, creating a DAG.

The idea is this would make it easier to sync identities across the private StampNet (because it's almost/kind of a CRDT) and could make it easier to detect malicious "forks" of identities.

Pros

• I get to build it.
• Probably more secure. Each identity is an audit log of itself. One can look at your identity or an identity where someone possibly got a copy of an old root key and "see" the forks, and decide which one is malicious.
• Easier to sync, because we're exchanging singular "idempotent" (in the sense that a transaction only gets run once) transactions instead of entire identity blocks (which would require merging).
• Simplifies a lot of the logic around signing, ie deprecates "root signature" (and many other signature types) because each change must be individually signed. This abstracts almost all of the operations into one single format with common components (signature, public data, private data).
• Can enforce that any new transaction must have a timestamp later than any previous transactions.
• Simplifies recovery system immensely.

Cons

• I have to build it.
• If you add a subkey named "<3PINEAPPLEPIZZA" the history will persist even it you delete it or rename it later, so everyone will still know what a sick freak you are. Might want some kind of rewrite history mechanism, like git (or, like, not...who cares?).
• Identities will only grow in size, although perhaps some kind of compression would be possible.
• Public representation of identity becomes more convoluted (do we show the final identity? the raw transactions?)
• Requires ripping out a lot of the signing code and tests in the identity representation itself. This simplifies the code, but is still work.
• Removing sensitive keys from your identity (for instance to put them on a USB dongle) becomes a bit more strange, because instead of removing the private key from the single identity object, you have to strip it from each of the key creation transactions' private sections.

Overall, not sure which wins. I'm leaning towards doing this but doing it later on, not immediately. Although it might make sense to do it before seriously starting the StampNet implementation.

Implementation

Transactions implement Public, giving them strip_private so we can remove private data from them (for publishing et al). The identity is built by ordering (via Kahn's algo) transactions and running them start to finish. Transactions link to any unlinked ones before them.

TODO

• [x] Build it
• [x] Implement chain reencryption

[orthecreedence]

Ended up working on this. Probably 80% of the way there. Needs some wires hooked up, some security assurances, and some heavy testing. However, it has centralized so much weird complexity in the identity system and made everything an absolute pleasure to work with. Not having to sign every little fucking thing is really much nicer. Also, it effectively solved the recovery system (#4) since I was thining of doing some kind of trnsaction chain there anyway.

Seriously, now that this is almost done, I can't believe I tried to do this project without it.

[orthecreedence]

Done. Very nice.