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 > > happens with both systems as I understand it. > > Yes. > > > 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
Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol
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 > happens with both systems as I understand it. Yes. > 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. But they cannot produce announcements where the total balance in subchannels is greater than what the actual specified UTXO has. Again, as I mentioned, in the future where the public mainnet LN is very large, it is likely that nodes with limited working memories will drop channels below a specified capacity from their in-memory routemaps, since the capacity is something they can verify and in general dropping lower-capacity channels is less likely to cause future payment failures. > > 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. This is not an issue. 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. >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. Certainly that can be done. It is not lying but being more honest --- it looks like you have more capacity, but you admit that there is less useable capacity than that. I suppose I fixated too much on the term "lie" here, since it is not the correct term as you are being *more* honest about the actual situation, not less. > 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. We would have to design this carefully. One side may be willing to let such information be known, but the other side might not. Current `channel_update` contains only signature from one side of the channel, as it contains data like "how much do I want to charge as fees if you use this channel to forward", which requires only the consent of one side. If one side admits "I
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 talking about situations where wearen't doing > > Burchert-Decker-Wattenhofer and want (unannounced) subchannels. > > Yes, but if you want to interoperate, and it is Burchert-Decker-Wattenhofer > that gets into BOLT instead
Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol
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 talking about situations where wearen't doing > Burchert-Decker-Wattenhofer and want (unannounced) subchannels. 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. > Another idea is to have peers lie in the channel announcement which > particular channel has the funds moving when routing a payment. 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. In the future, as the LN size increases, some nodes may remove channels of low capacity from their local routemaps in an effort to reduce their memory consumption. Larger capacity channels that are near to my node are more likely to succeed in forwarding, so it is better to retain them. This implies removing low-capacity channels that are far away from my node from my routemap to keep my routemap size manageable. > 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. This is already allowed in BOLT 1.1. Short channel IDs are only used as a cheap (8-byte) indicator for the next node in the route. If there is some private unannounced channel, or some other channel on the route, the forwarding node may use that if the publicly announced channel has insufficient capacity on the forwarding node side. Of course, if the publicly-visible channel has low total capacity, it becomes unlikely to be used for forwarding by third parties. Again, this is the tradeoff the Fulgurite user must consider. What could be done today would be this: 1. You and your peer lock your funds in a Fulgurite system. 2. The Fulgurite system is split into two subchannels, one is an "ordinary" HTLC-only channel, the other supports HTLC and DLC. 3. Everyone else on LN assumes your LN channel is the entire Fulgurite system (because that is what is committed onchain and that is what they will use). 4. If somebody routes through you, you prefer the HTLC-only subchannel. 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). In the future, when Burchert-Decker-Wattenhofer gets onto BOLT: 1. You and your peer lock your funds in a Fulgurite system. 2. The Fulgurite system is split into two subchannels, one is an "ordinary" HTLC-only channel, the other supports HTLC and DLC. 3. You and your peer pretend to create a Burchert-Decker-Wattenhofer channel factory that contains a single channel (the HTLC-only subchannel), with the rest of the funds not claimed to be used on LN. 4. If somebody routes through you, you prefer the HTLC-only subchannel. 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). > It should be trivial to compose Fulgurite in > Burchert-Decker-Wattenhofer exactly as-is, and you'd still get all the > nice scalability benefits. Exactly, which is why I mentioned how Burchert-Decker-Wattenhofer channel gossip will have to
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 > > > 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
Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol
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 > > 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. Of note, is that the update mechanism can always cancel any contract if all participants in the updateable cryptocurrency system have agreed. One can consider the fulfillment of the hashlock in an HTLC to actually cancel the contract, and put its fund into whoever fulfilled it. Similarly, if the timelock on an HTLC is about to expire, then both sides can agree to simply cancel it back to the beneficiary of the timelock branch. >From this point-of-view, then, when the timelock is about to expire, and the >other side refuses to sign off on the cancellation, our only remaining remedy >is to fail the system and drop to onchain for enforcement. Under Poon-Dryja there is no CSV requirement and the above point-of-view is easy to consider. Under Decker-Wattenhofer and Decker-Russell-Osuntokun, there exists this CSV requirement and this becomes complicated. 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). Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
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 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
Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol
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 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol
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
Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol
Hi Trey,
This document is a description of how I view individual channels on Lightning
currently.
The document is valuable as it provide a viewpoint of how Lightning works at
each channel.
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).
Punishment mechanisms are simply part of the update protocol (they are a
witness that older states have been superseded).
We can abstract away the update protocol (Decker-Wattenhofer, Poon-Dryja,
Decker-Russell-Osuntokun) from the description in the document.
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).
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).
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Thursday, December 6, 2018 3:12 AM, Trey Del Bonis
wrote:
> Hello all,
>
> I've been doing some thinking lately about some of the Lightning extension
> proposals like splicing and have been trying and try to generalize it into
> something that makes Lightning a lot more flexible and fault-tolerant overall.
>
> So I wrote up a document describing what I call "Fulgurite", after the term
> for
> fossilized lightning.
>
> Link: https://tr3y.io/media/docs/fulgurite.pdf (also attached)
> SHA1: d25371836a56630571182a65684df19027c3b9af
>
> It makes tracking channel state into building on a graph with moving forward
> in
> time, and merges the ideas of user balances and HTLCs into different types of
> "channel partitions" which are also used for other things I talk about in the
> doc.
>
> Ideally, it can make splicing and subchannels simpler. It also makes it pretty
> trivial to do discreet log contracts in channels vs on-chain, which is good
> for
> anonymity.
>
> I've been working on a toy implementation of the things in Fulgurite here,
> this
> isn't usable yet but there's the core parts: https://gitlab.com/delbonis/roz
>
> - Trey Del Bonis
>
> PS. If you were at the Chaincode Residency in October, you might know me
> as the
> guy that did Conway's Place! (= Conway's Game of Life + satoshis.place)
>
>
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
