(resend from the right src) >> On Oct 30, 2019, at 06:04, Joost Jager <[email protected]> wrote: >> > 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.
Quick correction. This is only partially true. You can still RBF the sub-package, the only issue I see immediately is you have to pay for the otherwise-free relay of everything the attacker relayed. Why not stick with the original design from Adelaide with a spending path with a 1CSV that is anyone can spend (or that is revealed by spending another output). >> > * 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 > _______________________________________________ > Lightning-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
