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
