Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-30 📝 Original message: > > > * Add ...
📅 Original date posted:2019-10-30
📝 Original message:
>
> > * 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.
>
The game returns, but both parties will be aware of the game they are
playing. They agreed to their peer's to_self_delay up front. (This is
different from the current situation where both peers are forced to accept
a remote_to_self_delay of 0.) With validation on the open/accept_channel
message, a node can still enforce both to_self_delays to be equal. We could
simplify this to a single to_self_delay that is proposed by the initiator,
but what was the original reason to allow distinct values?
> > 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.
>
With the mempool acceptance carve-out in bitcoind 0.19, we indeed won't be
able to safely produce a single OP_TRUE output for anyone to spend. An
attacker could attach low fee child transactions, reach the limits and
block further fee bumping.
> * 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.
>
It seems there isn't another way to do the anchor outputs given the mempool
limitations that exist? Each party needs to have their own anchor,
protected by a key. Otherwise it would open up these attack scenarios where
an attacker blocks the commitment tx confirmation until htlcs time out.
Even with the script OP_DEPTH OP_IF <pubkey> OP_CHECKSIG OP_ELSE 10 OP_CSV
OP_ENDIF, the "anyones" don't know the pubkey and still can't sweep after
10 blocks.
> * 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?
>
Similar to how it currently works. There should never be a commitment
transaction in which the initiator cannot pay the fee. With anchor outputs
there should never be a commitment tx in which the initiator cannot pay the
fee and the anchors. Also currently you cannot push everything to the other
side with push_msat. The initiator still needs to have enough balance to
pay for the on-chain costs (miner fee and anchors).
> 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.
>
Yes, it is free money. Therefore we need to validate the dust limit in the
funding flow. Check whether it is reasonable. That should also be done in
the current implementation. Otherwise your peer can set a really high dust
limit that lets your htlc disappear on-chain (although that is only free
money for the miner).
If we hard-code a constant, we won't be able to adapt to changes of
`dustRelayFee` in the bitcoin network. And we'd also need to deal with a
peer picking a value higher than that constant for its regular funding flow
dust limit parameter.
> 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.
>
Interesting. I wasn't aware of the brute-force method that watchtowers
could potentially use. I wanted to bring up the removal of key rotation
just in case everyone would agree we don't need it anymore. It isn't
required for the anchor outputs, but it would have been one (future)
commitment format less. But it seems we do need it.
In the light of this forgotten insight, is there a reason why the anchor
output would need key rotation? Having no rotation makes it easier to let
those anchors go straight into the wallet, which may mitigate the dust utxo
problem a bit. At least then they can be easily coin-selected for any
on-chain spent, if the market fees are low enough.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191030/170f6756/attachment.html>;
📝 Original message:
>
> > * 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.
>
The game returns, but both parties will be aware of the game they are
playing. They agreed to their peer's to_self_delay up front. (This is
different from the current situation where both peers are forced to accept
a remote_to_self_delay of 0.) With validation on the open/accept_channel
message, a node can still enforce both to_self_delays to be equal. We could
simplify this to a single to_self_delay that is proposed by the initiator,
but what was the original reason to allow distinct values?
> > 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.
>
With the mempool acceptance carve-out in bitcoind 0.19, we indeed won't be
able to safely produce a single OP_TRUE output for anyone to spend. An
attacker could attach low fee child transactions, reach the limits and
block further fee bumping.
> * 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.
>
It seems there isn't another way to do the anchor outputs given the mempool
limitations that exist? Each party needs to have their own anchor,
protected by a key. Otherwise it would open up these attack scenarios where
an attacker blocks the commitment tx confirmation until htlcs time out.
Even with the script OP_DEPTH OP_IF <pubkey> OP_CHECKSIG OP_ELSE 10 OP_CSV
OP_ENDIF, the "anyones" don't know the pubkey and still can't sweep after
10 blocks.
> * 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?
>
Similar to how it currently works. There should never be a commitment
transaction in which the initiator cannot pay the fee. With anchor outputs
there should never be a commitment tx in which the initiator cannot pay the
fee and the anchors. Also currently you cannot push everything to the other
side with push_msat. The initiator still needs to have enough balance to
pay for the on-chain costs (miner fee and anchors).
> 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.
>
Yes, it is free money. Therefore we need to validate the dust limit in the
funding flow. Check whether it is reasonable. That should also be done in
the current implementation. Otherwise your peer can set a really high dust
limit that lets your htlc disappear on-chain (although that is only free
money for the miner).
If we hard-code a constant, we won't be able to adapt to changes of
`dustRelayFee` in the bitcoin network. And we'd also need to deal with a
peer picking a value higher than that constant for its regular funding flow
dust limit parameter.
> 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.
>
Interesting. I wasn't aware of the brute-force method that watchtowers
could potentially use. I wanted to bring up the removal of key rotation
just in case everyone would agree we don't need it anymore. It isn't
required for the anchor outputs, but it would have been one (future)
commitment format less. But it seems we do need it.
In the light of this forgotten insight, is there a reason why the anchor
output would need key rotation? Having no rotation makes it easier to let
those anchors go straight into the wallet, which may mitigate the dust utxo
problem a bit. At least then they can be easily coin-selected for any
on-chain spent, if the market fees are low enough.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191030/170f6756/attachment.html>;