--- Day changed Thu Aug 29 2019
00:05 < raedah> https://github.com/decred/cspp
01:35 -!- Zenton [~user@unaffiliated/vicenteh] has joined #joinmarket     
02:00 < CgRelayBot> [cgan/AlexCato] hm. Is something strange going on? Not a single coinjoin for over 24 hours (no "!hp2 XXXXX" message at all). I havent seen that before
02:26 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
02:35 -!- MaxSan [~four@185.156.175.171] has quit [Quit: Leaving.]     
04:17 < waxwing> hi alexcato just got back, i might try one myself to see, hold on, need to get everything set up
04:24 < waxwing> you have your answer :)
04:36 -!- MaxSan [~four@185.156.175.171] has joined #joinmarket     
04:45 -!- MaxSan [~four@185.156.175.171] has quit [Read error: Connection reset by peer]     
04:45 -!- MaxSan [~four@185.156.175.171] has joined #joinmarket     
06:18 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket     
06:18 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]     
06:30 -!- kristapsk___ [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket     
06:30 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]     
06:31 -!- MaxSan [~four@185.156.175.171] has quit [Ping timeout: 268 seconds]     
06:32 -!- Giszmo [~leo@2407:7000:9d28:5100:8de1:da9d:15e7:2581] has quit [Read error: Connection reset by peer]     
06:34 -!- Giszmo [~leo@2407:7000:9d28:5100:40a3:b13a:6bd6:ce10] has joined #joinmarket     
06:55 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Remote host closed the connection]     
07:01 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket     
07:04 -!- kristapsk___ [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 260 seconds]     
07:24 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]     
07:25 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket     
07:38 -!- kristapsk___ [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket     
07:44 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 260 seconds]     
07:45 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket     
08:44 -!- Giszmo [~leo@2407:7000:9d28:5100:40a3:b13a:6bd6:ce10] has quit [Quit: Leaving.]     
09:13 < arubi> waxwing, I reread the doc and it looks good to me except one thing left to fixup in the "Indexed to keys" section, where it says "to publish the intended P or R value" and later "keep track of all R and P candidates" - should remove references to R
09:14 < waxwing> yeah i did that about an hour ago .. unless maybe i missed one more?
09:14 < waxwing> that section
09:15 < arubi> ah yea, just refreshed and it's gone :)
09:15 < waxwing> i also want to add a comment about harding's point on taproot but hopefully that's the last thing
09:16 < arubi> yea, definitely worth to mention about taproot
09:16 < waxwing> i'm writing some code now, done ecdh+tests and now ecies, the thing that'll take time is getting psbt in; someone's done a python lib but i don't know if it'll slot in.
09:25 < takinbo> waxwing: do you have a link for the psbt python library?
09:31 < belcher> which document are you guys talking about arubi waxwing ?
09:32 < arubi> belcher, the snicker bip on gist.  the link is open on my other laptop so can't copy+paste atn
09:32 < takinbo> belcher: that would be waxwing's SNICKER proposal
09:33 < arubi> belcher, https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79
09:33 < belcher> ty     
10:44 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 248 seconds]     
10:47 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has quit [Ping timeout: 245 seconds]     
10:48 < waxwing> belcher, oh sorry was afk
10:49 < waxwing> looking at this one: https://github.com/bjarnemagnussen/python-psbt although it's a fork
10:49 < waxwing> yeah started work on the bip draft last week. i was mostly prompted by some wasabi people discussing, i just thought, i really should have written this already
10:49 < waxwing> so if anyone ends up doing it we can at least agree on the format.
10:50 < waxwing> it's pretty nicely decoupled like that; the only thing that people need to agree on is how to parse an encrypted proposal. anything else you can sort of do on your own.
10:53 < belcher> i realize now that the privacy wiki page doesnt discuss snicker, thats an oversight
10:54 < arubi> waxwing, re Future improvements :: flagging transactions for snicker, I was thinking it might be as simple as setting the nlocktime field to something like 'SNK#' where '#' might be a bit field that describes snicker versions that this utxo supports
10:55 < waxwing> belcher, well not really it doesn't exist yet heh
10:55 < arubi> so with 0 and 1 it doesn't really matter, but maybe more flags later on for some usability
10:55 < belcher> loads of stuff which doesnt exist is in that page, like coinswap
10:55 < waxwing> arubi, ah yeah flags. i referred to it in one place but i think i forgot elsewhere. if you have thoughts about that please add.
10:56 < waxwing> belcher, true yeah. it is more speculative.
10:59 < waxwing> arubi, re: using nlocktime, interesting, i wanted some feedback on that: i was thinking (a) we obv can't use rbf since there can be no cooperation at least as the system is intended, to re-sign, so i was thinking it might be better to specify max nsequence and zero locktime (as i did). but i think there's nuance here, opinion?
11:02 < arubi> waxwing, I'm kinda rusty, but there was something about max nsequence affecting the nlocktime field
11:02 < arubi> like, disabling it?  what was it..  oh man I can't believe I forgot what it was :)
11:03 < waxwing> max nsequence disables cltv
11:04 < arubi> ah alright, so yea.  I think it's ok to max and zero them resp.
11:04 < belcher> you could maybe use rbf if you pre-sign a bunch of fee bumping transactions
11:04 < waxwing> and i think it's opt in rbf requires nsequence less than max - 1.
11:05 < arubi> right
11:05 < waxwing> belcher, yeah vaguely wondering about it. seemed a bit annoying but it is possible, so i suppose would be good if could avoid disallowing it.
11:05 < arubi> right you can pre-sign, but then receiver can just choose the highest fee paying one :)
11:05 < belcher> in the high fee future that we expect, allowing fee bumping will be a great idea
11:05 < waxwing> well but say the multiple versions reduced both recipient's amounts, then it'd be a normal kinda tradeoff
11:05 < waxwing> arubi, ^
11:06 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has joined #joinmarket     
11:06 < arubi> yea that would work for a profit driven receiver at least
11:06 < waxwing> in one scenario i had in mind (see the future section) i was wondering about a proposer using it as a payment and incentivising receivers to get on it quick, by adding more to their output
11:06 < arubi> but not for a troll e.g.
11:06 < waxwing> yeah a profit driven receiver might be a thing
11:07 < arubi> right if it's a payment then it definitely fits I think
11:07 < waxwing> so hmm should we just set nsequence to anything less than (max -1) and leave nlocktime undefined? so far i've said there that no custom scripts are allowed, but i really just mean "that's too complicated to cover here"
11:11 < arubi> generally I don't think receiver cares.  they could be anything and I don't see a risk for the receiver
11:12 < arubi> for nsequence specifically, it's designed so either party can choose their own.  proposer has to select receiver's nsequence for him, so let him use max-2
11:13 < arubi> that way it's forward compatible with payments at least
11:14 < arubi> nlocktime affects the whole tx right, so unless some script with cltv is used it can also be anything, even a future time.  receiver shouldn't mind?
11:16 < arubi> hopefully both sides agree that if it isn't used, they can set 'SNK#' with the flags that were used in the current CJ :)
11:21 < arubi> oh belcher btw I've been backtracking the ML on JM fidelity bonds, it's really fascinating stuff..
11:25 < arubi> points raised by ZmnSCPxj are really good I think.  not sure if anything newer was brought up other than what is shown in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/thread.html .  it hasn't updated the past few days afaict
11:28 < arubi> the point about a real-world contract between funders is kinda impossible to work around, but I'm wondering if there is a way to prove that a txout used for a bond in taproot doesn't contain a script path to redeem it
11:29 < arubi> I mean, prove it's not some musig for many keys.  maybe something like pay-to-contract..  I really don't know
11:30 < belcher> even such a taproot proof wouldnt be enough, because the renting of btc could be done just with musig or ecdsa-2p
11:30 < belcher> my view is its probably impossible to solve that issue, but it doesnt destroy the idea so its still worth doing
11:31 < belcher> the number of makers will be slightly reduced than it otherwise would be but i bet they'll still be quite a lot of makers... ofc we cant know for sure until we do it
11:36 < arubi> I see.  funny how the coin burner bond is kinda the ultimate proof that renting wasn't done heh
11:37 < arubi> I mean, it could still be that multiple parties funded the burn, but if they're profit driven then at this point they're actually waiting on accumulating enough CJ fees to cover the investment
11:38 < belcher> how does coin burner bonds avoid renting?
11:38 < arubi> well funders aren't getting their coins back whatsoever
11:39 < arubi> I mean, they have no way to enforce a payback, I think?
11:39 < belcher> oh i see, yes good point
11:40 < belcher> i wonder if thats an argument for making coin burner bonds more valuable than they otherwise would be, because they are proof that renting didnt happen
11:40 < belcher> i already had an idea of making coin age bonds less valuable than timelocked bonds because the sacrifice for coin age bonds is less
11:41 < arubi> when a burn bond is used, how does a maker prove its his?
11:41 < undeath> i wonder if anyone would be willing to burn funds. roi is pretty low with jm
11:43 < belcher> arubi the OP_RETURN output would include a commitment to a pubkey, where the privkey is known by the maker who funded it
11:43 < arubi> undeath, that's a good point, and actually the two extremes who'd use a burner in this case would be either somebody ideological, or an outright spy :)
11:43 < belcher> undeath the whole scheme relies on fees paid by takers going up, though id expect time locked bonds and possibly coin age bonds to be _far_ more popular
11:44 < arubi> belcher, so maybe my idea doesn't work, because that key could be a pre-signed musig for dividing the profits once these are made
11:44 < belcher> remember that the spy has to burn much more money than an honest maker, because a spy has to split up their money over many bots and the V^2 terms severely penalizes that
11:44 < arubi> but -- maybe if it wasn't a bitcoin pubkey...
11:44 < belcher> arubi but one entity still has to run the maker bot and collect the coinjoin fees
11:45 < belcher> what if they dont share those fees?
11:45 < arubi> ahh right, doh.  the fee don't go to the burner pubkey
11:45 < belcher> in a timelocked or coin age rented bond the cheated renter can broadcast the presigned backout tx, not so in a burned bond
12:21 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #joinmarket     
12:25 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]     
12:29 -!- belcher_ is now known as belcher     
12:33 -!- belcher_ [~user@unaffiliated/belcher] has joined #joinmarket     
12:42 -!- Sentineo [~Undefined@unaffiliated/sentineo] has quit [Ping timeout: 245 seconds]     
13:20 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
14:25 -!- Zenton [~user@unaffiliated/vicenteh] has joined #joinmarket     
15:05 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.5]     
15:59 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket     
16:36 -!- Xeha [~Xeha@unaffiliated/k1773r] has quit [Ping timeout: 272 seconds]     
16:37 -!- Xeha [~Xeha@unaffiliated/k1773r] has joined #joinmarket     
16:47 -!- Giszmo [~leo@143.120.252.27.dyn.cust.vf.net.nz] has joined #joinmarket     
17:09 -!- Xeha [~Xeha@unaffiliated/k1773r] has quit [Ping timeout: 252 seconds]     
17:11 -!- CgRelayBot [~CgRelayBo@p5DE4ABFB.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds]     
17:11 -!- Xeha [~Xeha@dynamic-82-220-88-142.ftth.solnet.ch] has joined #joinmarket     
17:11 -!- Xeha [~Xeha@dynamic-82-220-88-142.ftth.solnet.ch] has quit [Changing host]     
17:11 -!- Xeha [~Xeha@unaffiliated/k1773r] has joined #joinmarket     
17:13 -!- AgoraRelay [~jmrelayfn@p5DE4ABFB.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]     
17:22 -!- CgRelayBot [~CgRelayBo@p5DE4AA19.dip0.t-ipconnect.de] has joined #joinmarket     
17:24 -!- AgoraRelay [~jmrelayfn@p5DE4AA19.dip0.t-ipconnect.de] has joined #joinmarket     
17:54 -!- StopAndDecrypt_ [~StopAndDe@107.181.189.42] has quit [Ping timeout: 268 seconds]     
18:01 -!- Giszmo [~leo@143.120.252.27.dyn.cust.vf.net.nz] has quit [Quit: Leaving.]     
19:34 < raedah> how is change handling dealt with? I see cj-out and change-out has been added. What special considerations are given to change handling?
19:35 < raedah> Is change from mixdepth 4 contaminated...directly linked to change from mixdepth 0 ?
21:25 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has quit [Ping timeout: 268 seconds]     
23:00 -!- Giszmo [~leo@2407:7000:9d28:5100:40a3:b13a:6bd6:ce10] has joined #joinmarket     
23:41 < waxwing> raedah, any utxos in a single mixdepth can in principle be linked. movements of funds from one mixdepth to another are supposed to only be done via coinjoins.
23:41 -!- dopplergange [~dop@98.142.220.42] has quit [Quit: ZNC 1.7.3 - https://znc.in]     
23:41 < waxwing> i recommend reading tumbler_privacy.md for a description of the principles involved
23:41 -!- dopplergange [~dop@98.142.220.42] has joined #joinmarket     
23:42 < waxwing> re:any further special treatment of change, nothing in particular other than the fact that you can freeze utxos if you want, to allow explicitly choosing to spend one or more utxos in isolation.
23:43 < waxwing> the "in principle" in my first sentence is because you clearly won't link *every* usage in a single mixdepth, if you think about it
23:55 -!- Xeha [~Xeha@unaffiliated/k1773r] has quit [Ping timeout: 252 seconds]     
23:56 -!- Xeha [~Xeha@unaffiliated/k1773r] has joined #joinmarket     
23:57 -!- viasil [~viasil@95.174.67.204] has quit [Ping timeout: 268 seconds]     
23:58 -!- viasil [~viasil@95.174.67.204] has joined #joinmarket