[Lightning-dev] [PATCH] First draft of option_simplfied_commitment

[Matt Corallo]

> On Oct 30, 2019, at 03:04, Rusty Russell <rusty at rustcorp.com.au> wrote:
> 
> Joost Jager <joost.jager at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev