📅 Original date posted:2017-09-29
📝 Original message:One additional thought:
It should be useful to also define a multi-sig generation RPC.
This would facilitate multi-sig paper wallets stored in different
physical locations, amongst other use-cases.
Something like:
-----
genexternalmultisigaddress ( "m", "n", "type" )
Returns a new Bitcoin address and n number of private key(s).
This address and associated keys is intended for external usage such
as paper wallets and will not be used by internal wallet nor written
to disk.
Arguments:
1. "m" (integer, required) The number of required signers
to send funds.
2. "n" (integer, required) The number of authorized
signers
3. "type" (string, optional) one of: p2sh-p2pkh, p2sh-p2wpkh
default: p2sh-p2wpkh
Result:
{
"address", (string) The address in p2pkh or p2sh-p2wpkh
format.
"privkeys": [
(string) The private key in wif format.
]
}
Examples:
> bitcoin-cli genexternalmultisigaddress 2 3
-----
On 09/29/2017 10:29 AM, Dan Libby via bitcoin-dev wrote:
> Hi,
>
> I'm writing to suggest and discuss the addition of paper wallet
> functionality in bitcoin-core software, starting with a single new RPC
> call: genExternalAddress [type].
>
> -- rationale --
>
> bitcoin-core is the most trusted and most secure bitcoin implementation.
>
> Yet today (unless I've missed something) paper wallet generation
> requires use of third party software, or even a website such as
> bitaddress.org. This requires placing trust in an additional body of
> code from a less-trusted and less peer-reviewed source. Ideally, one
> would personally audit this code for one's self, but in practice that
> rarely happens.
>
> In the case of a website generator, the code must be audited again each
> time it is downloaded. I cannot in good faith recommend to anyone to
> use such third party tools for wallet generation.
>
> I *would* recommend for others to trust a paper wallet that uses
> address(es) generated by bitcoin-core itself.
>
> At least for me, this requirement to audit (or implicitly trust) a
> secondary body of bitcoin code places an additional hurdle or
> disincentive on the use of paper wallets, or indeed private keys
> generated outside of bitcoin-core for any purpose.
>
> Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
> or getrawchangeaddress for this purpose, because the associated private
> keys are added to the bitcoin-core wallet and cannot be removed... or in
> the case of hd-wallets are deterministically derived.
Dan Libby [ARCHIVE] /
npub1hm…jk43d
2023-06-07 18:06:40
in reply to nevent1q…x9c8
Author Public Key
npub1hm38d5dwxdq5zxlnv2qdfk3flecptqwl7g7u62ja0tr92d0hmrusejk43dPublished at
2023-06-07 18:06:40Event JSON
{
"id": "9d8a64dafde9c3f47f14b8979ef278dec08195299d561fdd8346534c535564d4",
"pubkey": "bee276d1ae3341411bf36280d4da29fe701581dff23dcd2a5d7ac65535f7d8f9",
"created_at": 1686161200,
"kind": 1,
"tags": [
[
"e",
"adbe104cdeb184e2b9ee2e7441c0306f637c427dfa72914e557b36050055e79e",
"",
"root"
],
[
"e",
"d28bf95292d589883498cd5505cb8b9e0bd80643f31c11d91c5960190f3052a2",
"",
"reply"
],
[
"p",
"e1ad0d0d83103f222425541294008149d215c1e1629b0bb37b98e19f698feb3e"
]
],
"content": "📅 Original date posted:2017-09-29\n📝 Original message:One additional thought:\n\nIt should be useful to also define a multi-sig generation RPC.\n\nThis would facilitate multi-sig paper wallets stored in different\nphysical locations, amongst other use-cases.\n\nSomething like:\n\n-----\n\n genexternalmultisigaddress ( \"m\", \"n\", \"type\" )\n\n Returns a new Bitcoin address and n number of private key(s).\n This address and associated keys is intended for external usage such\n as paper wallets and will not be used by internal wallet nor written\n to disk.\n\n Arguments:\n 1. \"m\" (integer, required) The number of required signers\n to send funds.\n 2. \"n\" (integer, required) The number of authorized\n signers\n 3. \"type\" (string, optional) one of: p2sh-p2pkh, p2sh-p2wpkh\n default: p2sh-p2wpkh\n\n Result:\n {\n \"address\", (string) The address in p2pkh or p2sh-p2wpkh\n format.\n \"privkeys\": [\n (string) The private key in wif format.\n ]\n }\n\n\n Examples:\n \u003e bitcoin-cli genexternalmultisigaddress 2 3\n\n-----\n\n\n\nOn 09/29/2017 10:29 AM, Dan Libby via bitcoin-dev wrote:\n\u003e Hi,\n\u003e \n\u003e I'm writing to suggest and discuss the addition of paper wallet\n\u003e functionality in bitcoin-core software, starting with a single new RPC\n\u003e call: genExternalAddress [type].\n\u003e \n\u003e -- rationale --\n\u003e \n\u003e bitcoin-core is the most trusted and most secure bitcoin implementation.\n\u003e \n\u003e Yet today (unless I've missed something) paper wallet generation\n\u003e requires use of third party software, or even a website such as\n\u003e bitaddress.org. This requires placing trust in an additional body of\n\u003e code from a less-trusted and less peer-reviewed source. Ideally, one\n\u003e would personally audit this code for one's self, but in practice that\n\u003e rarely happens.\n\u003e \n\u003e In the case of a website generator, the code must be audited again each\n\u003e time it is downloaded. I cannot in good faith recommend to anyone to\n\u003e use such third party tools for wallet generation.\n\u003e \n\u003e I *would* recommend for others to trust a paper wallet that uses\n\u003e address(es) generated by bitcoin-core itself.\n\u003e \n\u003e At least for me, this requirement to audit (or implicitly trust) a\n\u003e secondary body of bitcoin code places an additional hurdle or\n\u003e disincentive on the use of paper wallets, or indeed private keys\n\u003e generated outside of bitcoin-core for any purpose.\n\u003e \n\u003e Unfortunately, one cannot simply use getnewaddress, getaccountaddress,\n\u003e or getrawchangeaddress for this purpose, because the associated private\n\u003e keys are added to the bitcoin-core wallet and cannot be removed... or in\n\u003e the case of hd-wallets are deterministically derived.",
"sig": "1f549ba826aa08ebeed5b3e8bfecddc41a5b7625754a36eede406157d550642b88a85d58b38c3f297b05c4255c22fa483177aab6dae69844ceb560e544cdd32e"
}