Joost Jager <joost.ja...@gmail.com> writes: > We started to look at the `push_me` outputs again. Will refer to them as > `anchor` outputs from now on, to prevent confusion with `push_msat` on the > `open_channel` message. > > The cpfp carve-out https://github.com/bitcoin/bitcoin/pull/15681 has been > merged and for reasons described earlier in this thread, we now need to a= dd > a csv time lock to every non-anchor output on the commitment transaction. > > To realize this, we are currently considering the following changes: > > * Add `to_remote_delay OP_CHECKSEQUENCEVERIFY OP_DROP` to the `to_remote` > output. `to_remote_delay` is the csv delay that the remote party accepted > in the funding flow for their outputs. This not only ensures that the > carve-out works as intended, but also removes the incentive to game the > other party into force-closing. If desired, both parties can still agree = to > have different `to_self_delay` values.
I think we should unify to_self_delay if we're doing this. Otherwise the game returns. > * Add `1 OP_CHECKSEQUENCEVERIFY OP_DROP` to the non-revocation clause of > the HTLC outputs. > For the anchor outputs we consider: > > * Output type: normal P2WKH. At one point, an additional spending path was > proposed that was unconditional except for a 10 block csv lock. The > intention of this was to prevent utxo set pollution by allowing anyone to > clean up. This however also opens up the possibility for an attacker to > 'use up' the cpfp carve-out after those 10 blocks. If the user A is offli= ne > for that period of time, a malicious peer B may already have broadcasted > the commitment tx and pinned down user A's anchor output with a low fee > child. That way, the commitment tx could still remain unconfirmed while an > important htlc expires. Agreed, this doesn't really work. We actually needed a bitcoin rule that allowed a single anyone-can-spend output. Seems like we didn't get that. > * For the keys to use for `to_remote_anchor` and `to_local_anchor`, we=E2= =80=99d > like to introduce new addresses that both parties communicate in the > `open_channel` and `accept_channel` messages. We don=E2=80=99t want to re= use the > main commitment output addresses, because those may (at some point) be co= ld > storage addresses and the cpfp is likely to happen from a hot wallet. This is horribly spammy. At the moment we see ~ one unilateral close every 3 blocks. Hopefully that will reduce, but there'll always be some. > * Within each version of the commitment transaction, both anchors always > have equal values and are paid for by the initiator. Who pays if they can't afford it? What if they push_msat everything to the other side? > The value of the > anchors is the dust limit that was negotiated in the `open_channel` or > `accept_channel` message of the party that publishes the transaction. Now initiator has to care about the other side's dust limit, which is bad. And as accepter I now want this much higher, since I get those funds instantly. I don't think we gain anything by making this configurable at all; just pick a number and be done. Somewhere between 1000 and 10,000 sat is a good idea. > Furthermore, there doesn=E2=80=99t seem to be a compelling reason anymore= for > tweaking the keys (new insights into watchtower designs, encrypt by txid). That's not correct. This seems more like "forgotten insights" than "new insights", which isn't surprising how long ago Tadge and I did the watchtower design (BTW: I was the one who came up with encrypt by txid for that!). There are several design constraints in the original watchtowers: 1. A watchtower shouldn't be able to guess the channel history. 2. ... even if it sees a unilateral tx. 3. ... even if it sees a revoked unilateral tx it has a penalty for. 4. A watchtower shouldn't be able to tell if it's being used for both parties in the same channel. If you don't rotate keys, a watchtower can brute-force the HTLCs for all previous transactions it was told about, and previous channel balances. We removed key rotation on the to-remote output because you can simply not tell the watchtower about txs which don't have anything but an output to you. Here are the options I see: 1. Abandon privacy from watchtowers and don't rotate keys. Watchtowers will be able to brute-force your history if they see a unilateral close. 2. Remove HTLC output key rotation, and assume watchtowers don't handle HTLCs (so you don't tell them about early txs where the peer has no output but there are HTLCs pending). This seems less useful, since HTLC txs require metadata anyway. 3. Change to-local key rotation to use BIP32 (unhardened). We could also take some of the 48 bits (maybe 24?) we currently use to encode the commitment number, to encode a BIP32 sub-path for this channel. This would make it easier for hardware wallets to reconstruct. Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
