A small issue with the proposed dual-algo, "triple-purpose" mining: Since the "pure" block header itself does not carry information about which algo is used, it does not make much sense to put the difficulty target (nBits) in it. Especially in light of mining with getauxblock and getwork, it might make sense to share the block generation logic so that the same generated blocks can be returned by either method.

Instead of having the difficulty target in nBits in the pure block header, we should let nBits be free (or perhaps restrict it to be zero, so that we may use it in a controlled way if we later want to). Instead, the PoW data, which also specifies the mining algo, should have the nBits. All other validation rules stay the same (i. e., when verifying a block, we check that the nBits in the PoW data are as expected for the given algo, and then that the supplied PoW matches the target).

It would be very useful to allow people to place "restrictions" on receiving coins to specific addresses (e.g. that only one transaction can be received). Implementing this as a soft fork will enable better in-game market places, as unique items could be sold for CHI in the game state without the possibility of getting paid twice in CHI and the need for "locking" or refunding.

Here's roughly how I think those address restrictions should work:

• They are only temporary with a configurable (but bounded-from-above) number of blocks for which they are valid. This avoids the need to keep restrictions in the network state forever.
• Restrictions are defined by updating a name with a specific JSON in the value. The restriction will be put on the address that owned the name before the update, making sure that only the owner of an address can restrict it.
• Restrictions can define (at the minimum) a maximum number of transactions to the address, a minimum amount per transaction and a maximum total balance sent. This is enough to build a decent in-game market place.
• Restrictions are part of the consensus rules for which transactions are valid. Adding them will be a soft fork.

This should be fleshed out in more detail in a proper spec.

The draft spec for currencies should mention how atomic swaps work. Basically, it is not possible to transfer multiple tokens in a single transaction (definitely not for multiple players, and hard to verify for a single player). That should be described, and the proposed solution: Use "vessel" names as in the games.md doc and trade for CHI.