From jlrubin at mit.edu Tue Jul 27 18:21:48 2021 From: jlrubin at mit.edu (Jeremy) Date: Tue, 27 Jul 2021 11:21:48 -0700 Subject: [Lightning-dev] Impact of eltoo loss of state In-Reply-To: <1weQDZgYk8tBYX5shbIfWYRgLcOgsCzp23bAmaRzKBqVftfQLHUxGw9I55A2MRvSWiBG5hRDkSTeVLxL1pX5AZ8oiRc4WjTzy2BcJmrPZV0=@protonmail.com> References: <20210712081749.GB6250@erisian.com.au> <87czrl6jlj.fsf@gmail.com> <1weQDZgYk8tBYX5shbIfWYRgLcOgsCzp23bAmaRzKBqVftfQLHUxGw9I55A2MRvSWiBG5hRDkSTeVLxL1pX5AZ8oiRc4WjTzy2BcJmrPZV0=@protonmail.com> Message-ID: Just my 2 cents: I think worrying about the size of a resolution during a contested close scenario (too much) is not worth it. Encoding the state needed (e.g., in op_return or whatever) is the safest option because then you guarantee the availability of the closing transaction data in the protocol with no external dependencies. If you want to make it cheaper, then allow for Alice to choose to cooperate with a contesting Bob to replace the transaction with something smaller (quibble: we should get rid of mempool absolute fee increase rule for RBF perhaps... otherwise, this should be done as pre-broadcast negotiation) after observing the state published by Bob, but make it mandatory to at least reveal it if Bob wants to use the transaction unilaterally. -------------- next part -------------- An HTML attachment was scrubbed... URL: