Last active
August 29, 2015 14:13
-
-
Save maraoz/6963b877294fbc24e1f8 to your computer and use it in GitHub Desktop.
Transaction proposal protocol
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| transaction_proposal: { | |
| raw, | |
| xpubs[], | |
| m, | |
| input_metadata: [ | |
| { | |
| input_transaction, // (optional for participants with no access to the blockchain) | |
| path || paths[], | |
| sighash_type (defaults to SIGHASH_ALL) | |
| } || null | |
| ], | |
| output_metadata: [ | |
| { | |
| path || paths[] | |
| } || null | |
| ] | |
| } |
check if we need to include redeemScript in metadata.
Advantage of including master public keys in each tx proposal is that the participants don't have to store them as state. This also reduces privacy leaks if a participant is compromised.
The disadvantage of including them is that the tx proposal now becomes more sensitive and might need to protect it more than we would otherwise.
I believe we don't need to include redeemScripts in metadata - they can just be in the properly formatted scriptSigs. OP_0 SIG1 SIG2 REDEEM where SIG1 / SIG2 are replaced with OP_0 if not yet populated.
+1 on the redeem script not being necessary
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
should we include extended master public keys and the threshold (
minm-of-n) in each transaction proposal?