--- Log opened Mon Aug 09 00:00:33 2021
00:39 -!- jesseposner [~jesse@2601:647:0:89:e1d3:fa86:96b9:558] has quit [Ping timeout: 258 seconds]
00:40 -!- jesseposner [~jesse@2601:647:0:89:fc81:4172:cf69:7179] has joined #secp256k1
00:41 -!- waxwing [~waxwing@193.29.57.116] has quit [Changing host]
00:41 -!- waxwing [~waxwing@user/waxwing] has joined #secp256k1
02:14 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: Client closed]
03:13 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
03:46 -!- siv2r09 [~siv2r@103.77.37.165] has quit [Quit: Ping timeout (120 seconds)]
03:46 -!- siv2r09 [~siv2r@103.77.37.165] has joined #secp256k1
04:55 < real_or_random> re musig-dn-dn: this was something which we fixed very late in our writeup, I think only after some reviewer rightfully complained 
04:57 < real_or_random> we claim that the entire point of musig-dn is avoiding randomness but  then we in early revision of the paper, the signing algorithm used randomness for the NIZK proof...
05:00 < real_or_random> re "signing session":  Useful terminology often depends on the context and background of the reader. The background of the MuSig2 paper is the existing three-round  MuSig1, which clearly has something like a signing session., and we need to talk about MuSig1 too in this paper, so it makes sense to use the term "signing session" because it enables us to compare both protocols (and it would apply to any kind of protocol, no 
05:00 < real_or_random> matter how many rounds)
05:01 < real_or_random> That's why we call the two steps of the signing session Sign and Sign'.
05:01 < real_or_random> I think if you explain MuSig2 from scratch, then "Prepare" and "Sign" would be better terms. I agree that "Sign" relates to the point in time where the user commits to make a signature.
05:06 < real_or_random> And even though it's not clear from the terminology, the formal model in which we prove MuSig2 captures this: You can safely call "Prepare" as many times as  you wish and this won't help an attacker to obtain signatures. Only after you call "Sign(..., m, ...)" with some message m, you're committed to making a signature and it's possible to obtain a signature on m.
05:07 < real_or_random> To make things even more complicated: In MuSig1, the point of where the protocol expects a message and the point where you commit to making a signature are different.
05:09 < real_or_random> In MuSig1: You can safely perform the first round as many times as you wish and nothing happens. Then to perform the second round, the message *needs* to be fixed, otherwise you lose security. But only when you perform the third round, you commit to making a signature.
05:10 < real_or_random> In other words, these two properties are true: 1) You can preprocess only the first round without knowing the message. 2) You can still abort after the second round if you do not wish to sign.
05:13 < real_or_random> (But neither of these two useful properties has been formally proven in the MuSig1 paper. This is another thing we improved in the MuSig2 paper,  as I mentioned above.) 
05:16 < real_or_random> I guess we should create a multisignature FAQ with all these things and keep it updated
05:18 < real_or_random> there are many great write-up that mention particular features and subtleties but there's no single place to refer people to
05:58 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #secp256k1
06:01 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 250 seconds]
06:03 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
06:03 -!- lukedashjr [~luke-jr@user/luke-jr] has quit [Ping timeout: 248 seconds]
06:03 -!- siv2r09 [~siv2r@103.77.37.165] has quit [Quit: The Lounge - https://thelounge.chat]
06:12 -!- siv2r09 [~siv2r@103.77.37.165] has joined #secp256k1
06:54 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
06:56 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
09:12 -!- siv2r09 [~siv2r@103.77.37.165] has quit [Quit: The Lounge - https://thelounge.chat]
09:55 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
09:56 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
11:13 -!- kanzure_ is now known as kanzure
11:56 -!- DeanGuss [~dean@user/deanguss] has quit [Remote host closed the connection]
11:57 -!- DeanGuss [~dean@nonplayercharacter.me] has joined #secp256k1
11:57 -!- DeanGuss [~dean@nonplayercharacter.me] has quit [Changing host]
11:57 -!- DeanGuss [~dean@user/deanguss] has joined #secp256k1
17:06 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: Client closed]
18:20 -!- elichai2_ [sid212594@id-212594.stonehaven.irccloud.com] has joined #secp256k1
18:21 -!- FelixWeis_ [sid154231@id-154231.stonehaven.irccloud.com] has joined #secp256k1
18:23 -!- jesseposner_ [~jesse@2601:647:0:89:fc81:4172:cf69:7179] has joined #secp256k1
18:25 -!- elichai2 [sid212594@stonehaven.irccloud.com] has quit [Read error: Connection reset by peer]
18:25 -!- FelixWeis [sid154231@stonehaven.irccloud.com] has quit [Read error: Connection reset by peer]
18:25 -!- jesseposner [~jesse@2601:647:0:89:fc81:4172:cf69:7179] has quit [Read error: Connection reset by peer]
18:25 -!- FelixWeis_ is now known as FelixWeis
18:25 -!- elichai2_ is now known as elichai2
21:27 < harding> If anyone's interested in reviewing, a draft of the text we plan to run in Wednesday's Optech Newsletter, inspired by the conversations here last week, is at https://deploy-preview-625--bitcoinops.netlify.app/en/newsletters/2021/08/11/#preparing-for-taproot-8-multisignature-nonces with the commit at https://github.com/bitcoinops/bitcoinops.github.io/pull/625/commits/1c873dc53220eb0355c00fd8d22f25e47c0b7b7c ; it's less exciting than I was hoping for; 
21:27 < harding> it quickly explains at a high level why nonces are needed, why they can't be reused, the extra challenge of avoiding reuse in multisignatures, and touches on the challenges of storing them during a possibly extended multisignature signing session.  It also recommends people planning to use multisignatures in their software/hardware come here and describe what they plan to do before putting too much time/money into it so y'all can hopefully talk them 
21:27 < harding> out of bad decisions.
21:40 -!- belcher_ [~belcher@user/belcher] has joined #secp256k1
21:44 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 256 seconds]
--- Log closed Tue Aug 10 00:00:34 2021