{"type":"rich","version":"1.0","author_name":"npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","author_url":"https://nostr.ae/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-09-11\n📝 Original message:Greg,\n\nI added, stripped out, and added analogous musig delinearization 3 times in\nresponse to stuff posted here.  I'm adding it back now. Not sure why my\nhead is thick around that issue.\n\nThe security advantages of a redistributable threshold system are huge.\nIf a system isn't redistributable, then a single lost or compromised key\nresults in lost coins... meaning the system is essetntially unusable.\n\nI'm actually worried that Bitcoin releases a multisig that encourages loss.\n\n\n\n\nOn Tue, Sep 11, 2018 at 1:00 PM Gregory Maxwell \u003cgreg at xiph.org\u003e wrote:\n\n\u003e On Tue, Sep 11, 2018 at 4:34 PM Erik Aronesty \u003cerik at q32.com\u003e wrote:\n\u003e\n\u003e\u003e To answer points:\n\u003e\u003e\n\u003e\u003e - I switched to the medium article so that I could correct, edit and\n\u003e\u003e improve things to make them more clear.\n\u003e\u003e - I responded to feedback by modifying the protocol to make it work - not\n\u003e\u003e by ignoring it.\n\u003e\u003e\n\u003e\n\u003e To this moment there remains no response at your post.\n\u003e https://bitcointalk.org/index.php?topic=4973123.0\n\u003e\n\u003e I'm not sure how I am supposted to have figured out that you wrote a\n\u003e somewhat different repost of it elsewhere...\n\u003e\n\u003e - An M-1 rogue-key attack would require the attacker would to either\n\u003e\u003e\n\u003e\u003e   - attack the hash function to produce a predictable R based on a known\n\u003e\u003e mesage\n\u003e\u003e   - attack the DLP to influence x or k\n\u003e\u003e\n\u003e\u003e Neither attack gives any particular advantage to someone who has M-1 keys.\n\u003e\u003e\n\u003e\n\u003e You keep asserting this. It isn't true. Asserting it more does not make it\n\u003e any more true.  I already explained how to attack this style of signature\n\u003e (e.g. in the BCT thread).\n\u003e\n\u003e Set aside your 'interpolation' for a moment, and imagine that you\n\u003e construct a 2 of 2 signature by just adding the keys.  Your tell me your\n\u003e key, P1  and then I tell you that my key P2 which I derived by computing\n\u003e -P1  + xG.   We now compute P = P1 + P2 = P1 + -P1 + xG = xG ... and now in\n\u003e spite adding P1 with an unknown discrete log, I know the discrete log of P\n\u003e with respect to G and I did not need to violate the standard DL security\n\u003e assumption to achieve that.\n\u003e\n\u003e With the 'interpolation' in effect the same attack applies but its\n\u003e execution is somewhat more complex: instead of adding the negation of P1  I\n\u003e must add a number of multiplicities of P1 (like P1*2, P1*3, P1*4...)\n\u003e selected so that their interpolation coefficients add up to -1. Finding a\n\u003e suitable subset requires solving a randomized modular subset sum problem\n\u003e and Wagner's algorithm provides a computationally tractable solution to it.\n\u003e\n\u003e The potential of rogue keys applies to both the keys themselves and to the\n\u003e nonces. There are several ways to prevent these attacks, the musig paper\n\u003e describes a delinearization technique which doesn't require additional\n\u003e interaction or communication.\n\u003e\n\u003e I haven't tested whether the R,s version is susceptible though.\n\u003e\u003e\n\u003e\n\u003e There is a perfect bijection between the two encodings which is easily\n\u003e computable, so they're the same thing from an abstract security perspective.\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180911/1dad3a33/attachment.html\u003e"}