📅 Original date posted:2017-09-30
📝 Original message:On 09/29/2017 09:49 PM, Jonas Schnelli wrote:
> AFAIK, client implementations such as your proposal are off-topic for this ML.
> Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for such proposals.
ok, thanks. I will take the proposal there.
> I have to agree with Luke.
thanks for your feedback.
> And I would also extend those concerns to BIP39 plaintext paper backups.
>
> IMO, private keys should be generated and used (signing) on a trusted, minimal and offline hardware/os.
uhh.... do you apply this logic to the bitcoin-core wallet itself?
because clearly it generates keys and is intended to be used for signing
in online environments. Lots of real-world use-cases depend on that today.
So if existing bitcoin-core wallet behavior is "ok" in any context then
how is it any worse for it to generate a key/address that will not be
stored in the internal wallet, and the user may do with it as they wish?
That is all my proposed RPC call does and unlike the existing RPC calls
it never even stores the key or address to disk. It is also useful when
run on an offline hardware device, such as a laptop connected to an
non-networked printer.
Further, you mention the word trust. That's the crux of the matter. As
a full node operator, I've already placed my trust in the bitcoin-core
developers and dev/release practices. Why exactly should I trust the
software in this minimal offline hardware/os you mention if it is NOT
bitcoin core? And even if open source software, does that not at least
double my workload/expense to audit theat software in addition to
bitcoin-core?
> Users should have no way to view or export the private keys (expect for
> the seed backup).
I suppose that in your view then, dumpprivkey and dumpwallet RPCs should
be removed from bitcoin-core to fit this paradigm?
(Personally I actively avoid wallet software that takes this view and
treat users like children, preventing individuals direct access to the
keys for their own funds, which disempowers and sometimes results in a
form of lockin)
> Backups should be encrypted (whoever finds the paper backup should need a second factor to decrypt) and the restore process should be footgun-safe (especially the lost-passphrase deadlock).
This is more relevant to an application layer above the 2 RPC calls I
proposed. Encryption could be implemented (or not) by whichever software
calls the proposed RPC apis. And further the APIs can be called for
use-cases beyond just paper wallets.
Dan Libby [ARCHIVE] /
npub1hm…jk43d
2023-06-07 18:06:41
in reply to nevent1q…ju5m
Author Public Key
npub1hm38d5dwxdq5zxlnv2qdfk3flecptqwl7g7u62ja0tr92d0hmrusejk43dPublished at
2023-06-07 18:06:41Event JSON
{
"id": "c1f9163d0bff393b26f600b51a0fe0f66a728f198846bd188db2a35bde11f150",
"pubkey": "bee276d1ae3341411bf36280d4da29fe701581dff23dcd2a5d7ac65535f7d8f9",
"created_at": 1686161201,
"kind": 1,
"tags": [
[
"e",
"adbe104cdeb184e2b9ee2e7441c0306f637c427dfa72914e557b36050055e79e",
"",
"root"
],
[
"e",
"9552ef19c1d7f84ece89aa2037455f3a4c3744cd758649cddfc8d3a2655d1076",
"",
"reply"
],
[
"p",
"9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c"
]
],
"content": "📅 Original date posted:2017-09-30\n📝 Original message:On 09/29/2017 09:49 PM, Jonas Schnelli wrote:\n\n\u003e AFAIK, client implementations such as your proposal are off-topic for this ML.\n\u003e Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for such proposals.\n\nok, thanks. I will take the proposal there.\n\n\u003e I have to agree with Luke.\n\nthanks for your feedback.\n\n\u003e And I would also extend those concerns to BIP39 plaintext paper backups.\n\u003e \n\u003e IMO, private keys should be generated and used (signing) on a trusted, minimal and offline hardware/os.\n\nuhh.... do you apply this logic to the bitcoin-core wallet itself?\nbecause clearly it generates keys and is intended to be used for signing\nin online environments. Lots of real-world use-cases depend on that today.\n\nSo if existing bitcoin-core wallet behavior is \"ok\" in any context then\nhow is it any worse for it to generate a key/address that will not be\nstored in the internal wallet, and the user may do with it as they wish?\n That is all my proposed RPC call does and unlike the existing RPC calls\nit never even stores the key or address to disk. It is also useful when\nrun on an offline hardware device, such as a laptop connected to an\nnon-networked printer.\n\nFurther, you mention the word trust. That's the crux of the matter. As\na full node operator, I've already placed my trust in the bitcoin-core\ndevelopers and dev/release practices. Why exactly should I trust the\nsoftware in this minimal offline hardware/os you mention if it is NOT\nbitcoin core? And even if open source software, does that not at least\ndouble my workload/expense to audit theat software in addition to\nbitcoin-core?\n\n\u003e Users should have no way to view or export the private keys (expect for \n\u003e the seed backup).\n\nI suppose that in your view then, dumpprivkey and dumpwallet RPCs should\nbe removed from bitcoin-core to fit this paradigm?\n\n(Personally I actively avoid wallet software that takes this view and\ntreat users like children, preventing individuals direct access to the\nkeys for their own funds, which disempowers and sometimes results in a\nform of lockin)\n\n\u003e Backups should be encrypted (whoever finds the paper backup should need a second factor to decrypt) and the restore process should be footgun-safe (especially the lost-passphrase deadlock).\n\nThis is more relevant to an application layer above the 2 RPC calls I\nproposed. Encryption could be implemented (or not) by whichever software\ncalls the proposed RPC apis. And further the APIs can be called for\nuse-cases beyond just paper wallets.",
"sig": "e8be9dc8cd47e16ebdf40865726217b979f754fdb1f487b61445d74ba3ec0f2fc0441dc62475fff84ea30ea9de24bc160795a44ead965552db970c3d46ae8ffb"
}