Pieter Wuille

Note that Bitcoin's consensus rules rely on being able to set msghash=1 for pre-segwit transactions with SIGHASH_SINGLE set, for a txin index that doesn't have a corresponding txout index. That's...

Whatever approach is used to get automatic rerandomization upon signing will require an API with mutable objects, and the _sign function(s) currently take an immutable context object, for which it...

It's also provably does not impact the security of the signature scheme itself: there is no security risk from leaking the bit to an attacker, as it is at worst...

@gmaxwell I think it's used by a number of things, including BOLT11 in Lightning (where it helps avoiding encoding the payee ID), so I don't think that's a good idea,...

So, there are a bunch of related questions here: - Do we want a specific ECDH implementation, or do we want EC point-scalar multiplication? - For ECDH, we could have...

@gmaxwell Well a function that only takes an X coordinate and a scalar as input, and gives an X coordinate as output also satisfies that (doesn't need Y computing, and...

@apoelstra the ECDH function could accept NULL as point input, in which case it defaults to G, allowing the "pubkey creation" for ECDH with the same API.

One thing I like about using x-only is that it means all externally visible data structures are 32 bytes. Simply using _(p, Q.x) -> (pQ).x_ however leads to a malleability,...

I really see no way to avoid the malleability with x-only, without undoing the performance benefit. Am I missing something?

@peterdettman Use cases outside of Bitcoin are definitely not off the radar, though at some point we may need an extension mechanism, as those who want the library for signing-only...