Matt Corallo [ARCHIVE] on Nostr: đź“… Original date posted:2019-10-30 đź“ť Original message: > On Oct 30, 2019, at ...
đź“… Original date posted:2019-10-30
đź“ť Original message:
> 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
đź“ť Original message:
> 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