Off-chain joinmarket fees

[chris-belcher]

A conversation on IRC by @AdamISZ and myself.

tl;dr Improve privacy by paying coinjoin fees via LN instead of on-chain.

<waxwing> belcher, did you see my comment here last week about sendpayment?
<belcher> i dont think so
<waxwing> i think i'll just copy/paste it if not, it's quicker
<belcher> i mean i read the logs of this channel so i probably saw it, but didnt remember
<waxwing> > <waxwing> another thought i had, which i forgot to mention: a significant problem with joinmarket (as an idea generally, not just the implementation we have) is: directly spending in a single coinjoin is hampered by fees.
<waxwing> lis 04 15:21:25 > <waxwing> i mean this specifically: one privacy gain of coinjoin can be: paying someone reveals your own coins. this is not true in abstract in coinjoin because the payment is delinked from the specific set of inputs.
<waxwing> lis 04 15:21:40 > <waxwing> however this is not true in a JM CJ if we can assume positive fees paid by the spender.
<waxwing> lis 04 15:22:04 > <waxwing> hence, it is worth observing that the zero-fee-offer maker, or the negative-fee-offer maker, can remove that problem.
<waxwing> lis 04 15:22:35 > <waxwing> which opens up the possibility of suggesting to people that if they want to run a maker for privacy, they could specifically choose to offer zero fees and some reasonable fraction of bitcoin-cj-fee
<waxwing> lis 04 15:22:45 > <waxwing> or also negative fees (although be careful!)
<waxwing> lis 04 15:23:23 > <waxwing> this is, of course, a very similar but also slightly different suggestion to doing a patientsendpayment idea. one important functional difference is that there is a class of payments where you can't afford to be patient (most, in fact)
<waxwing> lis 04 15:24:00 > <waxwing> it's also nice that this can be done without software changes. just a case of people choosing to offer it, and takers consciously deciding to use it; they may choose low numbers of counterparties for this purpose (or just pick 1 or 2)
<waxwing> hmm a bit long sorry. but relevant to what you just said, i think.
<waxwing> it's always been a bit of a pain point with this software that the most obvious way to use it, to do a payment of a fixed amount, immediately, doesn't actually gain privacy in the way you might hope it does.
<belcher> i remember reading that but i didnt understand the significance i think
<belcher> are you saying how to get privacy you need to use the tumbler script?
<waxwing> yes, and that doesn't work for a payment with, say, a timeout window
<waxwing> which most payments have to some extent or other
<belcher> using bitcoin correctly shouldnt involve a timeout window IMO, bitpay are doing it wrong
<belcher> since that excludes you lowballing the miner fee and waiting for it to be confirmed at 4am
<waxwing> are there any merchant frontends that don't?
<belcher> idk
<belcher> wait does btcpay have a timeout window?
<belcher> damn
<waxwing> i think it almost certainly must
<waxwing> it's not realistic to expect merchants to .. not expect that feature (ugh, sentence construction)
<belcher> if the timeout is for unconfirmed transactions then suddenly you've excluded blocksonly operation
<waxwing> well yeah you could make that argument. i guess you're right we should have a very different sense of timeout here, but perhaps hours and not days. not realistic.
<belcher> depositing to exchanges doesnt have a timeout (but thats not using bitcoin as money)
<waxwing> you can just say 'don't use bitcoin for retail, wait for LN', ok fair enough.
<belcher> you can still use it for retail because the shipping times for goods takes at least a day
<belcher> for IRL retail blockchain transactions are already unsuitable i believe
<waxwing> you could ... if any payment software worked like that.
<belcher> see this is why its good for me to talk to actual users of bitcoin, i didnt know that
<belcher> i should tell btcpay
<waxwing> to be fair, i do remember a couple of times this working out OK.
<waxwing> e.g. balticair, i think, and it didn't see the tx in a block for a long time, the automated process failed.
<belcher> it also excludes privacy, even coinswap privacy is improved if you wait a longish time because the anonymity set grows
<waxwing> but then they processed it manually when it arrived.
<waxwing> so anyway i think the 0-fee (more accurately the 'share bitcoin tx fee and charge no coinjoin fee') maker provider would be a significant net benefit to the usability of this system. you could imagine this could work as significantly smaller liquidity pools, enough for retail payments and not more.
<waxwing> while the larger providers still charge a fee (they take more risk).
<waxwing> but ... just a thought.
<belcher> in what sense would it help usability
<waxwing> it gives an additional use case
<waxwing> you can actually improve privacy while making payments, or more specifically, you can prevent your payee from knowing your coins.
<belcher> i see
<belcher> the way i imagined it working in the beginning is that when you receive coins from anywhere, you use the tumbler script on them and have the destination be your own wallet, then when you want to make retail payments you use sendpayment from that wallet
<waxwing> oh for sure, that works, but it still has the troublesome point that any co-spends directly in the payment transaction are known to be co-owned.
<belcher> hmm yes
<waxwing> or even just, you're making a small payment with one utxo and it's (relative to that payment) very big
<belcher> "receiving coins" includes change outputs
<waxwing> if i'm a whale, and i want to spend a few dollars here and there to some merchant for T-shirts say, almost inevitably i'm going to leak the fact that i have a lot of coinage in some or all of my payments
<belcher> yep
<belcher> so what you said would also help with that
<waxwing> yeah that's the motivating scenario.
<belcher> coinswap (the multi-tx variety) could also do this, as the change output wont be known to the merchant
<waxwing> yes coinswap does this too but i'm worried about the XBI (cross-block interactivity) inconvenience.
<belcher> what about it worries you?
<waxwing> or put it another way: the liveness requirement. it's not do it now, then forget about it.
<waxwing> i think you need that especially for a retail payment use case.
<belcher> so are you concerned about it making payments slow?
<waxwing> hmm. i'd have to think about it. but i guess coinjoin should be much easier at each level (although less effective).
<belcher> CoinjoinXT doesnt require XBI but it would also make payments slow
<belcher> so i think it cant be that
<belcher> its only the DOS vulnerability i think? (or accidental DOS, that your internet might cut out)
<waxwing> agree, coinjoinxt (or unlimited) should be more addressing the tumbler style use case
<waxwing> well it's just the fact that you have to do anything, yeah, true it's limited to just accessing the chain/internet, but even that is a big practicality weakness.
<waxwing> or maybe look at it as being 'slow', either way, for the casual payment my suspicion is it's not attractive.
<belcher> i get it
<belcher> LN really is much better
<belcher> for small casual payments i mean
<waxwing> yes that's the best counterargument i think.
<belcher> when i think of privacy tech im generally thinking of mixing big amounts because i get the feeling LN solves the small amount case
<belcher> but as you say, it requires waiting for it to be built or building it
<waxwing> if bitcoin drops much lower then default LN channels won't be useful even for $100 payments :)
<belcher> :p
<belcher> hmm so we're at an all time low since december 2017 now
<belcher> it will be like 2014 again?
<waxwing> 'rhymes' etc
<waxwing> what about this use case: i trade lbtc style in person for cash
<waxwing> i don't think tumbler could work there because you might be prepared to wait a block but not a day
<belcher> so you mean lbtc style but without using lbtc's escrow
<waxwing> and i don't want joe bitcoin trader knowing how many coins i have
<waxwing> yeah
<waxwing> i suspect there's more of that kind of trading going on than people realise.
<belcher> LN might be the best when its mature, you open a channel with the buyer but with all the coins on your side, then when he gives you the cash in person you create a LN transaction that sends some coins to him
<belcher> DOS might be an issue, you could open the channel and then the buyer becomes a no-show
<waxwing> yeah but i mention it because those trades are sometimes quite large.
<belcher> ah
<waxwing> def the LN approach, with maturity of LN, is good, for smaller (say a couple of hundred and below i guess)
<waxwing> but it does need maturity/reliability of both the network and the available software.
<belcher> any quick on-chain transaction will have privacy issues because timing correlation can always be used
<waxwing> well but i mean i'm talking about using coinjoin specifically to create ambiguity about which set of inputs is yours.
<belcher> so maybe the best solution is a slow solution that you do beforehand, which maybe splits up your money into many small UTXOs (but then in the high-fee future that costs you lots of miner fees)
<belcher> ok how about this:
<belcher> the issue is that the joinmarket fees paid degrade privacy
<belcher> you need some joinmarket makers which take zero (or negative) fee on-chain
<belcher> but obviously you cant incentivize them to hang around waiting for you
<belcher> so... could you incentivize them off-chain by sending them a LN transaction?
<waxwing> ah yeah i remember this thought floating by at one point. it should be investigated def.
<belcher> im imagining a joinmarket where theres no on-chain coinjoin fees, instead the coinjoin fees get sent via LN
<waxwing> i think it should work, but it may be a bit tricky.
<belcher> it needs to be atomic
<waxwing> yeah that's the tricky part, but it's def possible. some preimage thing.
<belcher> or scriptless scripts (for privacy)
<waxwing> yes put the preimage in sign-to-contract. i think something like that.
<waxwing> or .. no, i'd have to go back and look at this stuff. if it needs adaptor sig stuff then it'd need schnorr, unless that new 2PC thing can address it.
<belcher> but this is a third use-case which isnt satisfied with either LN or slow privacy tech (coinswap, CJXT, tumblebit, etc etc)
<belcher> the use case of fast on-chain transactions
<waxwing> maybe last time i thought about it i decided 'meh' because you need to prearrange LN and make sure everyone can be paid.
<waxwing> but this direction of thinking should def be pursued, because that way we can get the incentivised model of CJ (JM) without its downsides.
<belcher> agreed
<belcher> shall we write down somewhere?
<waxwing> .. or just wait for CT and forget all this :)
<belcher> if CT ever gets added to bitcoin..
<waxwing> maybe we can just swap in and out of Liquid or something > <waves hands>