--- Day changed Sun Feb 09 2020 00:37 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds] 02:09 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Excess Flood] 02:09 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-bip-review 03:13 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection] 03:13 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Read error: Connection reset by peer] 03:13 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 03:16 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined ##taproot-bip-review 03:30 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-bip-review 03:38 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##taproot-bip-review 03:45 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-bip-review 03:58 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 03:59 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-bip-review 06:00 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 06:10 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 06:11 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-bip-review 07:07 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection] 07:08 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined ##taproot-bip-review 09:38 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 09:40 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-bip-review 11:22 < aj> fyi, https://bitcoincore.reviews/16902.html -- some of the preliminary PRs for taproot are on the review club agenda this week 11:24 < harding> \o/ 11:26 < aj> also, if anyone's interested in an asia-friendly timezone, https://twitter.com/kallewoof/status/1226442693628350464 11:54 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined ##taproot-bip-review 12:01 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 12:01 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##taproot-bip-review 13:24 -!- Netsplit *.net <-> *.split quits: so, ariard_ 13:25 -!- Netsplit over, joins: so, ariard_ 13:26 -!- so [~so@unaffiliated/so] has quit [Max SendQ exceeded] 13:26 -!- so [~so@unaffiliated/so] has joined ##taproot-bip-review 13:29 -!- Netsplit *.net <-> *.split quits: _0x0ff, nehan_, Aleru, philbw4, felixweis, fanquake, chm-diederichs, nothingmuch, evoskuil[m], Jackielove4u, (+2 more, use /NETSPLIT to show all of them) 13:30 -!- Netsplit over, joins: nothingmuch, felixweis, _0x0ff, evoskuil[m], fanquake, Jackielove4u, raj_, nehan_, chm-diederichs, Aleru (+2 more) 13:31 -!- Netsplit *.net <-> *.split quits: bsm117532, BlueMatt 13:31 -!- Netsplit *.net <-> *.split quits: maaku, willcl_ark 13:32 -!- Netsplit over, joins: willcl_ark, maaku 13:32 -!- Netsplit over, joins: bsm117532, BlueMatt 13:33 -!- Netsplit *.net <-> *.split quits: jnewbery, digi_james, pinheadmz, midnight 13:33 -!- Netsplit over, joins: jnewbery 13:33 -!- Netsplit over, joins: pinheadmz 13:33 -!- digi_james [sid281632@gateway/web/irccloud.com/x-dfjtnwutsesastim] has joined ##taproot-bip-review 13:34 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##taproot-bip-review 13:35 -!- Netsplit *.net <-> *.split quits: luke-jr, tecnovert 13:35 -!- Netsplit *.net <-> *.split quits: devrandom, lightningbot, meshcollider, harding, udiWertheimer, ajonas, amiti, RubenSomsen 13:36 -!- Netsplit *.net <-> *.split quits: fjahr, ariard_, arik__, maaku, hebasto, bsm117532, takinbo, philbw4, midnight, chm-diederichs, (+40 more, use /NETSPLIT to show all of them) 13:36 -!- Netsplit over, joins: tecnovert 13:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-bip-review 13:36 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined ##taproot-bip-review 13:36 -!- harding [quassel@2600:3c03::f03c:91ff:fe7b:78d1] has joined ##taproot-bip-review 13:36 -!- udiWertheimer [sid190185@gateway/web/irccloud.com/x-zbmgbozogiiedrvl] has joined ##taproot-bip-review 13:36 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-bwhyuyenhxtslndx] has joined ##taproot-bip-review 13:36 -!- ajonas [sid385278@gateway/web/irccloud.com/x-bdauihemiemvovns] has joined ##taproot-bip-review 13:36 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-sbtjxckdujyurjue] has joined ##taproot-bip-review 13:36 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined ##taproot-bip-review 13:36 -!- amiti [sid373138@gateway/web/irccloud.com/x-lbthmiefwmwhywun] has joined ##taproot-bip-review 13:36 -!- Netsplit over, joins: midnight, BlueMatt, pinheadmz, willcl_ark, _0x0ff, so, jeremyrubin, ghost43, afk11, elichai2 (+34 more) 13:36 -!- evoskuil[m] [evoskuilma@gateway/shell/matrix.org/x-smutavsdsnemjhnr] has quit [Ping timeout: 240 seconds] 13:36 -!- Netsplit *.net <-> *.split quits: so, pigeons, achow101, jeremyrubin, pipirell1, soju_ 13:38 -!- Netsplit over, joins: so, jeremyrubin, pigeons, achow101, soju_, pipirell1 13:38 -!- Netsplit *.net <-> *.split quits: real_or_random, arik__ 13:38 -!- Netsplit *.net <-> *.split quits: aj, justinmoon, fjahr, marcinja, moneyball, schmidty, elichai2, Lexyon__, dmkathayat, takinbo 13:39 -!- amiti [sid373138@gateway/web/irccloud.com/x-lbthmiefwmwhywun] has quit [Ping timeout: 260 seconds] 13:39 -!- Netsplit over, joins: waxwing, asoltys, andytoshi, gambpang, nickler, hebasto 13:39 -!- Netsplit over, joins: arik__, real_or_random, fjahr, takinbo, aj, elichai2, Lexyon__, schmidty, moneyball, dmkathayat (+2 more) 13:39 -!- Netsplit *.net <-> *.split quits: ghost43, sipa, afk11 13:39 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-cbgzncrypihcnuzr] has quit [Ping timeout: 245 seconds] 13:41 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-bwhyuyenhxtslndx] has quit [Ping timeout: 260 seconds] 13:42 -!- so [~so@unaffiliated/so] has quit [Ping timeout: 240 seconds] 13:42 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-bbjyzezpdeacymrx] has joined ##taproot-bip-review 13:42 -!- schmidty [sid297174@gateway/web/irccloud.com/x-frphjgyxoixiqfhi] has quit [Ping timeout: 245 seconds] 13:44 -!- schmidty [sid297174@gateway/web/irccloud.com/x-qcozuqvpewfxjjtb] has joined ##taproot-bip-review 13:44 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##taproot-bip-review 13:44 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-bip-review 13:44 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined ##taproot-bip-review 13:45 -!- Netsplit *.net <-> *.split quits: afk11, ghost43, sipa 13:47 -!- waxwing [~waxwing@193.29.57.116] has quit [Changing host] 13:47 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined ##taproot-bip-review 13:47 -!- amiti [sid373138@gateway/web/irccloud.com/x-jhpefzydvqyueffi] has joined ##taproot-bip-review 13:48 -!- so [~so@unaffiliated/so] has joined ##taproot-bip-review 13:50 -!- Netsplit over, joins: ghost43, afk11, sipa 13:50 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-poaqqqpfoopjpogd] has joined ##taproot-bip-review 14:02 -!- Netsplit *.net <-> *.split quits: afk11, ghost43, sipa 14:07 -!- Netsplit over, joins: ghost43, afk11, sipa 14:34 -!- mol [~molly@unaffiliated/molly] has joined ##taproot-bip-review 17:50 < harding> instagibbs: saw your tweet, I guess my email was unclear because what you said is what I was trying to say in the email. 17:50 < harding> https://twitter.com/theinstagibbs/status/1226663192455049216 17:51 < harding> instagibbs: I was trying to say that any n-of-n spends can be part of the anonymity set, which would include current n-of-n OP_CHECKMULTISIG users like Blockstream Green. 17:53 < harding> (Sorry for not replying on Twitter; I periodically lock myself out of my account for a week at a time when I think I'm spending too much time there, so I can't reply until Tuesday.) 17:53 < moneyball> fwiw that is how i read harding's response 18:37 < gmaxwell> harding: it's unclear how much current N of N (or other multisig) will eventually use schnorr multisig vs continue using CHECKMULTISIG, particularly because multisig implies additional rounds which are extremely inconvient for some use cases. 18:38 < harding> gmaxwell: yeah, fair point. 18:49 < aj> gmaxwell: n-of-n for cold wallets looks hard, but n-of-n for online hot wallets (lightning and maybe exchange hot wallets?) could mostly work? 18:50 < gmaxwell> yeah, e.g. the blockstream green thing has two online keys and an offline key (or two online keys and some csv timeout thing). 18:50 < gmaxwell> Thats why I said 'some use cases', instead of all. :) 18:51 < gmaxwell> In any case, I don't mean to be negative-- I think it's just a genuinely open question how often it'll be used. 18:51 < gmaxwell> obviously I'd like to see it used a lot. 18:54 < sipa> there are some things that can fundamentally not use the key path (e.g. if you want a policy that enforces a timelock in all conditions) - for those cases, having a pure MAST without taproot construction would be advantageous for efficiency 18:54 < sipa> but i think those are extremely rare 18:55 < gmaxwell> or, even, arguably irrational. 18:55 < sipa> for everything else it's a question of software complexity and tradeoffs whether using the super cheap key path is worth it 18:55 < sipa> i expect that often it won't be, but i very much like the incentive that it gives 18:56 < gmaxwell> even for online users, having the code to handle a multiround protocol is a big hurdle. ... thats a lot of why it took so many years for payment channels to exist. 18:57 < gmaxwell> It's extremely easy to implement a pure-ish function that takes a transaction adds a signature if it likes it and passes it along. Much harder to make some multistep protocol. Though at least there isn't a ton of complicated state that needs to be managed. 18:57 < aj> i wonder how much psbt support will simplify multiround signing protocols 18:58 < gmaxwell> I'm sure some people will implement musig signing by just making a service that serves up nonce commitments and their openings, disconnected from signing, and will end up exploitable as a result. :( 21:15 < gmaxwell> harding: re your email: arbitary k-of-n can also use the keypath, so long as they don't mind an interactive process (and storage) for generating their key in the first place. 21:15 < gmaxwell> harding: not just k-of-n where you can stick a k-of-k at the top. 21:17 < gmaxwell> harding: don't let the blockstream guys liquid specific focus create confusion on that. Nickler, andytoshi, etc. care a lot about a specific application where if someone you expects to sign instead emits garbage it won't cause any delay. Turns out that case is hard to solve, esp of n choose k is large enough that you can't just attempt all subset-signings in parallel. 21:18 < gmaxwell> But that particular usage really only aplies to time critical unattended automated systems. 21:19 < gmaxwell> All the existant CHECKMULTISIG usage I've seen (except for liquid) is not robust to broken signers... in copay or bitcoin core psbt workfor for example, if a signer insists on producing invalid sigs you'll just get inscrutiable failures. 21:20 < gmaxwell> If you're okay with getting an inscrutiable failure and having to retry with different signers, then a relatively straight-forward process lets you sign w/ the keypath using an arbritary threshold. 21:25 < gmaxwell> Essentially the process for K of N is: Each of the N parties makes a private key, each of the N parties makes a K of N sharing of their private key and distributes it to all the other parties. Each of the parties checks that they recieved consistent shares, and saves their shares of other parties keys. The key you pay to is the N of N key of all parties (you can, of course, also make bip32 21:25 < gmaxwell> tweaks of the result to get multiple keys from one setup process). Then at signing time, you sign like a K of K, except for your private key you also add in your shares of the N-K missing participants. 21:27 < gmaxwell> this simple version has the problem that if one of your signers is broken/malicious he can make your signatures fail. You can detect that (his partial signature, which you can verify on its own, will be invalid), but to continue you'd have to kick him out and the signing over with a different K that doesn't include him. 21:33 < gmaxwell> Verifyable secret sharing itself is pretty freeking simple. You implement standard SSS over the GF(N) field of the secp256k1 scalars, and send the person their share... and send everyone else their share converted into a public key. The interpolation process to recover the SSS value can be applied equally to pubkeys as it can be applied to scalars, so you use this fact to make sure that 21:33 < gmaxwell> everyone's shares add up correctly and can-- in fact-- be used to recover each player's pubkey. The reason for this step is because if you don't check, one signer could mess up their sharing and you wouldn't be able to sign without them. 21:35 < gmaxwell> My view is that the primary impedimate for most users is just that the multiple round trips suck-- but thats the same story for K of K except for K of K there isn't anything you can do with a malicious signer other than identify them to the user. 21:39 < gmaxwell> Someone could argue that the need to backup the shares is also an extra burden, but thats not clear to me: even for a N of N or checkmultisg you have to backup the redeemscript (or redeemscript template) -- otherwise if you forget your counterparties pubkeys, you're hosed. 21:40 < gmaxwell> An implementation could be hardened somewhat if you took the shares you recieved, encrypted them with a master key, and asked all participants to store them... I think at that point the durability requirements are identical to a script-hash CHECKMULTISIG except it's a bit more data to store.