--- Log opened Thu Nov 07 00:00:02 2019 00:00 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 250 seconds] 00:33 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 00:51 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #secp256k1 03:34 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Read error: Connection reset by peer] 04:53 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 265 seconds] 04:55 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #secp256k1 05:13 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 240 seconds] 05:14 -!- jonatack [~jon@213.152.162.74] has joined #secp256k1 06:07 -!- jonatack [~jon@213.152.162.74] has quit [Ping timeout: 264 seconds] 06:35 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 06:40 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 265 seconds] 08:02 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 08:14 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #secp256k1 08:22 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: No route to host] 08:23 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 08:26 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #secp256k1 09:42 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 10:21 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 11:02 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 12:18 < elichai2> the field arithmetic ASM is for arm, *not* arm64? 12:18 < sipa> correct 12:19 < elichai2> hmm, too bad. travis supports arm64 but not arm. wanted to add CI for that case 12:34 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Read error: Connection reset by peer] 12:43 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 13:12 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1 13:53 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #secp256k1 13:53 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host] 13:53 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #secp256k1 15:46 -!- gmaxwell [gmaxwell@wikimedia/KatWalsh/x-0001] has joined #secp256k1 15:46 < gmaxwell> https://www.reddit.com/r/Bitcoin/comments/dorlbl/bitcoin_optech_schnorrtaproot_workshop_online/f6smk76/ 15:47 < andytoshi> sigh 15:50 < gmaxwell> SSS is cryptography's vitamin C and he's our Linus Pauling. 15:50 < andytoshi> lol 15:53 < gmaxwell> it's like the perfect parallel, vitamin C is absolutely useful-- critical to human life, and understanding it was important to the development of modern civilization. And then there is a cult of people convinced that it's a cure-all, without any particular justification... and they even manage to make themselves sick from overusing it from time to time. 16:00 < sanket1729> Here are a couple of things you can do with SSS which (I think)you can't with multi-sig alone. Let me know if I am wrong. 16:00 < sanket1729> 1) You don't reveal that it is a multi-sig when it is spend 16:00 < sanket1729> 2) You can update the thresholds without creating a new transaction 16:01 < sanket1729> I am not advocating SSS in anyway. Just that I spent some time trying real hard to come up with things which SSS can do but multi-sig cannot 16:01 < sanket1729> clearly, dealing with signatures instead of private keys is a huge plus 16:01 < sipa> sanket1729: of course, there are obvious advantages... the question is whether they weigh up against the downside of bringing all keys to a single system (in a traditional setting) or the complexities of threshold signing (in a vss setting) 16:01 < gmaxwell> sanket1729: schnorr multisignature doesn't reveal that it is a multisignature. 16:02 < sanket1729> gmaxwell: for N of N right? or N of M too? 16:02 < gmaxwell> sanket1729: for N of M too. 16:03 < sipa> gmaxwell: better specify exactly which scheme you refer to 16:04 < gmaxwell> Somehow we managed to make a grave communication error, N of N is REALLY easy to explain... so e.g. bip schnorr points out that you can do that, and somehow more than a few people think that N of N is all you can do. 16:05 < sipa> gmaxwell: there is now a whole section in bip-tapscript that shows 4 different ways to do M of N 16:05 < gmaxwell> sanket1729: As far as updating thresholds, be careful with that-- you cannot in practice update thresholds for a shared secret except for strictly weakening security, unless you make strong and unrealistic assumptions about how users will act 16:06 < gmaxwell> (e.g. unless you assume the users will always securely delete their old shares and have no backups... and if you could trust them to act perfectly, why did you need to distribute the key in the first place? :) ) 16:08 < gmaxwell> sipa: I don't know if you followed the link, it's earonesty crapping on musig again and peddling his broken/insecure half understanding of secret sharing. 16:09 < sanket1729> I guess, I can cheat and reword that to delegation :) . N of M users can freely delegate to new N1 of M1 users 16:09 < sipa> gmaxwell, andytoshi: i think you're missing the simplest point earonesty is missing: he doesn't see the point of a degrading wallet... nothing related to SSS or thresholds or MuSig has anything to do with the fact that a degrading-multisig policy is interesting 16:09 < sanket1729> But agreed. it is not worth the complication 16:10 < gmaxwell> sanket1729: Under realistic usage the original N of M can still spend the coins, so you cannot go from some N of M set to a totally distinct N of M set... at best you can go from NofM to (NofM or N'ofM'). 16:11 < gmaxwell> I probably should add this resharing fallacy to the shamir secret snakeoil page. 16:11 < sipa> nor does fancy threshold tech (ignoring usability/complexity/security issues) in any way let you implement a degrading threshold policy, because it at least needs some CSV/CLTV based script 16:11 < gmaxwell> sipa: indeed, I was only paying attention to him again promoting his writeup, not the new motivation this time. 16:12 < gmaxwell> He thinks that re-sharing is a replacement for degrading it isn't, even if resharing could achieve the ideal functionality in the real world. 16:12 < sipa> sure, i'll go reshare my keys because i plan to be offline in the future! 16:12 < sipa> wtf 16:12 < gmaxwell> lol 16:13 < sipa> wouldn't that be great 16:14 < gmaxwell> andytoshi: good point that simple KOSK actually lets someone slip in a taproot script. 16:14 < gmaxwell> sipa: you should reply on that narrow point. If you're not going to, lemme know and I will. 16:14 < sipa> i'm not going to interact with him 16:14 < gmaxwell> Okay, I'll do it. 16:18 * sipa awaits the obvious "oh you just add one share that's timelock encrypted" suggestion as a solution to degrading thresholds 16:18 < andytoshi> i think greg's initial response was good. to the uninitiated it clearly says "you are a known crank" 16:18 < andytoshi> the rest might be fun, but probably not worth the effort :) 16:21 < gmaxwell> https://www.reddit.com/r/Bitcoin/comments/dorlbl/bitcoin_optech_schnorrtaproot_workshop_online/f6uzakl/ 16:21 < sipa> fair 16:21 < gmaxwell> revisions welcome 16:22 < sipa> lgtm 16:22 < sipa> without your help -> without their help 16:24 < gmaxwell> already fixed, thanks. 16:25 < sanket1729> just to clarify "degrading" means another spend condition which is timelocked? 16:25 < sipa> sanket1729: for example 2-of-3 that turns into 1-of-3 after some time 16:26 < gmaxwell> the term is in one of the presentations linked by the OP there. 16:27 < gmaxwell> sipa: does bip tapscript's list of ways to do n of m mention that you can do non-accountable thresholds with schnorr directly? 16:27 < sipa> yes 16:28 < gmaxwell> Sweet! 16:28 < sipa> it should probably be expanded to point out it's quite nontrivial 16:28 < sipa> https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki#cite_note-6 16:28 < gmaxwell> oh well it's pretty easy to do insecurely! 16:29 < sipa> haha, ok 16:30 < gmaxwell> I also kinda worry from hearing real_or_random talk that it might be the case that y'all may be at risk of your communication conflating signing time efficient byzantine robustness with doing it at all. 16:31 < andytoshi> yeah, that's true, we're trying to get this to work with liquid which needs to be unsupervised and therefore byzantine robust.. 16:31 < andytoshi> but many real-world scenarios have individuals acting where it's clear who's online and should be communicating and the whole thing is way simpler 16:31 < gmaxwell> Right. I think it's important to solve... but in the common use case where it's like a 2 of 3 and someone is getting out a signing hardware wallet, it's basically irrelevant. If it fails everyone yells at each other and tries again. 16:33 < gmaxwell> (and probably in those cases only $threshold people are participating at all.. at least until ByzantineBob has caused them to fail. and then they're like, shit, bob again? wake up Mary and kick him off the thread.) 16:37 < gmaxwell> I think this confusion is especially likely because byzantine fault at signing time is something a lot of people have just never thought of. For N of N it's not recoverable regardless... and for small thresholds you can simply handle it with retries or signing with all M choose N independantly in parallel. 16:38 < andytoshi> agreed on all counts 16:40 < gmaxwell> It only turns into an obviously hard problem when you're thinking about stuff like "I have 16 people online for an 11 of 20, and need to successfully sign even if 1-5 are malicious and don't want the bandwidth cost of running the signature 462 times in parallel" 18:26 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 18:30 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 245 seconds] --- Log closed Fri Nov 08 00:00:03 2019