From: Dmitry Petukhov <dp@simplexum•com>
To: Jonathan Underwood <junderwood@bitcoinbank•co.jp>
Cc: Bitcoin development mailing list <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)
Date: Sat, 29 Jun 2019 09:31:04 +0500 [thread overview]
Message-ID: <20190629093104.52f7a262@simplexum.com> (raw)
In-Reply-To: <CAMpN3m+Oa6oPzAmhoioOkuf8__NSPPNoSEMHJwo9PhjXosMwhg@mail.gmail.com>
В Sat, 29 Jun 2019 09:19:41 +0900
Jonathan Underwood <junderwood@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)
next prev parent reply other threads:[~2019-06-29 4:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-27 2:11 Jonathan Underwood
[not found] ` <20190627095031.4d5817b8@simplexum.com>
2019-06-27 5:07 ` Jonathan Underwood
[not found] ` <20190627122916.3b6c2c32@simplexum.com>
2019-06-27 8:16 ` Jonathan Underwood
[not found] ` <20190627134628.4d131264@simplexum.com>
[not found] ` <CAMpN3m+LiSW=kRCQio+C_2To66o_SEq-d_0Z122j+BUxvh=LDQ@mail.gmail.com>
2019-06-27 8:59 ` Jonathan Underwood
[not found] ` <20190627142120.2c24fddb@simplexum.com>
2019-06-27 9:32 ` Jonathan Underwood
2019-06-27 15:07 ` Peter D. Gray
2019-06-28 2:44 ` Jonathan Underwood
2019-06-28 14:37 ` Peter D. Gray
2019-06-28 15:00 ` Jonathan Underwood
[not found] ` <20190627144852.52c6d9e1@simplexum.com>
2019-06-27 9:52 ` Jonathan Underwood
[not found] ` <20190627181429.15dda570@simplexum.com>
2019-06-27 15:29 ` Dmitry Petukhov
2019-06-28 21:48 ` Dmitry Petukhov
2019-06-29 0:19 ` Jonathan Underwood
2019-06-29 4:31 ` Dmitry Petukhov [this message]
2019-06-29 4:46 ` Dmitry Petukhov
[not found] ` <20190629094512.558ce181@simplexum.com>
2019-06-29 8:11 ` Jonathan Underwood
2019-07-23 5:03 ` Jonathan Underwood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190629093104.52f7a262@simplexum.com \
--to=dp@simplexum$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=junderwood@bitcoinbank$(echo .)co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox