Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Christopher Allen via bitcoin-dev]

I think the key issue here is avoiding xpub key reuse in multisig. Not only
in the future with Schnorr, but we need it today!

Current common practice by hardware wallets is the 48'/0'/0'/2' derivation
for segwit multsig ( e.g.
[90081696/48'/0'/0'/2']xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b
) is the only one used for ALL multisigs offered by that hardware wallet.

As Pieter said, leveraging a HD path parameters can help, but we need a
better, less reusable path for the index.

I personally suggest a simpler solution, which is to create an index using
a PBKDF of the Account Policy (a descriptor with all xpubs and keys
removed), plus optional notes. (BTW, I think double sha256 or HMAC is
overkill).

Example: for the reference bit descriptor that might result in:

```
wsh(sortedmulti(2,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))
```

What Blockchain Commons (and the Airgapped Wallet Community) call a policy
map would be

```
wsh(sortedmulti(1,,,))
```

A PBKDF of that as would be unique for all 2 of 3 segwig transactions. With
the addition of the addition of the Policy Map creators optional note, it
would be truly unique. The Policy Map and/or PBKDF are small and could
easily added to existing APIs.

So for legacy hardware, we can use existing 48' subtree, but 3' as the
format for this form (2' is segwit), then the desktop can just ask for the
/48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token.
More sophisticated Airgapped apps you can send
"wsh(sortedmulti(1,,,))"+label and let the cosigner app do the PBKDF, and
optionally allow it return something different in a full keyset (i.e.
"[90081696/48'/0'/0'/3'/af3948cg…'/]xpub6DYLEk…", and then the requesting
app, knowing that it is different from the PBKDF can know what to do if it
needs to what to ask for in the future.

The other advantage of this technique is that the cosigner app can know
what policy it is participating in, before the descriptor is completed. It
may decide it doesn't want to participate in some funky 4:9 with a weird
script, and not return an xpub at all.

Long term I think a commitment scheme should be used, so that you don't
reveal what xpub you offered until all the parties xpubs are shared, but as
Pieter said, we can do that at the same time we do the musig. But we need
to prevent xpub reuse NOW, and I think my proposal easy and could the job.

-- Christopher Allen, Blockchain Commons
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core

[Pieter Wuille via bitcoin-dev]

> I'm not sure of the existing behavior is of when we issue a getdata request, 
> but noting that there could be a privacy implication of this sort of change. 
> Could you (or someone else) expand on why this is not a concern here?

What kind of privacy concern are you talking about? I'm not sure I see how this 
could matter.

Cheers,

--
Pieter___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

[Pieter Wuille via bitcoin-dev]

‐‐‐ Original Message ‐‐‐
On Thursday, February 11, 2021 6:38 AM, Dr Maxim Orlovsky 
 wrote:

> Thank you very much for all the clarifications; it’s good to have them sorted 
> out and clearly structured. From what you wrote it follows that we still need 
> to reserve a dedicated purpose (with new BIP) for BIP340 signatures to avoid 
> key reuse, am I right?

Maybe, but it would be for a particular way of using keys (presumably: 
single-key pay-to-taproot), not just the signature scheme itself. If you go 
down this path you'll also want dedicated branches for multisig participation, 
and presumably several interesting new policies that become possible with 
Taproot.

The only thing ECDSA/Schnorr specific about this is that - if you want to 
maintain provable security - the keys used for ECDSA and BIP340 should be 
separated by a hardened step. It seems however that all approaches people 
actually use to prevent reuse do that already.

And as I said, dedicated branches only help for the simple case. For example, 
it doesn't address the more general problem of preventing reuse of keys in 
multiple distinct groups of multisig sets you participate in. If you want to 
solve that you need to keep track of  index is for participating in what - and 
once you have something like that you don't need dedicated purpose based 
derivation at all anymore.

So I'm not sure I'd state it as us *needing* a dedicated purpose/branch for 
single-key P2TR (and probably many other useful ways of using taproot based 
spending policies...). But perhaps it's useful to have.

Greg Maxwell pointed out to me that there may be another reason to want 
non-reuse across ECDSA and BIP340 keys: if someone were to do all of these 
wrong:
* not follow BIP340 and re-use RFC6979 for BIP340 nonce generation
* reuse the same keys for both
* sign the same message with both
... you would actually leak your private key. This isn't a concern for Bitcoin 
transaction signing however, as the sighash (message) indirectly commits to 
BIP341 or not, and thus it'd be impossible to construct colliding messages. 
Still, it's a consideration to factor in.

Cheers,

--
Pieter

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

*BIP39 seed words list.

On Thu, Feb 11, 2021 at 11:11 AM Hugo Nguyen  wrote:

> Hi Pavol,
>
> On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> В Thu, 11 Feb 2021 05:45:33 -0800
>> Hugo Nguyen via bitcoin-dev 
>> wrote:
>>
>> > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
>> > >
>> > > This scheme might be vulnerable to rainbow table attack.
>> > >
>> >
>> > Thank you for pointing this out! Incidentally, Dmitry Petukhov also
>> > told me the same privately.
>>
>> My thought was that if TOKEN has the characteristics of a password
>> (short ASCII string), then it would be better to use key derivation
>> function designed for passwords, like PBKDF2.
>>
>> The counter-argument to this is that this adds another code dependency
>> for vendors, if the device firmware does not already have the required
>> key derivation function.
>>
>> Maybe this could be solved by going into opposite direction - make the
>> "token" even longer, use the mnemoic.
>>
>> The issue is that entering long data of the shared key into the device
>> manually is difficult UX-wise.
>>
>> Hww vendors that allow to enter custom keys into their device already
>> have to face this issue, and those who allow to enter custom keys via
>> mnemonic probably tackled this somehow.
>>
>> Maybe the shared key for multisig setup can be entered in the same way
>> ? (with maybe additional visual check via some fingerprint).
>>
>
> You just gave me a great idea! We can reuse the BIP32 seed words list!
> Perhaps the encryption key can just be 6 words, but it'll be derived the
> same way. BIP39 also uses PBKDF2 as a key derivation function, so it
> matches with what you described here.
>
> And all HWW should have this functionality already.
>
> Best,
> Hugo
>
>
>>
>> Although we would then have another issue of potential confusion
>> between two procedures (entering the main key and entering the shared
>> key for multisig setup), and the measures has to be taken to prevent
>> such confusion.
>>
>> The approaches can be combined - specify a key derivation function
>> suitable for passwords; via secure channel, share a password and/or the
>> derived key. If hww supports derivation function, it can derive the key
>> from password. If hww supports only keys, the key can be entered raw or
>> via mnemonic.
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

Hi Pavol,

On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> В Thu, 11 Feb 2021 05:45:33 -0800
> Hugo Nguyen via bitcoin-dev 
> wrote:
>
> > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
> > >
> > > This scheme might be vulnerable to rainbow table attack.
> > >
> >
> > Thank you for pointing this out! Incidentally, Dmitry Petukhov also
> > told me the same privately.
>
> My thought was that if TOKEN has the characteristics of a password
> (short ASCII string), then it would be better to use key derivation
> function designed for passwords, like PBKDF2.
>
> The counter-argument to this is that this adds another code dependency
> for vendors, if the device firmware does not already have the required
> key derivation function.
>
> Maybe this could be solved by going into opposite direction - make the
> "token" even longer, use the mnemoic.
>
> The issue is that entering long data of the shared key into the device
> manually is difficult UX-wise.
>
> Hww vendors that allow to enter custom keys into their device already
> have to face this issue, and those who allow to enter custom keys via
> mnemonic probably tackled this somehow.
>
> Maybe the shared key for multisig setup can be entered in the same way
> ? (with maybe additional visual check via some fingerprint).
>

You just gave me a great idea! We can reuse the BIP32 seed words list!
Perhaps the encryption key can just be 6 words, but it'll be derived the
same way. BIP39 also uses PBKDF2 as a key derivation function, so it
matches with what you described here.

And all HWW should have this functionality already.

Best,
Hugo


>
> Although we would then have another issue of potential confusion
> between two procedures (entering the main key and entering the shared
> key for multisig setup), and the measures has to be taken to prevent
> such confusion.
>
> The approaches can be combined - specify a key derivation function
> suitable for passwords; via secure channel, share a password and/or the
> derived key. If hww supports derivation function, it can derive the key
> from password. If hww supports only keys, the key can be entered raw or
> via mnemonic.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core

[Jeremy via bitcoin-dev]

I'm not sure of the existing behavior is of when we issue a getdata
request, but noting that there could be a privacy implication of this sort
of change. Could you (or someone else) expand on why this is not a concern
here?
--
@JeremyRubin 



On Wed, Feb 10, 2021 at 6:29 AM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> I'm proposing to stop the processing of unrequested transactions in
> Bitcoin Core 22.0+ at TX message reception. An unrequested transaction is
> one defined by which a "getdata" message for its specific identifier
> (either txid or wtxid) has not been previously issued by the node [0].
>
> This change is motivated by reducing the CPU DoS surface of Bitcoin Core
> around mempool acceptance. Currently, an attacker can open multiple inbound
> connections to a node and send expensive to validate, junk transactions.
> Once the canonical INV/GETDATA sequence is enforced on the network, a
> further protection would be to deprioritize bandwidth and validation
> resources allocation, or even to wither connections with such DoSy peers. A
> permissioned peer (PF_RELAY) will still be able to bypass such restrictions.
>
> Raw TX message processing has always been tolerated by Core and as such
> some Bitcoin clients aren't bothering with an INV/GETDATA sequence. Such
> change will break their tx-relay capabilities on the p2p network and
> require adaptation from them. Given deployment time of any release, I hope
> it provides a window time wide enough before the old tx-processing behavior
> becomes the minority.
>
> Eager to gather feedback on this proposal, especially if such change is
> deemed as too much constraining or fast on any Bitcoin software.
>
> Cheers,
> Antoine
>
> [0] See https://github.com/bitcoin/bitcoin/pull/20277
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Dmitry Petukhov via bitcoin-dev]

В Thu, 11 Feb 2021 05:45:33 -0800
Hugo Nguyen via bitcoin-dev 
wrote:

> > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))  
> >
> > This scheme might be vulnerable to rainbow table attack.
> >  
> 
> Thank you for pointing this out! Incidentally, Dmitry Petukhov also
> told me the same privately.

My thought was that if TOKEN has the characteristics of a password
(short ASCII string), then it would be better to use key derivation
function designed for passwords, like PBKDF2.

The counter-argument to this is that this adds another code dependency
for vendors, if the device firmware does not already have the required
key derivation function.

Maybe this could be solved by going into opposite direction - make the
"token" even longer, use the mnemoic.

The issue is that entering long data of the shared key into the device
manually is difficult UX-wise.

Hww vendors that allow to enter custom keys into their device already
have to face this issue, and those who allow to enter custom keys via
mnemonic probably tackled this somehow.

Maybe the shared key for multisig setup can be entered in the same way
? (with maybe additional visual check via some fingerprint).

Although we would then have another issue of potential confusion
between two procedures (entering the main key and entering the shared
key for multisig setup), and the measures has to be taken to prevent
such confusion.

The approaches can be combined - specify a key derivation function
suitable for passwords; via secure channel, share a password and/or the
derived key. If hww supports derivation function, it can derive the key
from password. If hww supports only keys, the key can be entered raw or
via mnemonic.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

[Dr Maxim Orlovsky via bitcoin-dev]

Hi Pieter,

... and sorry for misspelling your name in my first e-mail :(

Thank you very much for all the clarifications; it’s good to have them sorted 
out and clearly structured. From what you wrote it follows that we still need 
to reserve a dedicated purpose (with new BIP) for BIP340 signatures to avoid 
key reuse, am I right?

Kind regards,
Maxim

> On Feb 6, 2021, at 02:15, Pieter Wuille  wrote:
> 
> 
> On Friday, February 5, 2021 9:51 AM, Dr Maxim Orlovsky via bitcoin-dev 
>  wrote:
> 
>> Hi,
>> 
>> Background
>> 
>> 
>> 
>> Had a discussion last night in Bitcoin Core IRC with Peter Wuille on 
>> different topics regarding key derivations, security, key tweaks in context 
>> of Schnorr signatures & Taproot. Would like to share some action points and 
>> plans that emerged from there:
>> 
>> 1.  There is a real need for BIP-43 based new BIP with a new purpose field 
>> for keys used in Schnorr signatures. Peter will not do it (he is not very 
>> much interested in spending his time on wallet-level stuff), so someone else 
>> should.
>> 2.  Keys used in Schnorr signatures MUST NEVER BE used in ECDSA signatures, 
>> otherwise there is a risk of private key leak via correlation attack. This 
>> is rationale behind N1.
> 
> Hi Maxim,
> 
> thanks for bringing up this discussion here. I'd like to clarify a few things 
> though, as I think the above is formulated far too strongly.
> 
> There are two issues here: (1) reasons to avoid reusing the same key for 
> privacy reasons, and (2) reasons to avoid using related keys for 
> cryptographic reasons. And in practice, solutions to the first (which we 
> already need, unrelated to Taproot/Schnorr) mean the second is largely moot.
> 
> 
> # Don't reuse keys for privacy/organizational reasons.
> 
> Reusing the same key in Bitcoin scripts - for use in distinct signature 
> schemes or not - should always be avoided. It has obvious privacy 
> implications; I don't think this is controversial, and it's a problem that 
> exists today, unrelated to Taproot. E.g. you don't want to reuse the same 
> keys as both single-sig and participation in multisig.
> 
> My personal view here is that distinct standard derivation paths help with 
> this in the simple cases, but they're not a full solution in the most general 
> case. E.g. if you want to use one seed/root to participate in multiple sets 
> of multisig policies, you'll need some kind of index to assign to each 
> anyway. For this reason in general I prefer solutions that explicitly track 
> what path is used for what.
> 
> 
> # Don't use related keys for cryptographic reasons
> 
> There are some concerns to address here, but I want to make it clear there 
> are no known attacks against usage of related keys across ECDSA and Schnorr, 
> and I don't expect there will be. However, there is probably no proof for 
> this, and creating one may be tricky. On the other hand, the ecosystem 
> (Bitcoin, but also many other applications) has accepted ECDSA long ago, 
> while it had no security proofs whatsoever (and even the ones that exist now 
> rely on fairly unusual assumption; a proof for security of mixed 
> Schnorr/ECDSA usage would inherently need equally unusual assumptions too).
> 
> Now, as soon as a hardened derivation separates different uses there is no 
> concern at all. So any solution for avoiding key reuse (section above) that 
> works by assigning (implicitly or explicitly) different hardened derivation 
> paths (as BIP43 etc. do) to different uses implies there is never any concern 
> about related keys across Schnorr/ECDSA.
> 
> If the keys are not separated by a hardened step, it's more complicated. 
> Looking at the different cases:
> 
> (1) Signing with related ECDSA keys (e.g. two unhardened child keys from the 
> same xpub)
> 
> - This is very common on BIP32 usage today, so hopefully it is secure! Tim 
> Ruffing pointed me today to 
> https://link.springer.com/chapter/10.1007/978-3-030-36938-5_8 whose abstract 
> seems to indicate they prove this is actually secure, but I don't know under 
> what assumptions. Note that the comment there about Schnorr not having this 
> property does not apply to BIP340, because it uses key-prefixed Schnorr.
> 
> (2) Signing with related Schnorr keys.
> 
> - I believe this is secure simply because BIP340 challenges commit to the 
> pubkey (key prefixing), and thus a signature on one shouldn't teach you 
> anything about others. A formal proof is probably a bit longer, but still 
> trivial to construct.
> 
> (3) The real question: signing with a Schnorr key that is related to an ECDSA 
> key.
> 
> - I don't expect that this is easy to prove, but I have a very hard time 
> imagining how it could be exploitable, given the use of domain-separated 
> hashes. Aspects such as BIP340's key prefixing and the fact that Bitcoin 
> sighashes indirectly commit to the (set of) signing pubkeys make it even 
> harder.
> 
> 
> # TL;DR
> 
> * For privacy reasons, you 

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

Hi Pavol,

On Thu, Feb 11, 2021 at 5:25 AM Pavol Rusnak  wrote:

> > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
>
> This scheme might be vulnerable to rainbow table attack.
>

Thank you for pointing this out! Incidentally, Dmitry Petukhov also told me
the same privately.


>
> The following scheme might be more secure:
>
> DESCRIPTION = ASCII description provided by user
> NONCE = 256-bit random number
> ENCRYPTION_KEY = hmac-sha256(key=NONCE, msg=DESCRIPTION)
>
> Coordinator distributes DESCRIPTION (fka TOKEN) together with NONCE to
> the signers.
>

This does seem to add a lot more entropy. The challenge is to balance the
security requirement with UX. In the absence of some handshake protocol to
exchange the shared secrets (DESCRIPTION / NONCE) , the user will have to
enter these manually on the devices. I'll think about this some more.


>
> Also, is there any reason why you'd want to disable encryption? Why not
> keep that as mandatory?
>

Making it mandatory would be nice, but IMHO not all use cases might require
encryption. For example, if you are setting up the multisig locally under a
safe environment you control, encryption might be an overkill.

Best,
Hugo



>
>
> On Tue, 9 Feb 2021 at 12:39, Hugo Nguyen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen <
>> christoph...@lifewithalacrity.com> wrote:
>>
>>>
>>>
>>> On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen  wrote:
>>>

 I don't think reusing XPUBs inside different multisig wallets is a good
 idea... For starters, loss of privacy in one wallet will immediately affect
 privacy of other wallets. I think multisig wallets should be completely
 firewalled from each other. That means one unique XPUB per wallet. This is
 what we have been doing with the Nunchuk wallet.

>>>
>>> To be clear, I have stated repeatedly that xpub reuse into multisig is a
>>> poor practice. However, finding a trustless solution when a wallet is
>>> airgapped with no network, or is stateless like Trezor, is quite hard.
>>>
>>> The challenge also includes how does an airgapped or stateless wallet
>>> know that it is talking to the same process on the other side that that it
>>> gave the xpub to in the first place. Without state to allow for a
>>> commitment, or at least a TOFU, a cosigner who thought he was part of a 3
>>> of 5 could discover that he instead is in a 2 of 3, or in a script with an
>>> OR, as some form of scam.
>>>
>>
>> The shared secret approach that I mentioned in the proposal actually can
>> help you here. The TOKEN doubles as a session ID - thereby establishing a
>> common state on both sides.
>>
>> Best,
>> Hugo
>>
>>
>>>
>>> — Christopher Allen
>>>
 ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Pavol Rusnak via bitcoin-dev]

> ENCRYPTION_KEY = SHA256(SHA256(TOKEN))

This scheme might be vulnerable to rainbow table attack.

The following scheme might be more secure:

DESCRIPTION = ASCII description provided by user
NONCE = 256-bit random number
ENCRYPTION_KEY = hmac-sha256(key=NONCE, msg=DESCRIPTION)

Coordinator distributes DESCRIPTION (fka TOKEN) together with NONCE to the
signers.

Also, is there any reason why you'd want to disable encryption? Why not
keep that as mandatory?


On Tue, 9 Feb 2021 at 12:39, Hugo Nguyen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen <
> christoph...@lifewithalacrity.com> wrote:
>
>>
>>
>> On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen  wrote:
>>
>>>
>>> I don't think reusing XPUBs inside different multisig wallets is a good
>>> idea... For starters, loss of privacy in one wallet will immediately affect
>>> privacy of other wallets. I think multisig wallets should be completely
>>> firewalled from each other. That means one unique XPUB per wallet. This is
>>> what we have been doing with the Nunchuk wallet.
>>>
>>
>> To be clear, I have stated repeatedly that xpub reuse into multisig is a
>> poor practice. However, finding a trustless solution when a wallet is
>> airgapped with no network, or is stateless like Trezor, is quite hard.
>>
>> The challenge also includes how does an airgapped or stateless wallet
>> know that it is talking to the same process on the other side that that it
>> gave the xpub to in the first place. Without state to allow for a
>> commitment, or at least a TOFU, a cosigner who thought he was part of a 3
>> of 5 could discover that he instead is in a 2 of 3, or in a script with an
>> OR, as some form of scam.
>>
>
> The shared secret approach that I mentioned in the proposal actually can
> help you here. The TOKEN doubles as a session ID - thereby establishing a
> common state on both sides.
>
> Best,
> Hugo
>
>
>>
>> — Christopher Allen
>>
>>> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

[Dr Maxim Orlovsky via bitcoin-dev]

Hi Christopher,

Thank you very much! Will look forward to talk to you regarding all of these, 
as we discussed elsewhere.

Kind regard,
Maxim


> On Feb 5, 2021, at 23:37, Christopher Allen 
>  wrote:
> 
> Concept ACK.
> 
> I, in my role as a co-author of the emerging W3C Decentralized Identifier 
> standard and of the BTCR DID method, organizer of the Bitcoin Airgapped 
> Wallet Community 
> (https://github.com/blockchainCommons/airgapped-Wallet-Community/discussions),
>  and as principal architect of Blockchain Commons, am very interested in 
> supporting discussion on this topic, and implementation of anything we 
> decide. I also have some Patron's to Blockchain Commons interested in this 
> topic and may be willing to financially support some reference code.
> 
> -- Christopher Allen


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

[Dr Maxim Orlovsky via bitcoin-dev]

Hi Dmitry,

Thank you very much for readying and analyzing my proposal!

>> Testnet path is unhardened from this point & till the end of the
>> derivation path: no need to prevent private key leak there,
>> simplifies test software (hardened paths require private key access
>> for derivation).
> 
> I believe this will reduce robustness and will add complexity to the
> test software instead. If the derivation path is hardened in 'production
> code' and is unhardened in 'test code', then: code paths that depend on
> hardened derivation may not be tested; there will be unnecessary
> code that will need to deal with 'un-hardening' the paths for test code.
<...>
> It is OK to require privkey access to hardened paths in test
> software, because the same behaviour is expected in 'production’.

You are right, agree

> It is much more robust to just change the 'purpose' part of the path,
> and leave the rest unchanged.

Not sure whether the purpose is the correct place to indicate testnet: in this 
case it we will have to support one testnet per each blockchain type (which is 
not the case). So probably we should reserve a single dedicated value for any 
testnet withing ``blockchain` field using hardened path as you suggested - for 
instance, 0x may do the job.

Kind regards,
Maxim


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs

[ZmnSCPxj via bitcoin-dev]

Good morning Luke,

> > (to be fair, there were tools to force you to improve coverage by injecting 
> > faults to your RTL, e.g. it would virtually flip an `&&` to an `||` and if 
> > none of your tests signaled an error it would complain that your test 
> > coverage sucked.)
>
> nice!

It should be possible for a tool to be developed to parse a Verilog RTL design, 
then generate a new version of it with one change.
Then you could add some automation to run a set of testcases around mutated 
variants of the design.
For example, it could create a "wrapper" module that connects to an unmutated 
differently-named version of the design, and various mutated versions, wire all 
their inputs together, then compare outputs.
If the testcase could trigger an output of a mutated version to be different 
from the reference version, then we would consider that mutation covered by 
that testcase.
Possibly that could be done with Verilog-2001 file writing code in the wrapper 
module to dump out which mutations were covered, then a summary program could 
just read in the generated file.
Or Verilog plugins could be used as well (Icarus supports this, that is how it 
implements all `$` functions).

A drawback is that just because an output is different does not mean the 
testcase actually ***checks*** that output.
If the testcase does not detect the diverging output it could still not be 
properly covering that.

The point of this is to check coverage of the tests.
Not sure how well this works with formal validation.



> > Synthesis in particular is a black box and each vendor keeps their 
> > particular implementations and tricks secret.
>
> sigh.  i think that's partly because they have to insert diodes, and buffers, 
> and generally mess with the netlist.
>
> i was stunned to learn that in a 28nm ASIC, 50% of it is repeater-buffers!

Well, that surprises me as well.

On the other hand, smaller technologies consistently have lower raw output 
current driving capability due to the smaller size, and as trace width goes 
down and frequency goes up they stop acting like ideal 0-impedance traces and 
start acting more like transmission lines.
So I suppose at some point something like that would occur and I should not 
actually be surprised.
(Maybe I am more surprised that it reached that level at that technology size, 
I would have thought 33% at 7nm.)

In the modules where we were doing manual netlist+layout, we used inverting 
buffers instead (slightly smaller than non-inverrting buffers, in most 
technologies a non-inverting buffer is just an inverter followed by an 
inverting buffer), it was an advantage of manual design since it looks like 
synthesis tools are not willing to invert the contents of intermediate 
flip-lfops even if it could give theoretical speed+size advantage to use an 
inverting buffer rather than an non-inverting one (it looks like synthesis 
optimization starts at the output of flip-flops and ends at their input, so a 
manual designer could achieve slightly better performance if they were willing 
to invert an intermediate flip-flop).
Another was that inverting latches were smaller in the technology we were using 
than non-inverting latches, so it was perfectly natural for us to use an 
inverting latch and an inverting buffer on those parts where we needed higher 
fan-out (t was equivalent to a "custom" latch that had higher-than-normal 
driving capability).

Scan chain test generation was impossible though, as those require flip-flops, 
not latches.
Fortunately this was "just" deserialization of high-frequency low-width data 
with no transformation of the data (that was done after the deserialization, at 
lower clock speeds but higher data width, in pure RTL so flip-flops), so it was 
judged acceptable that it would not be covered by scan chain, since scan chain 
is primarily for testing combinational logic between flip-flops.
So we just had flip-flops at the input, and flip-flops at the output, and 
forced all latches to pass-through mode, during scan mode.
We just needed to have enough coverage to uncover stuck-at faults (which was 
still a pain, since additional test vectors slow down manufacturing so we had 
to reduce the test vectors to the minimum possible) in non-scan-momde testing.

Man, making ASICs was tough.


>
> plus, they make an awful lot of money, it is good business.
>
> > Pointing some funding at the open-source Icarus Verilog might also fit, as 
> > it lost its ability to do synthesis more than a decade ago due to inability 
> > to maintain.
>
> ah i didn't know it could do synthesis at all! i thought it was simulation 
> only.

Icarus was the only open-source synthesis tool I could find back then, and it 
dropped synthesis capability fairly early due to maintenance burden (I never 
managed to get the old version with synthesis compiled and never managed actual 
synthesis on it, so my knowledge of it is theoretical).


There is an argument that open-source software is not truly