--- Day changed Wed Sep 02 2020
00:05 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds]     
00:33 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
00:34 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
00:45 -!- robot-dreams [~robot-dre@172.92.4.53] has quit [Remote host closed the connection]     
00:45 -!- jonatack [~jon@194.187.251.163] has joined #bitcoin-core-pr-reviews     
00:48 -!- gzhao408 [uid453516@gateway/web/irccloud.com/x-ysgsmkxckcazkctb] has quit [Quit: Connection closed for inactivity]     
00:49 -!- musdom [~Thunderbi@202.186.37.216] has joined #bitcoin-core-pr-reviews     
00:51 -!- robot-dreams [~robot-dre@172.92.4.53] has joined #bitcoin-core-pr-reviews     
01:17 < jonatack> we did a review club that discussed UB, and how an uninitialized read affected a release late last year, and tools to mitigate these things: https://bitcoincore.reviews/17639
01:18 -!- musdom [~Thunderbi@202.186.37.216] has quit [Ping timeout: 240 seconds]     
01:19 -!- robot-dreams [~robot-dre@172.92.4.53] has quit [Remote host closed the connection]     
01:38 < brikk> jonatack: thanks for this timely link, it provided the context I needed as I was reading through the taproot pr comments this morning where sipa commented why there is an uninitialized variable
01:54 -!- musdom [~Thunderbi@202.184.23.26] has joined #bitcoin-core-pr-reviews     
02:12 -!- robot-dreams [~robot-dre@172.92.4.53] has joined #bitcoin-core-pr-reviews     
02:18 -!- robot-dreams [~robot-dre@172.92.4.53] has quit [Ping timeout: 260 seconds]     
02:49 -!- robot-dreams [~robot-dre@172.92.4.53] has joined #bitcoin-core-pr-reviews     
02:54 -!- robot-dreams [~robot-dre@172.92.4.53] has quit [Ping timeout: 258 seconds]     
03:01 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]     
03:02 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews     
03:05 < jonatack> brikk: 👍
03:18 -!- Eloisa82Mayer [~Eloisa82M@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
03:22 -!- jonatack [~jon@194.187.251.163] has quit [Ping timeout: 240 seconds]     
03:24 -!- robot-dreams [~robot-dre@172.92.4.53] has joined #bitcoin-core-pr-reviews     
03:29 -!- robot-dreams [~robot-dre@172.92.4.53] has quit [Ping timeout: 260 seconds]     
03:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
04:01 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
04:05 -!- Eloisa82Mayer [~Eloisa82M@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 246 seconds]     
04:12 -!- robot-dreams [~robot-dre@172.92.4.53] has joined #bitcoin-core-pr-reviews     
04:17 -!- robot-dreams [~robot-dre@172.92.4.53] has quit [Ping timeout: 256 seconds]     
04:34 -!- musdom [~Thunderbi@202.184.23.26] has quit [Ping timeout: 258 seconds]     
05:17 -!- robot-dreams [~robot-dre@172.92.4.53] has joined #bitcoin-core-pr-reviews     
05:22 -!- robot-dreams [~robot-dre@172.92.4.53] has quit [Ping timeout: 256 seconds]     
05:27 -!- mblackmblack [~matt@178.128.230.221] has quit [Ping timeout: 246 seconds]     
05:30 -!- mblackmblack [~matt@178.128.230.221] has joined #bitcoin-core-pr-reviews     
05:58 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 240 seconds]     
06:02 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews     
06:15 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]     
06:15 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
06:16 -!- ben93 [458895a5@c-69-136-149-165.hsd1.mi.comcast.net] has joined #bitcoin-core-pr-reviews     
06:17 -!- ben93 [458895a5@c-69-136-149-165.hsd1.mi.comcast.net] has quit [Remote host closed the connection]     
06:17 -!- jonatack [~jon@37.166.127.239] has joined #bitcoin-core-pr-reviews     
06:20 -!- bentatum [458895a5@c-69-136-149-165.hsd1.mi.comcast.net] has joined #bitcoin-core-pr-reviews     
06:20 -!- bentatum [458895a5@c-69-136-149-165.hsd1.mi.comcast.net] has left #bitcoin-core-pr-reviews []     
06:55 -!- jonatack [~jon@37.166.127.239] has quit [Read error: Connection reset by peer]     
06:56 -!- jonatack_ [~jon@37.166.127.239] has joined #bitcoin-core-pr-reviews     
07:05 -!- robot-dreams [~robot-dre@172.92.4.53] has joined #bitcoin-core-pr-reviews     
07:10 -!- robot-dreams [~robot-dre@172.92.4.53] has quit [Ping timeout: 240 seconds]     
07:12 -!- fronti [~fronti@irc.fh-biergarten.de] has joined #bitcoin-core-pr-reviews     
07:13 -!- cloudhead [~cloudhead@li1811-8.members.linode.com] has joined #bitcoin-core-pr-reviews     
07:22 -!- robot-dreams [~robot-dre@172.92.4.53] has joined #bitcoin-core-pr-reviews     
07:23 -!- lightlike [~lightlike@p200300c7ef16d7005597c88be3df51bc.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
07:37 -!- robot-dreams [~robot-dre@172.92.4.53] has quit [Remote host closed the connection]     
07:38 -!- robot-dreams [~robot-dre@172.92.4.53] has joined #bitcoin-core-pr-reviews     
07:42 -!- robot-dreams [~robot-dre@172.92.4.53] has quit [Ping timeout: 256 seconds]     
07:52 < michaelfolkson> This is a cool challenge https://twitter.com/theinstagibbs/status/1301165399787134977?s=20
07:53 < michaelfolkson> Post the change you made to the BIP and which test(s) failed as a result!
07:54 < pinheadmz> I actually found a mistake several months ago: https://github.com/sipa/bitcoin/pull/121/commits/c009b3c18e3fdd2764257b0b436ac10d992fc0dd
07:54 < pinheadmz> the only way to test it was to remove a redundant policy check (this is about how taproot doesnt work inside nested addresses)
07:58 < michaelfolkson> Months ahead of the game ;)
07:59 < pinheadmz> heh, I was implementing taproot for bcoin - pretty good review strategy. really gets you into the dirt
08:03 < michaelfolkson> I bet. What's the status of Taproot in bcoin? You write equivalent tests to Core as well in bcoin?
08:04 < pinheadmz> so, the bcoin taproot PR is a draft and its' been stale for months, while bip340 itself and the bitcoin core PR got updated. Hopefully I have time in the near future to catch up.
08:04 < pinheadmz> I started with sipa's PR and actually modifiied it to output a file of all the transations it generates in memory into a huge json file
08:05 < pinheadmz> then I used those as test vectors to iterate through bip340-342
08:05 < pinheadmz> https://github.com/pinheadmz/bitcoin/tree/taproottest1#taproot-test-vectors
08:05 -!- jonatack_ [~jon@37.166.127.239] has quit [Read error: Connection reset by peer]     
08:07 < aj>  pinheadmz: that patch (to output a file of all the txs) might be worth adding to the PR (or a later PR or whatever)
08:07 < pinheadmz> Yeah sipa mentioned that would be helpful as well to add test vectors to the BIP
08:07 < pinheadmz> and other implementations to test against like electrum and the other full node implementations
08:08 < pinheadmz> I need to rebase on the actual taproot PR, but Ive just been waiting for the protocol itself to settle down
08:20 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews     
08:24 -!- sergei-t [~sergei@94.103.211.82] has joined #bitcoin-core-pr-reviews     
08:35 -!- jonatack_ [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
08:35 -!- dhruvm [881873f9@gateway/web/cgi-irc/kiwiirc.com/ip.136.24.115.249] has joined #bitcoin-core-pr-reviews     
08:38 -!- jonatack_ [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Client Quit]     
08:39 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
08:49 -!- robot-dreams [~robot-dre@172.92.4.53] has joined #bitcoin-core-pr-reviews     
09:02 -!- sergei-t [~sergei@94.103.211.82] has left #bitcoin-core-pr-reviews []     
09:19 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews     
09:20 -!- gzhao408 [uid453516@gateway/web/irccloud.com/x-zvgwzciyegdflngh] has joined #bitcoin-core-pr-reviews     
09:43 -!- robot-dreams [~robot-dre@172.92.4.53] has quit [Remote host closed the connection]     
09:43 -!- robot-dreams [~robot-dre@172.92.4.53] has joined #bitcoin-core-pr-reviews     
09:46 < jnewbery> Hi folks, we'll get started in 15 minutes
09:50 -!- Paul_R [adf60e57@173-246-14-87.qc.cable.ebox.net] has joined #bitcoin-core-pr-reviews     
09:56 -!- figs [68c88135@104.200.129.53] has joined #bitcoin-core-pr-reviews     
09:56 -!- unweave [~unweave@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
09:59 -!- Paul_R [adf60e57@173-246-14-87.qc.cable.ebox.net] has left #bitcoin-core-pr-reviews []     
09:59 -!- Paul_R [adf60e57@173-246-14-87.qc.cable.ebox.net] has joined #bitcoin-core-pr-reviews     
10:00 -!- kimgnome [~manjaro-g@2804:14d:baa1:8ad0:7e67:a2ff:fee6:efb] has joined #bitcoin-core-pr-reviews     
10:00 -!- sosthene [~sosthene@176-191-246-113.abo.bbox.fr] has joined #bitcoin-core-pr-reviews     
10:00 < jnewbery> #startmeeting
10:00 < jnewbery> Hi folks. Welcome to PR Review club. Feel free to say hi!
10:00 < gzhao408> HI!!!!
10:00 < pinheadmz> hi     
10:00 < emzy> hi     
10:00 < robot-dreams> Hi     
10:00 < Paul_R> hi everyone
10:00 < nehan> hi     
10:00 < kimgnome> hi     
10:00 < sosthene> hi!     
10:00 < jnewbery> HI GZHAO!
10:00 < michaelfolkson> WHAT
10:00 < jnewbery> And let us know if it's your first time here. We love new participants.
10:00 < michaelfolkson> hi     
10:00 < kimgnome> First time
10:00 -!- hanhua [63687d99@99-104-125-153.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews     
10:00 < gzhao408> 😂
10:01 < jnewbery> welcome kimgnome!
10:01 < fjahr> hi     
10:01 < jonatack> hi. i see some people are wide awake at this hour ;)
10:01 < kimgnome> Thanks
10:01 < unweave> hi     
10:01 < jnewbery> Brief reminder of the format: I have some questions prepared that we'll go through, but feel free to jump in at any point. If you have a question, just ask at any time!
10:01 < sosthene> not really my first time, but it has been a while, a year I think :)
10:01 < dhruvm> hi     
10:01 < Paul_R> also my first time
10:01 < jnewbery> welcome back sosthene :)
10:01 < jnewbery> welcome Paul_R
10:01 < Paul_R> thx     
10:02 < jonatack> great to see new people :D
10:02 < jnewbery> other thing to remember: We're all here to learn, so there's no such thing as a stupid question.
10:02 < jnewbery> ok, let's get started!
10:02 < jnewbery> Notes and questions in the normal place: https://bitcoincore.reviews/17977-3
10:02 < jnewbery> Who had a chance to review this week's commit? (y/n)
10:02 < pinheadmz> y     
10:02 < gzhao408> y     
10:02 < robot-dreams> y     
10:02 < Paul_R> y     
10:02 < emzy> n     
10:02 < sosthene> n     
10:02 < nehan> .5y     
10:02 < jonatack> y     
10:02 < fjahr> y     
10:02 < jnewbery> wow that's a lot of review
10:02 < figs> y     
10:02 < jnewbery> Any initial thoughts from those who reviewed it? Is it what you expected taproot to look like?
10:03 < robot-dreams> initial thoughts: I expected it'd be a really scary change about elliptic curves, but it turned out to be slightly more approachable and focused on soft forks :)
10:04 < jnewbery> robot-dreams: good! Yes, all the EC stuff is hidden away in libsecp
10:04 < gzhao408> It taught me about script upgradeability using witness versions 🤔was wondering, if there was another script upgrade we wanted to do using v2 for example, would it be incompatible with taproot?
10:04 < nehan> i am super confused and am looking forward to learning more about what's going on!
10:04 < pinheadmz> yeah its simpler than i expected -- checkTaprootCommitmenet in particualr, the way the control block is merkleized is a lot simpler than i imagined
10:05 < jnewbery> robot-dreams: probably good to review the last taproot PR review club to see how we use the new libsecp interface: https://bitcoincore.reviews/17977-2
10:05 < pinheadmz> gzhao408 v2 wouldnt be inompatible with taproot kinda like how taproot (v1) isnt incompatible with segwit v0
10:05 < pinheadmz> i mean, they are incompatible but they dont interfere with each other
10:06 < michaelfolkson> We are swimming in possible upgrade paths https://bitcoin.stackexchange.com/questions/96951/what-are-the-different-upgradeability-features-in-the-bip-taproot-bip-341-prop/96952#96952
10:06 < gzhao408> right, but if they had distinct features that were both really nice, would we be able to have both in the same script? or would there be a better way?
10:06 < unweave> pinheadmz would it be accurate to say "wouldn't *need to be* incompatible" ?
10:06 -!- musdom [~Thunderbi@202.184.23.26] has joined #bitcoin-core-pr-reviews     
10:06 < pinheadmz> i see - well there are some logic in the code where its like (if WITNESSV0 || TAPROOT)
10:06 < pinheadmz> so you could add another (...|| V2) in there to share logic from taproot with v2
10:06 < gzhao408> my guess is no but I can't think of any concrete examples where it'd be necessary so 😅
10:07 < jnewbery> gzhao408: it's difficult for me to imagine something that abstract
10:07 < sosthene> But do we still need V2 anyway? :p
10:07 < jnewbery> but if there were eventually some segwit v2 I imagine it might have a superset of taproot's functionality maybe(?)
10:08 < pinheadmz> true also with leaf versions you could have a new script language inside a v1 taproot
10:08 < jnewbery> pinheadmz: yep, I expect you can do almost everything you want with script versions inside taproot
10:09 < michaelfolkson> It gets messy when you start wanting to take an old version (say 1) when you have a new version (say 2) and add new features to that old version to make say 3
10:09 < jnewbery> ok, first question: Will the new SCRIPT_VERIFY_TAPROOT and SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_TAPROOT_VERSION script verification flags be used for consensus checks or policy checks?
10:09 < gzhao408> thanks for answering my question <jnewbery> <pinheadmz>, I'll think on it more - just want to feel out what the boundaries of compatibility are
10:09 < robot-dreams> I think `SCRIPT_VERIFY_TAPROOT` is for consensus: it might cause some blocks to be rejected
10:09 < robot-dreams> On the other hand, I think `SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_TAPROOT_VERSION` is for policy: it might prevent some transactions from being signed or added to the mempool, but it won't cause blocks to be rejected
10:09 < pinheadmz> robot-dreams i think youre right, and "DISCOURAGE..." anything is just policy
10:09 < gzhao408> +1 robot-dreams, and I wanna check my understanding of the DISCOURAGE flags, I think it’s: before, v1 would have been WITNESS_UNKNOWN, so no requirements… and now there are (stricter) defined taproot spending rules. So if we didn’t discourage, it’s possible for us to accept an old v1 to mempool, but then it wouldn’t pass consensus after the soft fork?
10:09 < gzhao408> yeah, discourage but not enforce
10:10 < gzhao408> er - enforce in block validation*
10:10 < pinheadmz> discourage means: reject from mempool, still valid in block
10:10 < jonatack> counterargument to sow doubt: the flags are in protocol.h
10:11 < gzhao408> pinheadmz 👍
10:11 < Paul_R> therefore it's a policy, not consensus rule
10:11 < Paul_R> @pin
10:11 < Paul_R> pinheadmz
10:11 < gzhao408> :jonatack: well, policy flags is a superset of consensus flags
10:11 < jonatack> gzhao408: stirring things up
10:11 < pinheadmz> and then you might see in the future say if ANNEX gets a function, that DISCOURAGE ANNEX will be removed and the new annex rules enforced by soft fork
10:11 < gzhao408> u jonatack i counteratack
10:12 < gzhao408> AND It’s not possible to add a script verification flag that makes spending rules less strict, right? i.e. they are all backwards compatible
10:12 < pinheadmz> less strict rules -> hard fork :-(
10:12 < jnewbery> jonatack: the flags are in script/interpreter.h
10:13 < jnewbery> gzhao408: yes, adding a new flag should only make things more strict
10:13 < gzhao408> I think jonatack is referring to the STANDARD_SCRIPT_VERIFY_FLAGS in policy.h
10:14 < jonatack> i wondered if the "answer" might be "both"
10:14 -!- Paul_R [adf60e57@173-246-14-87.qc.cable.ebox.net] has quit [Remote host closed the connection]     
10:14 < robot-dreams> Yes, STANDARD_SCRIPT_VERIFY_FLAGS is in policy.h but I think it's also worth noting GetBlockScriptFlags
10:15 < jnewbery> my answer is: after the taproot softfork (however it gets activated), SCRIPT_VERIFY_TAPROOT will be a consensus rule
10:15 < jnewbery> SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_TAPROOT_VERSION is intended to be a policy rule
10:15 < jnewbery> why do we discourage future taproot versions?
10:16 < michaelfolkson> Because they are unencumbered?
10:16 < sosthene> To discourage people using future versions while there are still not defined?
10:16 -!- Paul_R [adf60e57@173-246-14-87.qc.cable.ebox.net] has joined #bitcoin-core-pr-reviews     
10:17 < robot-dreams> to communicate something like "this is a nonstandard transaction, don't do this"?
10:17 < pinheadmz> some of these policy rules are because they are anyone can spend, but a lot of policy rules are DDoS mitigation as well
10:17 < gzhao408> because... otherwise you might accept to mempool (if you didn't discourage in policy), and then there's a spending rule activated, and then it no longer passes consensus?
10:17 < gzhao408> (is that scenario possible?)
10:18 < pinheadmz> gzhao408 youd have to get the timing just right :-)
10:18 < gzhao408> <pinheadmz> couldn't it hang out in your mempool for a while if it was full?
10:18 < pinheadmz> get a tx in the mempool right on activation
10:18 < jnewbery> gzhao408: you certainly need to be careful around activation time with your mempool and propagating transactions
10:19 < pinheadmz> i wonder actually if the mempool evicts invalid txs on the edge of activation
10:19 < jnewbery> you're right that having a policy rule well in advance of activation prevents us from having this problem
10:19 < pinheadmz> I actually sent btc to a v1 address, that is an anyonecanspend output and its in the utxo set right now
10:19 < pinheadmz> someone could try to spend it on the block before taproot is enforced
10:19 < Paul_R> recently?
10:20 < pinheadmz> a few months ago, after bitcoin core eased the restriciton on DISCOURAGE UNKOWN WITNESS version
10:20 < jnewbery> pinheadmz: I don't think the mempool would do anything at activation time, but policy should mean that there aren't any of those transaction in there
10:21 < gzhao408> ! so at what point do we start applying SCRIPT_VERIFY_DISCOURAGE_UPGRADEABLE_TAPROOT_VERSION, would that theoretically be well before we start enforcing taproot in consensus?
10:21 < jnewbery> right, sending _to_ a v1 address is policy-valid. Spending _from_ v1 is policy-invalid
10:21 < pinheadmz> ah ok
10:21 < pinheadmz> what if a node / miner had requireStandard: false ?
10:21 < jnewbery> so someone could theoretically spend pinheadmz's output if they could get their transaction to a miner that isn't enforcing that policy
10:22 < jnewbery> but that transaction probably won't propogate through the network otherwise because it's policy-invalid for most nodes
10:22 < pinheadmz> but is there any chance that (lets say with standard: false) the spend enters a miner's mempool?
10:22 < pinheadmz> then the next block, taproot is enforecd
10:22 < pinheadmz> the mining code assumes the entire mempool is valid for the next block, i think ?
10:23 < jnewbery> pinheadmz: i believe you're right. So the miner needs to ensure that they're enforcing the new consensus rules on their mempool well before activation
10:23 < pinheadmz> interesting
10:23 < pinheadmz> theres no check mempool and evict function outside of a reorg ?
10:24 < Paul_R> jnewbery: are miner's generally this responsible?
10:24 < robot-dreams> this is for the miner's benefit, right? (they don't want to put in the work to mine a block and then have it be rejected cause of upgraded VERIFY rules)
10:24 < jnewbery> gzhao: SCRIPT_VERIFY_DISCOURAGED_UPGRADEABLE_TAPROOT_VERSION would be enforced in policy from when taproot is activated
10:24 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]     
10:24 < gzhao408> <jnewbery> ohhh i see, thanks!
10:25 < unweave> >that transaction probably won't propogate [...] because it's policy-invalid   I've had transactions confirm that violated policy and I didn't put any extra effort into shepherding them to a miner FWIW
10:25 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews     
10:25 < jnewbery> Paul_R: if they're running Bitcoin Core then any v1 spends are already policy-invalid and not in their mempool
10:25 < jonatack> pinheadmz: i've wondered when/why someone would set -acceptnonstdtxn
10:25 < pinheadmz> p.s. https://blockstream.info/tx/b53e3bc5edbb41b34a963ecf67eb045266cf841cab73a780940ce6845377f141?input:0&expand
10:26 < pinheadmz> 5,431 free satoshis for someone
10:26 < jonatack> it's testing only
10:26 < jnewbery> unweave: interesting
10:26 < jnewbery> Next question (although feel free to continue asking questions about flags/policy if there's anything unanswered): What is the maximum permitted size of the control block?
10:27 < unweave> If I recall correctly, it was a txn which had sub 1 sat/byte fee rate
10:27 < michaelfolkson> 33+32*128
10:27 < jonatack> static_assert(TAPROOT_CONTROL_MAX_SIZE == 4129); // 33 + (32 * 128)
10:28 < jnewbery> unweave: that is interesting. Most nodes won't propogate transactions with a feerate under 1 sat/byte
10:28 < jnewbery> michaelfolkson jonatack: exactly
10:28 < jnewbery> that was an easy one though :)
10:28 < jnewbery> Next: What happens if a segwit v1 output has a witness program that isn’t 32 bytes? What happens if there’s a P2SH-wrapped segwit v1 output?
10:29 < pinheadmz> jnewbery these are unencumbered
10:29 -!- Simon5 [a254a393@pool-162-84-163-147.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
10:29 < jnewbery> pinheadmz: yes!
10:29 < pinheadmz> although - there was the bech32 issue which could be mitigated if program length was more strictly enforced
10:29 < pinheadmz> lost track of that thread, i guess we are not doing anything about in taproot?
10:29 < robot-dreams> but I believe if the `SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_WITNESS_PROGRAM` flag is set, we will fail validation for these cases
10:29 -!- dhruvm [881873f9@gateway/web/cgi-irc/kiwiirc.com/ip.136.24.115.249] has quit [Ping timeout: 240 seconds]     
10:30 < jnewbery> bech32 is an address format. It doesn't impact consensus or validity of transactions.
10:30 < michaelfolkson> I had to look up what a control block is https://stackoverflow.com/questions/27216460/whats-a-control-block/27227335#27227335
10:30  * michaelfolkson shrugs
10:30 < pinheadmz> jnewbery yes but if we enforce v1 programs to be exactly 32 bytes then we can mitigate a user error where an address has extra qqqq's or whatever it was
10:31 < jnewbery> robot-dreams: right, exactly. So these transactions would be consensus valid, but would fail policy
10:31 < pinheadmz> robot-dreams good point
10:31 < jnewbery> pinheadmz: when you say "we enforce" are you talking about in the wallet software?
10:32 < pinheadmz> hm. i suppose yeah - but consensus doesn't allow witness v0 programs to be != 20 or 32
10:32 < pinheadmz> so even broken wallet software cant lose money sent to a v0 program with 33 bytes
10:33 < pinheadmz> a broken v1 wallet could, although tht point about policy i guess steps in there
10:33 < jnewbery> pinheadmz: yes, an OP_0 then a push that isn't 20 or 32 bytes is always invalid.
10:33 < Paul_R> Can a full-node be adversarial by not-listening to policy? could it then spread undesirable txs to miners & possibly blocks? will this nodes peers ban it?
10:34 < jnewbery> does anyone have any questions about 'P2SH-wrapped'?
10:34 < pinheadmz> Paul_R you cant force a peer to accept a tx. so *their* mempool polocy protects them, including miners
10:34 < jnewbery> Like for example "what is P2SH-wrapped?"? Does anyone have that question?
10:35 -!- musdom [~Thunderbi@202.184.23.26] has quit [Ping timeout: 258 seconds]     
10:35 < robot-dreams> jnewbery: I do have a question, why don't we support that for Taproot?
10:35 < jnewbery> good question robot-dreams!
10:35 < robot-dreams> I'd imagine it'd be a convenient way to let legacy wallets pay to a new address
10:35 < jnewbery> anyone got a good answer for that?
10:35 < pinheadmz> i think its bc it turns into a complexity nightmare
10:35 < pinheadmz> nested was essential for the transition to segwit
10:36 -!- Simon5 [a254a393@pool-162-84-163-147.nycmny.fios.verizon.net] has quit [Ping timeout: 245 seconds]     
10:36 < michaelfolkson> Because we were introducing bech32 right?
10:36 < pinheadmz> this just means that blockchain.com wallets cant send to taproot address :-P
10:37 < michaelfolkson> There is no new address format with Taproot
10:37 < pinheadmz> michaelfolkson right I mean, if you only want to accept taproot ouputs there is no address you can give to a legacy-legacy wallet
10:37 < pinheadmz> with segwit v0 you had the option of nested addresses
10:37 < michaelfolkson> So a P2SH wrapped Taproot won't be able to be spent
10:38 < jnewbery> Right exactly, bech32 has been around for several years, so there's nothing new for wallets to do to be able to send to a taproot output
10:38 < pinheadmz> michaelfolkson there's just no such thing
10:38 < pinheadmz> its anyone can spend
10:38 < jnewbery> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017307.html
10:38 < jnewbery> pinheadmz: exactly - it's unencumbered
10:38 < michaelfolkson> Ah ok
10:39 < nehan> what exactly does unencumbered mean?
10:39 < robot-dreams> Just confirming, "unencumbered" means it's a transaction output that anyone can figure out how to spend just by looking at it (no private keys / etc. neeeded)?
10:39 < robot-dreams> nehan: thanks for asking :)
10:39 < Paul_R> +1     
10:39 < jnewbery> yes that. It's anyone-can-spend
10:40 < michaelfolkson> There's no reason for wanting P2SH wrapped Taproot as far as I know. Other than for avoiding mistakes with anyone can spend
10:40 < jonatack> unencumbered by rules
10:40 < jnewbery> Of course, you'd need the preimage, so maybe unencumbered is maybe the wrong word
10:40 < jnewbery> but if you have the preimage, it's anyone can spend (eg a miner could steal it from you if you created a transaction spending it)
10:41 < jnewbery> does that make sense nehan?
10:41 < nehan> jnewbery: yes thanks
10:41 < jonatack> unencumbered by s/rules/script validation rules/
10:42 < jnewbery> good! Everyone else happy with that? It's a little bit subtle
10:42 < michaelfolkson> encumber -to burden with obligations (dictionary)
10:42 < jnewbery> ok, next question: Explain this line: if (!(flags & SCRIPT_VERIFY_TAPROOT)) return set_success(serror);
10:43 < nehan> why are v1 outputs with lengths other than 32 bytes unencumbered instead of unspendable?
10:43 < michaelfolkson> For future upgradability
10:43 < sosthene> nehan: iirc, it is to allow them being used in the future
10:43 < nehan> ah, ok thanks!
10:43 < pinheadmz> yeah, an interesting design charactersitic of taproot is ALLL the upgradeablity
10:43 < jonatack> The bitwise AND of (flags & SCRIPT_VERIFY_TAPROOT) equalling 1 (true) means we need to verify SCRIPT_VERIFY_TAPROOT?
10:43 < jonatack> so if bitwise AND evaluates to 0 (false) then no need to verify and we can return with success
10:43 < robot-dreams> jnewbery: Taproot validation is a soft fork: if the VERIFY flag is not set, it's unencumbered (similar to legacy client behavior for P2SH and Segwit)
10:44 < pinheadmz> i think the authors might have felt like segwit v0 was too restricvitve perhaps, that theyd painted themself into a corner
10:44 < fjahr> Checks that the SCRIPT_VERIFY_TAPROOT flag is set for this script check. If not it skips verification and returns with success immediately.
10:44 < jnewbery> michaelfolkson sosthene: potentially, but it seems unlikely we'd ever use non-20/32-byte v1 outputs for anything
10:44 < michaelfolkson> No loss though right? If there is even a chance we might use them, keep them upgradable?
10:45 < michaelfolkson> Apart from anyone can spend mistakes by people playing around with this stuff
10:45 < jnewbery> michaelfolkson: is that any worse than unspendable?
10:45 < nehan> well, anyone can spend seems always better than unspendable
10:45 < sosthene> jnewbery: why?
10:46 < michaelfolkson> Fair point. If you put something with anyone can spend on the blockchain you aren't getting it back :)
10:46 < sosthene> I mean, it seems that last year there was discussion about the benefits of leaving this door open, but maybe there are other arguiments since I'm not aware of
10:46 < michaelfolkson> But you aren't getting it back if it is unspendable either so...
10:46  * michaelfolkson shrugs
10:46 < nehan> unspendable = money burnt forever
10:47 < michaelfolkson> anyone-can-spend = enter into a race with the entire Bitcoin world
10:47 < Paul_R> could someone create a 'chain-analysis' of sorts, to automatically detect unencumbered coins and sweep them?
10:47 < jnewbery> robot-dreams: that's right, if the flag isn't set, then a v1 segwit output is unencumbered
10:47 < jnewbery> Paul_R: I'm sure they already have
10:47 < unweave> michaelfolkson and yet as pinheadmz 's txn shows, it's a very slow race, no?
10:48 < Paul_R> because then it seems like there would be some parties competing to do so, which would be a weird industry... yeah pinheadmz shows it is a very slow race so far haha
10:48 < unweave> Paul_R this already happens with low entropy keys
10:48 < michaelfolkson> Oh no that actually is unspendable isn't it?
10:48 < pinheadmz> that and as discussed, policy rejects spending from anyonecanspend
10:48 < pinheadmz> so itd have to be a clever miner
10:48 < michaelfolkson> Wasn't that a Taproot output?
10:48 < michaelfolkson> Before Taproot is activated?
10:48 < pinheadmz> and yes, the taproot address i used is just 32 0x01 bytes -- so this output is actually UNSPENDABLE once taproot activates!
10:49 < pinheadmz> (bc there is no private key for that witness program)
10:49 < Paul_R> pinheadmz all for 5000sats // .50 euros
10:49 < unweave> ah I think I misunderstood
10:49 < unweave> :)     
10:49 < michaelfolkson> Oh there's that too pinheadmz but it is currently unspendable now too right?
10:49 < jnewbery> Final question: What error is given if VerifyTaprootCommitment() fails? Why?
10:49 < pinheadmz> witness program mismatch
10:50 < pinheadmz> this is the function that checks that the control block crap and witness data match the output, aka witness program aka the adress coin is sent to
10:50 < pinheadmz> oops didnt mean to type crap
10:50 < michaelfolkson> banned
10:50 < jonatack> no more review club for you
10:50 < jnewbery> :shocked:
10:50 < pinheadmz> damn
10:51 < pinheadmz> starting my own ##PR-club-with-cuss-words
10:51 < robot-dreams> This means the witness program (Schnorr public key) didn't commit to the Merkle root demonstrated by the script
10:51 < fjahr> michaelfolkson: it's not really a race between the entire bitcoin world though, only the question which miner mines the next block. If you send a miner a anyonecanspend why would they mine it for you? They will just replace it with their own tx.
10:51 < robot-dreams> (though I don't yet know the mechanism by which a Schnorr public key commits to a hash)
10:51  * michaelfolkson checks code of conduct
10:52 < jnewbery> but yes, it's the function that checks that the witness program has commited to the witness, so if it fails, then it's a witness program mismatch
10:53 < jnewbery> ok, we have a few minutes left. Did anyone have any other questions or observations they wanted to share?
10:53 < unweave> [off topic] Paul_R see this presentation for examples of automated sweeping of low-entropy bitcoin funds https://www.youtube.com/watch?v=foil0hzl4Pg "DEF CON 23 - Ryan Castellucci - Cracking CryptoCurrency Brainwallets"
10:53 < Paul_R> unweave thx!
10:54 < michaelfolkson> Yeah I guess its worse than I said. Race in which you can only win if miner is dumb
10:54 < robot-dreams> to followup on P2SH wrapping:
10:54 < robot-dreams> was the conclusion "we're not going to support this because the benefit (allowing very old wallets to send to a taproot output) isn't worth the multitude of added complexity, privacy implications, etc."?
10:56 < jnewbery> robot-dreams: yes, those are good arguments against
10:57 < jnewbery> I argued against it here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016943.html because I think the benefits of allowing P2SH-wrapped segwit v0 don't apply any more
10:57 < jnewbery> ok, just about time to wrap up. Any final thoughts? How are y'all enjoying taproot review?
10:57 < jonatack> we lost gzhao408
10:58 < Paul_R> that was a great first experience, thanks everyone
10:58 < Paul_R> i wish i had come sooner
10:58  * gzhao408 was afk because of work meeting
10:58 < robot-dreams> very exciting taproot review, this was a great entry point into "what is taproot"
10:58 < michaelfolkson> I'd like to suggest added comments to Taproot PR but I guess it isn't a good time
10:58 < jnewbery> ok, let's call it. Thanks everyone. See you all next week!
10:58 < sosthene> thanks, that was very interesting
10:59 < gzhao408> jnewbery i am loving taproot review, script is very exciting stuff
10:59 < jonatack> Paul_R: great 🚀
10:59 < jnewbery> #endmeeting
10:59 < pinheadmz> thanks all!
10:59 < emzy> I will not lie it was over my head. But learnd a litte on the way. Thank you everone!
10:59 -!- Paul_R [adf60e57@173-246-14-87.qc.cable.ebox.net] has left #bitcoin-core-pr-reviews []     
10:59 < robot-dreams> thanks!
10:59 < pinheadmz> emzy feel free to stick around and ask more Qs if you have
10:59 < fjahr> thanks jnewbery
10:59 < gzhao408> thanks jnewbery!
10:59 < pinheadmz> this is my favorite channel on IRC :-) even outside of meetings, very helpful people lurking
11:00 < jnewbery> emzy: as long as you learn a little bit every time, then it'll all fit together eventually!
11:00 < emzy> pinheadmz: I will do. If the topice is more mine! :)
11:00 < jnewbery> pinheadmz: dawww 🤗
11:00 < michaelfolkson> Thanks jnewbery. And congrats on poaching mr wuille!
11:00 < emzy> jnewbery: right
11:00 -!- figs [68c88135@104.200.129.53] has quit [Remote host closed the connection]     
11:01 < jonatack> thanks jnewbery! great meeting
11:01 < jnewbery> emzy: and don't be afraid to speak up. Review club exists for everyone to be able to ask questions
11:01 < sosthene> I think for some of us it is more a speed issue than being afraid of asking questions
11:01 < emzy> Yes very welcoming group here.
11:02 < sosthene> I don't know about emzy, but I'm kind of slow
11:02 < michaelfolkson> I have thought about starting early (eg half hour early) and going over absolute basics before host shows
11:03 < michaelfolkson> So then when host shows at start it goes into second or third gear
11:03 < emzy> I'm slow in answering. Because of language barrier. But keeping up reading is no problem for me.
11:03 < unweave> +1 michaelfolkson
11:03 < sosthene> that might not be enough when it's about taproot though :o
11:04 < robot-dreams> michaelfolkson: that sounds awesome as long as people still feel ok asking any questions during the main meeting
11:04 < michaelfolkson> But even without that you can still post basic questions yourself before the meeting starts. We are free to chat here all day long
11:04 < sosthene> yeah, language barrier, I see we're at least 2 non native speakers here
11:04 < jnewbery> michaelfolkson: please no. The meeting is for everyone to be able to ask questions. What you're actually suggesting is turning the meeting into 1.5 hours
11:04 < michaelfolkson> Ok     
11:05 -!- sosthene [~sosthene@176-191-246-113.abo.bbox.fr] has quit [Quit: leaving]     
11:05 < jnewbery> having a fixed one hour time slot is the best we can do to make this meeting accessible to as many people as possible
11:05 < unweave> off topic: Can anyone explain what derandomization means in this abstract? https://eprint.iacr.org/2020/1057
11:06 < unweave> do they mean, adversarial nonces? e.g. an attacker trying to obtain valid signatures via malicious nonces?
11:06 < jonatack> emzy: sosthene: no worries, not everyone is great at multi-threaded irc chat either. i'm not.
11:06 < emzy> I had no issue with todays meeting. I'm simply more into network stuff like p2p.
11:06 < jnewbery> sosthene: I'm not sure if this would help you, but perhaps prepare by writing out questions before the meeting?
11:06 < unweave> jonatack IRC with branched timelines would be fun :)
11:07 < jonatack> unweave: heh. monotasking FTW here.
11:08 < michaelfolkson> I do think that is a common concern though and why a lot of first timers don't come back. They go away daunted at how little they know
11:08 < michaelfolkson> I am still daunted now but I fight through it ;)
11:09 < unweave> michaelfolkson would adding annotations to the PRreview club page add that context that new comers lack?
11:09 < unweave> s/page/web page/
11:09 < robot-dreams> sosthene: I write some stuff beforehand, a lot of my messages today were copy pastes from a text document :)
11:09 < emzy> I think wo had much easyer PRs in the past. Today was not the best to start of.
11:10 < michaelfolkson> Maybe... but it is a lot of work just to get those notes up. And they give a lot of context as it is
11:10 < michaelfolkson> You just can't summarize the whole of Mastering/Grokking/Programming Bitcoin into a page or two
11:13 < jonatack> unweave: the PRs to add the notes are public, i often review those PRs, and proposals to add additional basic context might be useful. writing the notes and questions can be the hardest part of hosting these sessions. i really spent a lot of time on them when i hosted.
11:14 < jonatack> unweave: the repo is here https://github.com/bitcoin-core-review-club/website/
11:14 < emzy> I appreciate they very much!
11:15 < michaelfolkson> It is hard. I get John's point. If we informally started early then the host would feel as if they have to be there from the start. But I would like to chat about stuff before the meeting starts while I am preparing and looking at stuff
11:15 < michaelfolkson> As long as it doesn't cover directly the questions that the host has prepared
11:16 -!- kimgnome [~manjaro-g@2804:14d:baa1:8ad0:7e67:a2ff:fee6:efb] has quit [Quit: Leaving]     
11:16 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]     
11:19 < unweave> jonatack yes I remember reading some of the review-club pr's to gain some more insight; maybe other's would gain value if the link to the website PR was included on the web page
11:19  * unweave shrugs
11:24 < michaelfolkson> I don't get your suggestion. What do you mean? The PR is linked on the web page?
11:24 < unweave> the PR of the code-review website
11:25 < michaelfolkson> Oh you mean the conversation that goes on around the creation of the notes prior to the meeting?
11:25 < unweave> yeah
11:26 < unweave> the content is hit or miss but sometimes seeing it evolve is helpful
11:26 < unweave> just a shot in the dark suggestion
11:26 < michaelfolkson> I haven't been monitoring that I don't think. I remember seeing a lot of conversation between Jon and Gloria before she hosted hers. That was interesting
11:27 < michaelfolkson> I think it depends on the host and how willing they are to spend time implementing Jon's great suggested edits ;)
11:28 < jonatack> unweave: subscribe to github notifications on that repo and you'll be in da loop -- that's how i know when someone PRed some notes
11:28 < michaelfolkson> Right, not too many notifications for this repo either
11:29 < jonatack> michaelfolkson: sometimes it's a give and take when the host is up for it, sometimes john or i just rewrite the notes a bit when the host is busy
11:29 < jonatack> michaelfolkson: good point
11:47 < jnewbery> Meeting log is up: https://bitcoincore.reviews/17977-3
11:48 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews     
11:48 < sipa> crap, seems i missed it!
11:49 < jnewbery> sipa: we activated taproot without you
11:50 < unweave> yep     
11:50 < jnewbery> hope that's ok
11:50 < pinheadmz> we're working on witness v2 already. lamport sigs. quantum resistant.
11:51 < jnewbery> don't forget the hypercubes and gigamegs
11:51 < sipa> kewl
11:51 < pinheadmz> april fools day idea: review club meeting where nothing makes sense and we only use star trek words
11:52 < robot-dreams> pinheadmz: so, regular meeting?
11:52 < jnewbery> in slightly more down-to-earth news, pinheadmz will host on signet next week. Notes and questions to follow soon in the normal place: https://bitcoincore.reviews/18267
11:53 < robot-dreams> pinheadmz: jkjk, alternatively, review club meeting where you're only allowed to use 1000 most common words? https://xkcd.com/simplewriter/
11:54 < sipa> the 10 100 words people use the most?
11:55 < unweave> "computer money makes people free"
12:00 < sipa> nehan: the space of witness versions is very small (there are just 17 of them), but if you treat the program length as part of the version, it's a lot bigger
12:00 < sipa> so i think it was a mistake that witness v0 enforced size 20 or 32 only
12:01 < pinheadmz> good way to put it -- so we can have witness v1 but where program is 33 bytes, and the 33rd byte opens up another 256 sub-versions
12:01 < sipa> exactly
12:02 < pinheadmz> i know this probablya bonkers question to think about right now -- but what do you think the *next* upgrade will be ?
12:04 < sipa> well, what kind of upgrade?
12:04 < pinheadmz> next to require a soft fork
12:05 < sipa> no idea :)
12:05 < sipa> i can talk about what kinds of softforks would be done how (as we have half a dozen upgrade mechanisms post-taproot...), but i'm not going to speculate about which may happen or when
12:06 < pinheadmz> recently watched your scaling talk introducing segwit from 2015 or whenevr that was... you mention schnorr and MAST even before segwit v0 bip was written! Taproot one was a long time coming
12:06 < sipa> dec 2015
12:06 < pinheadmz> no-beard sipa
12:06 < unweave> pinheadmz lol
12:06 < unweave> hong kong
12:07 < sipa> i think in many ways bip341, besides the taproot part, completes a number of upgrades that were started with segwit, but weren't completed
12:08 < sipa> leaf versions is one
12:08 < sipa> merkle tree based scripts
12:08 < sipa> committing to all spent UTXOs
12:11 < michaelfolkson> I guess when Taproot is done and dusted you'll revisit the work you did on Graftroot, G'root and cross input aggregation sipa
12:11 < michaelfolkson> In the far future
12:12 < michaelfolkson> There's not much out there on those topics. It kind of needs you or at least someone from a very small group of people to pick that up again
12:14 < unweave> sipa, I was confused (probably due to ignorance) as to what derandomization means in the MuSig-DN abstract https://eprint.iacr.org/2020/1057 Does derandomization mean, adversarial nonces? e.g. an attacker trying to obtain valid signatures via malicious nonces? of am I missing something
12:15 < unweave> s/of/or
12:17 < sipa> derandomized nonce just means there is no randomness involved in constructing the nonce
12:17 < sipa> it's desirable because RNGs are fragile things, especially on weak hardware, or on a paper wallet, ...
12:18 < michaelfolkson> Tim Ruffing discussed this in his Schnorr multisig presentation
12:18 < michaelfolkson> https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2020-06-17-tim-ruffing-schnorr-multisig/
12:18 < michaelfolkson> "Deterministic Randomness" section
12:19 < michaelfolkson> I'm assuming that is same topic
12:20 < sipa> unweave: in normal single-sig Schnorr/ECDSA signatures you really want derandomized nonces... for very pragmatic non-theoretical reasons; it's just easier to test, and less that can go wrong with them
12:21 < sipa> see e.g. RFC6979
12:21 < sipa> unfortunately, if you naively use such a derandomized nonce in a multisignature scheme like MuSig or BN, you're suddenly completely insecure
12:24 < unweave> yes I seem to recall some of those weaknesses,  I think my confusion was even more basic in that I didn't realize derandomized meant deterministically random (unless I've missed something)
12:24 < sipa> "deterministically random" is a contradiction :)
12:24 < sipa> if it's deterministic it's not random
12:24 < sipa> but i see why they're easy to confuse
12:29 < michaelfolkson> But derandomization is equivalent to deterministically random used in this context right?
12:29 < michaelfolkson> We are just using derandomization now instead
12:30 < sipa> just say "deterministic", not "deterministically random"
12:31 < michaelfolkson> deterministic, random and derandomized
12:31 < michaelfolkson> Three categories
12:32 < sipa> i think the term derandomization just refers to starting with an algorithm that's designed for random inputs, and then replacing it with something non-random
12:32 < sipa> the result is deterministic
12:33 < unweave> my gut intuition was deterministic randomness was, the result of a function but takes an argument which is random/entropic and all outputs of the function are independent of each other or at least stochastic and the size is as large as the input random input
12:33 < sipa> then it's random, not deterministic
12:34 -!- hanhua [63687d99@99-104-125-153.lightspeed.sntcca.sbcglobal.net] has quit [Remote host closed the connection]     
12:34 < sipa> with RFC6979 signing is fully deterministic; the nonce is effectively a hash of the private key and the message
12:35 < sipa> with MuSig-DN it's a bit more complicated, but similar; the nonce becomes a function of a nonce key, the message, and the public keys of all other signers
12:35 < sipa> there is no randomness involved at all at signing time
12:35 < michaelfolkson> Yeah if the function is not constant (constant being f(x) = 5 etc) then feeding a function random inputs will result in random outputs
12:36 < sipa> really what MuSig-DN accomplishes is making signing stateless
12:37 < sipa> you still have multiple rounds in the signing process, but the signer doesn't need to remember which one he has already participated in
12:37 < sipa> or remember randomness/nonces from one to the next
12:37 < unweave> ah, powerful
12:37 < sipa> it comes at a high cost though
12:37 < sipa> signing is orders of magnitude slower
12:38 < unweave> are the MuSig-DN verification costs lower than existing verification costs?
12:39 < sipa> the result is a schnorr signature, indistinguishable from other schnorr signatures
12:39 < sipa> so verification is literally identical
12:40 < unweave> eg signers gain covertness at computation penalty?
12:40 < sipa> compared to what?
12:40 < sipa> there is a privacy advantage compared to just MuSig
12:41 < unweave> non DN  MuSig
12:41 < sipa> *no privacy advantage
12:41 < unweave> oh     
12:41 < sipa> no, it just means signing doesn't need state/randomness
12:41 < unweave> so it's just soundness
12:41 < sipa> that's all
12:41 < unweave> ok     
12:41 < sipa> and you gain a round
12:41 < sipa> MuSig has 3 rounds; MuSig-DN has only 2 (but much more expensive ones)
12:42 < sipa> MuSig is also sound, and has a security proof under similar asusmptions as MuSig-DN
12:43 < sipa> but it needs randomly generated nonces at signing time
12:45 < michaelfolkson> Use MuSig-DN if you think you could lose previous state. Use MuSig if you are extremely confident you can store the previous state
12:45 < sipa> store the state *securely*
12:45 < sipa> it's not really about losing the state; it's about protecting an attacker from changing it
12:45 < unweave> yeah
12:46 < michaelfolkson> Attacker could hack you and change it or just delete it?
12:46 < sipa> that would make MuSig insecure
12:46 < unweave> If the nonce isn't random, you're pwned
12:46 < sipa> depending on implementation, it may be fine to let an attacker *see* your state
12:46 < sipa> but if they can modify it, you're screwed
12:47 < sipa> or even just if they can rewind your state to a previous version
12:47 < sipa> (so e.g. self-signing your state doesn't help)
12:48 < sipa> you could put it on a blockchain
12:48  * sipa hides
12:48 < unweave> good insight
12:49 < sipa> we have some upcoming work on another variant of MuSig that does still need state, but only has 2 rounds (of which one can even be in a setup step before the message is known)
12:49 < sipa> which should be a strict improvement over normal MuSig (it doesn't have the cost of MuSig-DN either)
12:51 < michaelfolkson> That would be good to get strict improvement. Too many flavors of MuSig will be bewildering
12:52 < sipa> yes     
12:53 < sipa> this musig2 construction also allows for private nesting (so you can have multiple levels of musig aggregation, and not tell your "sibling participants" that you have "child participants")
12:54 < michaelfolkson> Which you can't do with MuSig1 *or* MuSig-DN?
12:55 < sipa> indeed
12:56 < michaelfolkson> Which for Lightning channel funding transaction... MuSig2 or MuSig-DN...
12:57 -!- worc3131 [~AdminUser@2a02:c7f:c026:9500:7d0b:65d0:38a4:4786] has joined #bitcoin-core-pr-reviews     
12:57 < michaelfolkson> I guess it would be based on the participants' security considerations rather than Lightning protocol considerations...
12:58 < emzy> Is there already a proposal for lightning via taproot?
12:58 < sipa> MuSig-DN is unfortunately pretty unpractical due to computational costs (1s signing time on modern desktop cpu...)
12:59 < michaelfolkson> There are mailing list posts emzy but the implementation devs are staying clear for now (at least publicly)
12:59 < michaelfolkson> Z-man and AJ posted on the topic
12:59 < emzy> Ok.     
13:01 < michaelfolkson> Ah so MuSig-DN will be for very specific use cases where there is strong enough motivation
13:01 < michaelfolkson> Not Lightning
13:02 < michaelfolkson> Any chance MuSig-DN will iteratively improve over time? What does the crystal ball say :)
13:04 < sipa> unlikely
13:05 < sipa> well, it depends in exchange for what
13:05 < sipa> if you're ok with removing a security proof under traditional assumptions, you can probably do 10x better or so
13:14 -!- gleb4 [~gleb@178.150.137.228] has joined #bitcoin-core-pr-reviews     
13:37 < unweave> What use cases are excluded due to a 1 second signing time?
13:39 < sipa> any online service, pretty much
13:40 < sipa> hardware wallets (which are orders of magnitude slower than modern desktops)
13:42 < unweave> HW wallet was the only situation I could think of
13:42 < unweave> What's an example of "online service" not sure I follow.
13:44 < sipa> eh, anything
13:45 < sipa> any website that signs on behalf of customers (exchanges, online wallets, ...)
13:45 < sipa> services that act as 2FA signers like bitgo or blockstream green
13:45 < unweave> ah ok infrastructure sevices
13:45 < sipa> it's not impossible of course, but it'd be a very high cost
13:46 < unweave> yeah 1 second is very high for an infrastructure provider
13:58 -!- gzhao408 [uid453516@gateway/web/irccloud.com/x-zvgwzciyegdflngh] has quit [Quit: Connection closed for inactivity]     
14:04 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
14:06 -!- unweave [~unweave@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: unweave]     
14:46 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection]     
14:59 -!- Netsplit *.net <-> *.split quits: ariard
15:00 -!- ariard_ [~ariard@167.99.46.220] has joined #bitcoin-core-pr-reviews     
15:50 -!- musdom [~Thunderbi@202.184.23.26] has joined #bitcoin-core-pr-reviews     
15:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
16:05 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
16:24 -!- lightlike [~lightlike@p200300c7ef16d7005597c88be3df51bc.dip0.t-ipconnect.de] has quit [Quit: Leaving]     
16:33 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews     
16:33 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host]     
16:33 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews     
16:33 -!- TheRec_ [~toto@drupal.org/user/146860/view] has quit [Ping timeout: 260 seconds]     
17:03 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Read error: Connection reset by peer]     
17:03 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #bitcoin-core-pr-reviews     
17:16 -!- achow101_ [~achow101@unaffiliated/achow101] has quit [Ping timeout: 256 seconds]     
17:17 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-pr-reviews     
17:21 -!- raddev [~Android@pool-96-240-5-223.nwrknj.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
17:31 -!- raddev [~Android@pool-96-240-5-223.nwrknj.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
17:33 -!- raddev [~Android@pool-96-240-5-223.nwrknj.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
17:38 -!- raddev [~Android@pool-96-240-5-223.nwrknj.fios.verizon.net] has quit [Read error: No route to host]     
17:38 -!- raddev [~Android@pool-96-240-5-223.nwrknj.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
18:17 -!- dhruvm [881873f9@gateway/web/cgi-irc/kiwiirc.com/ip.136.24.115.249] has joined #bitcoin-core-pr-reviews     
18:25 -!- raddev [~Android@pool-96-240-5-223.nwrknj.fios.verizon.net] has quit [Read error: Connection reset by peer]     
18:25 -!- raddev_ [~Android@pool-96-240-5-223.nwrknj.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
18:49 -!- robot-dreams [~robot-dre@172.92.4.53] has quit []     
18:51 -!- dhruvm [881873f9@gateway/web/cgi-irc/kiwiirc.com/ip.136.24.115.249] has quit [Ping timeout: 256 seconds]     
20:39 -!- evanlinjin [~evanlinji@2404:4408:43ff:bb00:54d6:162b:a8d7:7fa4] has quit [Read error: Connection reset by peer]     
20:40 -!- evanlinjin [~evanlinji@2404:4408:43ff:bb00:4234:9184:49d5:7ba2] has joined #bitcoin-core-pr-reviews     
22:19 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds]     
22:50 -!- norisg [~nobody123@dslb-094-216-002-184.094.216.pools.vodafone-ip.de] has joined #bitcoin-core-pr-reviews     
22:54 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 256 seconds]     
22:55 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews     
23:57 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 258 seconds]     
23:59 -!- gleb [sid306870@gateway/web/irccloud.com/x-vvphgecjezmgtmwq] has quit []     
23:59 -!- gleb4 is now known as gleb