đź“… Original date posted:2017-09-30
đź“ť Original message:>
> 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.
The current Bitcoin Core wallet setup is not as ideal as it could be.
An good example is, that the wallet and the full node (the p2p logic on 8333) do share the same process (same memory space).
AFAIK a lot of users use Core in watch-only mode and do the signing offline (offline / through HWWs).
Although, Core has currently no direct support for offline signing (expect the rawtx API which are pretty expert-ish).
The Core development process goes into that direction but it takes time due to the strict and extremely important code quality insurance.
>
> 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.
IMO we should make it better not worse.
Paper wallets delude to do address reuse, the spending-procedure is unclear, and very likely insecure.
A quick photo-snapshot by an attack may result in a full compromised key.
Printer buffers, etc. are also something to worry here.
> 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?
I think Bitcoin Core does a great job there. But not sure about other security layers are outside of Core.
Especially your operating system.
The reason why we see a growing demand in hardware wallets is probably because people no longer trust in current available operating systems as well as current used desktop/laptop CPUs (like Intel wit it’s MME, etc.).
>
>> 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?
Yes. That actually something we are considering (especially if we would allow BIP44 or other HD public key derivation forms).
Also, we heard of "support sessions“ on IRC where attackers told victims they must enter „dumpprivkey“ in the Console and give them the output in order „to fix the problem“.
> (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)
I dislike that as well – in general. But I guess most users like self-protection. Also, the user layer is attackable. If _you_ can access the private-keys, an attacker can do also. What most users want is a key-safe that only signs transactions which they could verify beforehand in a safe environment, and not a way to export private keys or something else that can touch the keys.
>> They should never leave the device over the channel used for the signing I/O. Users should have no way to view or export the private keys (expect for the seed backup). 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).
>
> Is there really nothing existing yet to address all of this?
The answer is probably: No (for now). But working towards this should be the focus.
---
/jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170930/c2a58417/attachment.sig>;
Jonas Schnelli [ARCHIVE] /
npub1nf…3dtxs
2023-06-07 18:06:41
in reply to nevent1q…2czv
Author Public Key
npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxsPublished at
2023-06-07 18:06:41Event JSON
{
"id": "3bb0ef1487037d75407e40abdaeb806ca6edfcf3abf3511004ec0fe6a19dfce0",
"pubkey": "9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c",
"created_at": 1686161201,
"kind": 1,
"tags": [
[
"e",
"adbe104cdeb184e2b9ee2e7441c0306f637c427dfa72914e557b36050055e79e",
"",
"root"
],
[
"e",
"c1f9163d0bff393b26f600b51a0fe0f66a728f198846bd188db2a35bde11f150",
"",
"reply"
],
[
"p",
"bee276d1ae3341411bf36280d4da29fe701581dff23dcd2a5d7ac65535f7d8f9"
]
],
"content": "📅 Original date posted:2017-09-30\n📝 Original message:\u003e \n\u003e uhh.... do you apply this logic to the bitcoin-core wallet itself?\n\u003e because clearly it generates keys and is intended to be used for signing\n\u003e in online environments. Lots of real-world use-cases depend on that today.\n\nThe current Bitcoin Core wallet setup is not as ideal as it could be.\nAn good example is, that the wallet and the full node (the p2p logic on 8333) do share the same process (same memory space).\nAFAIK a lot of users use Core in watch-only mode and do the signing offline (offline / through HWWs).\nAlthough, Core has currently no direct support for offline signing (expect the rawtx API which are pretty expert-ish).\n\nThe Core development process goes into that direction but it takes time due to the strict and extremely important code quality insurance.\n\n\u003e \n\u003e So if existing bitcoin-core wallet behavior is \"ok\" in any context then\n\u003e how is it any worse for it to generate a key/address that will not be\n\u003e stored in the internal wallet, and the user may do with it as they wish?\n\u003e That is all my proposed RPC call does and unlike the existing RPC calls\n\u003e it never even stores the key or address to disk. It is also useful when\n\u003e run on an offline hardware device, such as a laptop connected to an\n\u003e non-networked printer.\n\nIMO we should make it better not worse.\nPaper wallets delude to do address reuse, the spending-procedure is unclear, and very likely insecure.\nA quick photo-snapshot by an attack may result in a full compromised key.\nPrinter buffers, etc. are also something to worry here.\n\n\u003e Further, you mention the word trust. That's the crux of the matter. As\n\u003e a full node operator, I've already placed my trust in the bitcoin-core\n\u003e developers and dev/release practices. Why exactly should I trust the\n\u003e software in this minimal offline hardware/os you mention if it is NOT\n\u003e bitcoin core? And even if open source software, does that not at least\n\u003e double my workload/expense to audit theat software in addition to\n\u003e bitcoin-core?\n\nI think Bitcoin Core does a great job there. But not sure about other security layers are outside of Core.\nEspecially your operating system.\nThe reason why we see a growing demand in hardware wallets is probably because people no longer trust in current available operating systems as well as current used desktop/laptop CPUs (like Intel wit it’s MME, etc.).\n\n\u003e \n\u003e\u003e Users should have no way to view or export the private keys (expect for\n\u003e\u003e the seed backup).\n\u003e \n\u003e I suppose that in your view then, dumpprivkey and dumpwallet RPCs should\n\u003e be removed from bitcoin-core to fit this paradigm?\n\nYes. That actually something we are considering (especially if we would allow BIP44 or other HD public key derivation forms).\nAlso, we heard of \"support sessions“ on IRC where attackers told victims they must enter „dumpprivkey“ in the Console and give them the output in order „to fix the problem“.\n\n\u003e (Personally I actively avoid wallet software that takes this view and\n\u003e treat users like children, preventing individuals direct access to the\n\u003e keys for their own funds, which disempowers and sometimes results in a\n\u003e form of lockin)\n\nI dislike that as well – in general. But I guess most users like self-protection. Also, the user layer is attackable. If _you_ can access the private-keys, an attacker can do also. What most users want is a key-safe that only signs transactions which they could verify beforehand in a safe environment, and not a way to export private keys or something else that can touch the keys.\n\n\n\u003e\u003e They should never leave the device over the channel used for the signing I/O. Users should have no way to view or export the private keys (expect for the seed backup). 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\u003e \n\u003e Is there really nothing existing yet to address all of this?\n\nThe answer is probably: No (for now). But working towards this should be the focus.\n\n\n---\n/jonas\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170930/c2a58417/attachment.sig\u003e",
"sig": "256d7169c1590f796e375d64d3602d572c21780fb75365906e0d70bc92b81bcaf8304af2ed6b2d0d949ae42e0e70ce4224721505c48a859c0481a2ee91d0e770"
}