Replying to Avatar Ademan

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...
Avatar
waxwing 2y ago

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?

Reply to this note

Please Login to reply.

Discussion

Avatar
Ademan 2y ago

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).

Avatar
Ademan 2y ago

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...