Topic: BIP 143 and Armory wallet format (Read 639 times)
Interesting, what's the new stuff? I remember recommending to etotheipi that some way to create a chain of multi-sig addresses using 2+ xpubs would be useful. Can fully see why you'd want to take time over designing the format, the timing right now whereby so much of the developmental roadmap is available means you could do a pretty consummate future proofing job, given enough opportunity.
Perhaps the separate container format is the true compromise then. (2) seems less attractive now that you bring up the backup issue.
It depends a great deal on how long we can expect to wait for Segwit activation (before the end of the year may be too optimistic, but we'll see), and then in turn how much of that time you will need to finish wallet 2.0. It's in your hands.
It depends a great deal on how long we can expect to wait for Segwit activation (before the end of the year may be too optimistic, but we'll see), and then in turn how much of that time you will need to finish wallet 2.0. It's in your hands.
The new wallets are complicated because of the amount of new stuff I want to cram in there. Just delivering BIP32 support is the matter of a day. But adding the features incrementally results in a constantly changing wallet format. I want it to be done once and for all so that makes things a bit more complicated.
Perhaps the separate container format is the true compromise then. (2) seems less attractive now that you bring up the backup issue.
It depends a great deal on how long we can expect to wait for Segwit activation (before the end of the year may be too optimistic, but we'll see), and then in turn how much of that time you will need to finish wallet 2.0. It's in your hands.
It depends a great deal on how long we can expect to wait for Segwit activation (before the end of the year may be too optimistic, but we'll see), and then in turn how much of that time you will need to finish wallet 2.0. It's in your hands.
Considering uncompressed keys will eventually become invalid for Segwit outputs anyway, (1) doesn't sound terrible.... although I'm aware that people like me with pre-existing wallets with alot of in-use addresses would feel that most. Sounds cheapest to implement. (3) sounds expensive, in contrast. Is (2) the compromise between user fatigue and developer fatigue? lol
1) is the only consistent solution, since backups won't convey the extra flag and legacy wallets can't carry compressed keys without significant changes.
2) is the intersection between the path of least resistance and lowest runtime resource requirement. Requires 1) as a backdrop for restored wallets.
3) is more expensive to implement than 2) but is immune to unforeseen snafus with unused fields. This is basically how lockboxes are implemented. The independent container can also be carried around with an optional expert feature to blanket compress all keys in case of a blind restore.
Ideally I don't want the old wallets to have any SW capacity. SW requires deep modifications to the signer and wallet format. My original plan was to force people to upgrade to the new wallet format if they want SW support and allow legacy branches to exists within the new wallets, i.e. importing your root key to the new wallet format would result in one Armory 1.35 derivation branch and any amount of BIP32 branches.
The issue with this new restriction on SW inputs is that now I either have to rush the new wallets out or extend the legacy wallet format. Or not offer SW at activation, which I'd rather avoid.
Considering uncompressed keys will eventually become invalid for Segwit outputs anyway, (1) doesn't sound terrible.... although I'm aware that people like me with pre-existing wallets with alot of in-use addresses would feel that most. Sounds cheapest to implement. (3) sounds expensive, in contrast. Is (2) the compromise between user fatigue and developer fatigue? lol
Any thoughts yet as to what issue/s could prevent the conversion working?
Addresses for compressed pubkeys differ from their uncompressed counterparts (the raw data is different thus the hash digest is different). The database tracks addresses by their hash160 value (the common representation in transaction outputs and what Armory uses to create recipient scripts).
For the DB to track addresses based on compressed pub keys, it needs the hashes for the compressed keys. The DB does not deal in public keys, only the client does. This means the client has to deliver hashes for compressed public keys.
---------
So far so good, complications start here:
I don't want to modify the existing wallet format for 2 reasons:
1) It's an age old code (in the Bitcoin sense) that has proven it's robustness. If it's not broken, I'm not gonna fix it.
2) Some people may want to stay away from SegWit for whatever reasons, one being they don't trust me to handle crypto related code (again, for whatever reasons).
In light of these reasons, I do not want to modify the existing wallet code. As a matter of fact, the current wallets are mostly implemented in Python, whereas the signer code I'm writing for SegWit and subsequent wallet format that will fully leverage that signer will be in C++. This will further the separation of these 2 mission critical sources. The new signer will be proxied into the existing wallet pipeline only for SW signing.
The legacy wallet code and signer will remain in Armory, and the new wallets and signer will coexist with it during a long phase where the new code will eventually be enabled by default. At first it will only operate when signing SW transactions, which the legacy signer is incapable of.
---------
To get back on topic, I do not want to modify the legacy wallet code to save compressed pubkey hashes. I am left with:
1) Either compute all compressed keys on the fly at each start. This is slow. Refer to the wallet consistency check progress bar to get an idea of how long it would take to compute all the compressed keys for all your wallets.
2) Flag the addresses that have been used for SegWit operations through unused fields in the address container format.
3) Design a companion file to hold the meta data.
4) Some other exotic solution.
I believe there will be a slight change to the current wallet format to include some meta data about whether that wallet will support segwit (and thus do this conversion).
Any thoughts yet as to what issue/s could prevent the conversion working?
I believe there will be a slight change to the current wallet format to include some meta data about whether that wallet will support segwit (and thus do this conversion).
Any thoughts yet as to what issue/s could prevent the conversion working?
https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#restrictions-on-public-key-type
The linked section in BIP143 sounds alot like any attempt to spend an Armory wallet output (held by uncompressed public keys) to a P2WPKH or P2WSH address will not be relayed by default policy. Does this mean that we may have to rely on miners who use non-standard relay policy to spend directly to P2WPKH or P2WSH addresses? There's also a suggestion that trying this carries a danger that could render the outputs unspendable when the native Segwit addresses are activated.
(I realise the new wallet format could be used as an intermediate step. Sounds expensive to me though....)
This has already been discussed and solved (mostly). At some point we will be moving to a new wallet format which supports BIP 32 and compressed keys. For now, what will happen is that the uncompressed keys will be dynamically converted to compressed keys for the creation of the scripts. I believe there will be a slight change to the current wallet format to include some meta data about whether that wallet will support segwit (and thus do this conversion). The linked section in BIP143 sounds alot like any attempt to spend an Armory wallet output (held by uncompressed public keys) to a P2WPKH or P2WSH address will not be relayed by default policy. Does this mean that we may have to rely on miners who use non-standard relay policy to spend directly to P2WPKH or P2WSH addresses? There's also a suggestion that trying this carries a danger that could render the outputs unspendable when the native Segwit addresses are activated.
(I realise the new wallet format could be used as an intermediate step. Sounds expensive to me though....)
https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#restrictions-on-public-key-type
The linked section in BIP143 sounds alot like any attempt to spend an Armory wallet output (held by uncompressed public keys) to a P2WPKH or P2WSH address will not be relayed by default policy. Does this mean that we may have to rely on miners who use non-standard relay policy to spend directly to P2WPKH or P2WSH addresses? There's also a suggestion that trying this carries a danger that could render the outputs unspendable when the native Segwit addresses are activated.
(I realise the new wallet format could be used as an intermediate step. Sounds expensive to me though....)
The linked section in BIP143 sounds alot like any attempt to spend an Armory wallet output (held by uncompressed public keys) to a P2WPKH or P2WSH address will not be relayed by default policy. Does this mean that we may have to rely on miners who use non-standard relay policy to spend directly to P2WPKH or P2WSH addresses? There's also a suggestion that trying this carries a danger that could render the outputs unspendable when the native Segwit addresses are activated.
(I realise the new wallet format could be used as an intermediate step. Sounds expensive to me though....)
Jump to: