--- Day changed Thu Jan 23 2020 00:01 -!- evoskuil[m] [evoskuilma@gateway/shell/matrix.org/x-ephmtkfshqalyewp] has quit [Ping timeout: 250 seconds] 00:02 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has joined ##taproot-bip-review 00:02 -!- nothingmuch [~nothingmu@unaffiliated/nothingmuch] has joined ##taproot-bip-review 00:02 -!- nehan_ [~nehan@41.213.196.104.bc.googleusercontent.com] has joined ##taproot-bip-review 00:02 -!- raj_ [~quassel@ec2-18-217-191-36.us-east-2.compute.amazonaws.com] has joined ##taproot-bip-review 00:45 -!- asoltys [~adam@115.96.198.104.bc.googleusercontent.com] has joined ##taproot-bip-review 00:45 -!- dr_orlovsky [~dr-orlovs@ip216.ip-54-36-238.eu] has joined ##taproot-bip-review 00:45 -!- philbw4 [~znc-admin@157.245.253.12] has joined ##taproot-bip-review 02:34 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds] 02:55 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-bip-review 03:29 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 272 seconds] 04:18 -!- evoskuil[m] [evoskuilma@gateway/shell/matrix.org/x-bzqgrajcrngebnhu] has joined ##taproot-bip-review 04:22 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-bip-review 04:44 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 246 seconds] 05:21 -!- jonatack [~jon@213.152.162.79] has joined ##taproot-bip-review 07:10 -!- jonatack [~jon@213.152.162.79] has quit [Ping timeout: 268 seconds] 07:27 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined ##taproot-bip-review 07:40 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 240 seconds] 07:51 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has joined ##taproot-bip-review 08:12 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has quit [Quit: notmandatory] 09:00 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-bip-review 11:41 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds] 11:42 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined ##taproot-bip-review 11:57 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 11:58 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined ##taproot-bip-review 12:24 -!- orlovsky [~dr-orlovs@194.230.155.171] has quit [Quit: Textual IRC Client: www.textualapp.com] 12:25 -!- dr-orlovsky [~dr-orlovs@194.230.155.171] has joined ##taproot-bip-review 13:06 -!- pigeons [~pigeons@androzani.sysevolve.com] has quit [Ping timeout: 264 seconds] 13:18 -!- Netsplit *.net <-> *.split quits: maaku, jkczyz, willcl_ark 13:25 -!- jkczyz [~jkczyz@135.84.132.250] has joined ##taproot-bip-review 13:25 -!- pigeons [~pigeons@androzani.sysevolve.com] has joined ##taproot-bip-review 13:26 -!- pigeons is now known as Guest92238 13:50 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 248 seconds] 13:58 -!- jonatack [~jon@213.152.161.138] has joined ##taproot-bip-review 14:01 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined ##taproot-bip-review 14:01 -!- maaku [~quassel@ec2-54-186-10-232.us-west-2.compute.amazonaws.com] has joined ##taproot-bip-review 18:08 < jeremyrubin> If I look at an arbitrary Taproot key K, can I test if the root is R without knowing anything else? No, right? I need to know Q such that Q tweaked with R is K? 18:09 < sipa> if K = Q + H(Q||R)G, and R is uniformly random, then K is computationally indistinguishable from uniformly random 18:10 < sipa> so not only can you not test for it, you can in fact not learn anything at all about R if you don't know Q 18:11 < sipa> this goes both ways; if either Q or R is unknown and uniformly random, K will be indistinguishable from uniformly random 18:12 < jeremyrubin> right. And vice versa -- you can't learn anything of Q only knowing R and K because you can't compute H(Q||R)G 18:13 < jeremyrubin> But it would be possible, in theory, were you to learn the midstate of H(Q||...) (and assuming some padding or something) then you could compute K-H(Q||R) G = Q without knowing Q 18:14 < jeremyrubin> (but Q is 32 bytes so for sha256 there is non midstate you could send without revealing Q) 18:15 < jeremyrubin> I don't have a use for this, just checking that my understanding is correct. 18:16 < sipa> all seems right 18:17 < gmaxwell> you could also do ZKPs over any of these values. 18:18 < jeremyrubin> Interestingly, there's sort of provably no use for having H(H(Q) || R) instead of H(Q || R) because to send over the midstate so that you might compute Q from K, R you may as well just send Q. 18:19 < gmaxwell> in general learning H(Q) or midstate(Q) is also pretty close to equivilent to revealing Q. 18:20 < jeremyrubin> The thing I'm brainstorming a little in the ##ctv-bip-review channel is the case where a sender picks some random key K, encrypts it to your key YG and includes it as op_return or whatever, computes a MusigKey(YG, KG), then you can do something like stealth addresses. 18:21 < jeremyrubin> The thing I was thinking of in particular, is if there was a way to put in the Tapscript an OP_CTV to paying your unencumbered key 18:21 < jeremyrubin> then you can skip encrypting K 18:21 < jeremyrubin> and just do opportunistic multisig for privacy 18:22 < jeremyrubin> But that *only* works if there's some way for the owner of key Y to see that their tapscript is for them without knowing K 18:22 < jeremyrubin> But as this seems to not be the case, you would still need to learn at least KG for this protocol to work 18:22 < sipa> not revealing any information about the scripts to someone who doesn't know the internal pubkey is an intentional privacy property 18:23 < jeremyrubin> Reasonable 18:23 < jeremyrubin> You'd have to encrypt it and include an op_return or communicate out of band, so there's not really an improvement (other than maybe in terms of API) from stealth addresses today 18:24 < jeremyrubin> Has anyone written up post-taproot stealth addresses? 18:25 < sipa> i don't think stealth addresses are interesting as they require putting unnecessary data onchain 18:26 < sipa> my best guess for solving the practical problem they solve is lightning 18:26 < gmaxwell> sipa: one could technically use one of the signature's Rs... 18:26 < gmaxwell> joinmarket donations work that way, IIRC. 18:27 < jeremyrubin> Clever -- so you spend, and then the R value is decrypted by the recipient to reveal the tweak? 18:27 < sipa> gmaxwell: have any reference? 18:28 < sipa> needing to do EC operations to detect incoming transactions is annoying too 18:28 < gmaxwell> jeremyrubin: the tweak is ECDH with a sender provided point and a recipent pubkey (which is part of their address)... reuse of r just uses R as the senders point. 18:28 < sipa> gmaxwell: where does the sender provide the point? 18:28 < jeremyrubin> That's different than stealth addresses though IIRC 18:28 < gmaxwell> jeremyrubin: no its not. 18:29 < jeremyrubin> For a stealth address isn't the point encrypted 18:29 < jeremyrubin> So that an adversary aware of recipient PK can't check who it belongs to? 18:29 < gmaxwell> jeremyrubin: DDH means they cannot check. 18:29 < jeremyrubin> ah ok 18:30 < gmaxwell> sipa: the R value of one of their signatures. (e.g. the first, or any and you just have to check all of them) 18:30 < jeremyrubin> But by picking R this way is there risk of revealing the senders SK? 18:30 < gmaxwell> sipa: you sign using a nonce generating function that returns k in the aux data. 18:31 < jeremyrubin> Need to re-read on DDH 18:31 < gmaxwell> R isn't picked in a special way. 18:31 < jeremyrubin> Gotcha! 18:31 < sipa> jeremyrubin: DDH means that given 4 points A,B,C,D you cannot check whether A/B = C/D 18:31 < gmaxwell> You could break security mishandling the returned k, for sure. So don't mishandle it. :) any kind of cryptographic software is dangerous. :) 18:31 < sipa> or formulated alternatively, you cannot distinguish tuples (G,aG,bG,abG) from random 4-tuples 18:32 < jeremyrubin> So you send the funds to rKG basically? 18:32 < sipa> jeremyrubin: does not compute - you can't multiple two points 18:32 < jeremyrubin> Ah 18:32 < jeremyrubin> I mean 18:32 < jeremyrubin> rkG 18:33 < jeremyrubin> and the sender can compute that by mult kR 18:33 < jeremyrubin> but can't ever learn r this way since they just know R 18:33 < jeremyrubin> Wait but how do they then sign? 18:33 < gmaxwell> No, the user gives you two pubkeys. P1 and P2. (technically you can do one but then you can't delegate scanning). you compute their address as H(kP1)G + P2. 18:34 < gmaxwell> and you pick k however you want, and use that k in your signature. 18:34 < sipa> ah, neat 18:34 < jeremyrubin> Sorry, I feel I'm sufficienly ill informed on stealth addresses mechanics that I just know the general concept but not the actual protocol. Thx for explaining 18:34 < gmaxwell> The recipent scans all transactions and yanks out their r's and computes H(x1R)G + x2 and sees if that address got paid. 18:35 < gmaxwell> it's the same protocol, but instead of commuincating a point in an opreturn you abuse the fact that the signature already has a point in it. 18:35 < jeremyrubin> Neat 18:36 < gmaxwell> this does, however, require your wallet do ecdh with every transaction. but like a fast desktop can do 6000/sec/core or whatever, so not really an issue. 18:36 < sipa> can you scan for multiple P1/P2 pairs simultaneously any faster? 18:36 < gmaxwell> regular stealth addresses are exactly the same but use an op return and have some additional hash (optional?) you can use to skip irrelevant outputs at the expense of your privacy. 18:37 < sipa> seems not, apart from some batch inversion maybe 18:37 < gmaxwell> sipa: not really. 18:37 < gmaxwell> right. 18:38 < gmaxwell> Thats one of the reasons I liked the 'rerandomizable dual point pubkeys' idea, because it means you could give out lots of distinct addresses and stil scan them with one key. :) 18:38 < jeremyrubin> I like the idea that someone else could ZKP you are not the owner of a tx in a block tho 18:38 < jeremyrubin> s/tx/output/ 18:38 < jeremyrubin> that would make the outsourcing better 18:39 < jeremyrubin> So then no outsourcer can lie to you about finding funds 18:41 < gmaxwell> I don't think outsourcing really makes a lot of sense, except in so far as that "outsoucrcing" lets you preserve a good online wallet/ offline wallet split. 18:41 < gmaxwell> The problem is that essentially anyone who would _offer_ outsourcing would inevitably be in the surveilance business. Because duh. 18:42 < jeremyrubin> Well... 18:42 < gmaxwell> (and indeed, we know from calling up tracking companies and pretending to be customers that they're getting data from existing things like that) 18:42 < jeremyrubin> You can share a P2 with a set of people! 18:42 < jeremyrubin> balancing out the "scan everything" v.s. "scan some things" 18:43 < gmaxwell> In any case, scanning everything is pretty cheap regardless. 18:43 < gmaxwell> Monero works that way inherently. 18:43 < gmaxwell> And it seems to work well enough. 18:43 < jeremyrubin> So another question: 18:43 < jeremyrubin> Given a known Taproot X 18:43 < jeremyrubin> Can someone re-blind it? 18:43 < jeremyrubin> Or would that interfere? 18:44 < sipa> no, because the hash commits to all the inputs 18:45 < sipa> (and it has to) 18:45 < gmaxwell> you can make a version of that above scheme that works with taproot but the existance of the script cannot be hidden. 18:45 < gmaxwell> I mean, can't be hidden from the sender. 18:45 < jeremyrubin> right 18:45 < jeremyrubin> Because they need to tweak Q 18:45 -!- notmandatory [~textual@76.169.37.102] has joined ##taproot-bip-review 18:45 < jeremyrubin> Is that correct? 18:45 < gmaxwell> Right. 18:45 < jeremyrubin> Seems not the ~worst~ tradeoff 18:46 < jeremyrubin> Gain 1 privacy lose 1 privacy 18:46 < gmaxwell> of course, if you can interact with the recipent you can just ask them to generate you an address and the need for any of this stuff goes away. 18:47 < jeremyrubin> Well... sort of. I think stealth addresses are actually really useuful for interacting with cold wallets in a sense. 18:47 < jeremyrubin> When you don 18:47 < jeremyrubin> *don't want to / can't do public HD key derivation 18:48 < jeremyrubin> and you don't have a cache of pre-generated HD keys 18:49 < gmaxwell> I mean, this _is_ a public HD key derrivation... so whatever reason you have for not using that should apply here equally. 18:49 < jeremyrubin> The difference being that you're encoding the tweak param in the txn 18:50 < jeremyrubin> making it so you don't need to store the tweak, it's in the txdata 18:50 < jeremyrubin> Above just storing the blockchain that is 18:50 < gmaxwell> you don't need to store it in any case. It can just be some hash of your private key, for example. 18:51 < gmaxwell> And as far as scanning goes, yes you have to scan but thats true for the stealth address too and it's a much more expensive scan that also requires and ECDH with each transaction. 18:51 < jeremyrubin> fair pt 18:51 * jeremyrubin afk 18:52 < gmaxwell> I don't think they're useless, but I think their applicability is pretty narrow. Essentially they're great for public donation addresses. In most other circumstances you have two way communication. 18:53 < gmaxwell> There are great reasons to not use public derrivation unfortunately they all apply to stealth addresses equally. 19:08 < maaku> gmaxwell: most times in real life I make payments I don't have two-way low latency electronic communication available 19:15 -!- notmandatory [~textual@76.169.37.102] has quit [Quit: notmandatory] 19:20 < gmaxwell> you have two way communication available or how would you know you need to pay / know that the thing you've paid for is done. 19:21 < gmaxwell> You might not be paying electronically at all, sure, but the communication is kind of inherent in the whole act of 'paying'. 20:15 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has joined ##taproot-bip-review 20:24 < maaku> gmaxwell: instructions are often relayed one-way and/or reused 20:24 < maaku> e.g. "send a wire transfer with these routing numbers..." 20:26 < maaku> and what I am given is a generic PDF 20:26 < maaku> they know I paid not because of some memo field, which would count as 2-way communication, but because some human checks that the desired amount showed up 20:27 < maaku> I mean, tihs is a clunky brittle system and we can do better. But it's not exactly accurate to say that in most circumstances you have suitable two-way communication setup 20:29 < maaku> prior to payment 20:30 < maaku> which is communication itself, I suppose 22:39 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has quit [Quit: notmandatory]