Re: [bitcoin-dev] Is BIP32's chain code needed?

2020-10-05 Thread Lloyd Fournier via bitcoin-dev
Hi Leonardo, I can't tell you what the BIP32 author was thinking but if I put myself in their shoes these are the reasons I might have done it this way: 1. Use HMAC rather than normal SHA2 -- this is just best practice for key derivation (even though I don't think it would make a difference to

Re: [bitcoin-dev] Taproot (and graftroot) complexity

2020-09-20 Thread Lloyd Fournier via bitcoin-dev
Hi Jay, I don't think there's much of a difference in security or privacy. The advice to avoid key-reuse remains the same and for the same reasons. LL On Sat, Sep 19, 2020 at 11:08 PM Jay Berg via bitcoin-dev wrote: > > Newb here.. don’t know if "in-reply-to" header is misbehaving. > > But

Re: [bitcoin-dev] Revisiting squaredness tiebreaker for R point in BIP340

2020-08-13 Thread Lloyd Fournier via bitcoin-dev
Thanks for bringing this discovery up and a big thanks to Peter Dettman for working on this. I second what Nadav said. Removing pointless complexity is worth it even at this stage. I also maintain a non-libsecp implementation of BIP340 etc. Having two ways to convert an xonly to a point is a pain

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Lloyd Fournier via bitcoin-dev
A quick correction to my post: > > Here's where the truly novel part comes in. Ruben solves this by extending > the standard *TLC contract: > 1. Bob redeem with secret > 2. Alice refund after T1 > 3. Bob redeem without secret after T2 > > This is actually: 1. Bob redeem with redeem secret 2.

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Lloyd Fournier via bitcoin-dev
Ruben, In my opinion, this protocol is theoretical breakthrough as well as a practical protocol. Well done! I want to try and distil the core abstract ideas here as they appear to me. From my view, the protocol is a combination of two existing ideas and one new one: 1. In atomic swaps you can

Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-05 Thread Lloyd Fournier via bitcoin-dev
On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote: > > Trust-minimization of Bitcoin security model has always relied first and > > above on running a full-node. This

Re: [bitcoin-dev] Mitigating Differential Power Analysis in BIP-340

2020-03-25 Thread Lloyd Fournier via bitcoin-dev
Hi Pieter, Thanks for the detailed response. > /secret key/secret keyI'll try to summarize the discussion we had that led > to this choice, but most of it is on > https://github.com/sipa/bips/issues/195 if you want the details. Ahh I can't believe I missed that github issue while searching. I

[bitcoin-dev] Mitigating Differential Power Analysis in BIP-340

2020-03-24 Thread Lloyd Fournier via bitcoin-dev
Hi List, I felt this topic deserved it's own thread but it follows on from the mailing list post [2] announcing a new PR [1] to change BIP-340 in several ways, including adding random auxiliary data into the nonce derivation function. Rather than hashing the randomness with the secret key and

Re: [bitcoin-dev] BIP 340 updates: even pubkeys, more secure nonce generation

2020-03-21 Thread Lloyd Fournier via bitcoin-dev
* To protect against differential power analysis, a different way of > mixing in this randomness is used (masking the private key completely > with randomness before continuing, rather than hashing them together, > which is known in the literature to be vulnerable to DPA in some > scenarios). > I

Re: [bitcoin-dev] Hash function requirements for Taproot

2020-03-16 Thread Lloyd Fournier via bitcoin-dev
On Fri, Mar 13, 2020 at 4:04 AM Tim Ruffing wrote: > > I mean, the good thing is that there's a general method to defend > against this, namely always adding a Merkle root on top. Maybe it's > useful to make the warning here a litte bit more drastic: >

Re: [bitcoin-dev] Schnorr sigs vs pairing sigs

2020-03-06 Thread Lloyd Fournier via bitcoin-dev
Hi Erik, There are a strong arguments for and against pairing based sigs in Bitcoin. One very strong argument in favour over non-deterministic signatures like Schnorr over BLS is it enables a kind of signature encryption called "adaptor signatures". This construction is key to many exciting up

Re: [bitcoin-dev] Hash function requirements for Taproot

2020-03-05 Thread Lloyd Fournier via bitcoin-dev
> I am uncertain what you mean here by "coin-tossing". > From the comparison to MuSig, I imagine it is an interactive key generation protocol like this: > * Everybody generates fresh keypairs. > * Everybody sends the hash of their pubkey to everyone else. > * After receiving a hash of pubkey from

[bitcoin-dev] Hash function requirements for Taproot

2020-03-04 Thread Lloyd Fournier via bitcoin-dev
Hi List, I recently presented a poster at the Financial Cryptography conference '2020 which you can find here: https://github.com/LLFourn/taproot-ggm/blob/master/main.pdf. It attempts to show the security requirements for the tweak hash function in Taproot. In this post I'll give a long

Re: [bitcoin-dev] BIP 340 updates: even pubkeys, more secure nonce generation

2020-02-26 Thread Lloyd Fournier via bitcoin-dev
> > Perhaps they even deserve their own BIP? > > Yes, a standard for nonce exfiltration protection and MuSig would be > important > for compatibility across wallets. > > > On 2/26/20 4:20 AM, Lloyd Fournier via bitcoin-dev wrote: > > Hi Pieter, > > > > Let me put c

Re: [bitcoin-dev] BIP 340 updates: even pubkeys, more secure nonce generation

2020-02-25 Thread Lloyd Fournier via bitcoin-dev
Hi Pieter, Let me put change (1) into my own words. We are already computing affine coordinates since we store public keys as the affine x-coordinate. It is faster to compute is_even(y) than is_quadratic_residue(y) so we get a speed up here during keypair generation. In the verification

Re: [bitcoin-dev] [Annoucement] Discreet Log Contract Protocol Specification

2020-01-28 Thread Lloyd Fournier via bitcoin-dev
Hi Chris, This is a really exciting effort. I hope I will be able to contribute to it. I was wondering if you had seen the idea that DLCs can be done in only two transaction using Schnorr[1]. I also think this can be done in Bitcoin as it is today using ECDSA adaptor signatures [2]. In my mind,

Re: [bitcoin-dev] Composable MuSig

2019-12-08 Thread Lloyd Fournier via bitcoin-dev
Hi ZmnSCPxj, I think you're idea of allowing multiple Rs is a fine solution as it would essentially mean that you were just doing a three party MuSig with more specific communication structure. As you mentioned, this is not quite ideal though. > It seems to me that what is needed for a

Re: [bitcoin-dev] Composable MuSig

2019-12-01 Thread Lloyd Fournier via bitcoin-dev
Hi ZmnSCPxj, > > Just a quick note: I think there is a way to commit to a point properly > > with Pedersen commitments. Consider the following: > > COM(X) = (y*G + z*H, y*G + X) where y and z are random and the opening is > > (y,z,X). This seems to be a unconditionally hiding and

Re: [bitcoin-dev] Composable MuSig

2019-11-29 Thread Lloyd Fournier via bitcoin-dev
Hi ZmnSCPxj, Very interesting problem. Just a quick note: I think there is a way to commit to a point properly with Pedersen commitments. Consider the following: COM(X) = (y*G + z*H, y*G + X) where y and z are random and the opening is (y,z,X). This seems to be a unconditionally hiding and

Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'

2019-10-10 Thread Lloyd Fournier via bitcoin-dev
Hi Thread, This may not be the most practical information, but there actually did exist an almost perfect analogy for Bitcoin addresses from the ancient world: From wikipedia https://en.wikipedia.org/wiki/Bulla_(seal) "Transactions for trading needed to be accounted for efficiently, so the clay

Re: [bitcoin-dev] [Lightning-dev] OP_CAT was Re: Continuing the discussion about noinput / anyprevout

2019-10-06 Thread Lloyd Fournier via bitcoin-dev
Hi Thread, I made a reply to the OP but didn't "reply all" so it just went directly to Ethan. Since the comments were interesting I'll attempt to salvage them by posting them in full: == Lloyd's post == Hi Ethan, I'd be interested to know what protocols you need OP_CAT for. I'm trying to figure

Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal

2019-08-12 Thread Lloyd Fournier via bitcoin-dev
Hello Runchao and ZmnSCPxj, I think we can simplify the explanation here by not using joint signatures and payment channel like constructions. ZmnSCPxj's more complex construction could be more dynamic and practical in some settings but at least for me it gets in the way of capturing how this