Redeem transaction from async payment should always have 1 input

[louisinger]

The current async payment coin selection works like the onchain one: merge several VTXOs into one tx (the redeem transaction).

However in case someone tries to double-spend one of the VTXO input by broadcasting the unilateral exit branch, the ASP has to put onchain the other inputs in order to broadcast the redeem transaction.
It means the ASP has to pay high onchain fees while trying to defend himself from malicious behaviour.
Having 1 redeem transaction for each VTXO spent should fix this problem and lower the cost for the ASP.

we need to rework the async payment coin selection process:

Today

Alice has 2 VTXOs ; v1 = 0,5 BTC ; v2 = 0,6 BTC
Alice ---async pay 1 BTC---> Bob

redeem tx = v1, v2 --> v3 to Bob (1 BTC), v4 to Alice (0,1 BTC)

at the end of the async payment Bob owns v3 and alice owns v4 (the change)

Expected

Alice has 2 VTXOs ; v1 = 0,5 BTC ; v2 = 0,6 BTC
Alice ---async pay 1 BTC---> Bob

first redeem tx = v1 --> v3 to Bob (0,5 BTC)
second redeem tx = v2 --> v4 to Bob (0,5 BTC) and v5 to Alice (0,1 BTC)

at the end of the async payment Bob owns v3 and v4 and alice owns v5 (the change)