--- Log opened Wed Apr 21 00:00:32 2021 00:18 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation 00:25 -!- duringo [ad004d0f@173.0.77.15] has quit [Ping timeout: 240 seconds] 00:35 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation 00:37 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds] 00:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 01:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 01:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 01:22 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed] 01:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 03:45 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox] 03:47 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation 03:48 -!- CARO2 [~Cesar@2804:7f4:c29e:157f:101:eee4:6455:2b6] has quit [Ping timeout: 260 seconds] 04:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 05:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds] 05:26 -!- CARO [~Cesar@2804:7f4:c29e:157f:b900:a53f:b4e6:5b03] has joined ##taproot-activation 05:48 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Quit: Leaving] 05:48 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation 05:50 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Client Quit] 05:51 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation 06:06 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection] 06:06 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation 07:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 07:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 07:36 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation 07:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 08:32 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 246 seconds] 08:33 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 08:33 -!- shesek [~shesek@164.90.217.137] has joined ##taproot-activation 08:33 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 08:33 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation 08:36 -!- proofofkeags_ [~proofofke@205.209.28.54] has joined ##taproot-activation 08:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 09:35 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds] 09:37 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-activation 09:47 -!- wiscojabroni [5d2c50a9@93-44-80-169.ip96.fastwebnet.it] has joined ##taproot-activation 10:00 -!- pglazman [~pglazman@c-73-71-224-94.hsd1.ca.comcast.net] has joined ##taproot-activation 10:00 -!- jesseposner [~jesseposn@2601:645:200:162f:1de9:895b:e660:35bb] has joined ##taproot-activation 10:01 -!- larryruane_ [uid473749@gateway/web/irccloud.com/x-elisawrkhzqhccwc] has joined ##taproot-activation 10:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 10:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 10:28 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 10:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 10:49 -!- duringo [ad004d53@173.0.77.83] has joined ##taproot-activation 10:50 -!- proofofkeags_ [~proofofke@205.209.28.54] has quit [Ping timeout: 252 seconds] 10:51 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation 10:51 -!- cguida [~Adium@205.209.28.54] has joined ##taproot-activation 11:00 -!- pglazman [~pglazman@c-73-71-224-94.hsd1.ca.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 11:06 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection] 11:06 -!- mips_ [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation 11:13 -!- wiscojabroni [5d2c50a9@93-44-80-169.ip96.fastwebnet.it] has quit [Quit: Connection closed] 11:16 < robert_spigler> faketoshi: wow. Thanks for the link 11:18 < robert_spigler> aj: re: key path spending. Isn't multisig key path spending as well? And MuSig/schnorr signatures make it look like a single sig spend 11:19 < robert_spigler> Or is that the "agree all" condition of the script tree 11:22 < jeremyrubin> it's maybe better to think of Taproot as a few transformations on a binary tree that has script with participants names instead of keys 11:22 < jeremyrubin> transformation 1 is to pick a branch that *just* has some multisig and "promote" it to the top level key 11:22 < jeremyrubin> usually you'll want to pick the most likely to be used multisig 11:23 < jeremyrubin> this may or may not be the n of n 11:23 < jeremyrubin> next you can optionally compile any of the multisigs in the tree, and mandatorily compile the promoted one into a single key 11:24 < jeremyrubin> For a subset of key-only multisigs, you can do this non-interactively 11:24 < jeremyrubin> for some of them it requires the participants to generate a key together online 11:27 < jeremyrubin> if you only have *some* keys online (e.g., imagine you have a key in deeep cold storage), but want it in say a 2 of 3, you might need to do something like musigkey(HotA and HotB) or musigkey(musigkey(HotA or HotB) and Cold) 11:30 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##taproot-activation 11:32 -!- sanketcell [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##taproot-activation 11:40 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Remote host closed the connection] 11:40 -!- sanketcell [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Remote host closed the connection] 11:41 -!- sanketcell [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##taproot-activation 11:41 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##taproot-activation 11:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 11:54 -!- faketoshi is now known as bcman 11:54 -!- bcman is now known as faketoshi 12:11 < roasbeef> cccccckjglcnbbiefkhjdnedgukjrlcgivbuktrvkvlc 12:11 < jeremyrubin> nice password boss 12:11 < roasbeef> fuck, my private keys 12:12 < jeremyrubin> if your coins get stolen do you realize a capital gain? 12:14 < jeremyrubin> Does you posting your key here mean that I have income? 12:14 < jeremyrubin> hmm 12:15 -!- sword_smith [sword_smit@bitcoinfundamentals.org] has quit [Quit: leaving] 12:19 < robert_spigler> lol 12:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds] 12:20 < robert_spigler> jeremyrubin: 😬 I appreciate it but I think I'm more confused now 12:20 < jeremyrubin> Hmm 12:20 < robert_spigler> How I had been thinking about taproot: 12:20 < jeremyrubin> I think maybe you can kinda just ignore the issue then? 12:21 < jeremyrubin> You write a Policy using rust-miniscript Policy Compiler 12:21 < jeremyrubin> and then it makes the best taproot desc for you 12:23 < jeremyrubin> ah -- happy to listen to your explanation too; didn't mean to cut you off 12:23 < robert_spigler> Thanks! 12:24 < robert_spigler> You have the key-path spend, which is single sig (which everything now looks like), or multi-sig. (Which MuSig/schnorr turns into single-sig). Then you have the script-tree MAST like structure. Since Schnorr sigs are linear, you can tweak the combined key by the top "agree all" script, making it look like a single sig key spend. If you end up using one of the other non-cooperative scripts, you reveal 12:24 < robert_spigler> the tweak and the path of MAST-like script tree, but don't have to reveal all scripts like you used to with P2SH/P2WSH. 12:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 12:25 < jeremyrubin> This is a bit too much of an "intent" approach to understanding it IMO 12:26 < jeremyrubin> There's some MuSig research about classes of circuits (noninteractively?) I need to digest still 12:27 < jeremyrubin> But the reason I say it's not quite right is that 12:27 < jeremyrubin> I could have like 3 conditions that represent the "cooperative case" 12:28 < jeremyrubin> e.g., {Alice, Bob, Charlie}, {Dave, Eve}, {Alice, Eve} 12:28 < jeremyrubin> Now *maybe* using MuSig I *could* make this cooperative a single key, maybe not 12:29 < robert_spigler> Yeah, I was wondering how threshold sigs work 12:30 < robert_spigler> In this case, I thought the cooperative would be (Alice, Bob, Charlie, Dave, Eve) 12:30 < jeremyrubin> Notably, conside a contract where I *always* want some hash reveale 12:30 < jeremyrubin> any cooperative close of this contract requires either H(group A), H(group B), H(group c) be revealed 12:30 < jeremyrubin> w/o some sort of scriptless script thing, I always need to be in a script path 12:31 < jeremyrubin> Or imagine I *only* want to enable cooperation once some timeout is satisfied 12:31 < jeremyrubin> The taproot assumption is that there's always *some identifiable group* who have authority to spend the coin with 0 restrictions 12:31 < jeremyrubin> It's a decent assumption, but an assumption 12:32 < jeremyrubin> Not all contracts can use it, but many can 12:32 < jeremyrubin> Further, it doesn't have to be the "all agree" case, and it actually shouldn't be! 12:32 < jeremyrubin> It should be the *most likely* case 12:33 < jeremyrubin> E.g., if you have a 10 of 15 multisig musig key for a FedPeg deposit, most likely that's what's being used and should be the top key 12:33 < jeremyrubin> but your "all agree" situation might be a 10 of 10 of independent high security cold storage auditors 12:34 < robert_spigler> "Further, it doesn't have to be the "all agree" case, and it actually shouldn't be! 12:34 < robert_spigler> It should be the *most likely* case" - That's really interesting, makes sense though 12:35 < robert_spigler> So currently, the most likely m of n threshold sig case is the top key in the script tree, but if MuSig comes out with a threshold scheme, all threshold spends would move to the key path? 12:36 < jeremyrubin> Well it's not so simple 12:36 < jeremyrubin> Because you are going to use Policy to compile this 12:36 < jeremyrubin> and Policy is not guaranteed to produce optimal encodings 12:37 < jeremyrubin> so it's possible you could transform policy to emit some hybrid musig key that would be the most likely path 12:37 < jeremyrubin> but it might be *unlikely* that you figure out what exactly that optimal one is? 12:37 < jeremyrubin> so it might just be a "relatively likely key" 12:38 < robert_spigler> if its a "relatively likely key", you have to reveal the tweak and script path, no? 12:39 < jeremyrubin> Ah maybe here's an intersting subcase 12:39 < robert_spigler> And miniscript/policy isn't in core yet? 12:39 < jeremyrubin> it doesn't need to be 12:39 < jeremyrubin> it's user software non consensus 12:39 < jeremyrubin> Imagine that you have a all-approve key, but you don't care about privacy when it is used. It's even more likely! 12:40 < jeremyrubin> And then you have some other key, but you really care about privacy when it's used 12:40 < jeremyrubin> you might make that the top level key to reveal less about what's happening 12:40 < jeremyrubin> I hope i'm not confusing you btw 12:40 < robert_spigler> No, I really appreciate it 12:40 < jeremyrubin> this is why I said that your approach is a bit intent driven 12:41 < jeremyrubin> it's better to be technical driven and then apply an objective function to rank how good the technical ops matched intent 12:41 < robert_spigler> That makes sense 12:42 < jeremyrubin> The top level is just *any* group point 12:42 < jeremyrubin> the script tree is just any script tree 12:42 -!- mips__ [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation 12:42 < jeremyrubin> (well any binary script tree, not balanced) 12:43 < robert_spigler> In a non-cooperative case, (when the tweak and script path is revealed), how does the user(s) have the original full combined schnorr sig to tweak? Because that requires all pubkeys and sigs to create? And therefore full cooperation? 12:43 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 12:43 < jeremyrubin> And then you can ask questions like "given X knowledge of use case, does T minimize {fees, info leak, etc}" 12:43 < jeremyrubin> fees minimization is a decent proxy for information leak in a lot of use cases 12:45 < jeremyrubin> robert_spigler: yes, this is one of the things that I think is under studied from a UX perspective. When using Taproot keys you need a lot of information 12:45 < jeremyrubin> Sipa has a PR for taproot descriptors open 12:45 < jeremyrubin> they allow reconstructing 12:45 < jeremyrubin> but I don't think they support musig natively yet 12:46 < jeremyrubin> Nor will it be easy to support "this key was interactively made with 30 people" 12:46 < jeremyrubin> I think those are Hard Problems 12:46 -!- mips_ [~mips@gateway/tor-sasl/mips] has quit [Ping timeout: 240 seconds] 12:46 < jeremyrubin> and unlikely to be a part of core for a long while 12:46 < jeremyrubin> (musig probably, but "key with 30 people" will take ages) 12:47 < robert_spigler> Very interesting 12:47 < robert_spigler> There's a pretty active Bitcoin Design community, but it would take a lot of reach out and explaining to them (I'm still wrapping my mind around it) 12:48 < jeremyrubin> https://github.com/bitcoin/bitcoin/pull/7601 12:48 < jeremyrubin> HTLC support, 5 years ago, no progress 12:48 < jeremyrubin> Not a dump on core but things where the design space is huge and you need sophisticated reasoning about multiparty smart contracts just seem unlikely to be in scope for core for some time 12:49 < jeremyrubin> I wish that *were not* true, and would love someone to take me to task on it, but it's my opinion 12:49 < jeremyrubin> Fortunately, there are *modular* paths for this 12:50 < jeremyrubin> Just to be seen if those make any progress 12:51 < robert_spigler> So were you saying that miniscipt/policy needs to be merged in core before taproot wallet support is as well (know its not consensus code) 12:51 < jeremyrubin> Nope! 12:51 < jeremyrubin> Descriptors for taproot are coming 12:51 < jeremyrubin> Miniscript/Policy can output descriptors 12:52 < jeremyrubin> So core can import a descriptor and "know" what the output is 12:52 < jeremyrubin> what I'm saying is an issue is that core will just see "pk = 0x12412341231...." 12:52 < jeremyrubin> and have no idea what key that is 12:52 < jeremyrubin> now, descriptors *could* have musig support. 12:52 < jeremyrubin> So you could get musig(x,y,z) 12:53 < jeremyrubin> but then broaded circuits of schnorr multiparty things might still be black boxed to core 12:53 < jeremyrubin> and even musig descriptors also require musig signing 12:53 < jeremyrubin> Which *might* be supportable inside of PSBTs, with modifications 12:54 < jeremyrubin> but i think you need a new partial signature system since MuSig requires >1 round of communication to sign 12:54 < jeremyrubin> so you might e.g. need to pass around a PSBT 2x to sign instead of 1x 12:54 < robert_spigler> Ok, so still lots of exciting work to be done :) 12:55 < jeremyrubin> achow101 could answer more on if PSBT's exisiting signature map could be used for musig key descriptors 12:55 < jeremyrubin> so it might not require a new PSBT version at least, but definitely a new PSBT workflow 12:56 < jeremyrubin> robert_spigler: all this to say is that I think it will be some time before *core* supports this stuff nicely 12:56 < robert_spigler> (I think final question). How would you set up with taproot, say, a 3-of-5 threshold scheme where any 3 of 5 look like a single sig. Is this possible, or only the most likely 3 of 5, and the complete 5 of 5? 12:56 < jeremyrubin> but external tools (e.g., learn.sapio-lang.org) will be able to support it relatively soon 12:56 < robert_spigler> jeremyrubin: very cool! Saw you opened a PR to merge support to core 12:56 < jeremyrubin> Ah that's slightly different 12:57 < jeremyrubin> just an bip'd opcode that makes sapio work better, but not actual integration 12:57 < robert_spigler> Ah ok 12:57 < jeremyrubin> robert_spigler: with my current understanding of musig non interactive circuits (which i think I'm missing a paper that helps relax this), i can answer 12:57 < jeremyrubin> 1st off, are all parties online? 12:57 < jeremyrubin> or do I just know keys for them 12:58 < jeremyrubin> and by online I mean both online *and* have access to key easily 12:58 < jeremyrubin> if online but key in cold storage inaccessible it is offline 12:59 < robert_spigler> You know pubkey but and full wallet descriptor, but all privkeys offline in cold storage 13:00 < jeremyrubin> ok, so then in that case what you do is generate all 5 choose 3 groups 13:00 < jeremyrubin> e.g., {a,b,c,d,e} -> {{a,b,c}...} 13:00 < robert_spigler> Each signer knows pubkey and own privkey. and full wallet descriptor, but privkey offline in cold storage. Coordinator knows all pubkeys and descriptor, no privkeys. Is online with blockchain 13:01 < jeremyrubin> no coordinator required! 13:01 < jeremyrubin> every part could compile identically 13:01 < robert_spigler> ok interesting! 13:01 < jeremyrubin> Then you have a question to ask: 13:01 < jeremyrubin> is there ever a scenario where *more* than 3 people could be online at the same time? 13:02 < jeremyrubin> e.g., if these are all backups, and I'm using it to recover after armageddon, the answer is "no" 13:02 < jeremyrubin> so if it's "I keep 3 online always and the other 2 are for availability in case of catastrophe" 13:02 < jeremyrubin> say "yes" 13:03 < robert_spigler> no 13:04 < jeremyrubin> if it's "I know one group is more likely to be online than the others" say "yes" 13:04 < robert_spigler> no to that too 13:05 < jeremyrubin> Ok, then I pick a arbitrary group in the 5 choose 3 and promote it to the taproot key 13:05 < jeremyrubin> (arbitrary can be deterministic if you want no coordinator) 13:05 < jeremyrubin> and then I build a binary tree (deterministic if coord free) 13:05 < jeremyrubin> of the other key groups 13:06 < jeremyrubin> now, question: 13:06 < jeremyrubin> do you want to be able to support the case where people can online sign *one message*? 13:06 < jeremyrubin> Or do you want to require a multi-round protocol? 13:07 < robert_spigler> no, lets keep it simple 13:07 < jeremyrubin> (tbh this is kind of exhausting to go through; might switch to something else in 5 mins.... answer is "what's your application") 13:07 < robert_spigler> Sorry 13:07 < robert_spigler> I appreciate the help 13:08 < jeremyrubin> Ok, so then I add the promoted group as the key, and the others as the tree, make a taproot key and call it a day 13:08 < robert_spigler> And all the time 13:08 < jeremyrubin> but you can see by how many question I asked you 13:08 < jeremyrubin> that it's not like there's one answer on how to do these things 13:09 < robert_spigler> Definitely 13:09 < jeremyrubin> and there are different properties and tradeoffs 13:09 < jeremyrubin> and different types of signing algs can be asynchonous easily 13:09 < jeremyrubin> others require a bit more synchonicity from participants 13:09 < robert_spigler> Yes, it will be interesting to see how it is worked into GUI's 13:10 < robert_spigler> have a good day! Again, really appreciate you walking me through all this! 13:10 < jeremyrubin> np 13:10 < jeremyrubin> FWIW this is why I am generally in favor of a few things: 13:11 < jeremyrubin> 1) We should develop more tooling *before* we activate BIPs in general 13:11 < jeremyrubin> however, this is nigh impossible to fund/motivate with the process so drawn out 13:12 < jeremyrubin> 2) we should be more agressive with releasing safe BIPs because we can't do 1, so if we want software for what's *possible* this decade, we need to pipeline progress better 13:13 < jeremyrubin> e.g., segwit is still not universally adopted 13:15 <@michaelfolkson> This should probably be in ##taproot-bip-review but what SegWit tooling would you have liked to have seen pre-SegWit? Lightning has used SegWit post SegWit activation 13:16 <@michaelfolkson> It is hard to get people to spend a lot of time on tooling if they don't know if/when/in what final form a soft fork will activate. 13:17 <@michaelfolkson> I'm sure Lightning will use MuSig post Taproot activation at some point 13:18 < jeremyrubin> I would have liked to see e.g. Miniscript/Policy outputting Taproot trees. 13:18 < jeremyrubin> I'm not asking andytoshi and sanket1729 to do that work; I've tinkered with it too 13:18 < jeremyrubin> but that would have made it much more "testable" and would increase confidence in the design of taproot for sure 13:19 < jeremyrubin> I made https://en.bitcoin.it/wiki/Taproot_Uses 13:21 < jeremyrubin> https://medium.com/blockstream/musig2-simple-two-round-schnorr-multisignatures-bf9582e99295 is great too 13:21 < jeremyrubin> robert_spigler: you should read that! 13:22 < robert_spigler> Thanks, will do! 13:22 <@michaelfolkson> Right. I expect a lot more tooling pre soft fork activation makes sense for an opcode soft fork (e.g. CTV) rather than a structural soft fork (e.g. SegWit, arguably Taproot too) 13:22 < robert_spigler> read it when it first came out, but haven't in a while 13:23 < jeremyrubin> disagree, for a signature algorithm you'd want to make sure it works on a *very wide* variety of systems 13:23 < jeremyrubin> taproot has both structural and scriptual elements 13:24 < jeremyrubin> I'm not claiming taproot doesn't have that, but for example can I do a multisig with a coldcard? 13:24 <@michaelfolkson> ECDSA/Schnorr are pretty vanilla though right? I can't imagine there are use cases where someone goes "Oh I wish this specific feature had been included in the Schnorr soft fork" 13:24 <@michaelfolkson> Perhaps I'm wrong. Can't tell the future 13:25 <@michaelfolkson> Tapscript is pretty small 13:25 < jeremyrubin> yes you're very wrong IMO 13:25 <@michaelfolkson> Interesting 13:26 < jeremyrubin> ECDSA and Schnorr are, in a sense, insufficiently refined types 13:26 < jeremyrubin> It's sort of like saying C++ and Rust are standard languages so your program written in C++ or Rust is standard 13:26 < jeremyrubin> actually using ECDSA or Schnorr requires making deeply informed choices around the specific implementation 13:28 <@michaelfolkson> This is very interesting but yeah we should take it to ##taproot-bip-review 13:28 < jeremyrubin> https://decrypt.co/31463/bitcoin-segwit-bug-fix-could-lock-wallet-users-out-funds 13:28 < jeremyrubin> For example 13:28 < jeremyrubin> i don't think it's even really right convo for there TBH 13:29 < jeremyrubin> this is more meta about 'what type of knowledge should we strive for before pushing upgrades' 13:29 < jeremyrubin> probably a wizards chat if anything 13:29 <@michaelfolkson> Yeah agreed 13:30 < jeremyrubin> But just for the record, then I'm out, I think that Taproot is OK to activate without this, and we can only hope to improve the process going forward so that our epistemology of "did we solve the right problems" improves 13:31 < jeremyrubin> This will become easier as bitcoin matures as there will be more tech solving problems as opposed to tech in search of problem 13:31 < jeremyrubin> /fin 13:31 <@michaelfolkson> Agreed. Talking to yourself with all your CTV applications ;) 13:39 < jeremyrubin> not sure exactly, but CTV has been problem motivated from the getgo :) 13:39 < jeremyrubin> https://docs.google.com/presentation/d/1BuIJj8KkGFM8uOCXuQDgnwTLOHyUM72j6ofrkxwj_qg/edit?usp=sharing 13:41 < jeremyrubin> and earlier https://github.com/jeremyrubin/lazuli 13:41 < andytoshi> jeremyrubin: i'm down to do the taproot descriptor work (as is sipa). but it's not our #1 priority right now 13:41 < andytoshi> if you wanted to jump on it i wouldn't complain :P 13:41 < jeremyrubin> sipa already drafted some descriptor stuff BTW andytoshi 13:43 < andytoshi> right, i need to take a look at that 13:43 < jeremyrubin> moving this to ##miniscript 13:49 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation 13:51 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 14:02 -!- mips__ [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection] 14:02 -!- mips__ [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation 14:25 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds] 14:26 -!- joerodgers [joerodgers@gateway/vpn/mullvad/joerodgers/x-62861712] has joined ##taproot-activation 14:38 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation 14:55 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 14:55 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation 15:00 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection] 15:00 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation 15:01 -!- mips_ [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation 15:04 -!- mips__ [~mips@gateway/tor-sasl/mips] has quit [Ping timeout: 240 seconds] 16:07 -!- cguida [~Adium@205.209.28.54] has quit [Quit: Leaving.] 16:26 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds] 16:27 -!- sanketcell [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds] 16:27 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 252 seconds] 17:00 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##taproot-activation 17:01 -!- sanketcell [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##taproot-activation 17:01 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 17:04 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 17:05 -!- belcher_ is now known as belcher 17:29 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 245 seconds] 18:55 -!- mips_ is now known as mips 19:30 < sugarpuff> Am I understanding this correctly, that there is consensus on the feature among the developers, and the only remaining thing is how to go about enabling it? 19:31 < sugarpuff> If so, why are you guys doing it that way? That makes it sounds to me like you're waiting on / asking for permission from people who are not developers 19:31 < sugarpuff> Why not just enable it via a flag day? 19:33 < jeremyrubin> sugarpuff: you are incorrect (slightly); bitcoin core has code which can activate Taproot by Novemebr 19:34 < jeremyrubin> There's not really an open question among most developers w.r.t. that, 19:34 < jeremyrubin> see https://github.com/bitcoin/bips/pull/1104 19:34 < jeremyrubin> which has 13 acks including all 3 BIP authors 19:34 < jeremyrubin> (this matches the code in Core) 19:35 < jeremyrubin> However, there is a group of developers who do not think this is a good process for various reasons 19:35 < jeremyrubin> Said developers have prepared an alternative release which you can learn about tat taproot.works 19:35 < jeremyrubin> https://taproot.works 19:36 < jeremyrubin> I don't personally endorse running said client at this time. But no one is waiting for or asking for permission, different approaches have proceeded in parallel 19:37 < jeremyrubin> Otherwise, you can run 0.21.1 which will be released on https://bitcoincore.org/en/releases/ soon 19:38 < jeremyrubin> If you want to test this release, Release Candidate 1 is available here https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2021-April/000098.html 19:38 < jeremyrubin> (RC1 comes out and then a few days later RC1 becomes the final version unless a bug is found) 19:38 < jeremyrubin> sugarpuff: does that answer your question? 19:40 < sugarpuff> Not really. I think though, this might be the answer I was looking for: the devs want wider consensus to back up their decision to enable this feature, in a sense, so that they don't come off as moving without that wider consensus (that extends to a group beyond the developers)? 19:41 < jeremyrubin> ah, yeah. the "why not a flag day" question I think is answered by shinobiusmonk on taproot.works 19:41 < jeremyrubin> If core developers built in this guaranteed activation method, some people would use this to characterize Bitcoin’s core developers as forcing the decision to activate Taproot on to the miners and users of Bitcoin. This would lend credence to arguments that developers control Bitcoin. This runs counter to Bitcoin’s ethos of decentralization — no individual or group controls the network. Thus we cannot expect core 19:41 < jeremyrubin> developers to make this choice. And indeed, they haven’t. This is good. 19:43 < jeremyrubin> I don't fully agree with implication that therefore day 0 we must do a UASF when releasing BTW. 19:44 < jeremyrubin> I also don't fully agree that UASF must be done with mandatory signalling 19:45 < jeremyrubin> So I think that ST is a punt on getting consensus about how UASFs _should_ work to an extent. If it's not controversial, miners will activate 19:49 < sugarpuff> well, this will be an interesting experiment. I think it will go like this: either miners activate Taproot, or Taproot will be pushed through. It really isn't giving miners much of a choice, only the illusion of choice 19:49 < jeremyrubin> ah 19:49 < jeremyrubin> so that's the slight diff with ST 19:49 < jeremyrubin> if miners are like "no, and here's why not" 19:49 < jeremyrubin> Then we can at least... try to fix it 19:51 < sugarpuff> fair enough. but you see, even there, the assumption seems to be that taproot is fundamentally sound, with only minor "fixes" being needed if the miners don't activate. I personally trust the core developers to make technical decisions about the software features, not miners... if a miner wants to join this channel or the other dev channels, they can put on their "dev hat" and become a developer in a 19:51 < sugarpuff> sense. but the decision should be with the group that knows what it's talking about imho 19:53 < luke-jr> that's what differentiates Bitcoin from fiat 19:53 < jeremyrubin> sugarpuff: I generally agree, if a miner is informed enough on the technicals to raise a concern, they'd be more like a developer anyways 19:54 < sugarpuff> I think what differentiates Bitcoin from fiat is the rules that have been chosen. Not anything else. 19:54 < jeremyrubin> A sort of Epistocracy (rule of the wise) is somewhat beneficial... I don't care what users who aren't informed think 19:55 < jeremyrubin> I also think that e.g., it would be cheap for the US Govt to hire 100 devs who hate privacy to work on Bitcoin 19:55 < jeremyrubin> So it can't just be "devs decide" 19:57 < sugarpuff> I think some rules are more collectively agreed on as being "Bitcoin" than others. I think ultimately it is "devs decide", but also there will always be a group of *users* who will support this specific set of rules, even if the current devs are replaced by a different group that changes the rules completely. 19:58 < sugarpuff> so for example, if the 21m cap were removed, there would be a fork, and one of them would be called "Bitcoin" and the other something else, and it's anyone's guess which chain would have more users 19:58 < jeremyrubin> sugarpuff: what if devs decide miners get a pass at activating it early? 19:58 < jeremyrubin> that's essentially the path right now 19:59 < jeremyrubin> The whole point of ST is that it fails by august so a second deployment can be put out without wasting a ton of time 19:59 < jeremyrubin> the other options pursued earlier all were much slower 19:59 < jeremyrubin> just a flag day would also be slower BTW 20:00 < luke-jr> (not really) 20:00 < sugarpuff> right. you all can decide to try to maintain friendly relations with miners and see if they will cooperate. I think that is wise. Ultimately though you are competing against other coins, so if you decide Bitcoin must adopt Taproot via flag day or something else, you will make that decision. If you're convinced this is the only way to keep Bitcoin competitive, you'll override any miners who disagree 20:00 < jeremyrubin> of course 20:01 < jeremyrubin> sugarpuff: i'm more concerned with getting BIP-119 CTV ready for deployment :) 20:02 < jeremyrubin> Keep in mind that if Taproot is good for bitcoin, it will increase price, good for miners too 20:06 < aj> sometimes an increase in price would be bad for miners, in that it would cause more people to buy new mining hardware increasing difficulty; but atm aiui mining hardware is already being sold as fast as it can be manufactured... 20:09 < jeremyrubin> Certainly -- I've studied this exact effect with Spork 20:10 < jeremyrubin> If miner perceive a fork to decrease profit, they'll just delay it uneccessarily as long as possible 20:10 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 20:13 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 22:57 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 240 seconds] 22:59 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation --- Log closed Thu Apr 22 00:00:33 2021