-
Notifications
You must be signed in to change notification settings - Fork 968
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow adding hash(x) as a signer of an account #846
Comments
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. |
The idea right now is to add a new type of public key that is really just H(x)
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:
|
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".
|
@stanford-scs nicolas had some concerns with this design:
|
and in general - I don't want the ledger to be a messaging platform. |
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 |
See #965, possible dupe? |
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 #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. |
Merged in #1124 |
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
The text was updated successfully, but these errors were encountered: