<div dir="ltr">Hi y'all, <br><br>We've been discussing the current state of the spec and implementation<br>readiness of anchor outputs for a few week now on IRC. As detailed<br>conversations are at times difficult to have on IRC, and there's no true<br>history, I figured I'd start a new discussion thread where we can hammer out<br>the final details.<br><br>First, on the current state of implementation. Anchor outputs are now fully<br>supported in the master branch of lnd. A user can opt into this new format<br>by specifying a new command line parameter: --protocol.anchors (off by<br>default).  Nodes running with this flag will use the feature bit 1337 for<br>negotiation. We didn't use the range above 65k, as we realized that would<br>result in rather large init messages. This feature will be included in our<br>upcoming 0.10 release, which will be entering the release mandate phase in<br>the next week or two. We also plan to add an entry in the wiki declaring our<br>usage of this feature bit.<br><br>Anchors in lnd implement the spec as is currently defined: two anchors at<br>all times, with each anchor utilizing 330 satoshis. <br><br>During the last spec meeting, the following concerns were raised about<br>having two anchors at all times (compared to one and re-using the to_remote)<br>output:<br><br>  1. two anchors adds extra bytes to the commitment transaction, increasing the<br>     fee burden for force closing<br>  2. two anchors pollutes the UTXO set, so instead one anchor (for the force<br>     closing party) should be present, while the other party re-uses their<br>     to_remote output for this purpose<br><br>In response to the first concern: it is indeed the case that these new<br>commitments are more expensive, but they're only _slightly_ so. The new<br>default commitment weight is as if there're two HTLCs at all times on the<br>commitment transaction. Adding in the extra anchor cost (660 satoshis) is a<br>false equivalence as both parties are able to recover these funds if they<br>chose. It's also the case that force cases in the ideal case are only due to<br>nodes needing to go on-chain to sweep HTLCs, so the extra bytes may be<br>dwarfed by several HTLCs, particularly in a post MPP/AMP world. The extra<br>cost may seem large (relatively) when looking at a 1 sat/byte commitment<br>transaction. However, fees today in the system are on the rise, and if one<br>is actually in a situation where they need to resolve HTLCs on chain,<br>they'll likely require a fee rate higher than 1 sat/byte to have their<br>commitment confirm in a timely manner.<br><br>On the topic of UTXO bloat, IMO re-purposing the to_remote output as an<br>anchor is arguably _worse_, as only a single party in the channel is able to<br>spend that output in order to remove its impact on the UTXO set. On the<br>other hand, using two anchors (with their special scripts) allows _anyone_<br>to sweep these outputs several blocks after the commitment transaction has<br>confirmed. In order to cover the case where the remote party has no balance,<br>but a single incoming HTLC, the channel initiator must either create a new<br>anchor output for this special case (creating a new type of ad-hoc reserve),<br>or always create a to_remote output for the other party (donating the 330<br>satoshis).  The first option reduces down to having two anchors once again,<br>while the second option creates an output which is likely uneconomical to<br>sweep in isolation (compared to anchors which can be swept globally in the<br>system taking advantage of the input aggregation savings).<br><br>The final factor to consider is if we wish to properly re-introduce a CSV<br>delay to the to_remote party in an attempt to remedy some game theoretical<br>issues w.r.t forcing one party to close early without a cost to the<br>instigator. In the past we made some headway in this direction, but then<br>reverted our changes as we discoverers some previously unknown gaming<br>vectors even with a symmetrical delay. If we keep two anchor as is, then we<br>leave this thread open to a comprehensive solution, as the dual anchor<br>format is fully decoupled from the rest of the commitment.<br><br>Circling back to our implementation, we're ready to deploy what we have as<br>is.  In the future, if the scheme changes, then we'll be able to easily<br>update all our users, as we're also concurrently working on a dynamic<br>commitment update protocol. By dynamic I mean that users will be able to<br>update their commitment type on the fly, compared to being locked into a<br>commitment type when the channel opens as is today.<br><br>Would love to hear y'alls thoughts on the two primary concerns laid out<br>above, and my response to them, thanks!<br><br>-- Laolu<br></div>