> On Oct 30, 2019, at 03:04, Rusty Russell <ru...@rustcorp.com.au> wrote: > > Joost Jager <joost.ja...@gmail.com> writes: >> * 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.
Hmm? If you have a CSV lock, it can’t be used for carve-out/CPFP period. I don’t see why this doesn’t work. We definitely should stick to this. >> * 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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev