Re: [bitcoin-dev] Schnorr signatures BIP
Correct, there is an interaction step to deduce G*k, when signing, each participant has to publishes G*ki. I didn't talk about it. That doesn't break it, but you're correct, it's not non-interactive. On Wed, Sep 5, 2018 at 9:06 AM Andrew Poelstra wrote: > On Wed, Sep 05, 2018 at 08:26:14AM -0400, Erik Aronesty wrote: > > Why would you call it FUD? All the weird hemming and hawing about it is > > really strange to me. The more I look into it and speak to professors > > about i, the more it seems "so trivial nobody really talks about it". > > > > 1. Generate an M of N shared public key (done in advance of signing > > this gets you the bitcoin address) > > 2. Generate signature fragments (this can be done offline, with no > > communication between participants) > > > > Detailed explanation with code snippets: > > > > > https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-e7860ab34e7f > > > > The hemming and hawing is because you've been repeatedly told that your > scheme doesn't work, and to please implement it in some computer algebra > system so that you can see that (or so we can see where your mistake is), > and you instead continue to post incomplete/incoherent copies of the same > thing across multiple mediums - Reddit, this list, Bitcointalk, Medium, > etc ad nauseum. > > It's distracting and offensive to people who have spent a lot of time and > energy thinking about this stuff, and more importantly it causes confusion > in the public eye. Phrasings like "weird hemming and hawing" suggest that > we don't know/don't care about some insight you have, which is not true. > This is why your posts are FUD. > > For example, in your linked post I looked at every single instance of the > character 'k' and *not one of them* defined the value 'k' from which 'R' > is derived in the signing procedure. > > > Of course there is no possible value, individual signers cannot learn 'R' > at signing time without interaction, and your whole scheme is broken. Given > the number of times you've been told this, I find it hard to believe that > this was an honest mistake. > > > > Andrew > > > > -- > Andrew Poelstra > Research Director, Mathematics Department, Blockstream > Email: apoelstra at wpsoftware.net > Web: https://www.wpsoftware.net/andrew > > "Make it stop, my love; we were wrong to try > Never saw what we could unravel in traveling light > Nor how the trip debrides like a stack of slides > All we saw was that time is taller than space is wide" >--Joanna Newsom > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Schnorr signatures BIP
Why would you call it FUD? All the weird hemming and hawing about it is really strange to me. The more I look into it and speak to professors about i, the more it seems "so trivial nobody really talks about it". 1. Generate an M of N shared public key (done in advance of signing this gets you the bitcoin address) 2. Generate signature fragments (this can be done offline, with no communication between participants) Detailed explanation with code snippets: https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-e7860ab34e7f On Sun, Sep 2, 2018 at 8:05 PM Andrew Poelstra wrote: > On Wed, Aug 29, 2018 at 08:09:36AM -0400, Erik Aronesty wrote: > > Note: > > > > This spec cannot be used directly with a shamir scheme to produce > > single-round threshold multisigs, because shares of point R would need to > > be broadcast to share participants in order to produce valid single > > signatures. > > > > (R, s) schemes can still be used "online", if share participants publish > > the R(share) but, not sure if it matter much, this choice eliminates > > offline multiparty signing in exchange for batch validation. > > > > Please stop with this FUD. No tradeoff was made. There are no > non-interactive > Schnorr signatures. > > > Andrew > > > -- > Andrew Poelstra > Mathematics Department, Blockstream > Email: apoelstra at wpsoftware.net > Web: https://www.wpsoftware.net/andrew > > "A goose alone, I suppose, can know the loneliness of geese > who can never find their peace, > whether north or south or west or east" >--Joanna Newsom > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Testnet3 Reest
On Fri, Aug 31, 2018 at 9:43 PM Gregory Maxwell via bitcoin-dev wrote: > We looked at doing this previously in Bitcoin core and jtimon had some > patches, but the existing approach increased the size of the > blockindex objects in memory while not in signed testnet mode. This > could probably have been fixed by turning one of the fields like the > merkel root into a union of it's normal value and a pointer a > look-aside block index that is used only in signed block testnet mode. I am currently working on an implementation that simply puts a global mapping of block hash to signature that is transparently (de)serialized in the block header. We were looking into various ways to stuff the signature into the actual header itself without changing its size, but this looked like it required truncating the prevblock/merkleroots and such, which seemed a bit too invasive. I don't think my approach with a global mapping to sig differs in any meaningful way from your suggested union, but corrections welcome. The code is here: https://github.com/kallewoof/bitcoin/tree/signet I believe jtimon is interested in helping out, and Jeremy Rubin has also said he wants to help. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Schnorr signatures BIP
On Wed, Sep 05, 2018 at 08:26:14AM -0400, Erik Aronesty wrote: > Why would you call it FUD? All the weird hemming and hawing about it is > really strange to me. The more I look into it and speak to professors > about i, the more it seems "so trivial nobody really talks about it". > > 1. Generate an M of N shared public key (done in advance of signing > this gets you the bitcoin address) > 2. Generate signature fragments (this can be done offline, with no > communication between participants) > > Detailed explanation with code snippets: > > https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-e7860ab34e7f > The hemming and hawing is because you've been repeatedly told that your scheme doesn't work, and to please implement it in some computer algebra system so that you can see that (or so we can see where your mistake is), and you instead continue to post incomplete/incoherent copies of the same thing across multiple mediums - Reddit, this list, Bitcointalk, Medium, etc ad nauseum. It's distracting and offensive to people who have spent a lot of time and energy thinking about this stuff, and more importantly it causes confusion in the public eye. Phrasings like "weird hemming and hawing" suggest that we don't know/don't care about some insight you have, which is not true. This is why your posts are FUD. For example, in your linked post I looked at every single instance of the character 'k' and *not one of them* defined the value 'k' from which 'R' is derived in the signing procedure. Of course there is no possible value, individual signers cannot learn 'R' at signing time without interaction, and your whole scheme is broken. Given the number of times you've been told this, I find it hard to believe that this was an honest mistake. Andrew -- Andrew Poelstra Research Director, Mathematics Department, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew "Make it stop, my love; we were wrong to try Never saw what we could unravel in traveling light Nor how the trip debrides like a stack of slides All we saw was that time is taller than space is wide" --Joanna Newsom signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
