📅 Original date posted:2015-03-12
📝 Original message:Den 12 mar 2015 17:48 skrev "Mike Hearn" <mike at plan99.net>:
>>
>> b) "Creation date" is just a short-term hack.
>
>
> I agree, but we need things to be easy in the short term as well as the
long term :)
>
> The long term solution is clearly to have the 12 word seed be an
encryption key for a wallet backup with all associated metadata. We're
heading in that direction one step at a time. Unfortunately it will take
time for wallets to start working this way, and all the pieces to fall into
place. Restoring from the block chain will be a semi regular operation for
users until then.
This have been mentioned a few times before, and what I think is necessary
is to create a common file format that can be interpreted by a library
which all wallets can use. I see it as similar as the work to create
libconsensus for parsing the blockchain.
We need something extensible that can describe how to derive all addresses
used by the user. What HD branches to derive and how, with block numbers
(or bloom filters of block hashes or similar) to note where all previously
known transactions related to the wallet have occurred, and the last known
block (so only new blocks need to be scanned).
A way to describe one HD tree as a multisignature wallet tied to a hardware
wallet if you have that (could include serial number or MAC of the device
for simple identification by the wallet client). A way to describe another
set of addresses as using a custom extension. A way to denote one private
key as being used for stealth addresses together with details for how to
identify the transactions (prefix, mailbox to look in, etc). Labels for
transactions. P2SH script templates so those addresses can be recovered. A
way to describe Copay style multisignature wallets and what server to use
for coordinating with the other coowners. A way to describe threshold
crypto group signature wallets and how to coordinate. Computer parsable
descriptions of HD branches as change addresses, as being used for
receiving payments in merchant payment systems, etc... Also, you should
really be talking to people like accountants and auditors to see what
features they'd like to see when it comes to things like how company
wallets could have rules defined for how to use the various HD branches.
And so on... I think you get my point by now.
The basic idea is that the wallet uses the library to parse the wallet file
and tells the user which sections it understands (can't expect all wallets
to handle custom extensions or stealth addresses, etc), then proceeds to
scan the blockchain for those addresses. Then the user also won't be
surprised that not all funds are found and won't think they're lost.
I think it should be referred to as an import/export format, more than as a
backup format.
You always want the most recent metadata the wallet of origin can provide
when importing, to reduce unnecessary extra work. You don't want really old
backup files. If people add new seeds and various new extensions that can't
be automatically recovered from old wallet backups, they need new backups.
You might as well use the wallet's own internal formats for backup, as the
wallet developer might better know how to optimize for the use cases he
have designed for. But at the same time we should ask wallet developers to
offer conversion tools to generate export format files from custom wallet
data files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/8331a17a/attachment.html>;
Natanael [ARCHIVE] /
npub179…lpmjt
2023-06-07 15:31:33
in reply to nevent1q…v6xg
Author Public Key
npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjtPublished at
2023-06-07 15:31:33Event JSON
{
"id": "45c4775e14727f89271f8441c7e2af9e07601c1da3a40c4c9383c418885cf1f4",
"pubkey": "f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018",
"created_at": 1686151893,
"kind": 1,
"tags": [
[
"e",
"bf192ab1459041905386f8a0c7782f07de04af2932326a4e49fe0d6ce14ed93c",
"",
"root"
],
[
"e",
"f20a3301dbab06555c4dcc2bb97aa8fe9960e17901e2264c1a87e55b4e067771",
"",
"reply"
],
[
"p",
"91f69cdafb42e79d05623057c68f017374e590d6d540d9c60e22a6cae85cfe5b"
]
],
"content": "📅 Original date posted:2015-03-12\n📝 Original message:Den 12 mar 2015 17:48 skrev \"Mike Hearn\" \u003cmike at plan99.net\u003e:\n\u003e\u003e\n\u003e\u003e b) \"Creation date\" is just a short-term hack.\n\u003e\n\u003e\n\u003e I agree, but we need things to be easy in the short term as well as the\nlong term :)\n\u003e\n\u003e The long term solution is clearly to have the 12 word seed be an\nencryption key for a wallet backup with all associated metadata. We're\nheading in that direction one step at a time. Unfortunately it will take\ntime for wallets to start working this way, and all the pieces to fall into\nplace. Restoring from the block chain will be a semi regular operation for\nusers until then.\n\nThis have been mentioned a few times before, and what I think is necessary\nis to create a common file format that can be interpreted by a library\nwhich all wallets can use. I see it as similar as the work to create\nlibconsensus for parsing the blockchain.\n\nWe need something extensible that can describe how to derive all addresses\nused by the user. What HD branches to derive and how, with block numbers\n(or bloom filters of block hashes or similar) to note where all previously\nknown transactions related to the wallet have occurred, and the last known\nblock (so only new blocks need to be scanned).\n\nA way to describe one HD tree as a multisignature wallet tied to a hardware\nwallet if you have that (could include serial number or MAC of the device\nfor simple identification by the wallet client). A way to describe another\nset of addresses as using a custom extension. A way to denote one private\nkey as being used for stealth addresses together with details for how to\nidentify the transactions (prefix, mailbox to look in, etc). Labels for\ntransactions. P2SH script templates so those addresses can be recovered. A\nway to describe Copay style multisignature wallets and what server to use\nfor coordinating with the other coowners. A way to describe threshold\ncrypto group signature wallets and how to coordinate. Computer parsable\ndescriptions of HD branches as change addresses, as being used for\nreceiving payments in merchant payment systems, etc... Also, you should\nreally be talking to people like accountants and auditors to see what\nfeatures they'd like to see when it comes to things like how company\nwallets could have rules defined for how to use the various HD branches.\n\nAnd so on... I think you get my point by now.\n\nThe basic idea is that the wallet uses the library to parse the wallet file\nand tells the user which sections it understands (can't expect all wallets\nto handle custom extensions or stealth addresses, etc), then proceeds to\nscan the blockchain for those addresses. Then the user also won't be\nsurprised that not all funds are found and won't think they're lost.\n\nI think it should be referred to as an import/export format, more than as a\nbackup format.\n\nYou always want the most recent metadata the wallet of origin can provide\nwhen importing, to reduce unnecessary extra work. You don't want really old\nbackup files. If people add new seeds and various new extensions that can't\nbe automatically recovered from old wallet backups, they need new backups.\nYou might as well use the wallet's own internal formats for backup, as the\nwallet developer might better know how to optimize for the use cases he\nhave designed for. But at the same time we should ask wallet developers to\noffer conversion tools to generate export format files from custom wallet\ndata files.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/8331a17a/attachment.html\u003e",
"sig": "26061150943f693852cfedefd4ca43f6b5d6d8d42e3c3ba3d2baf88dfcce1cabf78730d0e4ff6ae984789c770e1c2d9e3fbba45552af28c282f1194a97a09976"
}