12019-12-03T00:07:48  *** jonatack has quit IRC
  22019-12-03T00:49:00  *** Chris_Stewart_5 has quit IRC
  32019-12-03T01:08:31  *** Chris_Stewart_5 has joined ##taproot-bip-review
  42019-12-03T01:20:20  *** achow101 has quit IRC
  52019-12-03T01:21:53  *** Chris_Stewart_5 has quit IRC
  62019-12-03T02:07:26  *** achow101 has joined ##taproot-bip-review
  72019-12-03T03:26:59  *** reallll has joined ##taproot-bip-review
  82019-12-03T03:30:21  *** belcher has quit IRC
  92019-12-03T04:22:59  *** CubicEarth has quit IRC
 102019-12-03T04:23:00  *** arik_ has joined ##taproot-bip-review
 112019-12-03T04:41:11  *** CubicEarth has joined ##taproot-bip-review
 122019-12-03T05:09:06  *** arik_ has quit IRC
 132019-12-03T05:34:07  *** arik_ has joined ##taproot-bip-review
 142019-12-03T06:35:04  *** jonatack has joined ##taproot-bip-review
 152019-12-03T06:42:11  *** arik_ has quit IRC
 162019-12-03T07:05:49  *** pinheadmz has quit IRC
 172019-12-03T07:06:16  *** pinheadmz has joined ##taproot-bip-review
 182019-12-03T07:44:59  *** reallll is now known as belcher
 192019-12-03T08:15:05  *** jonatack has quit IRC
 202019-12-03T08:30:10  *** jonatack has joined ##taproot-bip-review
 212019-12-03T08:51:53  *** jonatack has quit IRC
 222019-12-03T08:54:37  *** davterra has quit IRC
 232019-12-03T08:58:52  *** b10c has joined ##taproot-bip-review
 242019-12-03T09:06:40  *** yaslama has joined ##taproot-bip-review
 252019-12-03T09:55:36  *** jonatack has joined ##taproot-bip-review
 262019-12-03T11:34:39  *** andytoshi has quit IRC
 272019-12-03T12:05:42  *** Chris_Stewart_5 has joined ##taproot-bip-review
 282019-12-03T12:40:12  *** davterra has joined ##taproot-bip-review
 292019-12-03T12:42:57  *** jonatack has quit IRC
 302019-12-03T12:46:33  *** davterra has quit IRC
 312019-12-03T12:48:37  *** Chris_Stewart_5 has quit IRC
 322019-12-03T12:51:48  *** Chris_Stewart_5 has joined ##taproot-bip-review
 332019-12-03T12:58:27  *** davterra has joined ##taproot-bip-review
 342019-12-03T13:15:23  *** andytoshi has joined ##taproot-bip-review
 352019-12-03T13:15:23  *** andytoshi has joined ##taproot-bip-review
 362019-12-03T14:11:13  *** pyskell has joined ##taproot-bip-review
 372019-12-03T14:35:15  *** arik_ has joined ##taproot-bip-review
 382019-12-03T14:47:57  *** arik_ has quit IRC
 392019-12-03T15:05:50  *** yaslama_ has joined ##taproot-bip-review
 402019-12-03T15:06:37  *** yaslama has quit IRC
 412019-12-03T15:15:31  *** pyskl has joined ##taproot-bip-review
 422019-12-03T15:19:44  *** pyskell has quit IRC
 432019-12-03T15:47:06  *** yaslama_ has quit IRC
 442019-12-03T16:16:45  *** jonatack has joined ##taproot-bip-review
 452019-12-03T16:41:48  *** _andrewtoth_ has quit IRC
 462019-12-03T16:55:04  *** arik_ has joined ##taproot-bip-review
 472019-12-03T17:25:10  *** nehan has joined ##taproot-bip-review
 482019-12-03T17:44:49  *** _andrewtoth_ has joined ##taproot-bip-review
 492019-12-03T18:13:14  *** davterra has quit IRC
 502019-12-03T18:46:45  *** Moller40 has joined ##taproot-bip-review
 512019-12-03T19:00:28  <pyskl> hi
 522019-12-03T19:00:32  *** pyskl is now known as pyskell
 532019-12-03T19:00:32  <kabaum> hi
 542019-12-03T19:00:49  *** pyskell has quit IRC
 552019-12-03T19:00:49  *** pyskell has joined ##taproot-bip-review
 562019-12-03T19:01:17  <jonatack> hi
 572019-12-03T19:01:31  <instagibbs> hi
 582019-12-03T19:03:04  <Moller40> hi
 592019-12-03T19:04:41  <kabaum> Ok, I'll just ask it.
 602019-12-03T19:04:41  <kabaum> Why is taproot called taproot? I understand that taproot is a class of roots as described in https://en.wikipedia.org/wiki/Taproot. Why is that a good analogy for Q, the witness program in taproot bip?
 612019-12-03T19:05:18  <instagibbs> gmaxwell, ^
 622019-12-03T19:05:33  <sipa> it taps a (merkle root) into a key
 632019-12-03T19:05:42  <sipa> is how i always interpreted it
 642019-12-03T19:07:03  <pyskell> it also sounds cool
 652019-12-03T19:07:15  <sipa> certainly better than any name i'd come up with
 662019-12-03T19:08:21  <kabaum> sipa: What is meant by "tap" in that interpretation?
 672019-12-03T19:09:50  <sipa> i don't know :p
 682019-12-03T19:10:26  <kabaum> sipa: ok
 692019-12-03T19:10:30  <jonatack> Original presentation (I believe) of taproot doesn't go into details on the name: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html
 702019-12-03T19:10:46  <sipa> tap
 712019-12-03T19:10:48  <sipa> verb
 722019-12-03T19:10:52  <sipa> 2. exploit or draw a supply from (a resource).
 732019-12-03T19:10:52  <sipa> "clients from industry seeking to tap Philadelphia's resources of expertise"
 742019-12-03T19:11:11  <sipa> seems vaguely appropriate
 752019-12-03T19:12:15  <instagibbs> re:schnorr threshold: does BLS make threshold sigs significantly easier? or do they all suffer from roughly similar complexity
 762019-12-03T19:12:33  <jonatack> "a special delegating CHECKSIG which I call Taproot"
 772019-12-03T19:13:28  <sipa> instagibbs: signing and any kind of multisignature is easier with BLS due to not needing interaction rounds to agree on a nonce
 782019-12-03T19:14:29  <instagibbs> I see, that probably makes it impervious to signers saying they'll sign, then not as a DoS
 792019-12-03T19:14:34  <instagibbs> (for one)
 802019-12-03T19:15:05  <sipa> but i don't know enough to say for sure
 812019-12-03T19:30:12  <kabaum> Is there hope to get threshold signatures to work securely with schnorr?
 822019-12-03T19:30:42  <kabaum> For cases where k-1>=n/2
 832019-12-03T19:31:44  <sipa> ping nickler, real_or_random, andytoshi
 842019-12-03T19:32:25  <andytoshi> pong
 852019-12-03T19:32:36  <sipa> kabaum: from what i've heard, yes
 862019-12-03T19:33:12  <andytoshi> kabaum: yes, definitely hope :)
 872019-12-03T19:33:18  <sipa> traditional solutions try to guarantee low bandwidth/complexity with unbounded sizes of participants, even when some are malcious
 882019-12-03T19:33:28  <sipa> which makes proving all properties very hard
 892019-12-03T19:34:05  <andytoshi> in some circumstances - like if you aren't concerned about byzantine actors - like in a typical "2 of 3 parties, one of which is a key in cold storage" or "k of n parties, all of whom are actual humans who can be phoned or sued" it's actually not too bad
 902019-12-03T19:34:20  <sipa> but if you accept solutions where you just run one protocol instance per combination of potential set of signers (which for things like 5-of-8 is just 56...) in parallel, it's much easier
 912019-12-03T19:34:51  <sipa> or accept that a malicious participant can make you stall and start over (once per malicious actor)
 922019-12-03T19:35:03  <andytoshi> i think we're making things seem harder than they are, by simultaneously trying to get a full BFT-secure scheme, implemented as a safe API that you can't abuse to leak keys even when talking to gapped HSMs, that also works with a minimum of state or randomness
 932019-12-03T19:35:28  <sipa> yeah
 942019-12-03T19:35:38  <andytoshi> also yeah, you can seriously just run n-choose-k musig instances in parallel which will be practical for almost all quorums you'll use in practice
 952019-12-03T19:37:18  <andytoshi> but unfortunately(?) blockstream's usecase for this has all of these requirements (big quorums, bft security, autonomous operation) ... and blockstream is paying most of the people working on implementing threshold sigs rn
 962019-12-03T19:37:31  <andytoshi> and also we're perfectionists about safe apis..
 972019-12-03T19:38:53  <andytoshi> instagibbs: yes, BLS makes all this stuff waay easier. no randomness, which eliminates almost all of the attack vectors, and no interaction, which eliminates the rest of them
 982019-12-03T19:39:12  <andytoshi> i'm actually not sure how you could screw up a bls threshold scheme implementation without making it fail to work..
 992019-12-03T19:39:57  <sipa> sounds like a challenge
1002019-12-03T19:40:00  <andytoshi> lol
1012019-12-03T19:40:43  <sipa> but i agree; you're never sending around scalars
1022019-12-03T19:40:48  <andytoshi> jonatack: kabaum: regarding the name, as i recall we (gmax sipa and i) literally were brainstorming "what's something that sounds kinda like a merkle root but it's hidden" and greg knew the word taproot
1032019-12-03T19:40:53  <andytoshi> from his past like as a botanist or something
1042019-12-03T19:41:22  <sipa> ah
1052019-12-03T19:41:30  <sipa> so it really means "hidden tree" ?
1062019-12-03T19:41:48  <kabaum> So it's a hidden root. Like a... taproot?
1072019-12-03T19:42:12  <andytoshi> oh wow TIL there is actually a metal band called taproot
1082019-12-03T19:42:42  <andytoshi> i think the word refers to an initial "anchor" root that a plant puts down and then other roots branch from it
1092019-12-03T19:42:58  <andytoshi> i don't think it's particularly "hidden" other than being a root
1102019-12-03T19:43:12  <kabaum> hidden in soil
1112019-12-03T19:43:22  <andytoshi> whoa taproot has an album called "blue-sky research" this is awesome
1122019-12-03T19:43:28  <sipa> metal band?
1132019-12-03T19:43:32  <andytoshi> yep
1142019-12-03T19:43:34  <sipa> sure it isn't called ŧàpřổøť or so?
1152019-12-03T19:44:01  <pyskell> it's taproot but their logo is entirely impossible to read
1162019-12-03T19:44:09  <kabaum> andytoshi: Sorry, the taproot Q isn't hidden
1172019-12-03T19:44:17  <sipa> https://en.wikipedia.org/wiki/Metal_umlaut
1182019-12-03T19:46:47  <pyskell> the schnorr bip says for threshold signatures that "most schemes in the literature have been proven secure only for the case k-1 < n/2" what's n in this case? number of participants?
1192019-12-03T19:47:01  <sipa> pyskell: yes, k-of-n threshold
1202019-12-03T19:47:01  <andytoshi> pyskell: yeah
1212019-12-03T19:47:38  <andytoshi> sipa has an argument for why this makes sense, academically at least
1222019-12-03T19:48:04  <sipa> andytoshi: i think you mean real_or_random ?
1232019-12-03T19:48:13  <andytoshi> oh, i might
1242019-12-03T19:48:30  <sipa> he explained it to me, but i forgot
1252019-12-03T19:50:35  <pyskell> is that integer division such that 2-of-3 wouldn't be secure because 2-1 == 3/2?
1262019-12-03T19:51:16  <sipa> just read it as 2*(k-1) < n
1272019-12-03T19:51:21  <sipa> to avoid division issues
1282019-12-03T19:52:09  <pyskell> ahh okay
1292019-12-03T20:07:02  *** dr-orlovsky has quit IRC
1302019-12-03T20:14:59  *** Moller40_ has joined ##taproot-bip-review
1312019-12-03T20:18:49  *** Moller40 has quit IRC
1322019-12-03T20:20:31  *** pinheadmz_ has joined ##taproot-bip-review
1332019-12-03T20:23:30  *** pinheadmz has quit IRC
1342019-12-03T20:23:30  *** pinheadmz_ is now known as pinheadmz
1352019-12-03T20:27:21  *** Moller40 has joined ##taproot-bip-review
1362019-12-03T20:31:14  *** Moller40_ has quit IRC
1372019-12-03T20:47:20  *** rottensox has quit IRC
1382019-12-03T21:14:18  *** rottensox has joined ##taproot-bip-review
1392019-12-03T21:31:30  *** dr-orlovsky has joined ##taproot-bip-review
1402019-12-03T21:49:31  *** b10c has quit IRC
1412019-12-03T21:57:28  *** pyskell has quit IRC
1422019-12-03T22:08:33  *** pinheadmz has quit IRC
1432019-12-03T22:08:55  *** pinheadmz has joined ##taproot-bip-review
1442019-12-03T22:15:00  *** arik_ has quit IRC
1452019-12-03T22:21:32  *** Chris_Stewart_5 has quit IRC
1462019-12-03T22:30:24  *** pinheadmz has joined ##taproot-bip-review
1472019-12-03T22:38:03  *** Chris_Stewart_5 has joined ##taproot-bip-review
1482019-12-03T22:43:07  *** Chris_Stewart_5 has quit IRC
1492019-12-03T23:32:15  *** ddustin has joined ##taproot-bip-review
1502019-12-03T23:36:51  <ddustin> Might be worth adding a space between review and ; in the status so the github link is clickable
1512019-12-03T23:46:32  <gmaxwell> andytoshi: The name was more inspired by the fact that it's most efficient there is one spending branch which has vastly more probablity than the others... but then it also nicely works in that it 'taps' into the key.
1522019-12-03T23:47:35  <gmaxwell> oh you mostly said that.
1532019-12-03T23:48:08  <sipa> wow, a 3rd different interpretation that makes sense (whether you meant that or not):
1542019-12-03T23:49:11  <sipa> * it's adding a most-important branch to a merkle tree (similar to how the taproot is the most important branch of the root of a plant)
1552019-12-03T23:50:09  <gmaxwell> kabaum: What it clear what andytoshi and sipa were saying above?  The k-1>=n/2 limit exists in byzantine robust polynomial overhead signing protocols.  It's not an issue if you don't care about a byzantine attacker jamming your signing OR don't mind using exponential bandwidth/cputime in the presence of one.   I think almost all (but not quite all) multisig usage is not byzantine robust, it
1562019-12-03T23:50:09  <gmaxwell> could be... but the software just isn't implemented that way.
1572019-12-03T23:50:36  <gmaxwell> kabaum: like in bitcoin core. you can add signatures to a partial transaction but I don't think any interface will strip invalid ones or even tell you which ones failed.
1582019-12-03T23:51:02  <sipa> byzantine robustness also requires a BFT communication network between the participants
1592019-12-03T23:51:28  <sipa> often described as "reliable broadcast channel", which doesn't physically exist
1602019-12-03T23:51:39  <sipa> we could use a blockchain though ;)
1612019-12-03T23:51:42  * sipa hides
1622019-12-03T23:56:34  <gmaxwell> as soon as one person in the world absolutely has to have byzantine robust signing, then it makes sense to implement though... and once it exists I don't know why you wouldn't use it.
1632019-12-03T23:58:55  <gmaxwell> andytoshi: careful, if you go around telling people that I was a botanist, Wright is going to start telling people I was growing heroin for bin laden, https://twitter.com/AldersonBSV/status/1199160142048063488