Conversation
RFC to support shared ownership for two-party N-of-N multisignature outputs Describes the protocol for creating a multiparty bulletproof and commitment for multisignature outputs Requires a soft-fork due to changes in slate formatting incompatible with the current slate version
| ``` | ||
| (multisig_key_b_pub, multisig_key_b_sec) = b.keychain().derive_key(multisig_key_id) | ||
|
|
||
| part_commit_b = PedersenCommit(value, multisig_key_b_sec) |
There was a problem hiding this comment.
Is it possible for B to cancel the pubkey of A here? e.g.
part_commit_b = PedersenCommit(value, multisig_key_b_sec) - (part_commit_a - value*H)
or something similar? The attempt would be to create a commit_sum output that contains only the blinding factor of the party B. I'm not able to follow the bulletproof parts that follow because I'm not familiar with BPs, but perhaps the receiver could throw away the final bulletproof and simply construct the bulletproof alone since they know both values. This would also require B to also cancel the same key in the partial excess pubkey of B since A expects their private key to be a part of that.
| The receiver then adds the Pedersen commitments together to get the `commit_sum`. The `commit_sum` is used for the remainder of the multiparty bulletproof building protocol, and is the commitment for the finalized bulletproof. | ||
|
|
||
| ``` | ||
| commit_sum = secp.commit_sum([part_commit_a, part_commit_b], []) |
There was a problem hiding this comment.
part_commit_a + part_commit_b = PedersenCommit(2*value, multisig_key_a_sec + multisig_key_b_sec)
The value is committed to twice. So, unless they are referring to 2 different values, either part_commit_a shouldn't include it, or part_commit_b shouldn't, or they should split it.
|
|
||
| Versioned slates allow for the incremental addition of new features to Grin transaction building. A new slate version 5 is proposed to include changes for multisignature outputs and atomic swaps. | ||
|
|
||
| Originally slate versions corresponded with hard forks in the Grin protocol, but there are no longer any scheduled hard forks. This means a soft fork is required to implement these changes. |
There was a problem hiding this comment.
This is just a wallet protocol change. No fork of any kind is needed.
3 participants
RFC to support shared ownership for two-party N-of-N multisignature outputs
Describes the protocol for creating a multiparty bulletproof and commitment for multisignature outputs
Requires a soft-fork due to changes in slate formatting incompatible with the current slate version
Link to rendered text