pull down to refresh
100 sats \ 0 replies \ @m0wer OP 21h \ parent \ on: Critical Security Vulnerability in React Server Components: CVSS 10.0 tech
SN not affected😉
Depends on the size, but most times yes.
But I meant as a maker, where a taker pays the extra transaction fees from the additional inputs. So you get the consolidation for free (or even making some profits), you help the taker disguise their inputs, and you get a proper equal output.
Optimize maker offers in terms of maximizing profits, not in number of rounds.
Change can also be mixed in coinjoins. There's actually a setting for consolidating change as a maker by providing multiple inputs. The alternative is of course the submarine swaps yes, but usually pretty expensive.
Yes, and it also says that the protocol is designed for privacy of the equal outputs, not the change. And that change should not be spent together with equal outputs.
I actually just wanted a way to analyze transactions to gather stats on the fee limits used and optimize maker offers.
The other idea is to find ways to make change outputs ambiguous on purpose so that they gain some privacy as well and economize the coinjoin a bit more.
Maybe it doesn't. But here are some cases where it does:
- Taker immediately spends the equal amount output -> useless coinjoin.
- Taker is doing a payjoin to a taproot address (bc1p...) and all other equal amounts are segwit (bc1q...) due to the limitations in the joinmarket clientserver implementation -> also useless coinjoin.
- Taker spends change out (not the equal amount) thinking that it can't be linked to the input. It probably can be.
And I'm sure there might be other reasons depending on the case. The project is just a tool to do the matching.
Argh the link is wrong in the post content, should be https://github.com/m0wer/joinmarket_analyzer