#asknostr
Hey nostr:nprofile1qqsxwkuyle67y94tj378gw8w2xw2wa6nwmwlqhddlwnz0z7sztsaw2qpz9mhxue69uhkummnw3ezuamfdejj7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3jamnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kz7ex47xm I figure you're the guy to ask here. If I'm building a coinjoin but want to *consolidate* two outputs from separate participants which are going to the same recipient, how can all participants validate that their coins are accounted for in the outputs *without* sharing their destinations and amounts with all other participants? I assume this is possible, but I'm struggling to construct it.
ex
A sending 1BTC to D
B sending 1BTC to E
C sending 2BTC to D
Ideally, the outputs would be
3BTC to D
1BTC to E
But how can participants differentiate that from
2BTC to D
1BTC to E
1BTC to F
(without knowing the destinations of each participant's coins, ruining all unlinkability)
I've had a few ideas, but I've run into a brick wall every time. Blinded addition seems not to be useful, since you need to first prove you have contributed enough in inputs which seems to necessitate linking your blinded value to the inputs, ahead of time, negating the value of blinded addition?
I hope I'm missing something obvious (or even a paper doing exactly this?)
Oh wait, I'm being *really* dumb, any protocol that unlinkably shuffles outputs can then consolidate outputs at the end prior to signing... no fancy crypto needed... 🤦
I swear I figured that out when I was first thinking about this problem, but I forgot about it...
Unlinkably shuffle then consolidate, yes, sure but i think maybe it doesn't end there.
I'm strongly reminded of how wabisabi works. With wabisabi, you can get blinded credentials on amounts, which can be split or combined, they're 'algebraic' commitments. So that's along the lines of what you say here.
I feel like the tricky part is user verification at the end. Alice sees an output to Bob of 3btc, she's paying him 2btc, i guess it's ok fir her to use greater than or equal to?
Maybe this is never discussed because it's not realistically going to happen?
Yeah it definitely is a rare case where you will have multiple parties sending to the same recipient, but I happen to have one (funding an assurance contract).
Also WRT greater-than-or-equal I think after shuffling, the un-consolidated outputs would be shared with all the participants, so they could verify their outputs are present. Then they can verify that the consolidated outputs are equivalent.
Since outputs don't have an "identity", the shuffling should probably occur over `(id, script_pubkey, value)` where `id` is randomly chosen by each participant for each of their outputs, but shuffling could otherwise proceed according to other protocols.
I wonder if running the protocol twice is necessary for fee estimation of the consolidated transaction, and if doing that is a problem at all...
