--- Log opened Sat Aug 21 00:00:45 2021
04:14 -!- Floofie [~Thunderbi@c-66-30-49-23.hsd1.ma.comcast.net] has quit [Quit: Floofie]
04:25 < waxwing> something occurred to me this morning: given the way our code is written, takers could actually make up weird transaction patterns with extra outputs and the makers wouldn't care.
04:26 < waxwing> see https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmclient/jmclient/maker.py#L215-L234
04:27 < waxwing> so as an example, a taker could construct transactions where he matched each maker's change output with another output of the same size. makers won't complain unless i missed something.
04:28 < waxwing> (notice that the nValue check is only *after* the address check so that particularly variant should work just as others)
04:34 < waxwing> i should caution that i haven't tried it, but i think so.
08:22 < waxwing> https://x0f.org/web/statuses/106794801817080640
08:23 < waxwing> i think it's cool it's possible just by editing a couple of functoins in taker.py, even though it would need a lot more careful thinking to be done *right*.
08:23 < waxwing> (don't use it though. not joking, absolutely 100% don't use that code with money).
08:43 < JoinMarketRelay> [hackint/s45rutz7e] Nice idea. some type of nested cj for cjchangeamount ^_^
08:54 < waxwing> yeah it's already a thing in wasabi i think. any such scheme has the issue of bloating out the number of utxos.
08:55 < waxwing> but it's nice for takers to have freedom to make other kinds of things, if they want. you always have that 'oh you don't want to stand out from the crowd' effect, so maybe there' not an obvious practical use. or maybe there is :)
09:01 < JoinMarketRelay> [hackint/s45rutz7e] That shouldnt be only argument against new features. if this or in the end similiar taker option find it way into master and goes released, you may no longer "stand out from the crowd". at least if enough taker adopted that usage as an option.
09:06 < JoinMarketRelay> [hackint/s45rutz7e] I thought, if we have multiple maker to choose from that use all the default settings. and if they take part in continued tumbler rounds, the taker could choose two makers with same size utxo. if they are paid same fees, this could give samesize both cjout and CJchangeamounts? making the maker outputs mixed too? as long there is enough cjfee
09:06 < JoinMarketRelay> tolerance to get same size output results after fees (the privacy-enchanged YG, does make outputs more
09:06 < JoinMarketRelay> [hackint/s45rutz7e] randomized. )
09:10 < waxwing> s45.. :  don't think we'll be pushing out that as an option in the main releases. but i guess you got the point: people can do that anyway if they code it themselves taker side, there is zero change required on makers for that to work.
09:10 < waxwing> that's why i thought it was worth describing. if it required changes on both sides, there would be no point in demonstrating it. obviously we can change anything if we code it.
09:11 < waxwing> re: other idea, yeah it is really nice to have multiple makers with same utxo size on input. but output changes will be different basically always.
09:23 < JoinMarketRelay> [hackint/s45rutz7e] Taker know only fees and maxsize beforehand from orderbook, but not utxo size of input before selection without burning his commitment. but for the case the taker passively selected two with samesize inputs he learns from response of maker, the taker could try matching both maker cjchange by matching the fee paid. from maker side, I personally
09:23 < JoinMarketRelay> would agree to get less fees paid for increased privacy through mixed out anonset. if the taker
09:23 < JoinMarketRelay> [hackint/s45rutz7e] (previously withing range of specified fee tolerance) would overpay more than asked the one maker with less fees than the other maker asks for cjfee, all could benefit. but this require maker allow getting more fees than announced in offer because if the cjfee is not expected, even it is 1 sat more than he expacted, he will not sign his
09:23 < JoinMarketRelay> outputs in the transaction received from the taker built tx
09:30 < JoinMarketRelay> [hackint/s45rutz7e] I think maker have no reason for complain as long it stay within his cjfee_factor & txfee_factor range
09:52 < hij> As a maker, if you update to 0.9 from 0.8.x, can you still use the old joinmarket.cfg?
10:13 -!- NorrinRadd [~username@154.6.20.113] has quit [Ping timeout: 240 seconds]
10:15 -!- NorrinRadd [~username@154.6.20.113] has joined #joinmarket
10:47 < xyy> <hij> "As a maker, if you update to 0.9..." <- Just use vimdiff man
10:49 < xyy> do = diff obtain 
10:49 < xyy> dp = diff put
10:49 < xyy> Done.
10:53 < xyy> Then you’ll also find something about fidelity bonds that you can ignore if you are ok with no longer getting much volume
15:23 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has quit [Remote host closed the connection]
15:26 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has joined #joinmarket
17:04 -!- JMBridged [~CoinJoins@gateway/tor-sasl/jmbridge] has joined #joinmarket
17:04 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has quit [Ping timeout: 244 seconds]
17:04 -!- JMBridged is now known as JMBridge
17:28 -!- hij [~hij@ip72-194-211-20.sb.sd.cox.net] has quit [Ping timeout: 250 seconds]
18:22 -!- belcher_ [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
18:34 -!- belcher_ [~belcher@user/belcher] has joined #joinmarket
19:22 -!- davterra [~davterra@143.198.56.186] has quit [Quit: Leaving]
19:48 -!- davterra [~davterra@143.198.56.186] has joined #joinmarket
22:59 -!- belcher_ is now known as belcher
--- Log closed Sun Aug 22 00:00:45 2021