Open remyers opened 1 year ago
Yes to this! There is already a draft for this change buried somewhere in an old local repo/branch. We already discussed a similar use of tlvs
for better asset abstraction.
This allows to separate the "base" swap protocol from an asset specific protocol as they might diverge depending on the asset.
This is something I want to tackle as soon as we have a somewhat stable implementation.
This specification could be improved by using byte encoding for Lightning messages instead of JSON encoded payloads. This would make the specification more precise, faster to parse and require less space to transmit and store messages. Current Lightning messages use byte encodings for this reason and all Lightning implementations implement codecs for handling byte encodings. Using an encoding format familiar to reviewers of current Lightning messages should also help increase feedback and facilitate eventual adoption.
This is a big change, but should help with the evolution and adoption of PeerSwap.
For example, the
swap_in_request
message as currently described looks like:type
: 42069payload
json encoded:An example of this message described with byte encoding based on the fundamental Lightning types might look something like the following:
type: 42069 (
swap_in_request
)data:
u16
:protocol_version
]u32
:swap_id
]chain_hash
:network
]short_channel_id
:short_channel_id
]u64
:amount
]point
:pubkey
]request_tlvs
:tlvs
]tlv_stream
:request_tlvs
types:
asset_id
)...*byte
:data
]Note:
network
field indicates thechain_hash
of the network used to create on-chain transactions, such as Bitcoinmainnet
orsignet
, but could also indicate a network such as Liquid.The optional
asset_id
contains anynetwork
specific data needed for on-chain transactions.