Allow adding hash(x) as a signer of an account

[jedmccaleb]

This means that any transaction on the account can be authorized by knowing x.
This will allow atomic cross chain trading: https://en.bitcoin.it/wiki/Atomic_cross-chain_trading

[MonsieurNicolas]

Idea being that the signature matching that signer would have to be "x" (the pre-image). This integrates well with the way we deal with multiple signers (allowing any combination using weights).

Note that this allows accounts to be drained by anybody (etc) if the weight of the "hash signer" is sufficient to perform some operations - probably not something that people would want in most cases but I don't think we would stop this in core.

[jedmccaleb]

The idea right now is to add a new type of public key that is really just H(x)

enum CryptoKeyType
{
    KEY_TYPE_ED25519 = 0,
    KEY_TYPE_HASH = 1
};

union PublicKey switch (CryptoKeyType type)
{
case KEY_TYPE_ED25519:
    uint256 ed25519;
case KEY_TYPE_HASH:
    uint256 hash;
};

Now this key can be added to an account's list of signers and given weights just like any other signer.

When signatures are checked for an account to make sure it has the proper authorization for a tx, instead of doing the normal signature verification for public keys of this type it will just ensure that:

H( signature ) = signer

[jedmccaleb]

David brought up the point that it would be nice to have x stuck in the ledger somewhere so you don't have to go root around for the transaction that exposed it. Also once x is exposed there is no reason for the signer to be H(x) since x is now known.

So the idea is that we would make another "PublicKey" type KEY_TYPE_VALUE that would just be x. When a transaction is verified that uses KEY_TYPE_HASH the KEY_TYPE_HASH is changed to KEY_TYPE_VALUE=x.

So an account with KEY_TYPE_VALUE is trivial to sign for. You just include the value as a "signature".

enum CryptoKeyType
{
    KEY_TYPE_ED25519 = 0,
    KEY_TYPE_HASH = 1,
    KEY_TYPE_VALUE = 2
};

union PublicKey switch (CryptoKeyType type)
{
case KEY_TYPE_ED25519:
    uint256 ed25519;
case KEY_TYPE_HASH:
    uint256 hash;
case KEY_TYPE_VALUE:
    uint256 value;
};

[jedmccaleb]

@stanford-scs nicolas had some concerns with this design:

• usually the escrow account will get merged in so x won't persist in the ledger anyway
• we don't control the size of x. If the cross chain swap operation needs a very large x it is better not to leave this in the ledger.

[MonsieurNicolas]

and in general - I don't want the ledger to be a messaging platform. x is something people will exchange off the network using their own scheme; by forcing it into our protocol we're just adding complexity that is not needed.

[MonsieurNicolas]

note that this needs to be combined with some other scheme to protect the account (only allow some transaction for example). otherwise the party revealing x can cheat.

[graydon]

See #965, possible dupe?

[jedmccaleb]

These are actually slightly different and I think we probably want both.

This one is what will allow atomic cross chain swaps. It adds the hash(x) as a signer so the signature check is: does hash(sig) == signer ?

#965 is for making a defined chain of txs. it adds a tx hash as a signer. So you can potentially only allow a certain tx to be the next one that works for an account.
its signature check is: does (this tx hash) == signer ?

[vogel]

Merged in #1124