A flaw in creating commitment transaction if without Sendmany

[neocarmack]

During creating C1a, there are two unbroadcast outputs constructed simutanously: 0.Alice2 & Bob 60, and 1. Bob 40. The output 0 sends 60 USDT to the multisig address Alice2 & Bob, while the output 1 sends 40 USDT to Bob's address.

Currently, omnicore does not support sendmany, so we have to construct two temporary transactions based on which the two outputs are created. Here comes the problem: If Alice broadcasts output 0 only, and just ignore the output 1, then Bob will never get his 40 USDT.

This flaw will not occur if we construct the two outputs by sendmany based on one parent transaction, so Alice is not able to just broadcast one of them.

[dexX7]

Hello @neocarmack,

we want to add sendmany for quite a while, but we've never pinned down the specifics. We have limited payload space and there are multiple ways to approach this.

For example:

1. In one transaction, there could be multiple sends of one specific token type (e.g. only USDT, but to more than one receiver)
2. In one transaction, there could be multiple sends of multiple tokens (e.g. USDT and Maid in one transaction)

Further:

3. The receiver address may be encoded within the payload and there wouldn't be an explicit output for each receiver
4. Or there could be a new output for every receiver

Please let me know, what you need.

[neocarmack]

Emm, i'm sure in this stage, one token to multiple receivers meets our requirment.

[dexX7]

Awesome, thanks for the fast feedback!

Do you need explicit BTC outputs for each receiver?

[neocarmack]

It will be better if we can have BTC outputs for receivers.

[neocarmack]

Initial Send-to-Many transaction format: https://gist.github.com/dexX7/1138fd1ea084a9db56798e9bce50d0ef

[dexX7]

Thanks for the reference @neocarmack. We're pretty close with releasing it, but ironing out the last details. Please feel free to hop into the comment section in the gist.