Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
Regarding the dust relay limit, there may be a little bit of a misunderstanding as to a few important details. The purpose of it (much like the dust output values in the anchor outputs) is to discourage outputs which are not ever economically spendable, not short-term uneconomically spendable. This value is, thus, *not* connected to the mempool's min relay fee (except for the purposes of calculating the constant, which may be part of the disconnect here). The min relay fee represents a short-term DoS limit, and, thus, can float wildly (though, since 2017, and even in general, we largely have not seen it go up much in absolute value at all). Further, and, critically, there are a number of issues with *any* policy change that makes several bits of the P2P network less efficient, and, thus, they are generally avoided where possible. These include, compact block relay, feerate estimation, relay-DoS-resistance, etc. While none of this is to say that the dust limit will *never* change, I really don't think its unreasonable to hard code it - there's no pressure *to* change it, and if there's an additional reason not to (ie that deployed software relies on that value, which other software, more than lightning already does), then it almost certainly wont be. Matt On 11/14/19 9:56 AM, Joost Jager wrote: >> So then because unilateral close is the only way to resolve atm, it is >> correct also in theory that there will never be a commitment tx >where the >> non-initiator pays fees? But the point is clear, channels can get >stuck. > >Yeah. Generally, it doesn't happen because we insist on a reasonable >balance in the channel, but it's theoretically possible. > > > Ok, summarizing just for clarity: > > - there will never be a commitment tx where the non-initiator pays fees > - generally a unilateral close doesn't happen because we insist on a > reasonable > balance in the channel > > If we hard-code a constant, we won't be able to adapt to changes of `dustRelayFee` in the bitcoin network. And we'd also need to >deal with a peer picking a value higher than that constant for its regular >funding >>> flow dust limit parameter. >>> Note that we can't adapt to dustRelayFee *today*, since we can't >change >>> it after funding (another thing we probably need to fix). >> You can't for an existing channel, but at least for a new channel >you can >> pick a different value. Which wouldn't be possible if we'd put a fixed >> (anchor) amount in the spec. > >That's not really much consolation though for the existing network. > >Still Matt assures me that the relay dust limit is not going to change, >so I think we're best off cutting down our test matrix by choosing a >value and putting it directly into the spec. > >By my calculations, at minfee it will cost you ~94 satoshis to spend. >Dust limit is 294 for Segwit outputs (basically assuming 3x minfee). > >So I'm actually happy to say "anchor outputs are 294 satoshi". These >are simply spendable, and still only $3 each if BTC is $1M. Lower is >better (as long as we stick with funder-pays), as long as they do >eventually get spent. > > > Looking at https://github.com/bitcoin/bitcoin/commit/9022aa3, is > `dustRelayFee` really never going to change? It even is a (hidden) cmd > line parameter that can be set easily. > > If the fee market would rise and stay high for an extended period of > time, why wouldn't people use this flag to raise the dust relay fee? If > we then have our hard coded 294 sat anchors, no force close transactions > can be broadcast anymore. It would be risky to open new channels at that > point, because they can only be coop closed. > > Maybe Lightning is relevant enough by that time to keep people from > touching `dustRelayFee`, but what if not? The fix at that point would be > to introduce a new commitment format, which given our process takes a > long time. > > I'd think that having at least an option to adapt to `dustRelayFee` > changes for new channels makes Lightning more robust. The two options > that I know of are: > > - Reuse `dust_limit_satoshis` on the `open_channel`/`accept_channel` > messages as the anchor size. This ignores that an anchor does not need > to be net positive after sweeping (because it's purpose is to get the > commit tx confirmed), while we generally do want htlcs to be net > positive. It may however be not such a big deal in practice. Suppose > we'd just set this to 294 sat to get the desired anchor output value > (and make it a soft requirement for channel acceptance). The worst that > can happen is that there is a force close with one or more pending htlcs > that aren't economical to sweep. Which can happen anyway because this is > a channel open parameter and it is impossible to know what is economical > for the lifetime of the channel. Instead of burning to fees, the htlc > output will sit there waiting for fees to
Re: [Lightning-dev] Doubt regarding payment channel capacity
Good morning list, Some hundred or so blocks ago, lightning-dev emails were being undelivered. It seems okay now. There was a long discussion I had with Subhra at the time, unfortunately it ended up being off-list due to the mailing list being down. In any case, I believe it would be of interest, and thus below is the emails involved. Regards. ZmnSCPxj > Good morning Subhra, > > > Hello, > > Thanks a lot for the detailed explanation. It justifies why this > > attack may not sustain quite long in the network. Another question > > regarding routing then. It is assumed that when channels are probed for > > routing, it will be checked whether there is enough balance in the channel > > to route the payment or not. But the only view which one has of the channel > > is the initial capacity of the channel and not the balance of the channel > > at that moment. What if the pair of nodes in a channel are byzantine and > > reports a wrong value of residual balance ? Consider the previous example > > where B and C may have locked some amount between them say 1 BTC but B and > > C are part of one collective controlled by an adversary. What if BC gets > > routing request for 20 transaction, each having payment value of 0.1 BTC ? > > Again the case may be that T_i channel with B (i \in [1,20]), each channel > > T_i,B having capacity of 0.3 BTC and C has channel with D_i (i \in 1 to > > 20), each having channel capacity of 0.3 BTC. So now in this case it > > doesn't matter what balance BC has, it just goes on reporting a balance of > > 0.1 BTC to accept all routing request till lifetime of the channel, but in > > reality it is not locking any fund at all. So is this possible where a > > wrong information of channel's balance is reported ? > > You strongly misunderstand. > > Neither B nor C can misreport the funds in the channel, for the following > very simple reason: > > - There is no facility to actually remotely report the channel balance. > > Thus this is still not a problem. > > Nobody else particularly cares what the exact balance is on the B<->C > channel (because if they were econmically-separate entities and had a good > amount of traffic with the network, then the exact balance would have changed > by the time you receive the information anyway, so why bother asking?). > > > Everybody else only cares whether it is possible to route via the B<->C > channel or not. > That is all that is reported: whether an HTLC of amount X can be routed right > now, or not. > In your case, it would mean that B and C would always report that it can be > routed right now, but so? > It just means increased payment reliability on the rest of the network (and > reflects the truth as well: B and C are the same entity anyway, thus the > reliability of the B<->C channel is equivalent to the reliability of the B C > aggregate). > > There is no way for B and C to somehow promote this into an attack on the > network. > > Fundamentally speaking, if B and C are the same economic entity, then the > B<->C channel (which has to be backed by some UTXO, else it cannot be > announced on Lightning) is no different from that single economic entity > keeping some funds on a hot online wallets. > > If an entity keeping some funds in a hot wallet has no effect on the > Lightning Network, then the existence of the B<->C channel also has no effect > on the Lightning Network. > Economically speaking, if you are going to put funds in a hot wallet anyway, > on a computer you are obligated to keep online 144 blocks a day, 2016 blocks > a difficulty adjustment, then you might as well put those funds in a real, > externally-earning channel on the Lightning Network, but I made that argument > already anyway. > > Regards, > ZmnSCPxj > > > On Fri, Nov 15, 2019 at 12:46 PM ZmnSCPxj zmnsc...@protonmail.com wrote: > > > > > Good morning Subhra, > > > > > > > So that means its not a problem if the cluster size increases from B->C > > > > to B->C->X->Y->Z ? I mean we still get a successful payment but is not > > > > at the cost of A locking greater processing fee for the intermediate > > > > node B,C,X,Y and Z even though they are one single entity ? > > > > Unnecessarily there is an increase in the path length, plus in this way > > > > B can spawn several such dummy nodes in order to gain processing fee. > > > > Sorry if I am not getting it correctly but as you have pointed out if > > > > there is a single node Q between A and D then obviously that will be > > > > preferred. But what if there is no alternate route available to A in > > > > order to reach D and A->B->C->D is the only option ? > > > > > > Yes, it is not a problem at all. > > > It is helpful to remember that the channels B<->C, C<->X, X<->Y, and > > > Y<->Z require being backed on the blockchain, and requires money to be > > > allocated for it. > > > This money could have been used elsewhere on the network to serve as > > >
[Lightning-dev] Lightning-dev down
Good morning list, A hundred to two hundred blocks ago, it seems the list was down, and messages to the list were not deliverable. This email also doubles as a test on whether the list is still down today. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
