replies in-line. Thanks!
2019年6月29日(土) 6:46 Dmitry Petukhov <d...@simplexum.com>:
> In your proposed field key format,
>
> {0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}
>
> I think you can replace the signing pubkey with just a fingerprint of
> the master key, that would save 29 bytes per 0x02 field.
>
Good point.
> If the only entity that is concerned about the validity of the
> signature is those that possess the signing_privkey, it will check the
> signature when it sees the 0x02 field starting with its own key
> fingerprint, and will ignore the field if the signature does not match.
>
> If someone other than the signer needs to check that this xpub-package
> was signed by certain cold key, it will need to know signing_pubkey
> anyway, before it parses PSBT, as it won't have the means to check if
> certain pubkey found in 0x02 field in PSBT is related to certain
> signer, without knowing anything about the pubkey beforehand.
>
> I'm not sure if the ability of unrelated parties to verify that
> xpub-package matches its signature is useful in practice. 29 bytes per
> 0x02 field is not a big saving of space, and if this ability is actually
> useful, the saving may not be worh loosing this ability.
>
All good points, I think we'll just use the first 4 bytes of the hash160 of
the pubkey, aka fingerprint.
> Other note: you have 'unused' value of 1 for `m` in your scheme, why
> not require m=1 for single-sig case, and use 0 as indicator that there
> are a serlal number following it?
>
0x00 is single sig, aka, OP_CHECKSIG
0x01 is multisig, aka, 1-of-3, 1-of-2 OP_CHECKMULTISIG
> The key for the field would be encoded as
>
> {0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}
>
> for usual case, and
>
> {0x02}|{signing_pubkey}|0x00|{serial}|{m}|{xpub}|...|{xpub}
>
> for the case when the signing scheme actually cares about different
> versions of xpub packages signed by certain cold key
>
since OP_CHECKMULTISIG only supports at most 15-of-15 due to stack item
size limitations, we could make 0xff into this serial marker.
> Going back to the idea of moving 'complex' usecases outside of BIP174:
> maybe we could have a 'BIP-specific' field, that would have the key as
>
> {0x0?}|{BIP-number}|{bip-specific-suffix-data}
>
> so that the different usecases that are not general enough to be
> included in BIP174 itself, may have their own BIPs. Vendor-specific
> fields may also be done as a separate BIP.
>
Definitely sounds good, but the currently proposed 0x01 global type is
being added to BIP174 directly under the assumption that it is useful for
all users of PSBT, and I would argue that 0x01 being an HD change verifying
method, it only seems logical to add a similar method of "verifying"
non-self keys, aka whitelisting for security purposes, and such a feature
would require this data be included into the PSBT sent into the device.
If the consensus is that this data is unneeded, 0x01 should probably also
be a separate BIP.
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?"
But that feature itself should be a separate BIP.
Also, POR_COMMITMENT being in BIP174 kind of set a precedent... :-/
> В Thu, 27 Jun 2019 20:29:32 +0500
> Dmitry Petukhov <d...@simplexum.com> wrote:
>
> > Oh, I saw that you covered it in another mail:
> >
> > > The expire / revoke problem is a larger problem than this feature
> > > can handle.
> >
> > > In general, if one of the cold keys is stolen, there is rarely a
> > > situation where you are completely sure the other cold keys haven't
> > > been compromised... so the best practice would be all signers
> > > generate new keys and all funds are moved to a completely new
> > > multisig wallet (no common xpubs).
> >
> > The setup might not be 'all cold keys', but the keys with different
> > levels of exposure to possible theft. In this config, compromise of
> > one of the 'warm' keys might not necessary require changing the
> > 'cold' key.
> >
> > I'm not sure whether this usecase warrants adding extra 'serial'
> > field, but on the other hand it is rather simple change, and those who
> > does not care can always set 0.
> >
> > В Thu, 27 Jun 2019 18:14:29 +0500
> > Dmitry Petukhov <d...@simplexum.com> wrote:
> >
> > > What do you think about adding serial number to the xpub package ?
> > >
> > > The key would be
> > >
> > > {0x02}|{signing_pubkey}|{serial}|{m}|{xpub}|...|{xpub}
> > >
> > > and if the signer have the ability to store a counter, it can reject
> > > 'outdated' xpub packages, and only accept those that was signed
> > > using the serial number that it deems recent. This would allow a
> > > limited mechanism to 'revoke' previously signed packages that have
> > > compromized keys in them.
> > >
> > > В Thu, 27 Jun 2019 17:16:14 +0900
> > > Jonathan Underwood <junderw...@bitcoinbank.co.jp> wrote:
> > >
> > > > I see what you mean.
> > > >
> > > > What about this?
> > > >
> https://github.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd719148e3027e?short_path=82656c8#diff-82656c833e31e6751a412ce5e5c70920
> > > >
> > > > Plus side: for single sig case, the key only increases by one byte
> > > > (0x00 for the {m} value)
> > > >
> > > > This way if it was 2 of 3 like before, you sign the whole "packet"
> > > > so each key only signs the packet once. Way better than n!
> > > >
> > > > Anywho. Please send your feedback. Thanks.
> > > > Jonathan
> > > >
> > > > 2019年6月27日(木) 16:27 Dmitry Petukhov <d...@simplexum.com>:
> > > >
> > > > > How would signer know that there _should_ be at least 3
> > > > > signatures signed by the key owned by this signer ?
> > > > >
> > > > > If it does not know that it should enforce 2of3 multisig, for
> > > > > example, the attacker that control only one key A can fool
> > > > > signer B by sending to 1of1 single-sig that is derived from A's
> > > > > xpub, and providing only sBxA in PSBT.
> > > > >
> > > > > If the signer does not have a hardcoded configuration that
> > > > > will mandate a particular multisig scheme, it will allow sending
> > > > > to any scheme.
> > > > >
> > > > > If the signer has a rich enough state to store updatable
> > > > > configuration, it can just store the trusted xpubs directly.
> > > > >
> > > > > Alternatively, signer can sign not individual xpubs, but whole
> > > > > xpub packages that correspond to particular multisig
> > > > > configuration, and enforce that destination addresses correspond
> > > > > to this configuration.
> > > > >
> > > > > But this would not be possible with your PSBT scheme that uses
> > > > > individual key-xpub pairs.
> > > > >
> > > > > В Thu, 27 Jun 2019 14:07:47 +0900
> > > > > Jonathan Underwood <junderw...@bitcoinbank.co.jp> wrote:
> > > > >
> > > > > > Thanks for the reply.
> > > > > >
> > > > > > The way we would do it is:
> > > > > >
> > > > > > Let's say we have 3 cold keys for multisig: A B and C
> > > > > >
> > > > > > Whose xpubs are: xA xB and xC
> > > > > >
> > > > > > We all sign each other's xpubs, whose signatures are:
> > > > > > sAxB
> > > > > > sAxC
> > > > > > sBxA
> > > > > > sBxC
> > > > > > sCxA
> > > > > > sCxB
> > > > > >
> > > > > > We can then create a wallet that says "when verifying change
> > > > > > with 0x01 global type proposed by Andrew Chow, if the change
> > > > > > is multisig, we MUST require the other pubkeys to have
> > > > > > signatures via my 0x02 proposal"
> > > > > >
> > > > > > This way, all my PSBTs for my cold will have:
> > > > > > 1. an 0x01 entry to tell me how to get my change.
> > > > > > 2. All 6 of the signatures above.
> > > > > >
> > > > > > And the signer will then look at the change, check my pubkey
> > > > > > by deriving the xpub and checking equality to the
> > > > > > BIP_DERIVATION of the output... it will then check the OTHER
> > > > > > pubkeys via BIP32_DERIVATION to master fingerprint, then link
> > > > > > that fingerprint to a 0x02 sig from MY key, verifying all
> > > > > > pubkeys.
> > > > > >
> > > > > > So this proposal of mine would not only fix the "send to
> > > > > > address verification" problem for HD, but also the multisig
> > > > > > change problem with 0x01.
> > > > > >
> > > > > > Cool.
> > > > > >
> > > > > > Only thing that is kind of sad is having to include n! (of
> > > > > > m-of-n) signatures in every PSBT... but tbh, the PSBT size is
> > > > > > not of much concern.
> > > > > >
> > > > > > Thanks for the reply.
> > > > > > - Jonathan
> > > > > >
> > > > > >
> > > > > > 2019年6月27日(木) 13:49 Dmitry Petukhov <d...@simplexum.com>:
> > > > > >
> > > > > > > Hi!
> > > > > > >
> > > > > > > I wonder how your scheme handles multisig ?
> > > > > > >
> > > > > > > As I understand, you sign individual xpubs with cold keys,
> > > > > > > so that cold keys can check destination addresses are
> > > > > > > trusted.
> > > > > > >
> > > > > > > I seems to me that if you sign individual xpubs of a
> > > > > > > multisig warm wallet, and one key from that multisig is
> > > > > > > compromized, attackers can then create a single-sig
> > > > > > > destination address that they control, and move the coins
> > > > > > > in a chain of two transactions, first to this single-sig
> > > > > > > address, and then to an address that they independently
> > > > > > > control.
> > > > > > >
> > > > > > > My idea to prevent this [1] is to sign the whole 'xpub
> > > > > > > package' of the multisig wallet, but there is also an issue
> > > > > > > of 'partial compromize', where some of the keys in a
> > > > > > > multisig warm wallet is compromized, and you do not want to
> > > > > > > regard a particular 'xpub package' as trusted. My idea was
> > > > > > > [2] to use an auxiliary message that would be signed along
> > > > > > > with the 'xpub package', and that message can include
> > > > > > > specific 'epoch' word that hardware wallet can show
> > > > > > > prominently before signing, or have 'serial number' for
> > > > > > > xpub packages (but that will require to store last known
> > > > > > > serial inside hw wallet, making it stateful).
> > > > > > >
> > > > > > > I like the idea to extend PSBT to accomodate these schemes,
> > > > > > > but given that the huge number of possible schemes that each
> > > > > > > may probably require its own PSBT field type, I think that
> > > > > > > this is better dealt with outside of PSBT, as 'PSBT
> > > > > > > metainformation', or using some form of 'vendor-specific',
> > > > > > > or 'metainformation-specific' PSBT field. This way each
> > > > > > > usecase can be independently described in its own
> > > > > > > documentation, that would include the particulars of the
> > > > > > > format for the metainformation. This would also make it
> > > > > > > easier to implement PSBT for simple cases, because the
> > > > > > > 'core specification' would not grow that big.
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > > >
> > > > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html
>
> > > > > > >
> > > > > > > [2]
> > > > > > >
> > > > > > >
> > > > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.html
>
> > > > > > >
> > > > > > >
> > > > > > > В Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via
> > > > > > > bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > > Hello all,
> > > > > > > >
> > > > > > > > Just wanted to pick your brains about an idea for PSBT
> > > > > > > > extension.
> > > > > > > >
> > > > > > > > One problem we try to solve with cold -> warm and warm ->
> > > > > > > > hot sends for our exchange wallet is "How do I know that
> > > > > > > > the address I am sending to is not a hacker's address
> > > > > > > > that was swapped in between unsigned tx creation and first
> > > > > > > > signature?"
> > > > > > > >
> > > > > > > > We have a proprietary JSON based encoding system which we
> > > > > > > > are looking to move towards PSBT, but PSBT is missing this
> > > > > > > > key functionality.
> > > > > > > >
> > > > > > > > BIP32_DERIVATION does allow us to verify the address is
> > > > > > > > from a certain XPUB, but, for example, it can not allow us
> > > > > > > > to verify a signature of that xpub.
> > > > > > > >
> > > > > > > > I have made a rough draft of the proposed key value
> > > > > > > > specification.
> > > > > > >
> > > > >
> https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification
> > > > >
> > > > > > > >
> > > > > > > > The signing key path used in the spec is just randomly
> > > > > > > > chosen 31 x 4 bits shown as numbers with hardened paths.
> > > > > > > >
> > > > > > > > Since this issue seems similar to the change address
> > > > > > > > issue, I started from that as a base. With the HW wallet
> > > > > > > > case, I can verify the xpub by just deriving it locally
> > > > > > > > and comparing equality, however, in our case, we need to
> > > > > > > > verify an xpub that we do not have access to via
> > > > > > > > derivation from our cold key(s) (since we don't want to
> > > > > > > > import our warm private key into our cold signer)
> > > > > > > >
> > > > > > > > So the flow would be:
> > > > > > > > 1. Securely verify the xpub of the warm / hot wallet.
> > > > > > > > 2. Using the airgap signing tool, sign the xpub with all
> > > > > > > > cold keys. 3. Upload the signature/xpub pairs to the
> > > > > > > > online unsigned transaction generator.
> > > > > > > > 4. Include one keyval pair per coldkey/xpub pairing.
> > > > > > > > 5. When offline signing, if the wallet detects there is a
> > > > > > > > global keyval XPUB_SIGNATURE with its pubkey in the key,
> > > > > > > > it must verify that all outputs have BIP32_DERIVATION and
> > > > > > > > that it can verify the outputs through the derivation, to
> > > > > > > > the xpub, and to the signature.
> > > > > > > >
> > > > > > > > In my attempt to fitting this into PSBT, I am slightly
> > > > > > > > altering our current system, so don't take this as an
> > > > > > > > indication 100% of how we work in the backend.
> > > > > > > >
> > > > > > > > However, I would like to hear any feedback on this
> > > > > > > > proposal.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Jonathan
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
