In the current peerswap protocol, the swap amount must be determined before the opening transaction is created. This is an issue because when the opening transaction confirms, the channel balance may have shifted such that the claim invoice can not be paid (or such that the pre-determined swap amount is not favorable anymore).
This can be mitigated by giving the taker multiple claim invoices with different amounts, each corresponding to an additional claim_by_invoice spending path in the opening transaction. In contrast to the current protocol, the taker is generally not allowed to claim the full opening transaction amount. Instead, the difference between claim invoice amount and opening transaction amount goes back to the taker. We call this flexible amount swaps.
In Bitcoin, flexible amount swaps can be achieved today by having the maker pre-sign transactions as follows: First, spending the opening transaction output for a claim_by_invoice path does not only require the preimage and the taker's signature but also the maker's signature. Second, when creating the opening transaction, the maker signs transactions spending the opening transaction output for every possible swap amount and sending the change back to itself. The taker must make sure to receive and safely store these signatures before paying any invoice. This solution is doable, but it increases the on-chain size of any swap attempt and would require a significant change to the protocol.
If Bitcoin adopted simple covenants of the OP_CTV or SIGHASH_ANYPREVOUT type, flexible amount swaps would be simpler than pre-signed transactions. The claim_by_invoice path of the opening transaction output would be set up such that it can only be spent by a transaction that provides the preimage pays the invoice amount to the taker and change to the maker (no signature needed).
Liquid tapscript has powerful covenants already, which should allow implementing flexible value swaps with by adding OP_INSPECTOUTPUTASSET, OP_INSPECTOUTPUTVALUE, OP_INSPECTOUTPUTSCRIPTPUBKEY and OP_INSPECTOUTPUTNONCE to the claim_by_invoice path such that the maker is guaranteed to receive the change. Additionally, taproot allows hiding unexecuted branches which means that there is no increased on-chain size when using flexible amount swaps.
In the current peerswap protocol, the swap amount must be determined before the opening transaction is created. This is an issue because when the opening transaction confirms, the channel balance may have shifted such that the claim invoice can not be paid (or such that the pre-determined swap amount is not favorable anymore).
This can be mitigated by giving the taker multiple claim invoices with different amounts, each corresponding to an additional
claim_by_invoicespending path in the opening transaction. In contrast to the current protocol, the taker is generally not allowed to claim the full opening transaction amount. Instead, the difference between claim invoice amount and opening transaction amount goes back to the taker. We call this flexible amount swaps.In Bitcoin, flexible amount swaps can be achieved today by having the maker pre-sign transactions as follows: First, spending the opening transaction output for a
claim_by_invoicepath does not only require the preimage and the taker's signature but also the maker's signature. Second, when creating the opening transaction, the maker signs transactions spending the opening transaction output for every possible swap amount and sending the change back to itself. The taker must make sure to receive and safely store these signatures before paying any invoice. This solution is doable, but it increases the on-chain size of any swap attempt and would require a significant change to the protocol.If Bitcoin adopted simple covenants of the
OP_CTVorSIGHASH_ANYPREVOUTtype, flexible amount swaps would be simpler than pre-signed transactions. Theclaim_by_invoicepath of the opening transaction output would be set up such that it can only be spent by a transaction that provides the preimage pays the invoice amount to the taker and change to the maker (no signature needed).Liquid tapscript has powerful covenants already, which should allow implementing flexible value swaps with by adding
OP_INSPECTOUTPUTASSET,OP_INSPECTOUTPUTVALUE,OP_INSPECTOUTPUTSCRIPTPUBKEYandOP_INSPECTOUTPUTNONCEto theclaim_by_invoicepath such that the maker is guaranteed to receive the change. Additionally, taproot allows hiding unexecuted branches which means that there is no increased on-chain size when using flexible amount swaps.