Re: [bitcoin-dev] Password-protected wallet on Taproot

2022-05-04 Thread Lloyd Fournier via bitcoin-dev
Hi Vjudeu, Perhaps this could make sense in some setting. e.g. instead of a hardware device which protects your secret key via pin you use a pinless device but you create a strong password and use a proper password hash to create another key and put them in a 2-of-2. But make sure you don't use

Re: [bitcoin-dev] Simple step one for quantum

2022-04-09 Thread Lloyd Fournier via bitcoin-dev
Hey all, A good first step might be to express this as a research problem on bitcoinproblems.org! I've had in mind creating a problem page on how to design a PQ TR commitment in each key so that if QC were to become a reality we could softfork to enable that spend (and disable normal key path

Re: [bitcoin-dev] CTV dramatically improves DLCs

2022-02-06 Thread Lloyd Fournier via bitcoin-dev
Hi Jeremy, On Sat, 29 Jan 2022 at 04:21, Jeremy wrote: > Lloyd, > > This is an excellent write up, the idea and benefits are clear. > > Is it correct that in the case of a 3/5th threshold it is a total 10x * > 30x = 300x improvement? Quite impressive. > Yes I think so but I am mostly guessing

[bitcoin-dev] CTV dramatically improves DLCs

2022-01-24 Thread Lloyd Fournier via bitcoin-dev
Hi dlc-dev and bitcoin-dev, tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a lot*. ## Introduction Dryja introduced the idea of Discreet Log Contracts (DLC) in his breakthrough work[1]. Since then (DLC) has become an umbrella term for Bitcoin protocols that map oracle

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-06-17 Thread Lloyd Fournier via bitcoin-dev
@James wrote: On Tue, 15 Jun 2021 at 21:13, James MacWhyte wrote: > > @Lloyd wrote: > > Of course in reality no one wants to keep their coin holding keys online >> so in Alogorand you can authorize a set of "participation keys"[1] that >> will be used to create blocks on your coin holding key's

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-06-15 Thread Lloyd Fournier via bitcoin-dev
On Tue, 15 Jun 2021 at 10:59, Lloyd Fournier wrote: > > > On Tue, 15 Jun 2021 at 02:47, Antoine Riard > wrote: > >> > This makes a lot of sense as it matches the semantics of what we are >> trying >> to achieve: allow the owner of an output (whether an individual or group) >> to reduce that

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-06-14 Thread Lloyd Fournier via bitcoin-dev
On Tue, 15 Jun 2021 at 02:47, Antoine Riard wrote: > > This makes a lot of sense as it matches the semantics of what we are > trying > to achieve: allow the owner of an output (whether an individual or group) > to reduce that output's value to pay a higher fee. > > Note, I think you're still

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-06-13 Thread Lloyd Fournier via bitcoin-dev
On Fri, 11 Jun 2021 at 07:45, Antoine Riard wrote: > Hi Lloyd, > > Thanks for this tx mutation proposal extending the scope of fee-bumping > techniques. IIUC, the serves as a pointer to increase the > output amount by value to recover the recompute the transaction hash > against which the

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-06-07 Thread Lloyd Fournier via bitcoin-dev
Hi Antione, Thanks for bringing up this important topic. I think there might be another class of solutions over input based, CPFP and sponsorship. I'll call them tx mutation schemes. The idea is that you can set a key that can increase the fee by lowering a particular output after the tx is

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-23 Thread Lloyd Fournier via bitcoin-dev
Hi Billy, I was going to write a post which started by dismissing many of the weak arguments that are made against PoS made in this thread and elsewhere. Although I don't agree with all your points you have done a decent job here so I'll focus on the second part: why I think Proof-of-Stake is

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

2021-04-16 Thread Lloyd Fournier via bitcoin-dev
On Fri, 16 Apr 2021 at 13:47, ZmnSCPxj wrote: > Good morning LL, > > > On Tue, 16 Mar 2021 at 11:25, David A. Harding via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > I curious about whether anyone informed about ECC and QC > > > knows how to create output scripts with

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

2021-04-05 Thread Lloyd Fournier via bitcoin-dev
On Tue, 16 Mar 2021 at 11:25, David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > I curious about whether anyone informed about ECC and QC > knows how to create output scripts with lower difficulty that could be > used to measure the progress of QC-based EC key

Re: [bitcoin-dev] New PSBT version proposal

2021-04-05 Thread Lloyd Fournier via bitcoin-dev
On Wed, 10 Mar 2021 at 11:20, Lloyd Fournier wrote: > Hi Andrew & all, > > I've been working with PSBTs for a little while now. FWIW I agree with the > change of removing the global tx and having the input/output data stored > together in the new unified structures. > > One thing I've been

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

2021-03-16 Thread Lloyd Fournier via bitcoin-dev
On Tue, 16 Mar 2021 at 09:05, Matt Corallo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > There have been many threads on this before, I'm not sure anything new has > been brought up here. > > Matt > > On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote: > > I do not personally

Re: [bitcoin-dev] New PSBT version proposal

2021-03-09 Thread Lloyd Fournier via bitcoin-dev
Hi Andrew & all, I've been working with PSBTs for a little while now. FWIW I agree with the change of removing the global tx and having the input/output data stored together in the new unified structures. One thing I've been wondering about is how output descriptors could fit into PSBTs. They

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