Rusty Russell, another contributor, had assumed that the packet format would not be modified to include the payment hash in either the header or e2e payload. They both agree that the payment hash should be authenticated as part of packet processing at each hop to prevent replay attempts by adversaries.Christian Lundkvist acknowledged the oversight and promised to add the payment hash to the spec and implementations. Christian Decker mentioned during a discussion on updating the Lightning Network specification that they have dropped the end-to-end payload but kept the shared secret backlog. They discussed the possibility of committing the routing information to the payment hash, but it was deemed awkward due to the increase in per-hop payload size. They proposed that the payment hash be concatenated to the material being authenticated similar to "associated data" in AEAD cipher modes.Olaoluwa Osuntokun explained in an email discussion that using EC-Schnorr instead of EC-DSA for on-chain keys in Bitcoin would allow the same pub/priv keys to be used for signing/verifying multi-sign for channel authentication proofs. He suggested separating onion privkey rotation for limiting the shared secret backlog, even without forward secrecy. The conversation also highlighted the importance of protecting different secrets and using independent keying material.Another discussion focused on issues regarding channel identification and proof sizes. It was noted that using blocknum+txnum to identify a channel does not account for transactions that open multiple channels concurrently. An extra byte or two would need to be added to encode the output index of the channel within the transaction. The compactness of identifying channels based solely on blockheight+offsets was acknowledged, but there were concerns about re-org safety. Rusty Russell suggested using schnorr multi-signature to address non-canonical graphs resulting in differing network views.The email conversation between Christian Decker and Rusty Russell discussed the onion routing protocol and key rotation policies. They considered two potential key rotations: rotating the key used in Bitcoin transactions and rotating the public key used for the DH shared-secret generation in the onion routing protocol. The discussion included the costs and feasibility of key rotation, as well as suggestions for using a "comms" key instead of the node's ID. Various rotation schemes, both active and passive, were proposed to address security and communication overhead concerns.Christian Decker and Laolu Osuntokun discussed the outstanding issues related to the onion routing protocol. They decided to defer some issues, such as key-rotation policies and payload formatting, to later versions. The specification of the rendezvous handshake was also deferred. For now, they agreed on fixed payload sizes and the possibility of using a generic encoding to make the protocol more flexible.The Lightning Network developers have been discussing various aspects of the onion routing protocol and its implementation. One of the main concerns is the key-rotation policy, with Rusty Russell suggesting using a "comms" key for each node instead of its ID to address the issue. He also discusses the potential costs of key rotation in terms of data storage.Another important topic of discussion is the use of HMAC and payload distribution among the hops. The developers agree that the entire packet, including payloads, should be covered by HMAC, but this can create a rendezvous problem. The suggestion is made to keep payload sizes fixed and potentially use a generic encoding like JSON or msgpack.In terms of security, the developers propose solutions to prevent potential attacks. One suggestion is to include a shared secret value in the per-hop payload for the final hop, ensuring that the payload matches this value to prevent compromise. They also discuss the need for pre-negotiated amounts between senders and recipients to avoid errors and theft by prior hops.The developers also address the issue of ambiguity when multiple channels on different chains use the same identifiers. To prevent guesswork, they suggest adding a realm byte to specify the target chain. This byte could be stored in the per-hop payload or added to the header.Other topics discussed include the complexity of the routing protocol, the format of the "onion blob" header, and the use of Schnorr keys within the Bitcoin network for space savings. The developers aim to find clean and simple solutions to these issues while ensuring the security and efficiency of the Lightning Network.The email thread discusses various options and proposals for designing a high throughput onion routing network. One option involves including payloads in the header HMAC computation, while another option focuses on anonymous rendezvous meetings. The group also discusses the use of timestamps, key rotation, and enabling intermediate nodes to reply to packets. They explore the challenges and trade-offs associated with each proposal, aiming to increase the robustness of onion routing within the network.The conversation delves into the use of HD onion key derivation in the Lightning Network and potential vulnerabilities. They propose using a new root key authenticated via a