<unnamed>

Public Key

npub1axv7m5dyyrnatcvmu7rse0860x9mnr95prje9x32rqvperr0rhhqp0ftr0

Profile Code

nprofile1qqswnx0d6xjzpe74uxd70pcvhna8nzae3j6q3evjng4psxqu33h3mmspzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgs3elly

Publishing to

relay.primal.net

Last Notes

2023-06-09 12:48:32 UTC

- reply

📅 Original date posted:2018-01-13
📝 Original message:
Hey everybody.
Say that the last time we updated channel state, we assumed 40 satoshi/byte
was enough to get confirmed, then I leave the channel for a few weeks, come
back to find my partner fell off the face of the internet.
I perform unilateral close with my output on CSV timelock... but it turns
out there’s 500 MB of txes at around 100 satoshi/byte and lets say my
transaction will never get confirmed at 40 sat/byte.
What course of action can I take?
1. to_local output can't be redeemed until the commitment transaction
(which will "never confirm") is confirmed + the CSV timeout.
2. to_remote output probably won't be redeemed as the other person is
offline.
The only remedy I can think of is hope that the other person comes back
online and CPFPs your to_remote output for you... but at that point it
would be better for them to just amicably close with normal outputs... so
basically your only hope is wait for other person to come online.
Since CSV will cause script verification to fail, a CPFP transaction will
not be propagated.
If we can't CPFP, the CSV timer won't start (it starts once the CSV
containing output is confirmed).
Seems like a problem.
Anyone have any solutions?
Thanks,
Jon
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180114/0fc7a441/attachment.html>

2023-06-07 18:19:40 UTC

- reply

📅 Original date posted:2019-07-23
📝 Original message:Hello All,
I have made a pull request based on the discussion currently. Please move
discussion there.
https://github.com/bitcoin/bips/pull/801
Thanks,
Jonathan
2019年6月29日(土) 17:11 Jonathan Underwood <junderwood at bitcoinbank.co.jp>:
> Even if the difference is apparent outside the signed data (in the
> output). Signing the data explicitly is more secure.
>
> ie. if some sort of vulnerability / way to break this system for 1-of-1
> multisig is found, someone who signed a single sig xpub whitelist will not
> be exposed.
>
> 2019年6月29日(土) 13:43 Dmitry Petukhov <dp at simplexum.com>:
>
>> В Sat, 29 Jun 2019 09:19:41 +0900
>> Jonathan Underwood <junderwood at bitcoinbank.co.jp> пишет:
>>
>> > > 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
>>
>> This informatin is available in per-output redeem/witness script,
>> signer will be able to distinguish between multisig/single-sig by
>> looking at this script. I think it only need to know the total number
>> of keys participating in the signing, and check that this number
>> matches the particulars of redeem/witness script.
>>
>
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190723/3a6f2496/attachment-0001.html>

2023-06-07 18:19:17 UTC

- reply

📅 Original date posted:2019-07-09
📝 Original message:Hi all,
Just to be brief, I'll kick off with an attack scenario.
1. I am a signer, I get a PSBT that is ready to sign. I parse. I sign
according to the PSBT as-is.
2. I notice my UTXO was stolen by a hacker because they changed my PSBT
input's sighashtype to SIGHASH_ANYONECANPAY | SIGHASH_NONE and after the
fact they changed the outputs to send to themselves, and added an input
they signed with SIGHASH_ALL.
3. I lose the BTC in my UTXO.
So we should definitely add to the signer checks "ensure the sighash type
given is the type of sighash you want to sign." etc.
My proposal for a wording change would be addition to the bullet list:
- If a sighash type is provided, the signer MUST check that the sighash
type is acceptable to them, and fail signing if unacceptable.
- If a sighash type is not provided, the signer SHOULD sign using
SIGHASH_ALL, but may sign with any sighash type they wish.
Any thoughts?
Thanks,
Jon
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190710/60601766/attachment.html>

2023-06-07 18:18:49 UTC

- reply

📅 Original date posted:2019-06-27
📝 Original message:> By the way, why is this particular path ?
The signing key path used in the spec is just randomly chosen 31 x 4 bits
shown as numbers with hardened paths. Just wanted to make sure it wasn't a
key that people are likely to use for something else.
> It is not clear to me what public key this refers to
I just used the same sentence from the other proposal for 0x01 global tag.
It is kind of confusing, but "can be derived" implies that it is referring
to an xpub, since normal public keys can not "derive children"...
But I could change it if it would be clearer.
2019年6月27日(木) 18:47 Dmitry Petukhov <dp at simplexum.com>:
> " It should be the public key at the highest hardened derivation index
> so that the unhardened child keys used in the transaction can be
> derived."
>
> It is not clear to me what public key this refers to - does this
> refer to 'signing pubkey' ? - then the exact derivation indexes for that
> are given in the value section:
>
> m/2042083607'/959190427'/1400854130'/990526201'
>
> By the way, why is this particular path ?
>
> В Thu, 27 Jun 2019 17:16:14 +0900
> Jonathan Underwood <junderwood at 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 <dp at 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 <junderwood at 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 <dp at 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 at 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
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/e247bc0d/attachment.html>

2023-06-07 18:18:49 UTC

- reply

📅 Original date posted:2019-06-28
📝 Original message:Thanks for the reply Peter. Comments inline:
2019年6月28日(金) 23:37 Peter D. Gray <peter at coinkite.com>:
> Thanks I get the idea better now: You want the PSBT creator to be
> able to indicate to the signers that it (the PSBT creator) controls
> specific outputs that don't otherwise look like change.
>
> Some problems:
>
> > extended private key of the current signer derived from the
> > signer's root to m/2042083607'/959190427'/1400854130'/990526201'
>
> 1) The PSBT creator would need to know that private key, and the Coldcard,
> as a matter
> of policy, will never export a private subkey.
>
I think you have misunderstood. The signature inserted into this 0x02 field
is generated BY the signer (Coldkey) airgapped ahead of time. Then the
signature (and all the xpubs that were signed, since basically the "key"
value contains the "pubkey" and "message" while the "value" part has the
"signature". so all data items for verification are present.) will be
stored on the unsigned transaction preparing app. (MyTrezor dot com etc.
have an encrypted storage through Dropbox + encrypting with Trezor, so
they, for instance, could store the "whitelist signatures" on that dropbox
feature.
> 2) The 'm' in that path depends on who is reading the PSBT file, in the
> multisig
> case. Each cosigner would need a different version of the PSBT file
Again, this is the m of the signer's root. The signer should have an xprv,
or some sort of seed (a la BIP39 or aezeed or Electrum phrase etc.) that
gets turned into a xprv. That xprv is m in this case... in the case that
some offline signer is storing the xprv of some path like "xprv/25'/42'" or
something, then the signer's "identity" is whatever xprv that signer holds
and not any of the xprvs derived from that first xprv.
The reason we want only one HD key to sign it is because we want the signer
to be able to generate that path from the root xprv they hold, check that
the pubkey matched the pubkey for verification, then verify. Now the signer
knows "oh, I have signed this xpub / multisig setup before, therefore I
trust it"
> 3) XPUB's are big and hard to parse, and this addition is using lots of
> them.
>
Any app requiring this level of security would gladly add a few millisecond
for parsing some xpubs.
Any HD wallet that can sign using HD derived keys already has the necessary
tools to parse an xpub.
> 4) Coinjoins, and more complex script types, will want to authorize
> outputs that the PSBT signer may not fully understand. Your proposal
> would only help P2PKH and M-of-N multisig users.
>
Yes. This proposal is not a requirement. It is just a reservation for a
slot in the key-value scheme for a use case that many exchanges and
hardware wallets should implement. We have implemented something similar to
this using JSON format internally, but since HW wallet makers seem to be
moving toward PSBT adoption, I would love for this info to be possible to
be sent into an HW wallet so that Trezor etc. can implement this
"whitelist" type situation in a way that the Trezor can trust. (remember, a
"whitelist" that just lives in my trezor dot com website cache etc. is
prone to modification, whereas with my proposal the worst case is a hacker
deletes a signature, so Trezor doesn't trust something it should have, and
fails signing. It can not add itself to the "whitelist" without the HW
wallet private key.)
To fix, may I propose:
>
>
The following suggestions seems to be predicated on a misunderstanding of
my proposal, so I will hold off for now.
> - the signer and PSBT creator must share a pubkey/private key out of band
> (setup time)
> - the origin of that key is out of scope of this standard (but it could be
> derived via BIP32)
> - the PSBT creator can, optionally, sign any or all output sections by
> number using that key
>
> I would prefer the signatures are in the global section, and the
> signature is over all the bytes in the indicated output section,
> as originally serialized when it came into the signer's possession.
>
> We should be able to support multiple signers for individual outputs,
> and also multiple signatures for the same output section. That would
> support different derived keys per co-signer, and also quorum
> approval or other policies like that.
>
> Afterthought: Might be good to allow signature over the unsigned
> transaction, or
> maybe it should be part of the signature always.
>
> ---
> Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG:
> A3A31BAD 5A2A5B10
>
> On Fri, Jun 28, 2019 at 11:44:15AM +0900, Jonathan Underwood wrote:
> > Hi Peter,
> >
> > tl;dr The problem this solves is "How can a signer verify an address with
> > HD changing the address every time?"
> >
> > As an aside: (This is sort of explaining the current PR for the 0x01
> global
> > field (separate from mine))
> > The problem is more easily understood with change addresses: If someone
> can
> > alter my PSBT before signing, they could replace my change address with
> > their address, and my signer would not know unless the signer just
> guesses
> > all the path sets it knows, then derives thousands of change addresses
> and
> > searches (most likely a signer is offline, so gap limit doesn't work
> since
> > we can't tell which change addresses have tx history. So the 0x01 global
> > tag will tell the signer "here's how you get from your master private key
> > to the xpub used in the change output's output BIP32_DERIVATION tag...
> you
> > can then derive the same key and check it is yours before signing."
> >
> > Back to my proposal, this problem extends across wallets, since,
> > for example, if I want to send from my cold wallet to my warm wallet, I
> > don't want to give my cold signer my warm master key just so it can
> derive
> > and check the key. That's what signatures are for. So this proposal says
> "A
> > signer can be built to only sign if it sees a signature that itself has
> > signed, then from that signed xpub(s) derives the BIP32_DERIVATION in the
> > outputs, and if the output doesn't match it will reject and not sign"
> >
> > This creates a sort of "chain of trust" for the wallet.
> >
> > Currently the best way to prevent this (hacker swapping the send to
> > address) without using signatures is to reuse the same address every time
> > you want to send to the warm wallet, since after a few times, the signers
> > (people) will be able to remember the address.
> >
> > This is a huge HD drawback for high security requirement environments.
> > Having this data in the PSBT standard will allow Trezor etc. to create an
> > enforceable whitelist feature.
> >
> > Let me know if you have feedback on the details.
> >
> > Thanks,
> > Jon
> >
> > 2019年6月28日(金) 0:07 Peter D. Gray <peter at coinkite.com>:
> >
> > > I haven't studied the new proposal in depth, but my first impression
> is:
> > >
> > > Wouldn't it just be easier and better to just sign the entire "outputs"
> > > section of the PSBT?
> > >
> > > The signature would cover every byte, and therefore would cover any
> > > future BIP additions to the outputs area, and also help non-multisig
> > > cases today.
> > >
> > > ---
> > > Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG:
> > > A3A31BAD 5A2A5B10
> > >
> > >
> >
> > --
> > -----------------
> > Jonathan Underwood
> > ビットバンク社チーフビットコインオフィサー
> > -----------------
> >
> > 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
> >
> > 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190629/4b55a1c7/attachment-0001.html>

2023-06-07 18:18:48 UTC

- reply

📅 Original date posted:2019-06-27
📝 Original message:Hi Peter,
tl;dr The problem this solves is "How can a signer verify an address with
HD changing the address every time?"
As an aside: (This is sort of explaining the current PR for the 0x01 global
field (separate from mine))
The problem is more easily understood with change addresses: If someone can
alter my PSBT before signing, they could replace my change address with
their address, and my signer would not know unless the signer just guesses
all the path sets it knows, then derives thousands of change addresses and
searches (most likely a signer is offline, so gap limit doesn't work since
we can't tell which change addresses have tx history. So the 0x01 global
tag will tell the signer "here's how you get from your master private key
to the xpub used in the change output's output BIP32_DERIVATION tag... you
can then derive the same key and check it is yours before signing."
Back to my proposal, this problem extends across wallets, since,
for example, if I want to send from my cold wallet to my warm wallet, I
don't want to give my cold signer my warm master key just so it can derive
and check the key. That's what signatures are for. So this proposal says "A
signer can be built to only sign if it sees a signature that itself has
signed, then from that signed xpub(s) derives the BIP32_DERIVATION in the
outputs, and if the output doesn't match it will reject and not sign"
This creates a sort of "chain of trust" for the wallet.
Currently the best way to prevent this (hacker swapping the send to
address) without using signatures is to reuse the same address every time
you want to send to the warm wallet, since after a few times, the signers
(people) will be able to remember the address.
This is a huge HD drawback for high security requirement environments.
Having this data in the PSBT standard will allow Trezor etc. to create an
enforceable whitelist feature.
Let me know if you have feedback on the details.
Thanks,
Jon
2019年6月28日(金) 0:07 Peter D. Gray <peter at coinkite.com>:
> I haven't studied the new proposal in depth, but my first impression is:
>
> Wouldn't it just be easier and better to just sign the entire "outputs"
> section of the PSBT?
>
> The signature would cover every byte, and therefore would cover any
> future BIP additions to the outputs area, and also help non-multisig
> cases today.
>
> ---
> Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG:
> A3A31BAD 5A2A5B10
>
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190628/eee0ccf7/attachment.html>

2023-06-07 18:18:47 UTC

- reply

📅 Original date posted:2019-06-27
📝 Original message:There is no need, as you can look at the number of xpubs and use that as n.
Your wallet will not allow {m=2}{xpub1}{xpub2} signed message to vouch for
2 of 4 because you signed 2 of 2 where the n is shown by the number of
xpubs signed.
There is no need to add the extra byte, except maybe to help people who are
implementing a wallet checking some features to remember to check for the
number of total keys.
----
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).
- Jonathan
2019年6月27日(木) 18:20 Dmitry Petukhov <dp at simplexum.com>:
> You're right re order of the keys, I forgot that redeem/witness
> scripts are included in outputs.
>
> But regarding the number of the keys, you need to always include all of
> xpubs, because otherwise, if you only put `m` in PSBT, and you use
> 2of3, for example, attacker may put 2 as `m`, two of your xpubs, but
> then use redeem/witness scripts for 2of4, where two other keys are
> under attacker's control.
>
> If you only encode `n`, and allow any 'm of n' scheme, then in 2of3
> case, if the attackers have control of only one of the keys, they can
> use redeem/witness scripts for 1of3, where two other keys are under
> their control.
>
> It seems to me that you need to sign the whole configuration:
> `n`, `m`, and the xpubs.
>
> And then there's a question of how to conveniently `expire` the keys
> that were compromized. If the attackers have a signature of
> `n+n+xpubs` package for some configuration that include the keys that
> was compromized, they can use that old signed package to fool the
> signer.
>
> Signer would need to somehow distinguish between old and new
> configurations, or you would need to change the keys in all the signers
> even if one is compromized, so the already-signed packages would become
> invalid.
>
> You could do without changing all the keys when only one is compromized
> by including a serial number in the xpub package (but that means signer
> will need to have a state where it would store the latest serial
> number), or you need some message to be included in the package that a
> human can check when manually signing, to ensure that 'obsolete' xpub
> package was not used.
>
> В Thu, 27 Jun 2019 17:56:06 +0900
> Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
>
> > The output will have redeemscript and witnessscript so order is not
> > necessary. I can just look at the multisig script and find the pubkey
> > inside it.
> >
> > -Jonathan
> >
> > 2019年6月27日(木) 17:45 Dmitry Petukhov <dp at simplexum.com>:
> >
> > > > m value for a multisig (set 0 for non-multisig), followed by 1 or
> > > > more 78 byte serialized extended public keys sorted in canonical
> > > > order
> > >
> > > Sorting xpubs would work if the addresses also sort their pubkeys
> > > (like in BIP67)
> > >
> > > But if the pubkey order in address creation is fixed, you better
> > > have the fixed order for xpubs, otherwise you would need to try all
> > > combinations of derived pubkeys when checking if the addresss match
> > > the presented xpubs. That would be factorial of the number of keys,
> > > not feasible beyond very small number of keys.
> > >
> > > Bitcoin Core, for example, currently does not support BIP67 and
> > > supports only fixed pubkey positions in their script descriptors
> > > specification.
> > >
> > > You also need to include all xpubs to match the address, for m of n
> > > standard multisig, you need to include n and check that number of
> > > keys is exactly n.
> > >
> > > Otherwise your would not be able to construct the address to
> > > compare to the destination address that you need to check, as you
> > > need all pubkesy to construct P2SH or P2WSH address.
> > >
> > > With Shnorr-musig, you probably can interpolate the combined pubkey
> > > out of m paticpant pubkeys (but don't cite me on this, I might be
> > > wrong)
> > >
> > > В Thu, 27 Jun 2019 17:16:14 +0900
> > > Jonathan Underwood <junderwood at 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 <dp at 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 <junderwood at 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 <dp at 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 at 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
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/6e5ce627/attachment-0001.html>

2023-06-07 18:18:46 UTC

- reply

📅 Original date posted:2019-06-27
📝 Original message:When I say order is not necessary I mean, I won't have to brute force order.
Either way, if we don't sort the xpubs in the key, it would be possible to
create multiple key value pairs for essentially the same group of pubkeys.
"I only want to sign if the multisig is in this order" is pointless.
And like I said, output PSBT includes redeemscript and witnessscript, so my
app can just say "if no redeemscript or witnessscript or BIP32_DERIVATION
for the output, fail"
- Jonathan
2019年6月27日(木) 17:56 Jonathan Underwood <junderwood at bitcoinbank.co.jp>:
> The output will have redeemscript and witnessscript so order is not
> necessary. I can just look at the multisig script and find the pubkey
> inside it.
>
> -Jonathan
>
> 2019年6月27日(木) 17:45 Dmitry Petukhov <dp at simplexum.com>:
>
>> > m value for a multisig (set 0 for non-multisig), followed by 1 or
>> > more 78 byte serialized extended public keys sorted in canonical
>> > order
>>
>> Sorting xpubs would work if the addresses also sort their pubkeys (like
>> in BIP67)
>>
>> But if the pubkey order in address creation is fixed, you better have
>> the fixed order for xpubs, otherwise you would need to try all
>> combinations of derived pubkeys when checking if the addresss match the
>> presented xpubs. That would be factorial of the number of keys, not
>> feasible beyond very small number of keys.
>>
>> Bitcoin Core, for example, currently does not support BIP67 and supports
>> only fixed pubkey positions in their script descriptors specification.
>>
>> You also need to include all xpubs to match the address, for m of n
>> standard multisig, you need to include n and check that number of keys
>> is exactly n.
>>
>> Otherwise your would not be able to construct the address to compare to
>> the destination address that you need to check, as you need all pubkesy
>> to construct P2SH or P2WSH address.
>>
>> With Shnorr-musig, you probably can interpolate the combined pubkey out
>> of m paticpant pubkeys (but don't cite me on this, I might be wrong)
>>
>> В Thu, 27 Jun 2019 17:16:14 +0900
>> Jonathan Underwood <junderwood at 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 <dp at 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 <junderwood at 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 <dp at 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 at 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
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> >
>>
>>
>
> --
> -----------------
> Jonathan Underwood
> ビットバンク社チーフビットコインオフィサー
> -----------------
>
> 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
>
> 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/c0a55da6/attachment-0001.html>

2023-06-07 18:18:45 UTC

- reply

📅 Original date posted:2019-06-26
📝 Original message: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
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/82c9ecc0/attachment.html>

2023-06-07 18:18:45 UTC

- reply

📅 Original date posted:2019-06-27
📝 Original message: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 <dp at 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 at 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
> >
>
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/14367388/attachment-0001.html>

2023-06-07 18:18:45 UTC

- reply

📅 Original date posted:2019-06-27
📝 Original message: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 <dp at 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 <junderwood at 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 <dp at 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 at 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
> > > >
> > >
> > >
> >
>
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/30b46b5a/attachment-0001.html>

2023-06-07 18:15:12 UTC

- reply

📅 Original date posted:2018-11-09
📝 Original message:> as it seems bad design to have to fix and maintain a wordlist for every
language as the checksum depends on it.
>From BIP39:
> The conversion of the mnemonic sentence to a binary seed is completely
independent from generating the sentence. This results in rather simple
code; there are no constraints on sentence structure and clients are free
to implement their own wordlists or even whole sentence generators,
allowing for flexibility in wordlists for typo detection or other purposes.
>
> Although using a mnemonic not generated by the algorithm described in
"Generating the mnemonic" section is possible, this is not advised and
software must compute a checksum for the mnemonic sentence using a wordlist
and issue a warning if it is invalid.
So BIP39 states "no constraints on sentence structure and clients are free
to implement their own wordlists or even whole sentence generators" and yet
at the same time one paragraph later "this is not advised and software must
compute a checksum for the mnemonic sentence using a wordlist and issue a
warning if it is invalid"...
My interpretation of this:
1. ChecksumCheck function attempts to 1. find the wordlist 2. calculate the
checksum.
2. If it fails to find the wordlist, return false
3. If the checksum doesn't match return false
4. If ChecksumCheck returns false, "issue a warning" but do not block seed
generation. "We couldn't check if your phrase is correct... you're on your
own"
99.99% of implementing apps interpretation: (remember, error handling for
userspace is not done by the BIP39 library, but the app that uses it)
1. Run ChecksumCheck
2. If False, hard fail, do not allow seed generation.
If more apps would implement to the word of the BIP39 spec, multiple
languages make sense, but since reality is no one follows the spec (/the
spec is way too open to interpretation) then expecting every app to load
every language is unreasonable.
Electrum actually handles BIP39 recovery the way the BIP specifies. I can
restore random strings if I want, and it warns me, and I can ignore it if I
wish.
Anywho. The BIP39 multi-language feature is crucial for non-English
speakers especially from Asia. Maybe northern Europeans have no problem
with English word spelling, but watching a normal Japanese person write
down their English mnemonic is painful.
One letter at a time, worried they wrote it wrong... still make mistakes...
lose money because of it.
Whereas users of Copay etc. that support Japanese wordlist write down their
seed easily, and I have never heard of a Japanese newbie complaining about
"but I'm writing it just how I have it written down" about their Japanese
seed... only English.
Not trying to give anyone a hard time, just telling the facts: lack of
localized words for recovery phrase causes more money loss than supporting
it. (When push comes to shove, at the very least Electrum will always
support their recovery because it lets you hash anything)
This is all anecdotal of course. Just sharing my experience evangelizing in
Japan.
Thanks,
Jon
2018年11月8日(木) 21:16 SomberNight via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Do you specifically want to support changing the language of seed
> words, while keeping the bip32 root seed they generate unchanged?
> What is the usecase for this?
>
> You mention that BIP39 already supports a few different languages.
> While this is true, many (I would guess most!) wallets only
> support the English wordlist.
> There are doubts even from the authors of the BIP whether it was
> a good idea in the first place to support multiple languages [0].
> I don't find this surprising as it seems bad design to have to fix and
> maintain a wordlist for every language as the checksum depends on it.
> The supported wordlists are effectively a part of the specification,
> and every new list would just make that specification larger.
>
> If changing the language of seeds is not a requirement, then look
> into Electrum seeds. They are language/wordlist agnostic.
>
> Mnemonic Sentence => PBKDF2 => BIP-0032 Seed
>
> The bip32 seed is derived by hashing the normalized mnemonic, and the
> checksum is derived the same way but by using a different cheaper
> hash (single round of HMAC-SHA512; generation grinds until it matches
> a pattern) [1]. For example, "9dk" is a valid segwit electrum seed.
>
>
> [0]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015507.html
> [1]: http://docs.electrum.org/en/latest/seedphrase.html
>
>
> > Date: Wed, 7 Nov 2018 00:16:41 +0800
> > From: Weiji Guo weiji.g at gmail.com
> > Subject: [bitcoin-dev] BIP- & SLIP-0039 -- better multi-language
> > support
> >
> > Hello everyone,
> >
> > I just realized that BIP-0039 is language dependent. I was assuming the
> > other way till I looked closer. The way the seed is derived from a
> BIP-0039
> > entropy, as is shown below, depends on which language to generate the
> > mnemonic sentence:
> >
> > Entropy <=> Mnemonic Sentence => PBKDF2 => BIP-0032 Seed
> >
> > Therefore when a user choose a non-English mnemonic code he or she is
> stuck
> > with that language. Meanwhile only a few native languages are supported.
> >
> > SLIP-0039 does not solve this issue in a user friendly way by providing
> > only an English wordlist. That's understandable as it aims to provide SSS
> > capability. However those users who do not speak English or recognize
> > English words will suffer.
> >
> > What I am trying to bring to attention of the community is that, no
> matter
> > if we make a new version of BIP-0039, or a new BIP (with SSS support), or
> > to enhance SLIP-0039, we really need to address this language issue.
> >
> > Here are what I propose:
> >
> > 1. The mnemonic code should be only a representation of underlying
> entropy
> > or (pre) master secret, seed, whatever. In this way, the same
> seed/secret
> > could be displayed in English or in Chinese or other languages. Then
> there
> > could be 3rd party conversion tools to support translations in case
> any
> > wallet software or device does not support all specified languages.
> Now it
> > looks like:
> >
> > Mnemonic Sentence <=> Entropy => PBKDF2 => BIP-0032 Seed
> >
> >
> > 2. Given that only 8 languages are supported in BIP-0039, we should allow
> > the seed/secret to be represented in decimal numbers, each ranging from 0
> > to 2047. So those who cannot find a native language support yet having
> > difficulty coping words in other languages could choose to just use
> numbers.
> >
> > So far I don't have a preference how this should be implemented. I'd like
> > to hear from community first.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181109/f93c2a37/attachment-0001.html>