ZmnSCPxj [ARCHIVE] on Nostr: đź“… Original date posted:2019-12-20 đź“ť Original message: Good morning Esteban, > ...
đź“… Original date posted:2019-12-20
đź“ť Original message:
Good morning Esteban,
> On Fri, Dec 20, 2019 at 12:59 PM ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
> > Current Lightning Network mutual closes are spends of 2-of-2 outputs.
> > Given that most people will use either 1-of-1 or 2-of-3 ("never go to sea with two chronometers, take one or three"), they stand out and it is reasonable to assume that any 2-of-2 will be Lightning.
>
> Interesting... alternatively, one could explore modifying the current 2-of-2 closing outputs to make them undistinguishable from 2-of-3 outputs by negotiating a random third public key with a nonexistent private key (like XORing random values provided by each channel participant).
It has the drawback of requiring three public keys in the resulting revealed SCRIPT rather than two.
Further, *hopefully* the incoming BIP-Schnorr, with *hopefully* upcoming improvements in the verifiable secret splitting thing, will allow "normal" MuSig 2-of-2 to be indistinguishable from 2-of-3 as well.
It would be best to have a standardized NUMS point, then have both participants add their own one-time points to that point, precommitting hashes of those points first, then providing the points, then generating the sum of standard NUMS plus their random points.
Regards,
ZmnSCPxj
đź“ť Original message:
Good morning Esteban,
> On Fri, Dec 20, 2019 at 12:59 PM ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
> > Current Lightning Network mutual closes are spends of 2-of-2 outputs.
> > Given that most people will use either 1-of-1 or 2-of-3 ("never go to sea with two chronometers, take one or three"), they stand out and it is reasonable to assume that any 2-of-2 will be Lightning.
>
> Interesting... alternatively, one could explore modifying the current 2-of-2 closing outputs to make them undistinguishable from 2-of-3 outputs by negotiating a random third public key with a nonexistent private key (like XORing random values provided by each channel participant).
It has the drawback of requiring three public keys in the resulting revealed SCRIPT rather than two.
Further, *hopefully* the incoming BIP-Schnorr, with *hopefully* upcoming improvements in the verifiable secret splitting thing, will allow "normal" MuSig 2-of-2 to be indistinguishable from 2-of-3 as well.
It would be best to have a standardized NUMS point, then have both participants add their own one-time points to that point, precommitting hashes of those points first, then providing the points, then generating the sum of standard NUMS plus their random points.
Regards,
ZmnSCPxj