В Sat, 29 Jun 2019 09:19:41 +0900 Jonathan Underwood <junderw...@bitcoinbank.co.jp> wrote:
> Though outside the scope of this BIP, one difficulty of a whitelist > feature would be revocation of signatures. If we pre-sign a > revocation cert and somehow make the wallet blacklist if seen... then > the question is "if your signer has a trustworthy store of state, why > not store the whitelist pubkeys?" In principle, if the hardware wallet can permanently store at least one counter, it can have rich state, stored externally. It would sign a state stored in RAM, and give out the state + signature to the supporting app. The state will include a serial number, corresponding to the internal counter stored in the hardware wallet. Next time, the app will give the signed state to the hardware wallet along with transaction data. Hardware wallet checks its signature over the state, checks that serial matches its internal counter, uses and modifies the state, then updates the internal counter and the serial number of the state, and gives out the signed new state to the app. If the app loses the state blob, though, there should be some mechanism to securely override the hw wallet internal state. This approach might have other limitations, as processing and storing big enough state in the RAM of a resource-constrained device might present a problem in itself. The 'add serial to xpub-package' idea is in the same vein: you can store this xpub-package serial inside the hw wallet directly, or inside its 'external rich state blob', but it can take only one byte (unlikely to need more than 255 xpub-package 'revocations', at that point you are probably OK to change your cold keys already) _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
