--- Log opened Tue Dec 17 00:00:41 2019
01:06 -!- andytosh1 [~apoelstra@wpsoftware.net] has joined #bitmetas
01:06 -!- jnewbery_ [~john@4.53.92.114] has joined #bitmetas
01:09 -!- bsm1175321 [~bsm117532@unaffiliated/bsm117532] has joined #bitmetas
01:10 -!- Netsplit *.net <-> *.split quits: andytoshi, instagibbs, Madars, jnewbery
01:11 -!- Netsplit *.net <-> *.split quits: bsm117532
01:11 -!- Netsplit over, joins: instagibbs
01:12 -!- andytosh1 [~apoelstra@wpsoftware.net] has quit [Ping timeout: 268 seconds]
01:17 -!- Madars [~null@unaffiliated/madars] has joined #bitmetas
03:32 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 248 seconds]
04:43 -!- jonatack [~jon@213.152.161.117] has joined #bitmetas
05:03 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has quit [Quit: ZNC 1.7.5 - https://znc.in]
05:05 -!- real_or_random [~real_or_r@173.249.7.254] has joined #bitmetas
06:33 -!- jonatack [~jon@213.152.161.117] has quit [Ping timeout: 245 seconds]
08:19 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #bitmetas
08:19 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]
08:19 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #bitmetas
08:29 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitmetas
09:13 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 246 seconds]
10:02 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #bitmetas
10:02 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]
10:02 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #bitmetas
10:34 < sipa> so, another idea: we already have, even for key path spends, a field in the witness that is not signed by the signature: the signature stack element itself
10:35 < sipa> if we'd permit the signature to be longer than 65 bytes, and the bytes after the 65th are ignored (but nonstandard)
10:36 < sipa> you could implement graftroot by putting the script-signed-over-to in an annex, and the inputs to that script in the toplevel signature
10:52 < andytoshi> is the total witness length signed?
10:52 < andytoshi> what prevents a 3rd party malleating this?
10:55 < sipa> oh, of course
10:55 < sipa> just nonstandardness would prevent that, which is not the nonmalleabiloty guarantee we aim for in other design choices
10:57 < andytoshi> oh yeah i gotcha
10:58 < sipa> the earlier graftroot-as-annex idea also has this problem
10:58 < sipa> ok, great, that's another reasom not to change things anymore :)
11:02 < andytoshi> yeah this is pretty cool
11:02 < sipa> i think it's very cool, but not quite good enough to actually accomodate
11:03 < sipa> aj earlier argued that without half aggregation graftroot is also only meh
11:04 < andytoshi> yeah, i would agree with that
11:04 < andytoshi> my initial excitement i think was because i thought we'd get different functionality from graftroot, vs a 1-in-1-out transaction
11:06 < aj> i thought graftroot was exactly as functional as a 1-in-1-out tx which was why it wasn't scary?
11:07 < andytoshi> well, it's 1-in-1-out but with a weird sighash mode
11:24 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 248 seconds]
11:29 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitmetas
11:35 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 268 seconds]
11:38 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitmetas
11:48 < jl2012> You may have a new sighash flag to allow extra data after the key path signature
11:50 < jl2012> But due to the lack of ANYPREVOUT in key path, the use case of graftroot is limited
11:51 < sipa> but a new sighash flag in the key path spend requires a new witness version anyway
11:51 < aj> it'd be a sighash_no_extra_data that's on by default and available from day 1, no?
11:57 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined #bitmetas
12:13 < aj> current survey results are 10 of 10 giving an ACK fwiw
12:48 < aj> sipa: you had "???" in "next steps" and didn't follow that up with "PROFIT" ???
12:49 < sipa> aj: i thought about doing that
12:50 < aj> hmm, maybe just letting everyone subconsciously think it is more persuasive
13:10 < jl2012> Is there a proof for the safety of halfagg?
13:12 < aj> don't think there's one written up anywhere?
13:14 < instagibbs> aj, more like "BRO DOWN"
13:23 < sipa> i have talked to both yannick seurin and dan boneh about half agg, and iirc both agreed that it's secure if you hash all keys/messages/nonces in the randomizers
13:23 < sipa> but nothing written up
14:47 < elichai2> andytoshi: I opened a PR for adding the pdf but I understand if you'd rather do it yourself because there's no good way to review binaries on git :/ (and pdflatex isn't deterministic so can't compare hashes) 
15:06 < andytoshi> elichai2: heh interesting point
15:07 < andytoshi> i could just trust you
15:07 < elichai2> That's fine too :) 
15:07 < elichai2> Just thought I should point out to you 
15:10 < andytoshi> merged
15:10 < andytoshi> i glanced at it, it looked like my style and you didn't add any of the swear words i spot-checked :P
15:11 < elichai2> LOOL
15:12 < elichai2> You didn't notice the "nobody really understands this shit just trust me" sentence at the end of the proof? ;) 
16:18 < jl2012> I think aggregation and graftroot are orthogonal. Only the latter allows you to do something that's not possible today
16:21 < jl2012> Graftroot is much easier to develop, so there is no reason to delay it for aggregation
16:23 < jl2012> Does MuSig have the same security assumptions as full aggregation?
16:25 < sipa> well it depends on what you mean by full aggregation
16:25 < sipa> as you can implement cross-input aggregation using musig-at-verify-time
16:26 < sipa> you can also use bellare-neven, which iirc has a tighter security reduction (but the same assumptions as musig's proof)
17:07 < jl2012> Tighter security reduction means less or equally secure?
17:08 < sipa> tighter security reduction means more secure
17:14 < sipa> or at least, the extent to which security is proven is higher
17:18 < sipa> so from a conservative security stanpoint, for cross-input aggregation we should use something based on bellare-neven
17:18 < sipa> though the assumptions for proving musig and bn secure are the same (ROM/DL)
17:43 < jl2012> BN does not allow public key aggregation?
17:43 < sipa> indeed
17:43 < jl2012> If MuSig is secure, BN must be secure?
17:43 < sipa> i don't know if there is a reduction from one to the other
17:43 < sipa> only a reduction from both to DL
17:44 < sipa> they're also similar computationally
18:54 < real_or_random> Now that you mention this I think the reason why MuSig's reduction is not as tight is that it needs the forking lemma twice. But that's assuming interactive signing 
18:55 < sipa> yes
18:55 < sipa> right, for cross-input aggregation where all inputs are signed by the same participant this does not apply
18:58 < real_or_random> hm okay, my first thought was that we may be able to get rid of the second forking... but the verifier still needs to compute the aggregated key. no idea, but we should have a look at this 
18:59 < real_or_random> repeating my messages, not sure if they arrived:
18:59 < real_or_random> 03:54 <real_or_random> Now that you mention this I think the reason why MuSig's reduction is not as tight is that it needs the forking lemma twice. But that's assuming interactive signing 
18:59 < real_or_random> 03:57 <real_or_random> (if I remember correctly) the second forking is due to the hashes in the aggregated key... 
18:59 < real_or_random> 03:58 <real_or_random> hm okay, my first thought was that we may be able to get rid of the second forking... but the verifier still needs to compute the aggregated key. no idea, but we should have a look at this 
19:13 < sipa> they arrived
--- Log closed Wed Dec 18 00:00:40 2019