Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use just a single BOLT-level message code #13

Open
ZmnSCPxj-jr opened this issue Oct 21, 2022 · 0 comments
Open

Use just a single BOLT-level message code #13

ZmnSCPxj-jr opened this issue Oct 21, 2022 · 0 comments

Comments

@ZmnSCPxj-jr
Copy link

ZmnSCPxj-jr commented Oct 21, 2022

Instead of having a half dozen message codes, just use a single BOLT-level code. Inside the payload of the message, the first two bytes are the big-endian peerswap-level code.

i.e. instead of swap_in_request= 42069, swap_in_agreement = 42073, etc. just use a single peerswap_message = 42069. Then define swap_in_request = 0, swap_in_agreement = 1 etc. but in the peerswap-level message code that is in the first 2 bytes of the BOLT-level message payload.

This is mostly just to "be nice" to the rest of the ecosystem, and should probably be encouraged as a rule for all extensions of BOLT spec, not just peerswap. This makes it more likely that two different extensions will not inadvertently overlap, and if two extensions do overlap, it would be trivial for one or both of them to switch just one message code. In the future, this also makes it easy to add new message types as the protocol evolves (we would have a 16-bit codespace to ourselves, instead of sharing a common 16-bit codespace with the formal BOLTs and with other extensions); there is no need to coordinate with developers of other extensions over the BOLT spec to allocate more new message codes.

On the other hand this is a pretty big break in the protocol tho, fine if you want to close this issue instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant