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
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
On Sat, 29 Jan 2022 at 04:21, Jeremy wrote:
> 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
Hi dlc-dev and bitcoin-dev,
tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a lot*.
Dryja introduced the idea of Discreet Log Contracts (DLC) in his
Since then (DLC) has become an umbrella term for Bitcoin protocols
that map oracle
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" that
>> will be used to create blocks on your coin holding key's
On Tue, 15 Jun 2021 at 10:59, Lloyd Fournier wrote:
> On Tue, 15 Jun 2021 at 02:47, Antoine Riard
>> > This makes a lot of sense as it matches the semantics of what we are
>> to achieve: allow the owner of an output (whether an individual or group)
>> to reduce that
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
> 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
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
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
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
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 <
> email@example.com> wrote:
> > > I curious about whether anyone informed about ECC and QC
> > > knows how to create output scripts with
On Tue, 16 Mar 2021 at 11:25, David A. Harding via bitcoin-dev <
> 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
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
On Tue, 16 Mar 2021 at 09:05, Matt Corallo via bitcoin-dev <
> There have been many threads on this before, I'm not sure anything new has
> been brought up here.
> On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:
> > I do not personally
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
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.
On Sat, Sep 19, 2020 at 11:08 PM Jay Berg via bitcoin-dev
> Newb here.. don’t know if "in-reply-to" header is misbehaving.
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
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
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
On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
> 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
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
I felt this topic deserved it's own thread but it follows on from the
mailing list post  announcing a new PR  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
* 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
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:
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
> 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
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
> > Perhaps they even deserve their own BIP?
> Yes, a standard for nonce exfiltration protection and MuSig would be
> for compatibility across wallets.
> On 2/26/20 4:20 AM, Lloyd Fournier via bitcoin-dev wrote:
> > Hi Pieter,
> > Let me put c
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
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. I also think this can be done in Bitcoin
as it is today using ECDSA adaptor signatures . In my mind,
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
> > 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
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
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
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 ==
I'd be interested to know what protocols you need OP_CAT for. I'm trying to
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
Mail list logo