Re: [Lightning-dev] Both-side funded channels
Il 12 settembre 2018 06:40:27 CEST, ZmnSCPxj via Lightning-dev ha scritto: > >> Don't you agree with me, that right now there is no good way to >initiate such receiving channel? Don't you think this is quite high >weakness of LN? > >No. People who have kept their node consistently online for a few >months generally find that they get incoming capacity anyway; you can >simply trade off between time and money in this case. Hello, if I may add another perspective on this issue: from the point of view of a routing node, it is advantageous to be as close as possible to as much merchants as possibile, to capture part of the flow of funds to them. Therefore, when a new merchant appears, I actually see the possibility of some competition between routing nodes to fund stable channels with them. This could turn the incoming capacity issue perhaps into a non-issue in the steady state. Regards, Gregorio ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Both-side funded channels
Good morning Giovanni, > I agree with you, Cezary, and was in tears of joy when read about that > "plan to implement possibility of both-side funding channels", as it > would be immensely beneficial for the growth of network. > > I think ZmnSCPxj is misreading that as something mandatory, or > something that would be integrated into the protocol and performed > automatically by all nodes. Only interpreting it in that way his > concerns about privacy and locked funds would make sense. If it is not integrated into the protocol as an optional extension at least, then it would be difficult to coordinate between the 4 or 5 extant implementations. Interoperability is a bit iffy already as-is for functionality that is already in the protocol (e.g. onchain fee disagreements when fees change rapidly on mainnet, unrecognized gossip types, etc). Further, if not supported by default on most nodes, it runs the risk that only a few nodes will enable incoming requests for outgoing capacity, potentially creating a centralization risk (although I believe laolu (and possibly others?) considers centralization in LN to be benign; I have not investigated this argument in detail, and can only provide a knee-jerk reaction to centralization). > As as I > could understand it, however, it would be something that nodes would > negotiate beforehand and only materialize if they decided it was > mutually beneficial. You may imagine negotiation between sapient intelligences, but it is often better to have this automated and supported at a much lower intelligence level, in much the same way that channel construction is often best left to autopilots. If so, then it is best to support it widely to ease the job of autopilots who have been instructed by sapient-level policy to find X BTC incoming capacity for up to N% in fees. I imagine an extension to `node_announcement` would advertise that a node supports dual-funding, and also contain the limits to that dual-funding. Thus I still see the potential privacy leak as a concern, since ideally every node should eventually support incoming dual-funding requests if it happens to have onchain capacity, to homogenize the network (improving decentralization and privacy). Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Both-side funded channels
I agree with you, Cezary, and was in tears of joy when read about that "plan to implement possibility of both-side funding channels", as it would be immensely beneficial for the growth of network. I think ZmnSCPxj is misreading that as something mandatory, or something that would be integrated into the protocol and performed automatically by all nodes. Only interpreting it in that way his concerns about privacy and locked funds would make sense. As as I could understand it, however, it would be something that nodes would negotiate beforehand and only materialize if they decided it was mutually beneficial. Regarding trustless swaps between on-chain and lightning funds, there's the work on https://submarineswaps.org/ (googling may be better for information on the topic: https://www.google.com/search?q=submarine+swaps) On 9/11/18, Cezary Dziemian wrote: > Thanks for answer, > > Do I understand what you described correctly? If some merchant would like > to just start using ln by receiving funds, he need to: > > 1. Fund channel with amount he would like to be able to receive + > dust_limit*2 > 2. Wait for confirmations to channel opening > 3. Buy onchain bitcoins for ln bitcoins > > Weaknesses are: > - he need to posses all funds he would like to receive + dust_limit*2 > - process takes longer > - process requires 2 on-chain transactions > - point 3 should be implemented in trustless way, so it also requires some > development > > Don't you agree with me, that right now there is no good way to initiate > such receiving channel? Don't you think this is quite high weakness of LN? > BTW Maybe there is someone who is working on this trustless swap between > on-chain and on-channel funds? > > Regards, > CD > > wt., 11 wrz 2018 o 09:06 ZmnSCPxj napisał(a): > >> Good morning Cezary, >> >> An issue is that this potentially leaks private information. If I >> request >> you to fund 1BTC and you accept, then I close the channel, then I request >> you to fund 2BTC and you decline, then I have a good guess, that your >> funds >> are between 1 BTC to 2 BTC. >> >> There are ways to mitigate this but are not perfect. >> >> In addition, it is important always, that the initiator of the action >> should be the one to pay for fees onchain, for both the opening >> transaction >> and the unilateral close transactions. >> >> An obvious attack vector is to launch several hundred Lightning nodes, >> tie >> up your onchain funds into channels, then permanently take my hundred >> nodes >> offline. The victim would then have to wait for some time (the >> `to_self_delay` parameter that I specified) to access the funds. >> >> The above attack is greatly mitigated by requiring that the initiator of >> the dual-sided channel pay a fee, based on the capacity requested from >> the >> initiatee, and the `to_self_delay` the initiator requests, to the >> initiatee, via the `push_msat` or similar mechanism. So, the first state >> of the new channel would not equal what each participant puts in, but is >> skewed to the initiatee, in order to reduce the above tie-up attack. Any >> node that wishes to *accept* dual-funding requests (i.e. potential >> initiatees) would have to set some feerate in terms of millisatoshi per >> satoshi-block, which is multiplied with the initiator `to_self_delay` and >> the capacity requested from the initiatee, then divided by 1000 to get >> the >> fee required for the initiator to pay the initiatee to perform >> dual-funding >> (and the initiator will also still be the one paying for all the onchain >> fees on top of that). >> >> The privacy leakage can be mitigated by requiring that the initiator >> always put up greater than or equal capacity it requests from the >> initiatee. The initiator would be required to provide proof that it owns >> some onchain UTXOs that in total equal or exceed the capacity it will put >> in, and those UTXOs are the only ones that can be used by the initiator, >> to >> fund the channel (even in single-funding the opening side has to provide >> the transaction that will fund the channel, and the UTXOs it owns can be >> found by looking up the funding transaction on the blockchain, so this is >> not a worse privacy loss for the initiator). This mitigation is >> imperfect >> as a rich entity could still probe a much-less-rich entity for how much >> it >> owns onchain (and so, I am uncertain how valuable this mitigation will be >> in practice; in addition some might not particularly care if their >> financial information is thus exposed, preferring to earn from routing >> fees >> and dual-funding fees). >> >> So, roughly speaking, I think the implementation will be that the channel >> will have a starting state that will put a little more money into the >> initiatee side, and the initiator always has to put up some amount of >> funds >> (and more likely will be required to put up greater than or equal to what >> it requests from the initiatee). >> >> The details might be hashed
Re: [Lightning-dev] Both-side funded channels
Thanks for answer, Do I understand what you described correctly? If some merchant would like to just start using ln by receiving funds, he need to: 1. Fund channel with amount he would like to be able to receive + dust_limit*2 2. Wait for confirmations to channel opening 3. Buy onchain bitcoins for ln bitcoins Weaknesses are: - he need to posses all funds he would like to receive + dust_limit*2 - process takes longer - process requires 2 on-chain transactions - point 3 should be implemented in trustless way, so it also requires some development Don't you agree with me, that right now there is no good way to initiate such receiving channel? Don't you think this is quite high weakness of LN? BTW Maybe there is someone who is working on this trustless swap between on-chain and on-channel funds? Regards, CD wt., 11 wrz 2018 o 09:06 ZmnSCPxj napisał(a): > Good morning Cezary, > > An issue is that this potentially leaks private information. If I request > you to fund 1BTC and you accept, then I close the channel, then I request > you to fund 2BTC and you decline, then I have a good guess, that your funds > are between 1 BTC to 2 BTC. > > There are ways to mitigate this but are not perfect. > > In addition, it is important always, that the initiator of the action > should be the one to pay for fees onchain, for both the opening transaction > and the unilateral close transactions. > > An obvious attack vector is to launch several hundred Lightning nodes, tie > up your onchain funds into channels, then permanently take my hundred nodes > offline. The victim would then have to wait for some time (the > `to_self_delay` parameter that I specified) to access the funds. > > The above attack is greatly mitigated by requiring that the initiator of > the dual-sided channel pay a fee, based on the capacity requested from the > initiatee, and the `to_self_delay` the initiator requests, to the > initiatee, via the `push_msat` or similar mechanism. So, the first state > of the new channel would not equal what each participant puts in, but is > skewed to the initiatee, in order to reduce the above tie-up attack. Any > node that wishes to *accept* dual-funding requests (i.e. potential > initiatees) would have to set some feerate in terms of millisatoshi per > satoshi-block, which is multiplied with the initiator `to_self_delay` and > the capacity requested from the initiatee, then divided by 1000 to get the > fee required for the initiator to pay the initiatee to perform dual-funding > (and the initiator will also still be the one paying for all the onchain > fees on top of that). > > The privacy leakage can be mitigated by requiring that the initiator > always put up greater than or equal capacity it requests from the > initiatee. The initiator would be required to provide proof that it owns > some onchain UTXOs that in total equal or exceed the capacity it will put > in, and those UTXOs are the only ones that can be used by the initiator, to > fund the channel (even in single-funding the opening side has to provide > the transaction that will fund the channel, and the UTXOs it owns can be > found by looking up the funding transaction on the blockchain, so this is > not a worse privacy loss for the initiator). This mitigation is imperfect > as a rich entity could still probe a much-less-rich entity for how much it > owns onchain (and so, I am uncertain how valuable this mitigation will be > in practice; in addition some might not particularly care if their > financial information is thus exposed, preferring to earn from routing fees > and dual-funding fees). > > So, roughly speaking, I think the implementation will be that the channel > will have a starting state that will put a little more money into the > initiatee side, and the initiator always has to put up some amount of funds > (and more likely will be required to put up greater than or equal to what > it requests from the initiatee). > > The details might be hashed out in November lightning-dev summit, and then > implementation will take perhaps a year or more after that. > > -- > > For myself, I think dual-funded channel, is not so important. > > Consider that the initiator may need to put up funds at least equal to the > capacity it requests to the other side, in order to mitigate the privacy > leakage above, and pay fees anyway, in order to get incoming capacity. Now > consider instead an alternate solution: off-to-onchain swap. Create a > single channel to anywhere on the network, then use an off-to-onchain swap > service (which will charge fees for the service that are slightly more than > onchain fees involved) to move the funds on that channel back onchain. You > can then repeat this process with "the same" funds to get more incoming > capacity, paying fees each time. > > This alternate solution, has the advantage that (1) it can in theory be > implemented today, although I am unaware of any good trustless > off-to-onchain swap services today,
Re: [Lightning-dev] Both-side funded channels
Good morning Cezary, An issue is that this potentially leaks private information. If I request you to fund 1BTC and you accept, then I close the channel, then I request you to fund 2BTC and you decline, then I have a good guess, that your funds are between 1 BTC to 2 BTC. There are ways to mitigate this but are not perfect. In addition, it is important always, that the initiator of the action should be the one to pay for fees onchain, for both the opening transaction and the unilateral close transactions. An obvious attack vector is to launch several hundred Lightning nodes, tie up your onchain funds into channels, then permanently take my hundred nodes offline. The victim would then have to wait for some time (the `to_self_delay` parameter that I specified) to access the funds. The above attack is greatly mitigated by requiring that the initiator of the dual-sided channel pay a fee, based on the capacity requested from the initiatee, and the `to_self_delay` the initiator requests, to the initiatee, via the `push_msat` or similar mechanism. So, the first state of the new channel would not equal what each participant puts in, but is skewed to the initiatee, in order to reduce the above tie-up attack. Any node that wishes to *accept* dual-funding requests (i.e. potential initiatees) would have to set some feerate in terms of millisatoshi per satoshi-block, which is multiplied with the initiator `to_self_delay` and the capacity requested from the initiatee, then divided by 1000 to get the fee required for the initiator to pay the initiatee to perform dual-funding (and the initiator will also still be the one paying for all the onchain fees on top of that). The privacy leakage can be mitigated by requiring that the initiator always put up greater than or equal capacity it requests from the initiatee. The initiator would be required to provide proof that it owns some onchain UTXOs that in total equal or exceed the capacity it will put in, and those UTXOs are the only ones that can be used by the initiator, to fund the channel (even in single-funding the opening side has to provide the transaction that will fund the channel, and the UTXOs it owns can be found by looking up the funding transaction on the blockchain, so this is not a worse privacy loss for the initiator). This mitigation is imperfect as a rich entity could still probe a much-less-rich entity for how much it owns onchain (and so, I am uncertain how valuable this mitigation will be in practice; in addition some might not particularly care if their financial information is thus exposed, preferring to earn from routing fees and dual-funding fees). So, roughly speaking, I think the implementation will be that the channel will have a starting state that will put a little more money into the initiatee side, and the initiator always has to put up some amount of funds (and more likely will be required to put up greater than or equal to what it requests from the initiatee). The details might be hashed out in November lightning-dev summit, and then implementation will take perhaps a year or more after that. -- For myself, I think dual-funded channel, is not so important. Consider that the initiator may need to put up funds at least equal to the capacity it requests to the other side, in order to mitigate the privacy leakage above, and pay fees anyway, in order to get incoming capacity. Now consider instead an alternate solution: off-to-onchain swap. Create a single channel to anywhere on the network, then use an off-to-onchain swap service (which will charge fees for the service that are slightly more than onchain fees involved) to move the funds on that channel back onchain. You can then repeat this process with "the same" funds to get more incoming capacity, paying fees each time. This alternate solution, has the advantage that (1) it can in theory be implemented today, although I am unaware of any good trustless off-to-onchain swap services today, and (2) you can keep repeating it with "the same" onchain funds, getting incoming capacity from multiple points on the network, until the service runs out of onchain funds to swap with you or you believe you have enough incoming capacity. In short: the common complaint, that you can only easily get incoming capacity equal to what you spend, can be taken advantage of, by spending your (offchain) Bitcoin to buy (onchain) Bitcoin. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, 10 September 2018 20:30, Cezary Dziemian wrote: > Hi, > > About weak ago I talked with Christian Decker, and he told me, that there is > plan to implement possibility of both-side funding channels. He told me, that > I will be able (for example) to pay 100 sat for peer if he agreed to put some > of his funds to channel. Everything in single, trustless transaction. > > Do I understand
[Lightning-dev] Both-side funded channels
Hi, About weak ago I talked with Christian Decker, and he told me, that there is plan to implement possibility of both-side funding channels. He told me, that I will be able (for example) to pay 100 sat for peer if he agreed to put some of his funds to channel. Everything in single, trustless transaction. Do I understand this correctly? And if so, do you have any predictions when it could be implemented? Cezary ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
