[PATCH] First draft of option_simplfied_commitment



Summary:

The email exchange discusses various aspects of anchor outputs and key rotation in the Lightning Network. The first issue raised is the possibility of an attacker 'using up' the cpfp carve-out after 10 blocks if the output type is normal P2WKH. However, introducing new addresses for each party's anchors in the open_channel and accept_channel messages could prevent this attack scenario. It is also noted that within each version of the commitment transaction, both anchors always have equal values and are paid for by the initiator. The value of the anchors is set to the dust limit negotiated in the open_channel or accept_channel message.The discussion also touches on watchtowers and their design constraints. Four constraints are listed, including the need to prevent a watchtower from guessing channel history even with a unilateral tx or revoked unilateral tx with a penalty. One option suggested is to abandon privacy from watchtowers and not rotate keys, but this would allow for brute-forcing of channel history. Another is to use BIP32 (unhardened) for key rotation on the to-local output. Finally, the idea of removing key rotation for anchor outputs is proposed as it may make it easier to let the anchors go straight into the wallet and mitigate the dust utxo problem.


Updated on: 2023-05-20T09:04:35.999065+00:00