Joost Jager <joost.ja...@gmail.com> writes: >> >> > * 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?
Because I didn't fight hard enough for simplicity :( There is no "negotiation" on opening; it's accept or error. That leads to a situation where every implementation MUST accept what every implementation offers. The unification proposal was to use the max of the two settings. That's fair; if you want me to suffer a 2 week delay, you should too. >> 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. Indeed :( >> 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. I think you're right, but I don't *like* it... >> * 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. Unfortunately, this is not correct (in theory). We can always get into a case where fees are insufficient (simultanous HTLC adds), but it's unusual. We used to specify that the non-funder would pay the remaining fee, but we dropped this in favor of allow unilateral close if this ever happened. > With anchor outputs > there should never be a commitment tx in which the initiator cannot pay the > fee and the anchors. There can be, but I think we can simply modify this so you have to pay the anchors *first* before fees. > 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). This is true; I forgot we fixed that, sorry. push_msat is a red herring. >> 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). True, and spec should note this BTW! I've added an issue. https://github.com/lightningnetwork/lightning-rfc/issues/696 > 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. Note that we can't adapt to dustRelayFee *today*, since we can't change it after funding (another thing we probably need to fix). If we really want to make it adjustable, could we make each side pay for its own; if you can't afford it, you don't get one? There's no point the funder paying for a fundee-anchor if the fundee has no skin in the game. That reduces the pressure somewhat, I think? > 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. I hate it, too. The original design was *so* much simpler :( > 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. Or what about we rotate the anchors and nothing else, which (assuming we make it anyone-can-spend-after-N-blocks) reduces the amount of onchain spam if someone completely loses their keys? That's a bigger change, but maybe it's worth it? Cheers! Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev