Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
RPC: Add parameter to addmultisigaddress / createmultisig to sort public keys #8751
Conversation
|
concept ACK |
fanquake
added
the
RPC/REST/ZMQ
label
Sep 18, 2016
|
Concept ACK, although I really don't like multiple-optional-positional-boolean APIs. Wish we switched to named arguments any day. One nit: the RPC help should mention BIP67 by name. |
laanwj
referenced this pull request
Sep 26, 2016
Merged
rpc: Add support for JSON-RPC named arguments #8811
|
Needs rebase |
|
@MarcoFalke thanks, done. @laanwj I should have mentioned, nits addressed. One travis run failed due to the compactblocks RPC test. |
| +class SortMultisigTest(BitcoinTestFramework): | ||
| + def __init__(self): | ||
| + super().__init__() | ||
| + self.num_nodes = 4 |
|
Concept ACK 7d7a647 |
| @@ -293,6 +294,7 @@ UniValue createmultisig(const JSONRPCRequest& request) | ||
| " \"key\" (string) bitcoin address or hex-encoded public key\n" | ||
| " ,...\n" | ||
| " ]\n" | ||
| + "3. \"fSort\" (bool, optional) Whether to sort public keys according to BIP67. Default setting is false.\n" |
afk11
Nov 24, 2016
Contributor
It should be a boolean. Just observed they aren't usually quoted in RPC output, fixing now.
|
I probably shouldn't have squashed @MarcoFalke, I'm sorry for rebasing out the commit you reviewed. The only thing to change this time was the removal of "'s from the RPC help message. |
luke-jr
suggested changes
Nov 25, 2016
Code looks reasonably correct, just a few nits. Did not verify tests.
| "2. \"keys\" (string, required) A json array of keys which are bitcoin addresses or hex-encoded public keys\n" | ||
| " [\n" | ||
| " \"key\" (string) bitcoin address or hex-encoded public key\n" | ||
| " ,...\n" | ||
| " ]\n" | ||
| + "3. fSort (bool, optional) Whether to sort public keys according to BIP67. Default setting is false.\n" |
| - CScript script; | ||
| + int nEncoded = 0; | ||
| + std::vector<std::vector<unsigned char>> vEncoded; | ||
| + vEncoded.resize(keys.size()); |
| + vEncoded.resize(keys.size()); | ||
| + BOOST_FOREACH(const CPubKey& key, keys) { | ||
| + vEncoded[nEncoded++] = ToByteVector(key); | ||
| + } |
luke-jr
Nov 25, 2016
•
Member
Seems like the loop would be better as:
for (size_t n = 0; n < keys.size(); ++n) {
vEncoded[n] = ToByteVector(keys[n]);
}| + } | ||
| + | ||
| + if (fSorted) { | ||
| + std::sort(vEncoded.begin(), vEncoded.end()); |
luke-jr
Nov 25, 2016
Member
I think this should do what BIP 67 requires, but someone more familiar with C++ and its locale support (or lack thereof) should probably confirm.
| @@ -78,7 +78,7 @@ bool ExtractDestinations(const CScript& scriptPubKey, txnouttype& typeRet, std:: | ||
| CScript GetScriptForDestination(const CTxDestination& dest); | ||
| CScript GetScriptForRawPubKey(const CPubKey& pubkey); | ||
| -CScript GetScriptForMultisig(int nRequired, const std::vector<CPubKey>& keys); | ||
| +CScript GetScriptForMultisig(int nRequired, const std::vector<CPubKey>& keys, bool fSorted); |
| "2. \"keysobject\" (string, required) A json array of bitcoin addresses or hex-encoded public keys\n" | ||
| " [\n" | ||
| " \"address\" (string) bitcoin address or hex-encoded public key\n" | ||
| " ...,\n" | ||
| " ]\n" | ||
| "3. \"account\" (string, optional) DEPRECATED. An account to assign the addresses to.\n" | ||
| + "4. fSort (bool, optional) Whether to sort public keys according to BIP67. Default setting is false.\n" |
added a commit
to bitcoinknots/bitcoin
that referenced
this pull request
Dec 21, 2016
|
Should update |
|
I rebased and addressed all the nits; pushed this to luke-jr/sort-multisigs @afk11 Are you still maintaining this? Can you pull my changes?
|
|
Sorry, yep I can pull these! I wanted to wait until named parameters was merged before hand, so I could avoid adding a positional parameter before the accounts parameters were changed I'll look at this in the next day or so (away from internet atm) wanna finish this up |
|
Merged commits and rebased. Apologies for the delay! |
|
The Apple build failed because the job time exceeded the maximum :/ |
|
Rebased |
|
Rebased |
|
The description for d70583a is no longer correct. |
|
@luke-jr Oops, yeah the rebase mightn't have been the easiest. So re-add the contents of setup_network? |
added a commit
to bitcoinknots/bitcoin
that referenced
this pull request
Jun 15, 2017
added a commit
to bitcoinknots/bitcoin
that referenced
this pull request
Jun 15, 2017
|
Perhaps I'm missing something, but I don't see the need for this. The It doesn't look like this PR is enforcing that the provided keys are compressed, so even with this PR, there are still expectations placed on the client. |
|
I think if developers are already committing to using the RPC to make a multisig script, making it easier to produce the same representation is more important than not. You are correct the PR as it stands doesn't validate it.. fixing this now. |
|
I'm still a weak concept NACK for this. I don't agree that we should add complexity to the server when the same outcome can be achieved by simply running a Sorry if that sounds negative - I think there needs to be some bar for adding new RPCs and arguments to avoid bloat. However, if I'm wrong and there's widespread consensus that this is useful functionality and should be merged, can I at least ask that you use named arguments instead of an Options object? There's really no need for Options objects in RPC calls since named args were added in #8811. |
|
Both RPC methods take an options object for this (sorry, the PR description wasn't updated with this) I appreciate where you are coming from and agree that most people can probably sort themselves, but they could also build a multisig script out of the keys and m/n. It's been a while since I've even used the RPC, but remember well the time when I didn't have a bitcoin library to do it all. I think it's worth including since once they continue using the flag, requests which mistakenly use the wrong order will reproduce the same redeem script (instead of always having a stateful order of public keys), and likewise with libraries that support it. |
| - CScript script; | ||
| + std::vector<std::vector<unsigned char>> vEncoded; | ||
| + vEncoded.reserve(keys.size()); | ||
| + BOOST_FOREACH(const CPubKey& key, keys) { |
|
Rebased and squashed a bit.
|
|
Concept ACK. Care to rebase? |
afk11
and others
added some commits
Nov 8, 2016
|
Rebased, sorry for the delay. Updated to check that keys are compressed before allowing sorting, and added more tests for this. Updated the docs/bips.md document to mention 0.15.1 instead of 0.15.0 (let me know whatever's best for this) |
|
Hmm, hate to reopen it, but now that we do actually have named arguments, could you rever to just adding a new boolean argument? options objects are just redundant now, and having options alias account in addmultisigaddress is just gross. Everything else seems fine at first glance. @jnewbery I'd generally agree with you, but, at least in principal, I think BIP67 is worth it. |
afk11 commentedSep 17, 2016
I figured it may be useful for these RPC methods to allow sorting public keys (BIP67) The PR adds a new boolean to createmultisig / addmultisigaddress at the end of their parameter list. By default, this is set to false to avoid a BC break.
I added a RPC test file
sort_multisig.pyfor testing createmultisig. Tests for addmultisigaddress went inwallet-accounts.py.Note: Code to check whether sorting is desired had to be replicated in both RPC methods (not in _createmultisig_redeemScript) because addmultisigaddress already takes a parameter at position 3.