--- Log opened Fri Aug 20 00:00:43 2021
00:07 < waxwing> xyy, 'maxsize' is not a config setting because it's defined by the coins in the wallet, but it is advertised along with minsize by each yg
00:08 < waxwing> re: mixdepth 2, that is a good point and i don't think we've been able to address it yet. afaict only a very high sophistication level from takers, where they literally analyze joins on chain, could address it, but perhaps i missed something.
00:08 < waxwing> certainly there are incentives that push them towards keeping default levels too, as you mention
00:10 < waxwing> re: 100BTC vs 5BTC, the thing is, this is a market for liquidity, and there is a lot more scarcity at larger amounts, and that's why it's always been the case that larger amount makers have been able to ask for larger percentage fees. at the lower end (say sub-0.2-0.5 BTC), fees in the past were vanishingly low, and i mean in relative terms. then again people are ok with smaller fees based on the balance of costs/benefits.
00:12 < waxwing> the selection pre-FB was *random under a maximum* (a point of annoyance tbh - many non-user commentators seem to be entirely unaware of this, but it was a crucial change to stop people swamping the bottom of the orderbook; it was changed from a heavy fee weighting).
00:13 < waxwing> this is tricky though; a market requires price sensitivity; 'random under a maximum' is the minimal amount of price sensitivity possible. and now we have two dimensions of taker choice - fee price, FB.
00:16 < waxwing> coming back to what i was talking about yesterday, i think i might be able to put together a proof of concept; using c-lightning plugin arch. i can have bots talking to each other over LN (though direct connection for now, for simplicity); see `sendonionmessage`; and maybe (not sure on this yet) have a HODL invoice encrypted to the adaptor sig. for such a PoC I would need to use ECDSA adaptors, but since we already have PoDLE that's not hugely hard in 
00:16 < waxwing> itself.
00:17 < waxwing> i mean arguably it's the first part of that that's more interesting to Joinmarket. based on my experimentation yesterday, i think it's entirely possible that we could set up a MessageChannel in jmdaemon using `sendonionmessage` in c-lightning.
00:17 < waxwing> then maybe use some directory server approach within that network as per undeath's old Issue on this topic
00:17 < waxwing> thoughts on that welcome
00:44 < waxwing> belcher, (anyone else,) thoughts? https://gist.github.com/AdamISZ/a41d92e73c7dcb02762fac34d4c414a0
01:02 < belcher> waxwing good writeup thanks
01:02 < belcher> consider what happens if the coinjoin ends up not confirming
01:02 < belcher> the coinjoin wouldnt happen but fees would still be paid to the maker i think
01:03 < belcher> fees go to the maker once the maker sees the signature, not when the coinjoin actually becomes confirmed.... i suppose this just means the taker has an even stronger incentive to get the coinjoin confirmed by paying enough in fees
01:26 -!- SomeFellow [~SomeFello@194.54.28.203] has joined #joinmarket
01:31 < SomeFellow> xyy: Nah, I meant maxsize. Based on what I knew about the guy when I posted that, it seemed like he had put 99% of his available funds in a FB, so he'd get picked almost every time (?), but he'd only be able to participate in comparatively small transactions (below his maxsize, which is based on what little money he had left after making that huge
01:31 < SomeFellow> FB).
02:34 -!- undeath [~undeath@user/undeath] has joined #joinmarket
02:36 < waxwing> belcher, yeah that did cross my mind. broadcast != confirm but i felt the incentives align so didn't think too much more. like you say.
02:37 < waxwing> my current suspicion is: it's basically the whole submarine swap thing; but, doing it the "good" way, where there's no fingerprint, meaning adaptors, requires PTLC i.e. schnorr on lightning.
02:37 < belcher> this would also mean makers have to manage incoming channel liquidity
02:38 < waxwing> if there is a way to do it without that i'll be happy but i don't know. that's where i'd want some LN expert to chime in.
02:38 < belcher> which is possible, i saw on reddit.com/r/thelightningnetwork people are setting up triangle channels, which is where they do A -> B -> C -> A and then they all rebalance so that A, B and C all have incoming and outgoing liquidity
02:38 < waxwing> liquidity: yeah, sure, there is no question that any such scheme is a substantial extra burden on participants. at least we can say that the size of these payments is right (i.e. very small)
02:38 < belcher> presumably most of the makers would open channels with each other, and then takers just need to be able to find routes to the mass of makers
02:39 < waxwing> yeah that comes back to the whole topology question. if we could piggybank messaging on the LN onion layer then we could probably use simple topologies to connect the participants, similarly
02:52 < openoms[m]> there are also the dual funded channels on c-lightning being started so both sides have bidirectional liquidity
02:53 < openoms[m]> there is surely an interest towards involving JM in there too
02:54 < openoms[m]> https://twitter.com/niftynei/status/1402034339458826241?s=19
02:55 < waxwing> yeah i saw while experimenting; in the regtest setup it dual funds *automatically*, afaik it's a setting in the config
02:55 < waxwing> of course it can't 'dual fund automatically' everywhere :)
02:56 < waxwing> right i should talk to lisa about this more. last time we talked was about podle like 2 years ago :)
02:56 < openoms[m]> <belcher> "which is possible, i saw on..." <- the good thing with triangles that there is an incoming channel too for everyone so there is no need to coordinate a balancing on top
02:56 < waxwing> i think in the end they didn't use it.
02:58 < openoms[m]> waxwing: yes, the peer needs to have it enabled (as an experimental feature for now) and have funds available in the cln wallet too https://medium.com/blockstream/c-lightning-opens-first-dual-funded-mainnet-lightning-channel-ada6b32a527c
03:59 < openoms[m]> overall I think the LN setup shouldn't hold back Makers. Most just want to participate in more coinjoins for free.
03:59 < openoms[m]> Even with an offchain fee payment protocol pairing a node (and liquidity management ) should be optional. If the receiving does not work, the Maker would not be paid. Would be a minimal loss only for most.
03:59 < openoms[m]> The Taker would get to keep the sats if the payment was provably attempted but failed or no Maker node was given.
04:00 < openoms[m]> setting no node would be the equivalent of setting a zero Maker fee
04:20 < waxwing> yeah that whole aspect is currently pretty blue sky considering it'd be a breaking change, and a large one. so maybe i shouldn't worry that PTLC might be required.
04:22 < waxwing> however, interesting to consider: you could actually mix the two. if 2/10 makers advertise off chain fees and the taker pays them, then it just makes the coinjoin *partially* less analyseable
04:22 < waxwing> like, those 2 makers both have equal ins/outs say. i mean admittedly it's a bit messy :)
04:32 < belcher> you could incentivize it by coding takers to preferentially prefer makers that use off-chain fees
04:34 < waxwing> i suppose my last comment is slightly stupid, in the sense that the main 'fingerprint' is the distinction between taker and maker roles. if you only have some makers then the taker in/change-out set still leaks that it is paying.
04:35 < waxwing> everything is kinda no good until you get to "every partition pays exactly equal portion of tx fee"
04:36 < belcher> you could have every peer pay and equal amount to the miner fee, and then the taker reimburses everyone else off-chain
04:37 < waxwing> yes; i was just retracting the earlier comment that with only 2/10 makers being off chain, it works. i guess it basically doesn't.
04:42 < belcher> isnt it still better than nothing?
04:44 < waxwing> yes, fair statement, but it does lose the biggest benefit - and it's the benefit that's being paid for.
04:44 < waxwing> but sure strictly it has to be better, logically
04:44 < waxwing> 'it's the benefit being paid for' isn't exactly correct but i think you get my point
06:05 -!- undeath [~undeath@user/undeath] has quit [Quit: WeeChat 3.2]
07:00 -!- Fontaine [~Fontaine@182.253.98.199] has joined #joinmarket
07:09 < Fontaine> Hi all. Im in the process of integrating JM into my app Fully Noded. I am an IRC newb, so please be patient with me. I have been able to get comms with the joinmarket-pit over my own tor thread to the clearnet hosts for darkscience and hackint, however whenever I try the tor v3 hosts I get "network is down" (have tried port 6697 and 6667). Just
07:09 < Fontaine> wondering if it is common for the IRC servers tor v3 addresses to go down? And if not is there something obvious I may be doing wrong?
07:50 -!- Fontaine [~Fontaine@182.253.98.199] has quit [Ping timeout: 246 seconds]
08:16 -!- hij [~hij@ip72-194-211-20.sb.sd.cox.net] has joined #joinmarket
08:22 < hij> Does taproot provide provide significant possible transaction cost savings if implemented in joinmarket? My limited understanding is that all the separate maker signatures would still need to be separate but if this was not the case and a single signature could be used the cost savings would be huge.
08:50 < xyy> <waxwing> "xyy, 'maxsize' is not a config..." <- true, so that's why I think he meant `minsize` instead? or why would a whale have an incentive to pretend they can only do maxsize of 0.3?
08:51 < belcher> hij taproot doesnt provide particularly notable fee savings, but i hope joinmarket uses it anyway because it allows batch validation which reduces the burden on full nodes, and possibly other cool benefits like snicker with point tweaking
09:18 < waxwing> xyy, i mean anything's possible, and i probably missed part of the conversation, but just as an example a person might try a small maxsize with a v. large bond to try the system out without exposing a big amount in a hot wallet. or other reasons i haven't thought of.
09:58 < openoms[m]> <Fontaine> "Hi all. Im in the process of..." <- according to here it should be only 6667, 6697 will probably drop you without SASL
09:58 < openoms[m]> https://hackint.org/transport/tor
10:03 < openoms[m]> for darkscience it is SSL encrypted and only uses 6697 on Tor also
10:22 < JoinMarketRelay> [hackint/the-eht] @Fontaine: https://pastebin.pl/view/f4fd511d
10:22 < JoinMarketRelay> [hackint/the-eht] please send volume
10:25 -!- SomeFellow [~SomeFello@194.54.28.203] has quit [Quit: Connection closed]
10:28 < JoinMarketRelay> [hackint/the-eht] interesting that agora doesn't want to update to .onion v3
11:02 -!- davterra [~davterra@143.198.56.186] has quit [Remote host closed the connection]
11:02 -!- davterra [~davterra@143.198.56.186] has joined #joinmarket
13:53 -!- Floofie [~Thunderbi@c-66-30-49-23.hsd1.ma.comcast.net] has joined #joinmarket
14:03 -!- Floofie [~Thunderbi@c-66-30-49-23.hsd1.ma.comcast.net] has left #joinmarket []
14:35 -!- NorrinRadd [~username@154.6.20.57] has quit [Ping timeout: 240 seconds]
14:51 < dave_uy> On the Ob Watcher, the fidelity bond value is satoshi ^ 2 right? How do I reverse that to get an idea of how much BTC is locked up and for how long?
14:52 < dave_uy> Would I just take the square root as an estimate? Is there a calculator out there?
15:10 -!- NorrinRadd [~username@154.6.20.113] has joined #joinmarket
15:34 < dave_uy> I found the Fidelity Bond tab which helps. I'll look at the Ob Watcher code to get the formula.
16:10 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has quit [Ping timeout: 244 seconds]
16:17 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has joined #joinmarket
16:25 < belcher> dave_uy yes the fidelity bond tab tells you everything, for details on the maths also see https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b
18:19 -!- belcher_ [~belcher@user/belcher] has joined #joinmarket
18:22 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 240 seconds]
18:28 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has quit [Remote host closed the connection]
18:29 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has joined #joinmarket
20:44 -!- Floofie [~Thunderbi@c-66-30-49-23.hsd1.ma.comcast.net] has joined #joinmarket
23:47 -!- dave_uy [~dave_uy@108.61.193.26] has quit [Quit: The Lounge - https://thelounge.chat]
23:48 -!- dave_uy [~dave_uy@108.61.193.26] has joined #joinmarket
--- Log closed Sat Aug 21 00:00:45 2021