Esteban Ordano [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-09-01 to 2019-12-20
💬 Posted a total of 3 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 14:57:52

- reply

📅 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>

2023-06-09 14:57:52

- reply

📅 Original date posted:2019-12-20
📝 Original message:
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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191220/d1e75785/attachment.html>

2023-06-07 19:39:08

- reply

📅 Original date posted:2015-09-01
📝 Original message:Slightly relevant: standardization of http queries to blockchain explorers.
It's not just about URLs, it's about the query body and response.
https://github.com/common-blockchain
On Tue, Sep 1, 2015 at 6:16 PM, Matt Whitlock via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Isn't this all backward? The "authority" component of the URL should
> identify the chain, and the "path" component should identify the particular
> block, tx, or address in that chain.
>
> So instead of:
>
>
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> It should be:
>
>
> blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
>
> And I would agree with allowing well-known chains to register a name, to
> be used as an alternative to the literal, hash syntax:
>
>
> blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
>
>
> On Tuesday, 1 September 2015, at 4:49 pm, Marco Pontello wrote:
> > On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón <
> > bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > >
> > > I would really prefer chain=<chainID> over network=<chainPetnameStr>
> > > By chainID I mean the hash of the genesis block, see
> > >
> > >
> https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
> > > I'm completely fine with doing that using an optional parameter (for
> > > backwards compatibility).
> > >
> >
> > I see that using the genesis block hash would be the perfectly rigorous
> way
> > to do it, but what do you think about the possibility of letting also use
> > the name constants, as a simple / more relaxed alternative? That would
> > spare a source lookup just to write a correct reference to a tx, maybe
> in a
> > forum or a post.
> >
> > So a reference to a certain tx could be either:
> >
> >
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
> >
> >
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
> >
> >
> blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main
> >
> > (or a different element name maybe)
> >
> > --
> > Try the Online TrID File Identifier
> > http://mark0.net/onlinetrid.aspx
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/d3ce3853/attachment.html>