📅 Original date posted:2017-09-29
📝 Original message:Anyway, I'll count that as a NAK from Luke. what do others here think?
I wish to guage if I were to submit a functional pull request for one or
both of these RPC calls, if would it be likely to be accepted.
If so I'm happy to contribute my time, otherwise...
On 09/29/2017 03:13 PM, Dan Libby wrote:
> It seems to me that the same statement can be made for *any* key storage
> mechanism depending on one's security/threat model, including
> bitcoin-core's internal wallet storage. There certainly are cases where
> a paper (or metal) offline wallet makes a lot of sense, particularly for
> long-term offline storage... something that electronic media pretty much
> sucks at.
>
> Though if you care to elaborate I'd be interested to learn of your
> specific critiques, if you have any beyond the generic statements here:
> https://en.bitcoin.it/wiki/Paper_wallet
>
> Regardless, the APIs I've proposed have uses beyond paper wallets. It
> can also be used by third party wallets, or any number of reasons that
> individuals or devs might have to generate keys.
>
>
>
> On 09/29/2017 02:03 PM, Luke Dashjr wrote:
>> Paper wallets are a safety hazard, insecure, and generally not advisable.
>>
>>
>> On Friday 29 September 2017 5:29:17 PM 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.
>>>
>>> As such, I'm throwing out the following half-baked proposal as a
>>> starting point for discussion:
>>>
>>>
>>> -----
>>>
>>> genexternaladdress ( "type" )
>>>
>>> Returns a new Bitcoin address and private key for receiving
>>> payments. This key/address is intended for external usage such as
>>> paper wallets and will not be used by internal wallet nor written to
>>> disk.
>>>
>>> Arguments:
>>> 1. "type" (string, optional) one of: p2pkh, p2sh-p2wpkh
>>> default: p2sh-p2wpkh
>>>
>>> Result:
>>> {
>>> "privKey" (string) The private key in wif format.
>>> "address" (string) The address in p2pkh or p2sh-p2wpkh
>>> format.
>>> }
>>>
>>> Examples:
>>> > bitcoin-cli genexternaladdress
>>>
>>> ----
>>>
>>> This API is simple to implement and use. It provides enough
>>> functionality for any moderately skilled developer to create their own
>>> paper wallet creation script using any scripting language, or even for
>>> advanced users to perform using bitcoin-cli or debug console.
>>>
>>> If consensus here is in favor of including such an API, I will be happy
>>> to take a crack at implementing it and submitting a pull request.
>>>
>>> If anyone has reasons why it is a BAD IDEA to include such an RPC call
>>> in bitcoind, I'm curious to hear it.
>>>
>>> Also, I welcome suggestions for a better name, or maybe there could be
>>> some improvements to the param(s), such as calling p2sh-p2wpkh "segwit"
>>> instead.
>>>
>>>
>>> ---- further work ----
>>>
>>>
>>> Further steps could be taken in this direction, but are not necessary
>>> for a useful first-step. In particular:
>>>
>>> 1. an RPC call to generate an external HD wallet seed.
>>> 2. an RPC call to generate N key/address pairs from a given seed.
>>> 3. GUI functionality in bitcoin-qt to facilitate easy paper wallet
>>> generation (and printing?) for end-users, complete with nice graphics,
>>> qr codes, etc.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
Dan Libby
Open Source Consulting S.A.
Santa Ana, Costa Rica
http://osc.co.cr
phone: 011 506 2204 7018
Fax: 011 506 2223 7359
Dan Libby [ARCHIVE] /
npub1hm…jk43d
2023-06-07 18:06:44
in reply to nevent1q…yspd
Author Public Key
npub1hm38d5dwxdq5zxlnv2qdfk3flecptqwl7g7u62ja0tr92d0hmrusejk43dPublished at
2023-06-07 18:06:44Event JSON
{
"id": "f9c487ecbd5de0da698de8d6f9687736b4afa61b47298df2c93183bb5b1024be",
"pubkey": "bee276d1ae3341411bf36280d4da29fe701581dff23dcd2a5d7ac65535f7d8f9",
"created_at": 1686161204,
"kind": 1,
"tags": [
[
"e",
"adbe104cdeb184e2b9ee2e7441c0306f637c427dfa72914e557b36050055e79e",
"",
"root"
],
[
"e",
"3274b0075ef431514adcbf3cad571e63e4ce4dc527b18a968e6d5deb62ce9b35",
"",
"reply"
],
[
"p",
"bee276d1ae3341411bf36280d4da29fe701581dff23dcd2a5d7ac65535f7d8f9"
]
],
"content": "📅 Original date posted:2017-09-29\n📝 Original message:Anyway, I'll count that as a NAK from Luke. what do others here think?\n\nI wish to guage if I were to submit a functional pull request for one or\nboth of these RPC calls, if would it be likely to be accepted.\n\nIf so I'm happy to contribute my time, otherwise...\n\nOn 09/29/2017 03:13 PM, Dan Libby wrote:\n\u003e It seems to me that the same statement can be made for *any* key storage\n\u003e mechanism depending on one's security/threat model, including\n\u003e bitcoin-core's internal wallet storage. There certainly are cases where\n\u003e a paper (or metal) offline wallet makes a lot of sense, particularly for\n\u003e long-term offline storage... something that electronic media pretty much\n\u003e sucks at.\n\u003e \n\u003e Though if you care to elaborate I'd be interested to learn of your\n\u003e specific critiques, if you have any beyond the generic statements here:\n\u003e https://en.bitcoin.it/wiki/Paper_wallet\n\u003e \n\u003e Regardless, the APIs I've proposed have uses beyond paper wallets. It\n\u003e can also be used by third party wallets, or any number of reasons that\n\u003e individuals or devs might have to generate keys.\n\u003e \n\u003e \n\u003e \n\u003e On 09/29/2017 02:03 PM, Luke Dashjr wrote:\n\u003e\u003e Paper wallets are a safety hazard, insecure, and generally not advisable.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Friday 29 September 2017 5:29:17 PM Dan Libby via bitcoin-dev wrote:\n\u003e\u003e\u003e Hi,\n\u003e\u003e\u003e\n\u003e\u003e\u003e I'm writing to suggest and discuss the addition of paper wallet\n\u003e\u003e\u003e functionality in bitcoin-core software, starting with a single new RPC\n\u003e\u003e\u003e call: genExternalAddress [type].\n\u003e\u003e\u003e\n\u003e\u003e\u003e -- rationale --\n\u003e\u003e\u003e\n\u003e\u003e\u003e bitcoin-core is the most trusted and most secure bitcoin implementation.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Yet today (unless I've missed something) paper wallet generation\n\u003e\u003e\u003e requires use of third party software, or even a website such as\n\u003e\u003e\u003e bitaddress.org. This requires placing trust in an additional body of\n\u003e\u003e\u003e code from a less-trusted and less peer-reviewed source. Ideally, one\n\u003e\u003e\u003e would personally audit this code for one's self, but in practice that\n\u003e\u003e\u003e rarely happens.\n\u003e\u003e\u003e\n\u003e\u003e\u003e In the case of a website generator, the code must be audited again each\n\u003e\u003e\u003e time it is downloaded. I cannot in good faith recommend to anyone to\n\u003e\u003e\u003e use such third party tools for wallet generation.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I *would* recommend for others to trust a paper wallet that uses\n\u003e\u003e\u003e address(es) generated by bitcoin-core itself.\n\u003e\u003e\u003e\n\u003e\u003e\u003e At least for me, this requirement to audit (or implicitly trust) a\n\u003e\u003e\u003e secondary body of bitcoin code places an additional hurdle or\n\u003e\u003e\u003e disincentive on the use of paper wallets, or indeed private keys\n\u003e\u003e\u003e generated outside of bitcoin-core for any purpose.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Unfortunately, one cannot simply use getnewaddress, getaccountaddress,\n\u003e\u003e\u003e or getrawchangeaddress for this purpose, because the associated private\n\u003e\u003e\u003e keys are added to the bitcoin-core wallet and cannot be removed... or in\n\u003e\u003e\u003e the case of hd-wallets are deterministically derived.\n\u003e\u003e\u003e\n\u003e\u003e\u003e As such, I'm throwing out the following half-baked proposal as a\n\u003e\u003e\u003e starting point for discussion:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e -----\n\u003e\u003e\u003e\n\u003e\u003e\u003e genexternaladdress ( \"type\" )\n\u003e\u003e\u003e\n\u003e\u003e\u003e Returns a new Bitcoin address and private key for receiving\n\u003e\u003e\u003e payments. This key/address is intended for external usage such as\n\u003e\u003e\u003e paper wallets and will not be used by internal wallet nor written to\n\u003e\u003e\u003e disk.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Arguments:\n\u003e\u003e\u003e 1. \"type\" (string, optional) one of: p2pkh, p2sh-p2wpkh\n\u003e\u003e\u003e default: p2sh-p2wpkh\n\u003e\u003e\u003e\n\u003e\u003e\u003e Result:\n\u003e\u003e\u003e {\n\u003e\u003e\u003e \"privKey\" (string) The private key in wif format.\n\u003e\u003e\u003e \"address\" (string) The address in p2pkh or p2sh-p2wpkh\n\u003e\u003e\u003e format.\n\u003e\u003e\u003e }\n\u003e\u003e\u003e\n\u003e\u003e\u003e Examples:\n\u003e\u003e\u003e \u003e bitcoin-cli genexternaladdress\n\u003e\u003e\u003e\n\u003e\u003e\u003e ----\n\u003e\u003e\u003e\n\u003e\u003e\u003e This API is simple to implement and use. It provides enough\n\u003e\u003e\u003e functionality for any moderately skilled developer to create their own\n\u003e\u003e\u003e paper wallet creation script using any scripting language, or even for\n\u003e\u003e\u003e advanced users to perform using bitcoin-cli or debug console.\n\u003e\u003e\u003e\n\u003e\u003e\u003e If consensus here is in favor of including such an API, I will be happy\n\u003e\u003e\u003e to take a crack at implementing it and submitting a pull request.\n\u003e\u003e\u003e\n\u003e\u003e\u003e If anyone has reasons why it is a BAD IDEA to include such an RPC call\n\u003e\u003e\u003e in bitcoind, I'm curious to hear it.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Also, I welcome suggestions for a better name, or maybe there could be\n\u003e\u003e\u003e some improvements to the param(s), such as calling p2sh-p2wpkh \"segwit\"\n\u003e\u003e\u003e instead.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e ---- further work ----\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Further steps could be taken in this direction, but are not necessary\n\u003e\u003e\u003e for a useful first-step. In particular:\n\u003e\u003e\u003e\n\u003e\u003e\u003e 1. an RPC call to generate an external HD wallet seed.\n\u003e\u003e\u003e 2. an RPC call to generate N key/address pairs from a given seed.\n\u003e\u003e\u003e 3. GUI functionality in bitcoin-qt to facilitate easy paper wallet\n\u003e\u003e\u003e generation (and printing?) for end-users, complete with nice graphics,\n\u003e\u003e\u003e qr codes, etc.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\n\n-- \nDan Libby\n\nOpen Source Consulting S.A.\nSanta Ana, Costa Rica\nhttp://osc.co.cr\nphone: 011 506 2204 7018\nFax: 011 506 2223 7359",
"sig": "f5071f25822d1b43c5a4311fbd686dbc2cb5c987662ea498bf990d51dc2e873341302623e6662c37dcdb9dd063b17ead246cff4afc7c77b136706bc777d01925"
}