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