Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Transaction proposal protocol
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
]
}
@maraoz

This comment has been minimized.

Copy link
Owner Author

maraoz commented Jan 20, 2015

sighash_type: part of tx_proposal, or part of input_metadata?

@maraoz

This comment has been minimized.

Copy link
Owner Author

maraoz commented Jan 20, 2015

should we include extended master public keys and the threshold (m in m-of-n) in each transaction proposal?

@maraoz

This comment has been minimized.

Copy link
Owner Author

maraoz commented Jan 20, 2015

check if we need to include redeemScript in metadata.

@devrandom

This comment has been minimized.

Copy link

devrandom commented Jan 20, 2015

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.

@devrandom

This comment has been minimized.

Copy link

devrandom commented Jan 20, 2015

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.

@eordano

This comment has been minimized.

Copy link

eordano commented Jan 23, 2015

+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
You can’t perform that action at this time.