[Lightning-dev] OpenCAP alias integrations with invoices/destination

Lane Wagner lane.c.wagner at gmail.com
Fri Dec 7 13:14:20 UTC 2018


Im working on a protocol that allows users to host crypto public addresses,
using a standard DNS lookup schema. It offers some advantages over
OpenAlias and I'm hopeful that we will see actual adoption.

I want users to be able to post lightning invoices as well, although I know
this is difficult because typically invoices must be generated uniquely for
each payment. I was thinking maybe posting a destination could be good, so
that people can open channels with you, but then people with existing
channels still couldnt send to you.

Does anyone have thoughts on this?

Protocol: https://GitHub.com/OpenCAP/protocol (link to discord for
discussion is there)

Implementation: https://ogdolo.com

Open source implementation: https://GitHub.com/OpenCAP/go-server


On Fri, Dec 7, 2018, 5:00 AM <
lightning-dev-request at lists.linuxfoundation.org wrote:

> Send Lightning-dev mailing list submissions to
>         lightning-dev at lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> or, via email, send a message with subject or body 'help' to
>         lightning-dev-request at lists.linuxfoundation.org
>
> You can reach the person managing the list at
>         lightning-dev-owner at lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Lightning-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Reason for having HMACs in Sphinx (Christian Decker)
>    2. Re: Fulgurite: ideas for making a more flexible   Lightning
>       Network protocol (ZmnSCPxj)
>    3. Fwd: Fulgurite: ideas for making a more flexible Lightning
>       Network protocol (Trey Del Bonis)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 06 Dec 2018 16:24:20 +0100
> From: Christian Decker <decker.christian at gmail.com>
> To: Corn? Plooy <corne at bitonic.nl>, ZmnSCPxj    <ZmnSCPxj at protonmail.com>
> Cc: "lightning-dev at lists.linuxfoundation.org"
>         <lightning-dev at lists.linuxfoundation.org>
> Subject: Re: [Lightning-dev] Reason for having HMACs in Sphinx
> Message-ID: <875zw6adaz.fsf at gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Corn? Plooy <corne at bitonic.nl> writes:
>
> >> The total_decorrelation_secrets serves as the payer-generated shared
> >> secret between payer and payee.  B cannot learn this, and thus cannot
> >> fake its own secret.  Even if it instead offers ((I + K[A]) + k[z] *
> >> G) for a new secret k[z], it cannot know how to change
> >> total_decorrelation_secrets from k[a] + k[b] to k[a] + k[z] instead.
> >>
> > The way things are now, the ephemeral key generation and the payment
> > hash/preimage generation are completely unrelated. This is what allows
> > an attacker to use the same payment hash, and use his own ephemeral key
> > pair to create a new onion packet around it.
>
> That is correct, one is generated by the recipient (secret and preimage)
> and the other one is generated by the sender (ephemeral key). Mixing the
> two seems very unwise, since the sender has very little control over
> what the effective ephemeral key that is going to be used for the last
> hop. This is the same issue that we have with rendez-vous routing, i.e.,
> that if we require the ephemeral key to be something specific at a given
> node we'd be breaking the hardness assumption of for the ephemeral key
> rotation.
>
> > Primarily, path decorrelation replaces the payment hash/preimage part.
> > Maybe I still don't understand something, but if that's the only thing
> > (without changing the ephemeral key / onion shared secret generation),
> > attacking the direct neighbor should still work; in your case, B would
> > still offer ((I + K[A]) + K[B]) to C, with an onion packet B created
> > himself. I'm not familiar enough with the path correlation to understand
> > what happens after step 6, but for C it looks the same, so she should do
> > the same.
> >
> >
> > I do see that, if you couple the "H"TLC payment secret generation to the
> > onion shared secret generation, you can make the attack impossible. Do I
> > understand correctly that this is the idea? After all, C still needs to
> > receive k somehow; my crypto math isn't that good, but my intuitive
> > guess is that i + k is the secret that allows C to claim funds locked in
> > ((I + K[A]) + K[B]) =? (i + (k[a] + k[b])) * G. If k is submitted from A
> > to C through some mechanism that replaces the current ephemeral key
> > system, then I understand what you're at.
>
> I can't quite follow where we would be mixing in the ephemeral key here,
> could you elaborate on that?
>
> > Assuming this is the case, it's pretty neat. I do wonder how it
> > interacts with rendezvous routing. If the sender and receiver each
> > create the k[..] values for their own part of the route, can the
> > receiver-generated onion packet still use points of the form ((I + K[A])
> > + K[B]), including K[..] values related to the sender side? I need to
> > dig deeper into this path decorrelation idea.
>
> Since we have very little control over what ephemeral key will actually
> be presented to the last hop if we have a multi-hop route, we can't
> really hide any information in the ephemeral key itself. What we could
> do is change the way the last hop generates the shared secret from it,
> i.e., have a last hop mode and a forwarding hop mode, and mix in the
> payment secret somehow, but I can't think of a good way to do that, and
> it seems contorted. Let's just have the sender prove knowledge of the
> original invoice by adding a TLV field with a shared secret from the
> invoice instead.
>
> Cheers,
> Christian
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 06 Dec 2018 23:22:57 +0000
> From: ZmnSCPxj <ZmnSCPxj at protonmail.com>
> To: Trey Del Bonis <j.delbonis.3 at gmail.com>
> Cc: "lightning-dev at lists.linuxfoundation.org"
>         <lightning-dev at lists.linuxfoundation.org>
> Subject: Re: [Lightning-dev] Fulgurite: ideas for making a more
>         flexible        Lightning Network protocol
> Message-ID:
>
> <qyU2TN0y6zXLjNtCrgEwlNjJh9WvMEnHLGoLEnS4c_9OXh8hyEn-gxnAwloz2cjUT1aedkonILtSJingtEucQYQiT6Y0wUgwZWkRmSKK_FA=@
> protonmail.com>
>
> Content-Type: text/plain; charset=UTF-8
>
> Good morning Trey,
> > One thing
> > we've talked about is if you and your counterparty want to route
> > payments through each other but also want to enter into discreet log
> > contracts, it might make sense to set up a subchannel for each purpose
> > so you don't have to re-sign for all the potential outcomes for the
> > DLCs (slow!) every time you add/remove an HTLC. Only the routing
> > (sub)channel would be announced to the routing network.
>
> Of note, the routing gossip is not trust-based.
> Instead, part of the routing gossip is the block and transaction and
> output on which the channel is anchored onchain.
> Nodes check if the specified txo is unspent, and matches the purported
> capacity of the channel.
> Once a channel outpoint is spent, nodes automatically remove it from their
> maps.
>
> In a world with Burchert-Decker-Wattenhofer factories, the factory would
> have an onchain txo.
> Gossip would contain all the channels in the factory, and would be signed
> by the same signatories as the onchain txo.
> Nodes would check that the channels purported to be contained in the
> factory sum up to the value of this txo.
>
> I suppose that could be relaxed, so that the channels purported to be in
> the factory would sum up to less than or equal to the value of the channel
> factory txo instead.
> This would allow a Fulgurite system to allocate only part of its funds to
> Lightning-visible routing nodes.
>
> It strikes me that the issue of re-signing the DLC subcontracts could be
> avoided if you use `SIGHASH_NOINPUT`.
> The same signatories could be used for the DLCs, and even if the update
> transaction changes, you can reanchor the DLC subcontracts with
> `SIGHASH_NOINPUT`.
>
> > > Code speaks louder than words.
> >
> > Of course. :)
>
> Yes, so feel free to ignore whatever I say, since I have not coded for a
> while.
>
> > > CSV requirements are a time-based requirement that affect the behavior
> of absolute timelocks used by HTLCs.
> > > It is better to admit this earlier than later, since it becomes
> possible as an attack point if you do not take care to pay attention to the
> CSV requirement.
> > > In particular, timelocked contracts need to be published onchain
> before the timeout expires, and a N-block CSV requirement then means you
> have to publish onchain N+1 blocks before the absolute timelock expires.
> >
> > Restrictions regarding when to publish could be managed at a higher
> > level. What Fulgurite is trying to solve is how to manage the state
> > negotiation rather than the high-level logic about when exactly to
> > publish commitment txs. Maybe we should slightly alter the mechanics
> > for how HTLC expiry works in-channel vs on-chain for this problem?
>
> At minimum the lower-level system would have to alert the higher-level
> system that a time-sensitive contract needs to collapse the Fulgrite system
> or else it would not be possible to enforce the timelock.
>
> Since contracts inside a multiparticipant updatable system can be
> cancelled by the agreement of all participants, I suppose the higher layer
> can decide to demand an update that the timelock be followed within the
> multiparticipant updatable system.
> But the upper layer needs to be informed of the latest time that the
> contract can be enforced onchain.
> Your alternative is that the upper layer needs to know whether the lower
> layer is using Poon-Dryja (no CSV requirement) or Decker-Wattenhofer (CSV
> requirement) or Decker-Russell-Osuntokun (CSV requirement), which you can
> argue is a layering violation.
> Further the exact specs (how many blocks do all participants agree is
> reasonable for the CSV requirement?) would vary.
>
> So it seems to me better to move time-sensitivity to Fulgurite than to
> higher layers.
> Higher layers can simply be concerned about what contracts it wants to
> enter into.
> The higher layer informs the Fulgurite layer of the shortest absolute
> timelock in each contract it enters into.
> The Fulgurite layer then returns to the higher layer the latest
> blockheight at which it can still safely collapse the Fulgurite system, or
> an error that the absolute timelock is too near and is already not
> enforceable at the Fulgurite layer.
>
> Regards,
> ZmnSCPxj
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 6 Dec 2018 20:41:30 -0500
> From: Trey Del Bonis <j.delbonis.3 at gmail.com>
> To: lightning-dev at lists.linuxfoundation.org
> Subject: [Lightning-dev] Fwd: Fulgurite: ideas for making a more
>         flexible Lightning Network protocol
> Message-ID:
>         <CAFUsdzpDzwQF=n5zVWOezN35Ng0htw=
> CWbyeNaoryqxmOp1skA at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> (Resubmitted because it was accidentally auto-discarded.)
>
> Hello list and ZmnSCPxj,
>
> >Non-participants cannot safely (non-custodially) use any such
> "shared-ownership update system" and any subsystems within it since they
> have no power to refuse to sign off an invalid state transition.
>
> I'm not trying to solve that problem.  Although I don't foresee it
> being difficult to allow participants to cooperatively join channels
> in a procedure like a splice, the output would be to a (n+1)-of-(n+1)
> multisig address (or alternatively, -1 for leaving channels).
>
> >*However*, I wonder if Fulgurite adds more complexity than necessary.
>
> I believe that the step up in complexity is justified given the change
> in how we express information in channels.
>
> >2-party shared-ownership update systems ("channels") are best, since
> everyone has to sign.  Fewer participants means fewer points of failure.
> Larger participant sets mean it is more likely somebody will be absent when
> any one of them wants to update the shared-ownership update system.
>
> You're right.  The point of bringing multiparty channels into this
> discussion was to say "here's how we'd do it in Fulgurite if somebody
> wanted to", it just requires a lot more coordination that not every
> environment would be able to have.  Points of failure, etc.
>
> >Burchert-Decker-Wattenhofer channel factories have the advantage that
> once the channels within the factory have been set up, participants can
> then be absent, and only their channels are affected.
>
> That's true.  My construction should still be able to do
> Burchert-Decker-Wattenhofer exactly as described with a little work
> using the same primitives, although I haven't gone out of my way yet
> to formulate how to do it yet since it's a little auxiliary to what
> we've been wanting to do with subchannels here at the DCI.  One thing
> we've talked about is if you and your counterparty want to route
> payments through each other but also want to enter into discreet log
> contracts, it might make sense to set up a subchannel for each purpose
> so you don't have to re-sign for all the potential outcomes for the
> DLCs (slow!) every time you add/remove an HTLC.  Only the routing
> (sub)channel would be announced to the routing network.
>
> >Code speaks louder than words.
>
> Of course. :)
>
> >CSV requirements are a time-based requirement that affect the behavior of
> absolute timelocks used by HTLCs.
> >It is better to admit this earlier than later, since it becomes possible
> as an attack point if you do not take care to pay attention to the CSV
> requirement.
> >In particular, timelocked contracts need to be published onchain before
> the timeout expires, and a N-block CSV requirement then means you have to
> publish onchain N+1 blocks *before* the absolute timelock expires.
>
> Restrictions regarding when to publish could be managed at a higher
> level.  What Fulgurite is trying to solve is how to manage the state
> negotiation rather than the high-level logic about when exactly to
> publish commitment txs.  Maybe we should slightly alter the mechanics
> for how HTLC expiry works in-channel vs on-chain for this problem?
>
> I'll admit that there's still a few unknowns that I have yet to think
> about and figure out how to deal with, like this.  But it's my
> intuition that there's probably a simple solution just by making sure
> the right checks happen in the right places.
>
> - Trey Del Bonis
>
> On Thu, Dec 6, 2018 at 6:20 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> >
> > Good morning list, and also Trey,
> >
> > I confirmed that Trey accidentally replied only to me, but intended to
> reply to the list.
> >
> > > > Burchert-Decker-Wattenhofer channel factories are essentially
> multiparty (> 2 participants) "channels" ("offchain updateable
> cryptocurrency systems") with multiple "child" 2-party channels. In general
> though having multiple channels between the same 2 participants is not as
> valuable (which is why Burchert-Decker-Wattenhofer only has two levels in
> the hierarchy, and why the parent level is multiparty while the child level
> is 2-party).
> > >
> > > Where I was going with the paper is to figure out some of the details
> > > surrounding how to actually implement the protocols described by the
> > > more formal reasearch in the area and leave space in the design for
> > > other protocols that have yet to be designed to be implemented without
> > > having to do a large overhaul of the protocol. If we want to go and
> > > do Burchert-Decker-Wattenhofer-style channel factories we just have to
> > > describe it in terms of manipulating the Fulgurite state graph,
> > > without everyone in the channel actually having to understand
> > > Burchert-Decker-Wattenhofer. Note that Fulgurite subchannels are
> > > expected to have only a subset of the participants of their parents.
> >
> > In effect, Fulgurite simply generalizes Lightning shared-ownership
> update systems ("channels").
> > The insight effectively is that:
> >
> > 1.  Any contract of interest to participants of a single
> "shared-ownership update system" can be done, as long as the contract is
> enforceable onchain.
> > 2.  The "shared-ownership update system" itself is a contract that is
> enforceable onchain.
> > 3.  Therefore, a "shared-ownership update system" can contain
> "shared-ownership update systems" of interest to its participants.
> >
> > So "subsystems" here can have the same set of participants, or a subset
> of participants.
> > Non-participants cannot safely (non-custodially) use any such
> "shared-ownership update system" and any subsystems within it since they
> have no power to refuse to sign off an invalid state transition.
> >
> > *However*, I wonder if Fulgurite adds more complexity than necessary.
> >
> > 2-party shared-ownership update systems ("channels") are best, since
> everyone has to sign.  Fewer participants means fewer points of failure.
> Larger participant sets mean it is more likely somebody will be absent when
> any one of them wants to update the shared-ownership update system.
> >
> > Burchert-Decker-Wattenhofer channel factories have the advantage that
> once the channels within the factory have been set up, participants can
> then be absent, and only their channels are affected.
> >
> >
> > > > Of note is that the existing update protocols can carry almost any
> Bitcoin-enforceable contract, including the same contracts used to enforce
> them. This is what allows update protocols to "nest" as in
> Burchert-Decker-Wattenhofer (or your concept of "parent" and "child"
> channels).
> > >
> > > Of course. But unless I'm mistaken I haven't seen any practical
> > > implentations of it yet, which is what I'm attempting to do. I know I
> > > won't get much adoption without BOLT support, but that's not a goal in
> > > the short term at least.
> >
> > Code speaks louder than words.
> >
> > > > There are some important details like the fact that
> Decker-Wattenhofer and Decker-Russell-Osuntokun impose an extra CSV on
> their transported contracts, and most contracts cannot be transported
> across systems (HTLCs can but with longer timelocks for each step).
> > >
> > > Building transactions might not be able to be 100% transparent to the
> > > partition behavior, but I don't really think that's a major
> > > restriction we need to worry about right now. Partitions talk about
> > > their on-chain representation at a relatively high level (see the
> > > `Contract` enum in the `core` crate) and the transaction builder (yet
> > > to be written) figures out how to implement that.
> >
> > I believe it *is* important to worry about it right now.
> > The only objection I have to Decker-Russell-Osuntokun is that it adds an
> additional CSV requirement to transported contracts.
> > Otherwise it is strictly superior to Poon-Dryja.
> > CSV requirements are a time-based requirement that affect the behavior
> of absolute timelocks used by HTLCs.
> > It is better to admit this earlier than later, since it becomes possible
> as an attack point if you do not take care to pay attention to the CSV
> requirement.
> > In particular, timelocked contracts need to be published onchain before
> the timeout expires, and a N-block CSV requirement then means you have to
> publish onchain N+1 blocks *before* the absolute timelock expires.
> >
> > Basically:
> >
> > 1.  Any absolute timelocked contract implies a timeout for the lifetime
> of the Fulgurite system/channel it is in.
> > 2.  The contract must be fulfilled via a non-timelocked branch before
> that lifetime.
> > 3.  If not fulfilled via a non-timelocked branch, the Fulgurite system
> must collapse onchain 1 block before the lifetime.
> > 4.  If the Fulgurite system is based on Decker-Wattenhofer or
> Decker-Russell-Osuntokun, it must collapse onchain N+1 blocks before the
> lifetime, where N is the CSV timeout for the update system used.
> >
> >
> >
> > Regards,
> > ZmnSCPxj
> >
>
>
> ------------------------------
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
> End of Lightning-dev Digest, Vol 40, Issue 8
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181207/bd4e84c8/attachment-0001.html>


More information about the Lightning-dev mailing list