{"type":"rich","version":"1.0","author_name":"npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","author_url":"https://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-04-20\n📝 Original message:\nChristian Decker \u003cdecker.christian at gmail.com\u003e writes:\n\u003e Rusty Russell \u003crusty at rustcorp.com.au\u003e writes:\n\u003e\u003e\u003e This is in stark contrast to the leader-based approach, where both\n\u003e\u003e\u003e parties can just keep queuing updates without silent times to\n\u003e\u003e\u003e transferring the token from one end to the other.\n\u003e\u003e\n\u003e\u003e You've swayed me, but it needs new wire msgs to indicate \"these are\n\u003e\u003e your proposals I'm reflecting to you\".\n\u003e\u003e\n\u003e\u003e OTOH they don't need to carry data, so we can probably just have:\n\u003e\u003e\n\u003e\u003e update_htlcs_ack:\n\u003e\u003e    * [`channel_id`:`channel_id`]\n\u003e\u003e    * [`u16`:`num_added`]\n\u003e\u003e    * [`num_added*u64`:`added`]\n\u003e\u003e    * [`u16`:`num_removed`]\n\u003e\u003e    * [`num_removed*u64`:`removed`]\n\u003e\u003e\n\u003e\u003e update_fee can stay the same.\n\u003e\u003e\n\u003e\u003e Thoughts?\n\u003e\n\u003e So this would pretty much be a batch-ack, sent after a whole series of\n\u003e changes were proposed to the leader, and referenced by their `htlc_id`,\n\u003e correct? This is one optimization step further than what I was thinking,\n\u003e but it can work. My proposal would have been to either reflect the whole\n\u003e message (nodes need to remember proposals they've sent anyway in case of\n\u003e disconnects, so matching incoming changes with the pending ones should\n\u003e not be too hard), or send back individual acks, containing the hash of\n\u003e the message if we want to safe on bytes transferred. Alternatively we\n\u003e could also use reference the change by its htlc_id.\n\n[ Following up on an old thread ]\n\nAfter consideration, I prefer alternation.  It fits better with the\nexisting implementations, and it is more optimal than reflection for\noptimized implementations.\n\nIn particular, you have a rule that says you can send updates and\ncommitment_signed when it's not your turn, and the leader either\nresponds with a \"giving way\" message, or ignores your changes and sends\nits own.\n\nA simple implementation *never* sends a commitment_signed until it\nreceives \"giving way\" so it doesn't have to deal with orphaned\ncommitments.  A more complex implementation sends opportunistically and\nthen has to remember that it's committed if it loses the race.  Such an\nimplementation is only slower than the current system if that race\nhappens.\n\nI've been revisiting this because it makes things like splicing easier:\nthe current draft requires stopping changes while splicing is being\nnegotiated, which is not entirely trivial.  With the simplified method,\nyou don't have to wait at all.\n\nCheers,\nRusty."}