Good morning Lane,

I believe Rusty is creating a spec for reusable payment offers, which would let 
payers request for BOLT11 invoices over the LN network.
In addition, I believe Laolu and friends are building some spontaneous-payment 
protocol without proof-of-payment, although I am uncertain the details.

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, December 7, 2018 9:14 PM, Lane Wagner <lane.c.wag...@gmail.com> 
wrote:

> 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-requ...@lists.linuxfoundation.org 
> wrote:
>
>> Send Lightning-dev mailing list submissions to
>>         lightning-dev@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-requ...@lists.linuxfoundation.org
>>
>> You can reach the person managing the list at
>>         lightning-dev-ow...@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.christ...@gmail.com>
>> To: Corn? Plooy <co...@bitonic.nl>, ZmnSCPxj    <zmnsc...@protonmail.com>
>> Cc: "lightning-dev@lists.linuxfoundation.org"
>>         <lightning-dev@lists.linuxfoundation.org>
>> Subject: Re: [Lightning-dev] Reason for having HMACs in Sphinx
>> Message-ID: <875zw6adaz....@gmail.com>
>> Content-Type: text/plain; charset=utf-8
>>
>> Corn? Plooy <co...@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 <zmnsc...@protonmail.com>
>> To: Trey Del Bonis <j.delboni...@gmail.com>
>> Cc: "lightning-dev@lists.linuxfoundation.org"
>>         <lightning-dev@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.delboni...@gmail.com>
>> To: lightning-dev@lists.linuxfoundation.org
>> Subject: [Lightning-dev] Fwd: Fulgurite: ideas for making a more
>>         flexible Lightning Network protocol
>> Message-ID:
>>         <CAFUsdzpDzwQF=n5zVWOezN35Ng0htw=cwbyenaoryqxmop1...@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 <zmnsc...@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>> End of Lightning-dev Digest, Vol 40, Issue 8
>> ********************************************
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to