Esteban Ordano [ARCHIVE] on Nostr: 📅 Original date posted:2019-12-20 📝 Original message: Indeed, please excuse the ...
📅 Original date posted:2019-12-20
📝 Original message:
Indeed, please excuse the brevity of my proposed mechanism and my basic
cryptographic toolkit. Thank you for building on it!
The additional cost in the closing transaction would be an interesting
trade-off for the privacy it provides. It could be negotiated on channel
opening alongside the fee structure. I brought it up because it would be
interesting to discuss this privacy improvement because it can be
implemented today, and phased out when viable.
I am worried that it might open the door for an entropy exhaustion attack
on negotiation, yet that might be easy to prevent.
E
On Fri, 20 Dec 2019 at 13:40 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191220/b0589629/attachment.html>;
📝 Original message:
Indeed, please excuse the brevity of my proposed mechanism and my basic
cryptographic toolkit. Thank you for building on it!
The additional cost in the closing transaction would be an interesting
trade-off for the privacy it provides. It could be negotiated on channel
opening alongside the fee structure. I brought it up because it would be
interesting to discuss this privacy improvement because it can be
implemented today, and phased out when viable.
I am worried that it might open the door for an entropy exhaustion attack
on negotiation, yet that might be easy to prevent.
E
On Fri, 20 Dec 2019 at 13:40 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191220/b0589629/attachment.html>;