Hi Robin,
Fascinating result.
Is it possible to give us an example of a protocol that uses BitVM that
couldn't otherwise be built? I'm guessing it's possible to exchange Bitcoin
to someone who can prove they know some input to a binary circuit that
gives some output.
Thanks!
LL
On Tue, 10 Oct 2
Hi Tom,
Thanks for the explanation. There's one remaining thing that isn't clear:
do you actually require parallel signing requests under the same key. It
seems to me that the protocol is very sequential in that you are passing a
utxo from one point to another in sequence. If so then the Schnorr b
Hi Tom,
These questions might be wrongheaded since I'm not familiar enough with the
statechain protocol. Here goes:
Why do you need to use schnorr blind signatures for this? Are the blind
signatures being used to produce on-chain tx signatures or are they just
for credentials for transferring own
Hello all,
1. No proof of knowledge of each R does *NOT* prevent wagner's attack.
2. In my mind, A generic blind signing service is sufficient for doing
blinded MuSig, Muig2, FROST or whatever without the blind signing service
knowing. You don't need a specialized MuSig2 blind singing service to
e
other
spending constraint. So your intuitive point holds in practice most of the
time.
LL
Cheers,
> waxwing/AdamISZ
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> --- Original Message ---
> On Monday, May 8th, 2023 at 05:37, Lloyd Fournier via bitc
Hi Waxwing,
On Tue, 2 May 2023 at 02:37, AdamISZ wrote:
> Hi Lloyd,
> thanks for taking a look.
>
> > I think your view of the uselessness of single signer adaptors is too
> pessimistic. The claim you make is that they "don't provide a way to create
> enforcement that the publication of signatur
Hi waxwing,
I think your view of the uselessness of single signer adaptors is too
pessimistic. The claim you make is that they "don't provide a way to
create enforcement that the publication of signature on a pre-defined
message will reveal a secret'' and so are useless. I think this is wrong.
If
Hi Yuval,
This is an interesting attack. Usually I think of spending with a big
weight witness in the context of slowing down a confirmation of a
transaction, especially a DLC creation tx. There you can delay its
confirmation past some time (i.e. see if your team won the game, and then
either tryi
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 sh
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
spen
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
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 s
@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
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 outp
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 stru
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 origin
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 signed
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
inap
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
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 cra
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 wonder
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
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 are
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 se
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 th
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
2. Alic
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 mak
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 curr
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
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 mess
* 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
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:
>
https://github.com/sipa/bips/blob/bip-taproot
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 and
> 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
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 descripti
generation function.
>
> > 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,
&g
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 algorithm,
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, th
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 composable
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 computationa
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 com
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 t
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
Hi ZmnSCPxj,
I can give some context on the exchange during the talk. I was the "Q" and
Andrew Polestra was the "A".
I followed up with Andrew after and he indeed knew about the pre-signed
nlocktime transaction double spend technique (actually, I thought he was
the one who originally came up with
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 rela
46 matches
Mail list logo
