Using SIGHASH_NONE | ANYONECANPAY in winner take all cases

[benthecarman]

Might be a nice benefit if in cases where the winner takes all the funds that the counter party's signature is instead using SIGHASH_NONE | ANYONECANPAY this way the user can add on their own inputs and outputs to be able to set custom fees or batch it with other txs for privacy.

Downside for this is it will definitely complicate some logic and could give DLCs a fingerprint

[Christewart]

Don't you want to use SIGHASH_SINGLE | ANYONECANPAY?

IIRC SIGHASH_NONE commits to zero outputs on the spending transaction, which means counter parties can send money anywhere?

[benthecarman]

IIRC SIGHASH_NONE commits to zero outputs on the spending transaction, which means counter parties can send money anywhere?

That's the point if it is an winner take all case it shouldn't matter where I spend it. It still should be safe from other people stealing the output and spending with how they like since it is a 2-of-2 multisig so on your own key you can sign with a SIGHASH_ALL

[ariard]

This is interesting as it's also let the winner takes all capture the looser fee contribution as you don't commit to hashOutputs. A wider generalization would be to use SIGHASH_SINGLE on all CETs such you can commit a high-fee, knowing it would be captured by the first-broadcasting party in case of low-feerate mempool at the time of CET maturity.

What could be considered as a vulnerability in other protocol may sounds as an advantage here. I need to think more about it.

EDIT: a counterparty at loss would give a SIGHASH_SINGLE to the winner. It doesn't sounds like a risk as the winner don't have incentive to pin himself.

[benthecarman]

I'm not sure about SIGHASH_SINGLE because there will be cases where both parties are receiving funds. For it to be secure they would want to sign a transaction where their output is at the same index as the funding output, if we did that then parties would no longer have a unified view.

[ariard]

That's a good point but do we need to have a unified view ? I think Alice don't care about Bob's signature and even having a valid state when she is it at loss and thus you can rely only on Bob to broadcast the fund and get back her balance. For the winner range of cases, Bob may be the only one to have a valid CET and thanks to Alice's SIGHASH_SINGLE he can unilaterally adjust the feerate.

If Bob fails to do so, you still have the refund ?

[benthecarman]

Privacy wise these may not be the best as AFIAK no other system is using SIGHASH_NONE | ANYONECANPAY or SIGHASH_SINGLE from a 2-of-2 multisig so it could give DLCs a unique fingerprint

[ariard]

I agree that's a fingerprint but it may be a worthy one if it gives us far more fee flexibility. Overall, we have a bunch of fingerprint which are more significant (spend pattern coupled to an oracle event, inaccurate feerate, CPFP broadcast, ...).

[Tibo-lg]

What I briefly mentioned during today's meeting was that we could create 2 CETs, one with special SIGHASH and one without, so it's possible to chose privacy if there is no fee issue. Of course this x2 the number of CETs so might not be very practical when there are a lot of possible outcomes.

[benthecarman]

With the use of SIGHASH_SINGLE we might be able to make a DLC watch tower. Would need to think about this more but we could give watch tower the sigs and they should be able to take a fee from the winning output.