Knee-jerk gut reaction replies inline :) Matt
On 3/30/20 3:00 PM, Olaoluwa Osuntokun wrote: -snip- > In response to the first concern: it is indeed the case that these new > commitments are more expensive, but they're only _slightly_ so. The new > default commitment weight is as if there're two HTLCs at all times on the > commitment transaction. Adding in the extra anchor cost (660 satoshis) is a > false equivalence as both parties are able to recover these funds if they > chose. It's also the case that force cases in the ideal case are only due to > nodes needing to go on-chain to sweep HTLCs, so the extra bytes may be > dwarfed by several HTLCs, particularly in a post MPP/AMP world. The extra > cost may seem large (relatively) when looking at a 1 sat/byte commitment > transaction. However, fees today in the system are on the rise, and if one > is actually in a situation where they need to resolve HTLCs on chain, > they'll likely require a fee rate higher than 1 sat/byte to have their > commitment confirm in a timely manner. Indeed, a few hundred sats isn't likely worth arguing about :) > On the topic of UTXO bloat, IMO re-purposing the to_remote output as an > anchor is arguably _worse_, as only a single party in the channel is able to > spend that output in order to remove its impact on the UTXO set. On the > other hand, using two anchors (with their special scripts) allows _anyone_ > to sweep these outputs several blocks after the commitment transaction has > confirmed. In order to cover the case where the remote party has no balance, > but a single incoming HTLC, the channel initiator must either create a new > anchor output for this special case (creating a new type of ad-hoc reserve), > or always create a to_remote output for the other party (donating the 330 > satoshis). This seems like a straw-man. Going from 1 anyone-spendable + 1 such UTXO to 2 anyone-spendable UTXOs + 1 such UTXO does not seem like a decrease to me. If you really want to nitpick, I have zero issue with having the to_remote+anchor revert to an anyone-can-spend form if it is of dust value. This may be a bit complicated for others, but with our new onchain stuff, it would be rather trivial for us to deal with. > The first option reduces down to having two anchors once again, > while the second option creates an output which is likely uneconomical to > sweep in isolation (compared to anchors which can be swept globally in the > system taking advantage of the input aggregation savings). > > The final factor to consider is if we wish to properly re-introduce a CSV > delay to the to_remote party in an attempt to remedy some game theoretical > issues w.r.t forcing one party to close early without a cost to the > instigator. In the past we made some headway in this direction, but then > reverted our changes as we discoverers some previously unknown gaming > vectors even with a symmetrical delay. If we keep two anchor as is, then we > leave this thread open to a comprehensive solution, as the dual anchor > format is fully decoupled from the rest of the commitment. If we want to deploy an upgrade, the commitment transaction format will change. Lets not get excited about reducing the diff in such a change for its own sake - the vast majority of the effort is the upgrade, not the diff of having an extra anchor. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
