Restrictions on Funding Change Script Public Keys

[nkohen]

Do we want any restrictions on what change Script Public Keys are allowed to be?

In the current state of the specification (see #51) both parties pay equal fees for the funding transaction so I'm currently leaning towards starting out with the restriction that specifying the length of the SPK requires only one byte (i.e. the var_int for the spk length takes up only one byte of the transaction).

In the future we will likely move to a model where each participant pays the fees for their own inputs and outputs rather than sharing this burden, at which point perhaps this restriction should be lifted.

[ariard]

Is there any reason to have var_int superior to one if we restrain to Segwit outputs only ? DLC is a new sytem, so less concern with being compatible with pre-Segwit software ?

[nkohen]

So currently I see no reason to restrict things only to Segwit (e.g. what if you're using DLC software on top of an older hardware wallet for cold stuff which wants to do P2SH or P2WPKH or something).

[nkohen]

It seems like it comes at very little cost and I only have the var_int restriction right now to make things simpler. Once parties are paying for their own change output fees then I can't think of a good reason to really have any restriction (but I could be wrong).

[benthecarman]

Having a mix of p2wpkh and p2sh(p2wpkh) inputs can reduce privacy. More than likely if there is a mix, one user has all p2wpkh inputs and the other use has all the p2sh(p2wpkh) inputs. However, I think that shouldn't be restricted by the protocol, if a user wants to protection from that they should be able to configure their wallet to do so.

[Christewart]

My argument for restricting it is for simplifying the number of scripts library developers need to support when building on the DLC protocol. I don't think this is a concern for us per-se in bitcoin-s as we have pretty extensive Script support, but other library developers may not and may not want to spend time on supporting eccentric change output scripts.

An example of real world problem of this the relay policy of bitcoin core nodes, I don't think bitcoin core will relay txs with non standard scripts. 🤷‍♂️

[benthecarman]

An example of real world problem of this the relay policy of bitcoin core nodes, I don't think bitcoin core will relay txs with non standard scripts. 🤷‍♂️

That makes sense, we can say only standard scripts I think that is just
P2PK, Raw Multisig. P2PKH, P2SH, P2WPKH, P2WSH

[Christewart]

I agree with those minus P2PK (pre-taproot any way) and raw multisig as I don't think bitcoin core will relay those? I'm not 100% on that though.

[benthecarman]

https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.cpp#L46

They are considered standard

[nkohen]

My argument for restricting it is for simplifying the number of scripts library developers need to support when building on the DLC protocol.

I'm quite confused, why on earth would a library need to support an SPK type in order to include it in a change output?

[nkohen]

I think I might understand ... they must only implement or call to something like what Ben is talking about because otherwise relay issues (but I still think calling this "support for SPK types" is a but much).

I'm reading the new dual-funding proposal and it looks like they have this requirement on outputs (checking standard-ness)

[benthecarman]

Yeah, only restriction should be is the output standard. That should cover every functionality a user could want but prevent people from putting a maliciously non-standard script so the tx isn't relayed

[nkohen]

Hm one consideration I hadn't though of before RE standardness is that if we want to use address serializations then we need the restriction proposed by @Christewart here along with P2PKH.