Laundry list of inter-peer wire protocol changes

One suggestion is to decouple certain aspects of the protocol, such as micro-transaction channel design, commit conditions, and routing, by creating separate sub-protocols with their own version numbers. Currently, Amiko Pay has already implemented the separation of micro-transaction channel design.There have been multiple suggestions for the inter-node protocol. One proposal is to use protobufs instead of open-coded structures to allow for easier extension with new fields. It is also recommended to prefix the initial key exchange and other packets with a length word to facilitate future extensions. Differences in HTLC negotiation schemes between lnd and lightning-c have been addressed, as well as the ability for initiators to abort new HTLC processes before revocation exchange. Version bits should be exchanged after the initial handshake to indicate compulsory and optional features. Wire protocol crypto has also been discussed, including the use of chacha20/poly1305 instead of AES/HMAC-SHA256 and a separate encoding stream for packet lengths. The choice between shachain and elkrem for generating revocation secrets has been debated, along with proposals regarding anchor tx renegotiation, R value vs keypair, and multi-sig txs.The Amiko Pay protocol aims to provide a decentralized payment network with privacy and security. It uses TCP for the transport layer and JSON with added conventions for serialization. Manual message confirmation is employed to ensure message delivery even after crashes and restarts. The protocol supports bi-directional routing, enabling the transmission of metadata and an arbitrary "receipt" between payer and payee. Multiple channels per link are utilized for efficient transaction routing, and different channel classes facilitate micro-transaction design. The protocol emphasizes the importance of implementation alongside specifications for future compatibility.In an email conversation, Rusty Russell and aj discuss the use of shachain and elkrem for generating revocation secrets. While elkrem is easier to understand, there are issues with the provided code example. The conversation also covers the indexing of shachain and elkrem, as well as the use of a simple secret "redeemhash" and multi-sig txs for escrow-style services.Proposed changes to the Lightning Network protocol include using open-coded messaging and implementing length prefixes for key exchange and packets. The protocol also incorporates security features such as exchanging version bits after key setup, using AES/HMAC-SHA256 or Chacha20/Poly1305 for wire protocol crypto, and separate encoding streams for packet lengths. Shachain and elkrem are tools used for generating revocation secrets, and the protocol allows for re-anchoring of channels and multi-sig transactions. There is also a debate between the R value vs keypair scheme, and individuals are encouraged to clone the lightning-core repository and write up their specifications.Rusty Russell, the developer of the inter-node protocol, is working on finalizing the 1.0 version and has listed proposed changes in an email conversation. These changes include using Protobufs instead of open-coded structures, adding length prefixes for key exchange and packets, supporting multiple in-flight HTLC negotiations, and allowing initiators to abort the HTLC process. Version bits are suggested to be exchanged after key setup for compulsory and optional features. Wire protocol crypto recommendations include AES/HMAC-SHA256 or Chacha20/Poly1305, and a separate encoding stream for packet lengths. Other topics mentioned include shachain vs elkrem, anchor tx renegotiation, R value vs keypair, and multi-sig transactions. Rusty acknowledges the possibility of missed changes and welcomes input from others.