On Tue, Jul 03, 2018 at 11:45:22PM +, Gregory Maxwell wrote:
> On Tue, Jul 3, 2018 at 5:21 AM, Peter Todd wrote:
> > The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing
> > about what the flag actually does.
>
> I believe that making the signature replayable is 1:1
On Mon, Jul 9, 2018 at 3:02 PM, Erik Aronesty via bitcoin-dev
wrote:
> and where H(g*x) can
> be considered their public index for the purposes of Shamir polynomial
> interpolation
This is isomorphic to the insecure musig variant where keys are
blinded by H(g*x) instead of a commitment to all
Because it's non-interactive, this construction can produce multisig
signatures offline. Each device produces a signature using it's own
k-share and x-share. It's only necessary to interpolate M of n shares.
There are no round trips.
The security is Shamir + discrete log.
it's just
Can you please clarify which terms in that description are elliptic curve
points, and which are scalars?
On Mon, Jul 9, 2018 at 11:10 AM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Actually, it looks like in order to compute a multiparty signature you
> will
On Mon, Jul 9, 2018 at 4:33 PM, Erik Aronesty wrote:
>>> with security assumptions that match the original Schnorr construction more
>>> closely,
>> More closely than what?
> More closely than musig.
Musig is instructions on using the original schnorr construction for
multiparty signing which
Actually, it looks like in order to compute a multiparty signature you will
need to broadcast shares of r first, so it's not offline :(
It is still seems, to me, to be a simpler mechanism than musig - with
security assumptions that match the original Schnorr construction more
closely, and should
On Mon, Jul 9, 2018 at 3:02 PM, Erik Aronesty via bitcoin-dev
wrote:
> with
> security assumptions that match the original Schnorr construction more
> closely,
More closely than what?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
- Adaptive r choice shouldn't be possible since r is derived from the
original threshold prf and it's not possible for a party to have any
adaptive impact on the value of r
- I'm guess I don't see how an attacker can use adaptive key choice in
this context either. Any modification of the key
