Show Posts
1
General Discussion / Bin backup format
« on: February 14, 2017, 11:07:02 pm »
I just wrote some code that decrypts and uncompresses the .bin file resulting from the backup procedure available at the Open Ledger, and have some comments and questions regarding this specific topic.
I would appreciate if other more informed parties can engage in a discussion here, and maybe that could help me expand the documentation about this feature, since I feel that it is somewhat lacking in that aspect.
First lets take a look at the resulting JSON string:
1- My first observation regarding this object is the replication of data in both the "public_name" and "id" fields. They are always the same. No matter what I do, I always seem to be getting the name of my wallet there. Which in this case just happened to be the same as my account name, but that is not necessarily always the case. Anyways I don't see the point of having 2 fields which always hold the same data.
2- The previous remak actually leads me to the second point, which is that it would be really useful to have the name of the account a key is referring to also stated here. I do recognize that the authority scheme can be more complex than just 1 key per account, and maybe this information was not included because of the desire to just keep things simple. But I don't see why the JSON object could not be expanded in order to accomodate a current snapshot of an account's authorities for instance.
3- There's also an issue with the "brainkey_sequence" field. I noticed it is being 1. It turns out that this account specifically was created outside of the web wallet with a key derivated using the sequence value of zero. This is suggesting me that the this field is not actually being dynamically generated. Or at least not for imported accounts. The "brainkey_sequence" was assumed to be 1 here, when in fact it was 0, and thus the information provided here is wrong.
4- Also there's the "private_keys" array. This field can also seem kind of redundant, since the information contained in the brainkey and brainkey_sequence can be very well be used to derive the encrypted key at the field called "encrypted_key". I say kind of, because I acknowledge situations where we might have just the private key and not an associated brain key, and we might be interested in store that into the bin backup. But my recommendation would be to use this field only for those specific cases.
5- And now my final point has to do with the "linked_accounts" field. This is a question actually (remember I told you I had one?
. I modified bilthon-25 to be controlled by bilthon-24, assuming that this would make the "linked_accounts" array have at least one element. But nothing happened here. So I'm in the dark with respect of what this field is actually supposed to have. Does anyone have any idea?
Best regards
Nelson R. Pérez
I would appreciate if other more informed parties can engage in a discussion here, and maybe that could help me expand the documentation about this feature, since I feel that it is somewhat lacking in that aspect.
First lets take a look at the resulting JSON string:
Code: [Select]
{
"wallet": [
{
"public_name": "bilthon-25",
"password_pubkey": "BTS7bq4tVD5CLBTPowT4WJJHmSh8YumfoDYMiZHiCzNWQMq8DcGFX",
"encryption_key": "9f95ca531a6750f3749ea8a2b70202bd59a9a051875608c04237cab3fda7f0c31129297a36af9c46f83a68713389a83d",
"encrypted_brainkey": "b71760d18703a7bba4c2525277dfedb9042aab58c71190deeb05bc90f2097bf634bc0533ac375395cfd0263cd3614abf22f90e53e7e7b88ca811f2b614ff053f60e9ec842bdd034adaa5f795e25c9615a6d9a60c73f03dc101c97bf7877d7897",
"brainkey_pubkey": "BTS5hfdU3ihm8wDPYuavWrGFopGySMcgEewmCDvTGPV29o14mtp7p",
"brainkey_sequence": 1,
"brainkey_backup_date": "2017-02-14T21:07:19.819Z",
"created": "2017-02-14T21:07:20.193Z",
"last_modified": "2017-02-14T21:07:20.699Z",
"chain_id": "4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8",
"id": "bilthon-25",
"backup_date": "2017-02-14T21:08:56.382Z"
}
],
"private_keys": [
{
"encrypted_key": "2ed26a282ae4ed06b594c91a352036d79a35c6c1a24d9d42523a74b5edde2c0f71155097cc9f6306a92a25ed2b846b83",
"pubkey": "BTS5ynSurmrfWj1HrF81wxaLuAtTbp4yxWDsZzc7b93XPEK4aiR1i",
"brainkey_sequence": 0,
"id": 1
}
],
"linked_accounts": []
}
All the sensitive information here is encrypted, so I guess there's no harm in publishing it here. And the referring account is just a test one with not much funds in it anyways.1- My first observation regarding this object is the replication of data in both the "public_name" and "id" fields. They are always the same. No matter what I do, I always seem to be getting the name of my wallet there. Which in this case just happened to be the same as my account name, but that is not necessarily always the case. Anyways I don't see the point of having 2 fields which always hold the same data.
2- The previous remak actually leads me to the second point, which is that it would be really useful to have the name of the account a key is referring to also stated here. I do recognize that the authority scheme can be more complex than just 1 key per account, and maybe this information was not included because of the desire to just keep things simple. But I don't see why the JSON object could not be expanded in order to accomodate a current snapshot of an account's authorities for instance.
3- There's also an issue with the "brainkey_sequence" field. I noticed it is being 1. It turns out that this account specifically was created outside of the web wallet with a key derivated using the sequence value of zero. This is suggesting me that the this field is not actually being dynamically generated. Or at least not for imported accounts. The "brainkey_sequence" was assumed to be 1 here, when in fact it was 0, and thus the information provided here is wrong.
4- Also there's the "private_keys" array. This field can also seem kind of redundant, since the information contained in the brainkey and brainkey_sequence can be very well be used to derive the encrypted key at the field called "encrypted_key". I say kind of, because I acknowledge situations where we might have just the private key and not an associated brain key, and we might be interested in store that into the bin backup. But my recommendation would be to use this field only for those specific cases.
5- And now my final point has to do with the "linked_accounts" field. This is a question actually (remember I told you I had one?
. I modified bilthon-25 to be controlled by bilthon-24, assuming that this would make the "linked_accounts" array have at least one element. But nothing happened here. So I'm in the dark with respect of what this field is actually supposed to have. Does anyone have any idea?Best regards
Nelson R. Pérez
