Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol
Hello ZmnSCPxj, >In any case, it is certainly possible for the spec to simply specify allowing >some multiparty system with unspecified link-level behavior, but with >specified global-level behavior (i.e. contains some channels that can be >routed through, but the spec will not define how the multiparty system >communicates between the nodes in order to coordinate updates to the system). Maybe discussion on this should be left for the standards meeting in a few weeks. >It is simply the option that the Fulgurite user has. >That is, balance the cost of transmitting a large number of DLC signatures, >vs. the benefit of earning a little money for routing. Oh I see what you're saying now. Misunderstanding on my part there. I think that these kinds of decisions should be communicated when setting up a channel. Perhaps during channel setup peers should specify how they expect to use a channel, like "should we do pseudo-BDW or are we ok with doing Layer-1 payments even in a multiparty scenario?". >Perhaps a new `channel_balance_update` gossip message that is signed by both >sides instead. >But the fact that we do not *currently* publish such, and yet payments in >current LN are reasonably successful, suggests that it might not be at all >necessary. I would agree with both statements. >This greatly increases bandwidth use for gossip, though. >In addition, most of the time the information will not be useful, since it is >not likely I will need the accurate information about this channel state if I >never have to make a payment that will route through that channel. >Current implementations already retry routes, and work well enough without >this information. >Various mini-enhancements like non-binding short-channel-id in onion hops, as >well as the potential to reuse rendezvous routing for rerouting via >alternative routes (modulo reservations Christian Decker has with actually >doing the math) can help improve payment success even with no accurate >knowledge of the channel state. Perhaps clients should try to talk to each node in the route and ask if they would be willing to or are able to relay a payment (or in the case of AMP, how much they can relay of the total). Of course they could lie (say they can but then refuse), but it would at least inform about peers that are genuinely dead. I'm not sure if this has been throughly discussed before or not. ~~~ Some of this is straying from Fulgurite itself and is relatively inconsequential. Should this be moved to another thread or IRC? - Trey Del Bonis On Mon, Dec 10, 2018 at 10:56 PM ZmnSCPxj wrote: > > Good morning Trey, > > > > > Would it really be masquerading though? The standard shouldn't care > > about how a multiparty channel is implemented, only the effective > > balance between each party in each subchannel. And that's regardless > > of if it's with Fulgurite being nested in BDW as previously mentioned, > > or with multiparty Fulgurite acting as though it were just BDW. > > I suppose it would depend on how we end up defining words. > In any case, it is certainly possible for the spec to simply specify allowing > some multiparty system with unspecified link-level behavior, but with > specified global-level behavior (i.e. contains some channels that can be > routed through, but the spec will not define how the multiparty system > communicates between the nodes in order to coordinate updates to the system). > > > > > > LN cannot support lying on gossip. > > > The issue is that if lying were possible, then it would be possible to > > > just give fake channels that do not exist at all (rather than being an > > > alias to some other channel) and which cannot actually route payments. > > > By requiring that funds be visibly locked onchain, we ensure that lying > > > attacks are costly and that attackers have the option of behaving > > > honestly (performing forwarding requests) and get compensated for the > > > opportunity cost, or swallowing the opportunity cost. > > > > I'm not saying lie altogether, you still have to have the funds locked > > on-chain. Just say "here's this (layer 1) channel, we can route x > > msat through it" and leave it at that, and have peers verify that x is > > less than or equal to what the on-chain txo says it should have. And > > apparently that's already in BOLT 1.1 so that should be doable soon. > > You still have the same security guarantees (with regard to verifying > > funds actually seem to exist) with BDW as you would with Fulgurite > > subchannels as external users can't verify that there's actually funds > > in a channel if there's no tx spending into it on-chain, which still > &
Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol
Hello ZmnSCPxj, > Yes, but if you want to interoperate, and it is Burchert-Decker-Wattenhofer > that gets into BOLT instead of Fulgurite, then we will need to have some way > to interoperate a Fulgurite system as masquerading as a > Burchert-Decker-Wattenhofer factory. Would it really be masquerading though? The standard shouldn't care about how a multiparty channel is implemented, only the effective balance between each party in each subchannel. And that's regardless of if it's with Fulgurite being nested in BDW as previously mentioned, or with multiparty Fulgurite acting as though it were just BDW. > LN cannot support lying on gossip. > The issue is that if lying were possible, then it would be possible to just > give fake channels that do not exist at all (rather than being an alias to > some other channel) and which cannot actually route payments. > By requiring that funds be visibly locked onchain, we ensure that lying > attacks are costly and that attackers have the option of behaving honestly > (performing forwarding requests) and get compensated for the opportunity > cost, or swallowing the opportunity cost. I'm not saying lie altogether, you still have to have the funds locked on-chain. Just say "here's this (layer 1) channel, we can route x msat through it" and leave it at that, and have peers verify that x is less than or equal to what the on-chain txo says it should have. And apparently that's already in BOLT 1.1 so that should be doable soon. You still have the same security guarantees (with regard to verifying funds actually seem to exist) with BDW as you would with Fulgurite subchannels as external users can't verify that there's actually funds in a channel if there's no tx spending into it on-chain, which still happens with both systems as I understand it. And I'd say that it is (somewhat) possible to lie in gossip. If parties in a BDW channel collude they could absolutely produce announcements that say there's much more balance in subchannels than there actually is, or vice-versa. But that's not really a problem when routing payments since they don't get much of anything from it since large payments would fail there anyways. > 5. If the HTLC-only subchannel has insufficient capacity you have two > options: (1) swallow the cost of signing all 1 million DLC sub-contract > signatures for every update of the HTLC, or (2) just pretend you're out of > funds in the specified direction, regardless of the DLC-subchannel state > (nobody can force you to use it anyway, and it is your choice to give up on > the routing fees). I'm not really sure how this is an issue since if the HTLC+DLC didn't exist at all then you'd have to reject the payments anyways. I'm in favor of publishing messages that say "yes I know it looks like there's more balance, there's actually less than that" for this reason, so that nodes would know not to send payments that way. What *would* be nice to do is just "lie" about the effective capacity of the channel in the announce or update message. And it's not really lying, you just don't have a way of justifying that announcement vs what it looks like on-chain. And of course NOINPUT would make DLCs less of a hassle, even in Poon-Dryja, as previously mentioned. Also aside from that, it'd be nice to have update_channel messages have a way to say the balances (and fees) in each direction in a channel. Since for very public nodes you'd be able to deduce roughly how much balance can flow in a particular direction and it would aid in calculating the optimal payment in the long run, especially for scenarios where you don't care about privacy as much as usability (and you can still fuzz the balances, etc.). You don't even have to publish update_channels very often, say every hour or day, depending on the capacity and usage of the channel. - Trey Del Bonis On Sun, Dec 9, 2018 at 11:31 PM ZmnSCPxj wrote: > > Good morning Trey, > > > > > > We might have to loosen the restrictions a bit how that information is > > > > validated of course. > > > > > For the case of Burchert-Decker-Wattenhofer channel factories, a single > > > channel announcement will be done for all channels within the factory, > > > signed off by all of the participants in the channel factory, and we > > > presume that the factory participants have validated that the money owned > > > by who is actually owned by that who. However, each channel within the > > > factory would then need channel updates only signed off by the two direct > > > participants in the channel. When channels within the factory are > > > reorganized, a new announcement will need to be done and signed off on by > > > participants in the factory who performed the reorg. > > > > I was more talki
Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol
Hi, > > We might have to loosen the restrictions a bit how that information is > > validated of course. > For the case of Burchert-Decker-Wattenhofer channel factories, a single > channel announcement will be done for all channels within the factory, signed > off by all of the participants in the channel factory, and we presume that > the factory participants have validated that the money owned by who is > actually owned by that who. However, each channel within the factory would > then need channel updates only signed off by the two direct participants in > the channel. When channels within the factory are reorganized, a new > announcement will need to be done and signed off on by participants in the > factory who performed the reorg. I was more talking about situations where we *aren't* doing Burchert-Decker-Wattenhofer and want (unannounced) subchannels. Another idea is to have peers lie in the channel announcement which particular channel has the funds moving when routing a payment. So you say "this channel has x msat capacity" and when other peers request to route payments through it, the parties already have agreed to send it through the unannounced subchannel. Or just leave the ability to route through unanounced secret subchannels to situations where you've been given an invoice with a partial path already provided and the sender just "assumes" that the payment will work. It should be trivial to compose Fulgurite in Burchert-Decker-Wattenhofer exactly as-is, and you'd still get all the nice scalability benefits. > Suppose we have a contract with a timelock at time N. > And this contract is put inside an update mechanism with CSV requirement of > time M. > The contract must be cancelled by the participants at time N - M. > However, if not cancelled, the contract will be dropped onchain, and its true > expiry will still be at time N. > In short, the contract changes between offchain (expires at time N - M) and > onchain (expires at time N). To do that generally would be to have partitions give an optional "must be gone by" deadline where we should either get rid of the partition by then (somehow, we don't actually care) or force the channel on-chain if we're not using a "timeless" update mechanism like Poon-Dryja. Operations like ExpireHtlc should calculate an earlier deadline at which they'd become accepted, and be the thing to actually remove the in-channel HTLC "the right way". Complementary to that, I have the update mechanism update a "validity deadline" as a side effect after a state has been re-signed, which helps us to know when to do periodic re-signings. - Trey Del Bonis On Sat, Dec 8, 2018 at 2:37 PM ZmnSCPxj wrote: > > Good morning Trey, > > There's already some amount of trust in the > > information you're getting about channels, so I think we have a bit of > > flexibility with regard to what we announce to the rest of the > > network. We might have to loosen the restrictions a bit how that > > information is validated of course. > > The validation of channel data (other than the fact that it is locked on the > blockchain) is simply checking that both sides of the channel have agreed, > i.e. signatures from one or both endpoints. > That is the only validation necessary, since any details of the channel will > be their inviolate demesne; we do not need global consensus for things like > what fees the node wants to charge for the use of the channel. > Only that the channel truly exists, is the only consensus validation we need. > > For the case of Burchert-Decker-Wattenhofer channel factories, a single > channel announcement will be done for all channels within the factory, signed > off by all of the participants in the channel factory, and we presume that > the factory participants have validated that the money owned by who is > actually owned by that who. However, each channel within the factory would > then need channel updates only signed off by the two direct participants in > the channel. When channels within the factory are reorganized, a new > announcement will need to be done and signed off on by participants in the > factory who performed the reorg. > > Burchert-Decker-Wattenhofer also allows channels to close and then > reorganized with only a proper subset of the original factory participants, > but this creates even more transactions and possibly greater CSV requirements. > > > > > 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 > > > t
Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol
Good afternoon, >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. >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. I haven't really thought much about what the consequences for routing discovery would be. There's already some amount of trust in the information you're getting about channels, so I think we have a bit of flexibility with regard to what we announce to the rest of the network. We might have to loosen the restrictions a bit how that information is validated of course. Someone smarter than me should comment on that in case it's a horrible idea though. >It strikes me that the issue of re-signing the DLC subcontracts could be >avoided if you use `SIGHASH_NOINPUT`. Oh yes. SIGHASH_NOINPUT makes a lot of things nicer and cleaner. And while I'm confident everyone is going to reach an agreement about it on Bitcoin eventually, I'm not exactly holding my breath. Plus there's other coins that might *never* support it, so I'd like to make sure designs can not require it if we can. >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. >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. I think I actually just devised an elegant way to make that work using deadline timing flags being passed out of the update state machine, it'll be in the repo later. As long as the update mechanism impl is smart enough to know when to emit that the upper layer shouldn't care. Of course still have checks underneath where necessary. There'd have to be negotiation beforehand about the CSV requirements, like during channel setup. It could be adjusted later though I figure out a good way to make that work. >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. That's a good way to do it. I'll try something like that. - Trey Del Bonis On Thu, Dec 6, 2018 at 6:23 PM ZmnSCPxj wrote: > > 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 a
[Lightning-dev] Fwd: Fulgurite: ideas for making a more flexible Lightning Network protocol
(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 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 o
