📅 Original date posted:2019-06-29
📝 Original message:В Sat, 29 Jun 2019 09:19:41 +0900
Jonathan Underwood <junderwood at 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)
Dmitry Petukhov [ARCHIVE] /
npub10r…9afdw
2023-06-07 18:18:53
in reply to nevent1q…6e7p
Author Public Key
npub10r66s2stvnancx9axwnfc5a34asjkwkgmkq7ztm5hf30x7fa4szsv9afdwPublished at
2023-06-07 18:18:53Event JSON
{
"id": "cfbf58b782c330cbd4a755e5d70b53fa43e77b2879b447cea3355f5cb3f3b916",
"pubkey": "78f5a82a0b64fb3c18bd33a69c53b1af612b3ac8dd81e12f74ba62f3793dac05",
"created_at": 1686161933,
"kind": 1,
"tags": [
[
"e",
"6dc430ad1a240d08cd6de3f78de0f3da923f2f5e843db09c88b3e0382b00b332",
"",
"root"
],
[
"e",
"470b16c5434db587084ce9f0f3bfe37ebb68d1bdf0acbbf8ccae0cf3ad6c862b",
"",
"reply"
],
[
"p",
"e999edd1a420e7d5e19be7870cbcfa798bb98cb408e5929a2a18181c8c6f1dee"
]
],
"content": "📅 Original date posted:2019-06-29\n📝 Original message:В Sat, 29 Jun 2019 09:19:41 +0900\nJonathan Underwood \u003cjunderwood at bitcoinbank.co.jp\u003e wrote:\n\n\u003e Though outside the scope of this BIP, one difficulty of a whitelist\n\u003e feature would be revocation of signatures. If we pre-sign a\n\u003e revocation cert and somehow make the wallet blacklist if seen... then\n\u003e the question is \"if your signer has a trustworthy store of state, why\n\u003e not store the whitelist pubkeys?\"\n\nIn principle, if the hardware wallet can permanently store at least one\ncounter, it can have rich state, stored externally. It would sign a\nstate stored in RAM, and give out the state + signature to the\nsupporting app. The state will include a serial number, corresponding to\nthe internal counter stored in the hardware wallet. Next time, the app\nwill give the signed state to the hardware wallet along with\ntransaction data. Hardware wallet checks its signature over the state,\nchecks that serial matches its internal counter, uses and modifies the\nstate, then updates the internal counter and the serial number of the\nstate, and gives out the signed new state to the app. If the app\nloses the state blob, though, there should be some mechanism to securely\noverride the hw wallet internal state.\n\nThis approach might have other limitations, as processing and storing\nbig enough state in the RAM of a resource-constrained device might\npresent a problem in itself.\n\nThe 'add serial to xpub-package' idea is in the same vein: you can\nstore this xpub-package serial inside the hw wallet directly, or inside\nits 'external rich state blob', but it can take only one byte (unlikely\nto need more than 255 xpub-package 'revocations', at that point you\nare probably OK to change your cold keys already)",
"sig": "d8e69ac3ee6cad1aaf3a38b96e045954a977e6b6364ce9d0e3ef42f9aa02c801c5ae12feebef07568c40a98d4c925d6dab14bd4f53ba64d38a412f4ddfe0a29e"
}