Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bip174: add global xpub field #784

Merged
merged 2 commits into from Jul 10, 2019

Conversation

@achow101
Copy link
Member

commented May 14, 2019

Adds a global type for xpubs as discussed on the bitcoin-dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016894.html

@achow101

This comment has been minimized.

Copy link
Member Author

commented May 14, 2019

@peter-conalgo

This comment has been minimized.

Copy link

commented May 14, 2019

+1 would implement

@stepansnigirev

This comment has been minimized.

Copy link

commented May 14, 2019

Just to clarify

It should be the public key at the highest hardened derivation index

Should means that it's a recommendation and I still can use non-hardened derivation index, right? If so, +1 from my side.

@achow101

This comment has been minimized.

Copy link
Member Author

commented May 14, 2019

Should means that it's a recommendation and I still can use non-hardened derivation index, right?

Yes. It is a recommendation, not a requirement.

@matthewleon

This comment has been minimized.

Copy link

commented May 14, 2019

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.

This is a somewhat confusing sentence. At a minimum, the word highest seems ambiguous. Perhaps an example could also be provided to clarify?

@peter-conalgo

This comment has been minimized.

Copy link

commented May 17, 2019

I think we're going to need a different 'key' for this field. Here are three xpub's with the same fingerprint, and if BIP45 was being used, they would all have the same derivation (m/45'). Without having a repeating key value, there is no way to represent this in the proposed PSBT format.

tpubD8NXmKsmWp3a3HvTG3Pe2mmkmwMfNPvVd4GorFdaQpnwV8v79zEchTuLkt1Ehz7ou5icAFYxDbS7gR592VocShPqNnmwDQcdbcPdDyVhAiG
tpubD8NXmKsmWp3a2S1WnJk9GBXBpJNEWEd5HEQsMtV29Kk4uBzxuH1JGBq8oLAHmmVgZCiXdGANT35niN1ibSZatwQ7zHYsTtWrzjo6aKK11g4
tpubD8NXmKsmWp3a1Hj6i1Be5fVbbRfH4Hg2reAZ9ctaizJFc9ddLG5GSHnS4f3iprEmrbFPWLmgsir2s9CaXQp2fVVMs5zVbJTnhvMxoErXQCW

[Aside: All share F1CFD170. These are constructed by modulating the chain code, but as a 32-bit truncated hash, there will be legitimate fingerprint collisions in real-world examples.]

As for a better key value to use, I think an index (32-bits, ascending) would be enough, or we could use the public key (33 bytes, compressed only).

IMHO, the key derivation path is not useful information since I cannot verify it, but maybe it's useful to detect innocent errors between the global section and paths in the ins/outs.

In conclusion, I propose we switch from using the (extended key fingerprint + key path) to just an (index + key path). Must start at zero, no gaps and so on.

@achow101

This comment has been minimized.

Copy link
Member Author

commented May 20, 2019

In conclusion, I propose we switch from using the (extended key fingerprint + key path) to just an (index + key path). Must start at zero, no gaps and so on.

I don't think requiring it to start at 0 and increment is really needed. We just need some fixed sized nonce that makes it unique. Also, I think it would be worth keeping the extended key fingerprint as that would allow for efficient lookups in the case where fingerprints don't collide. So the key would be nonce + fingerprint + path. I would prefer something else that can be used for uniqueness that would be known from the child pubkey, although I can't think of one right now.

@peter-conalgo

This comment has been minimized.

Copy link

commented May 21, 2019

  • yes to keeping the fingerprint, I missed that, and we need it for any xpub that has child_depth > 1.
  • nonce vs. index: sure. I'd use an index myself and still be compliant.
@stepansnigirev

This comment has been minimized.

Copy link

commented May 25, 2019

We could use the fingerprint of the key itself as a nonce. It's a bit redundant as it can be calculated from the xpub, but sometimes people don't know the root fingerprint and use the fingerprint of the last hardened key instead. So it may help to do quick lookups in such cases.
Or we could save 3 bytes and use a 1-byte nonce without any meaning - should be enough to prevent collisions.

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

I don't understand the reasoning. Because A wallet should already know out of band the xpub of B if his wallet want to create a new deposit address.

If A knows about the xpubs out of band, then he can detect that the output of E is not the proper change.

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

It is not specific to multisig wallets actually. In general the wallet A should know how to derive addresses, and as such know the xpubs already. Not only the xpub, but if you make a more complex wallet based on mini script for example, the wallet A not only need all the xpub out of band, but also the miniscript!

Also, what if the attacker replace the xpubof B in PSBT_GLOBAL_XPUB with his?

@peter-conalgo

This comment has been minimized.

Copy link

commented Jun 3, 2019

I can only comment on the Coldcard. We will support out-of-band methods to setup the xpubs involved in a multisig wallet, and also support the PSBT globals section. However there is a setting, called "Trust PSBT" with values:

  • Verify Only. Do not import the xpubs found, but do verify the correct wallet already exists on the Coldcard.

  • Offer Import. If it's a new multisig wallet, offer to import the details and store them as a new wallet in the Coldcard. (The user can view fingerprints and xpubs and M/N at this point before import.)

  • Trust PSBT. Use the wallet data in the PSBT as a temporary, multisig wallet, and do not import it. This permits some deniability and additional privacy.

When the XPUB data is not provided in the PSBT, regardless of the above, we require the appropriate multisig wallet to already exist on the Coldcard. Default is to 'Offer' unless a multisig wallet already exists, otherwise 'Verify'.

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

@peter-conalgo

and also support the PSBT globals section.

Stop me if I miss something, but if Coldcard does not know the xpubs out of band, then what prevent the attacker to put his own xpub in the PSBT global section? I don't understand how this proposal fix the problem it is aiming to solve.

@peter-conalgo

This comment has been minimized.

Copy link

commented Jun 3, 2019

In my opinion, hardware wallets must track the M/N and xpubs for multisig wallets with which they are involved or else, yes, they will be vulnerable to changes to the PSBT. How that is stored/setup is out of scope for BIP-174 (IMHO) but with this addition to the PSBT format, HW wallets can implement a "trust on first use" model, which has proven to be very useful security model (example: SSH server pub keys).

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

@peter-conalgo good point. I think that @achow101 should clearly clarify this.

The "trust on first use" is the only reason for this global xpub field.
This seems a good way to initialize a multisig wallet.

@NicolasDorier
Copy link
Member

left a comment

The only reason to use this global xpub field is for trust on first use scenario where one wants to initialize the multisig wallet by signing the first PSBT. Else this field must be disregarded, as an attacker could very well put his own xpub.

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

@peter-conalgo I think that this global xpub is not even useful in trust on first use scenario. Because you can't even know about m...

@peter-conalgo

This comment has been minimized.

Copy link

commented Jun 3, 2019

@NicolasDorier Coldcard takes M/N from the first multisig input of the associated transaction.

@stepansnigirev

This comment has been minimized.

Copy link

commented Jun 3, 2019

@NicolasDorier, why is it the only reason?
When multisignature wallet already exists and I am doing a transaction with some change going back to the wallet how can I verify that the change address uses the same master public keys without xpubs? That was the idea of this change. Storing xpubs on hardware wallets is an option, but if the hardware wallet is stateless (or wiped and initialized again) it helps.

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

@stepansnigirev because the attacker E can put his own xpub in this global field, and the HW has no way to know.

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

I like @peter-conalgo approach as this technique can be used as a very good UX to initialize wallets with more complex scripts without changing or adding PSBT fields later.

@stepansnigirev

This comment has been minimized.

Copy link

commented Jun 3, 2019

So there is an xpub E from the attacker, it is not in the input but it is in the output => the address is not a change address and we need to show to the user that keys are different.
Let's say input is from 2 of 3 multisig with keys xpub1/derivation1, xpub2/derivation2, xpub3/derivation3, if the output uses the same xpubs it will be considered as change address, if not - spending output. How can the attacker include his E in the output?

Can you describe the attack you are thinking of in more details? I don't understand.

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

@stepansnigirev

  • Global XPubs: A,B,E
  • Input 1: A+B (1/2)
  • Output 1: Destination
  • Output 2: A+E (1/2)
@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

A see that A and B are in input 1 => OK
Then A see that A and E are in output 2 => OK that's change

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

@stepansnigirev I don't believe about a stateless wallet which can't save in its memory the multi sig xpubs and m. Because how the HW would be able to give you securely a new address? How could you confirm securely on the trusted display that an address you see on your computer screen is indeed belonging to your secure wallet?

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

I am not against this BIP, but I think it is created for the wrong reason. And if HW wallet use this feature the wrong way here the problems:

  • Software supporting PSBT but not supporting the global XPUB will be unable to be used with HW wallet depending on this, resulting in user confusion. (@peter-conalgo use case of trust on first use does not fall into this problem, as coldcard will not require this field)
  • There is still many way to trick the HW into thinking an output is a change. This is a mine field, and the easiest way to deal with this minefield is by making sure the HW can itself derive the scriptPubKey, without relying on the PSBT (outside of the keypaths in the output).
@stepansnigirev

This comment has been minimized.

Copy link

commented Jun 3, 2019

@NicolasDorier , change address is a change address if ALL keys in inputs and change output are the same. As (A,B) != (A,E) the second output is not a change address => HW will show it as spending output.

Software that doesn't use xpubs will be able to use hardware wallets with single keys (without multisig) or with multisig but the change address will be shown to the user as a normal spending address if the hardware wallet doesn't store the xpubs. It HW stores xpubs - no problem, HW can ignore this field.

At the moment the fact that we are missing xpubs field in the standard makes PSBT incompatible with Trezor wallet. They don't use PSBT but they rely on xpubs.

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

@stepansnigirev so in this case it means:

  1. Wallet requiring this can't sign a coinjoined transaction. (because if there is two input A+B and A+E, then you need to use an heuristic to say "this should be a transaction signed by the A+B wallet because input A+B is the first input")
  2. They need additional logic to extract the template of the scriptPubKey of A+B and enforce that the change has the same template. Which is not an obvious thing to do outside the simplest case of multisig. (Even for multisig, this is hard as you don't know if you need to reorder the pubkeys lexicographically or not)
@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

@stepansnigirev if the HW does not understand PSBT natively like coldcard does, then the responsibility to tell what is the change or not goes to the component interfacing with the HW (like HWI). This component should pass some hints to the HW to tell which input and output to sign explicitly, which can be done outside of the PSBT spec. (this make sense because which input and output to sign for a wallet is not known by the PSBT creator)

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 5, 2019

@achow101 no it does not.

Imagine 2-of-A,B

You derive on keypath k both A and B, and get pubkeys A' and B'.

Should the script be:

2 A' B' 2 CHECKMULTISIG or 2 B' A' 2 CHECKMULTISIG or 2 P1 P2 2 CHECKMULTISIG where P1 and P2 are lexically ordered A and B.

It should be lexically ordered to preserve privacy (in the case of 2-3, you don't want to leak information about which party did not signed!)

Output descriptors and miniscript order it by design.

@achow101

This comment has been minimized.

Copy link
Member Author

commented Jun 5, 2019

On the other hand with a descriptor, there is no doubt possible

Miniscript: 1 of A,B

Input 1: 1 of A,B (pubkeys ordered)
Input 2: 1 of A,B (pubkeys unordered)
Input 3: 2 of A,B

Output:

Output 1: 1 of A,B (ordered)
Output 2: 1 of A,B (unordered)
Output 3: 2 of A,B
Output 4: C

There is only one change: Output 1.

This is completely pointless, just add a new field to the output that says it's change then. There's no reason for you to provide a descriptor globally. But that's not the goal. In a CoinJoin, the change outputs for each person are different and this approach doesn't work.


@achow101 no it does not.

Imagine 2-of-A,B

You derive on keypath k both A and B, and get pubkeys A' and B'.

Should the script be:

2 A' B' 2 CHECKMULTISIG or 2 B' A' 2 CHECKMULTISIG or 2 P1 P2 2 CHECKMULTISIG where P1 and P2 are lexically ordered A and B.

It should be lexically ordered to preserve privacy (in the case of 2-3, you don't want to leak information about which party did not signed!)

This is unrelated to a PSBT.

When you create a PSBT, you have already determined what the inputs and outputs are. This means that the scripts for everything are already locked in - the scriptPubKeys for the outputs are already determined which sets the order of pubkeys because the scriptPubKey commits to the script hash of the multisig script which sets the order. And the scripts for the inputs are locked in because the order is set by the scriptPubKey of the output being spent. Ordering is determined beforehand and is not a concern for any signer that receives a PSBT.

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 5, 2019

I know that the PSBT lock the outputs, I am just asking whether the HW should consider scripts with wrong order of pubkeys as change or not.

Ordering is determined beforehand and is not a concern for any signer that receives a PSBT.

Which I disagree with, because if the UTXO tracker is ordering public keys, but not the signer then a PSBT creator not ordering will create a PSBT that successfully get signed by the HW, but then the UTXO tracker will be unable to detect the change output, resulting in loss of fund if the user is not technical enough to recover it.

In a CoinJoin, the change outputs for each person are different and this approach doesn't work.

The Wallet interface can fill up the missing info before passing it down to the HW wallet.
I am already doing this in my own code in BTCPay, the PSBT creator I developped (NBXplorer) does not know the full BIP32 path. (only the change/index part)

So BTCpay need to process the PSBT (adding the account key path and fingerprint to all hdkeys) before sending it to the HW.

Do you have any down side to use output descriptors instead of a set of HD Keys?

@achow101

This comment has been minimized.

Copy link
Member Author

commented Jun 5, 2019

I am just asking whether the HW should consider scripts with wrong order of pubkeys as change or not.

I don't see how this is relevant to PSBT. It isn't the job of PSBT to specify exactly what a signer should display or not. That's a policy for a hardware wallet manufacturer to determine for themselves. IMO, the order matters. Effectively, I think change should be determined by matching descriptors. I would sign the input that matches a particular descriptor, and mark as change the output that has the same descriptor. But this isn't something that PSBT should specify.

Which I disagree with, because if the UTXO tracker is ordering public keys, but not the signer then a PSBT creator not ordering will create a PSBT that successfully get signed by the HW, but then the UTXO tracker will be unable to detect the change output, resulting in loss of fund if the user is not technical enough to recover it.

Why is the creator not using the same set of scriptPubKeys that the UTXO tracker is? I think this is such a contrived case that it is useless and unnecessary to consider. This really seems like a problem that the user needs to reconcile as to why their software are doing two different things.

The Wallet interface can fill up the missing info before passing it down to the HW wallet.

Sure, but that's for the protocol between the wallet and the hardware, not for PSBT.

Do you have any down side to use output descriptors instead of a set of HD Keys?

It is relatively large and just duplicates information already provided. Descriptors are written in ASCII and it massively wastes space. Also, descriptors are not a finalized format and can and do change.

@peter-conalgo

This comment has been minimized.

Copy link

commented Jun 5, 2019

Datapoint: Coldcard will reject any redeem script that doesn't have sorted public keys (per BIP-67), inputs or outputs.

Aside: We are putting the finishing touches on Coldcard's multisig support (see branch 'multisig'), and we already support the global XPUB field as originally proposed (with 32bit-nonce addition). Also, psbt_dump will parse and display them.

@achow101 Could you add the nonce from upthread into the diff which we are discussing?

My comment as a hardware wallet maker: to be safe the Coldcard has to understand precisely what we are signing. Therefore, duplicating any value that can be derived from the transaction itself is not helpful. It just becomes another value that we have to double-check. I like the original proposal as it provides just the information we need and no more. The proposal is sufficient for multisig, and IMHO, other transaction types, like Coinjoin, can add additional metadata to appropriate PSBT sections when we understand what they need to be safely signed.

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 5, 2019

Ok then if you insist on making this global xpub field, at list, in the BIP, describe how a HW should behave precisely, if I understand:

  1. Check first input's script, and extract m.
  2. Verify that the pubkeys in the input's script are all derived from xpubs present in the global xpub field.
  3. Verify that the pubkeys are ordered per BIP-67
  4. For each output, if the output's scriptPubKey can be derived from the xpubs extracted in the first input, m and the key paths, consider it as a change.
@achow101

This comment has been minimized.

Copy link
Member Author

commented Jun 5, 2019

describe how a HW should behave precisely,

I think that is completely out of scope for this BIP. It is not a specification of how hardware wallets should behave, it is a description of a data structure and the abstract workflow around it.

@achow101

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2019

@peter-conalgo I don't really like the nonce idea. Do you really think that collisions will really be a problem? The probability of having a master key fingerprint colliding within a PSBT is very low and in many other places, the master fingerprint is being used for uniqueness.

@peter-conalgo

This comment has been minimized.

Copy link

commented Jun 6, 2019

Collisions with a 32-bit truncated-hash can be legit---it's only mildly bad luck by my standards. I don't see any other spots in BIP-174 where BIP32 path is the key, so I think this is the only area with this potential problem. Of course the various implementations will still fall over, but that's not a concern when defining the file format. We just have to make it possible to create a conforming implementation that handles all cases.

Alternatives to the 32-bit nonce idea:

  1. We could loosen the rules about duplicate key values, maybe only in the global section, to allow repeated keys (but not repeated (key, value) pairs).

  2. We could insert a reserved value into the keypath when needed to make it unique (perhaps all ones). In case of multiple duplicates, you'd insert two of the reserved values.

  3. Use something else as the key, even just a counter, and then append the bip32 path after the xpub. More complex perhaps, but does allow growth in the future.

The problem I see with (1) and (2) is they won't get implemented, since they only happen in this special case. Most coders are happy with "works most of the time"... The nonce idea, and (3) force implementations to do it right.

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jun 7, 2019

I prefer a solution forcing implementation to do it right. Else we will end up with people having money locked unexpectedly (unless they are wizards).

@stepansnigirev

This comment has been minimized.

Copy link

commented Jun 7, 2019

What if we flip key and value? Having xpub as a key and derivation path as a value would prevent collisions. It's harder to do lookups though.
The only concern I have is that you could have multiple derivation paths for the same xpub depending on which parent key you consider a master key.

@achow101 achow101 force-pushed the achow101:bip174-xpubs branch from 2933f86 to c8dda7a Jun 9, 2019

@achow101

This comment has been minimized.

Copy link
Member Author

commented Jun 9, 2019

I've updated the changes as was discussed at Breaking Bitcoin.

The key is changed to be the xpub and the value is the derivation path. The depth of the provided derivation path must match the depth specified in the xpub.

I've also added a section on how change detection would work with this.

@achow101 achow101 force-pushed the achow101:bip174-xpubs branch from c8dda7a to 9f569de Jun 9, 2019

@stepansnigirev

This comment has been minimized.

Copy link

commented Jun 9, 2019

Looks good to me.

@peter-conalgo

This comment has been minimized.

Copy link

commented Jun 9, 2019


For outputs involving multiple keys, a signer can first examine the inputs that it is signing. It should determine the general pattern of the script.
For example, it can observe the redeemScript or witnessScript and determine whether it is multisig.
If it is multisig, it should determine how many keys there are, in what position they are, and how many signers are needed in order for the input to be valid.

This comment has been minimized.

Copy link
@NicolasDorier

NicolasDorier Jun 9, 2019

Member

Make sure the pub keys are ordered (BIP-67) else there will be problems of changes not detected by the wallet software.

This comment has been minimized.

Copy link
@achow101

achow101 Jun 9, 2019

Author Member

No. Enforcing multisig rules is out of scope for PSBT. This section is just to clarify how xpubs can be used for change detection. It isn't a description of what must be done.

This comment has been minimized.

Copy link
@NicolasDorier

NicolasDorier Jun 9, 2019

Member

Then remove in what position they are because it assumes there is no ordering...

This comment has been minimized.

Copy link
@NicolasDorier

NicolasDorier Jun 9, 2019

Member

If you specify in what position they are it means that if there is an input with 2 PubA PubB MULTISIG, then a change with 2 PubB' PubA' MULTISIG should not be considered a change. Which mean that BIP67 would be incompatible with what you are saying, not merely out of scope, but incompatible.

This comment has been minimized.

Copy link
@stepansnigirev

stepansnigirev Jun 9, 2019

Position matters in some cases. We could add an example:
If A, B and C are xpubs, ai, bi, ci are keys derived from them and input uses a spending script with condition (a1 or b1) and c1 then output with condition (a2 or b2) and c2 or (b2 or a2) and c2 can be considered as change, but (a2 or c2) and b2 should not.

This comment has been minimized.

Copy link
@NicolasDorier

NicolasDorier Jun 10, 2019

Member

@stepansnigirev no, if you follow BIP67, then (a2 or c2) and b2 SHOULD be considered as change and not (b2 or a2) and c2.

@stepansnigirev I am concerned only about multi sigs expressions. in the form of 2 A B 2 MULTISIG

@achow101 please remove the in what position they are this will really cause problem in the future. Either you force implementer to check BIP67, or you don't imply they can check the order.

If you say they can check the order, and that they do, we will have bunch of incompatibilities accross HW and wallet interfaces. This is an disincentive to use BIP67, which is bad: people using BIP67 will be incompatible with HW which check the order.

The whole point of PSBT is to nail down incompatibilities, not add more of them.

This comment has been minimized.

Copy link
@achow101

achow101 Jun 10, 2019

Author Member

@NicolasDorier The BIP is not saying anything about what signers must check. That whole section is about constructing the policy represented by a script, i.e. the descriptor. Public key order is something that can be part of such constructions. At no point does it say that signers must check that or that public key order must be part of the policy.

Incompatibilities between signers is to be expected because they will all probably have different signing policies. Specifying those signing policies is out of scope for this BIP. PSBT is an interchange format, not a description of how a wallet should work.

This comment has been minimized.

Copy link
@NicolasDorier

NicolasDorier Jun 11, 2019

Member

At no point does it say that signers must check that or that public key order must be part of the policy.

I agree, but it does, and that's my problem! it says that the public key order must be part of the policy:

If it is multisig, it should determine how many keys there are, in what position they are

This comment has been minimized.

Copy link
@achow101

achow101 Jun 11, 2019

Author Member

How about you read and review the current text instead of an outdated one? It no longer says that!

This comment has been minimized.

Copy link
@NicolasDorier

NicolasDorier Jun 11, 2019

Member

Indeed! The updated one seems OK to me.

@achow101 achow101 force-pushed the achow101:bip174-xpubs branch from 9f569de to e1f770e Jun 9, 2019

@achow101

This comment has been minimized.

Copy link
Member Author

commented Jun 12, 2019

@luke-jr This looks to be RTM.

@achow101

This comment has been minimized.

Copy link
Member Author

commented Jul 9, 2019

@luke-jr This can be merged.

@luke-jr luke-jr merged commit bf057da into bitcoin:master Jul 10, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jul 10, 2019

@achow101 do you have a test vector somewhere?

NicolasDorier added a commit to MetacoSA/NBitcoin that referenced this pull request Jul 10, 2019

@NicolasDorier

This comment has been minimized.

Copy link
Member

commented Jul 10, 2019

Here is what I get:

cHNidP8BAJoCAAAAAqmeyBQKKaI4mLDsQKtdpzGKG+W1MpcqHafaxBqbiHg8AAAAAAD/////qZ7IFAopojiYsOxAq12nMYob5bUylyodp9rEGpuIeDwBAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAATwEENYfPA9tUzYaAAAAAPyQBTmKLwpLRdTq/jl153VaJxd4KnlaDe6Lv6N2k8KEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8Q2QxqTwAAAIAAAACAAAAAgAABAE4BAAAIAAIAwusLAAAAABl2qRQFw/p8wLK+KgyugzKd8/kd2nKDjoisAMLrCwAAAAAZdqkUHatMqMPhz5T3nB9d5BX6mSv77jGIrAAAAAAiBgPM2yteF/6Eznlt1wjiHtdnWCue+MH/36jP8/gx7RMm2xTZDGpPAAAAgAAAAIAAAACAAAAAgAABAE4BAAAIAAIAwusLAAAAABl2qRQFw/p8wLK+KgyugzKd8/kd2nKDjoisAMLrCwAAAAAZdqkUHatMqMPhz5T3nB9d5BX6mSv77jGIrAAAAAAiBgJ8eKXzQrU9QnNbxV5xU2g6eyIl9Pug2hG25WklswpitRTZDGpPAAAAgAAAAIAAAACAAQAAgAAAAA==
@junderw

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2019

So, after properly reading this entire thread, I've come to realize that Cold-card is trying to implement a feature similar to my other global data point proposal #801

However, instead of internalizing the whitelist data (via an HW internal state combined with Trust on First Seen) my proposal is to create a signature with a specific private key of the HW seed, and have that signature passed in through the PSBT... meaning the wallet does not need an internal state.

My proposal also seems to deal with a few of @NicolasDorier concerns... (though some are still existing)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.