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

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.

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

> 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

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

‐‐‐ 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

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

*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: >> >> >

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

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

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

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

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

В 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

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

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

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

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

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

> 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

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

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

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

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). >

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

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