pull down to refresh
27 sats \ 6 replies \ @OT 30 Nov \ parent \ on: Analyze JoinMarket Bitcoin CoinJoin transactions using ILP. bitcoin
I'm pretty sure in the docs they say that 1 round is not sufficiently conjoined.
Anyway, you're probably right that some people won't understand and are going to mess it up.
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.
reply
change should not be spent together with equal outputs.
And normally it will not be, as equal output and change will end up in different mixdepths.
reply
In Jam the change is always separated from the CJ output.
I actually just wanted a way to analyze transactions to gather stats on the fee limits used and optimize maker offers.
Negative offers might be the way.
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.
I saw Floppy comment the other day on Joinstr about the change being submarine swapped into the LN channel.
reply
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.
reply
reply
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.
reply