[bisq-network/proposals] Segwit support plan (#226)

[chimp1984]

@oscarguindzberg 
After more though about the Segwit implementation roadmap I would suggest following handling of legacy/segwit mixed cases.

Offers:
If offer was created pre segwit release the reserved funds sit on a legacy address.
If offer was created post segwit release the reserved funds sit on a segwit address.
I don't see any problems here.

Open trades when one user has updated and the other not:
The Multisig and delayed payout tx are created pre segwit. Once the payout tx is created they send the funds to the defined legacy payout addresses. If delayed payout gets published it goes to the legacy burningman address.

Trade between not updated and updated users:
Case: Maker has pre segwit verions and taker has post segwit version. 
Taker uses funds from segwit address and create the taker fee tx with reserved funds to a segwit address. Maker had alreayd created maker fee tx and reserved funds are sitting on a legacy address. 
Both create the 2of2 P2SH Multisig and use mixed inputs (maker has legacy utxo, taker has segwit utxo) and send those to the P2SH multisig. The delayed payout tx and later the payout tx is also handled in legacy style, though the taker can receive the funds on a segwit address (we need to check if there is no address validation at makers side which would fail for segwit addresses for old users, is so we need to send funds to legacy address for taker as well).
Case: Maker has post segwit verions and taker has pre segwit version.
Same as above, just swapped roles when it comes to segwit address support. MultiSig is P2SH.

The trade messages at creating the multisig need a new flag for indicating segwit support. If the flag on at user is missing P2SH multisig is used.

Only if both users have updated they can use P2WSH.

I am aware that handling both might be a bit more dev effort but if we dont support that we would run into lot of backward compatibility issues. Specially open trades cannot be handled by a hard fork (see comments above).

For BSQ I do not see any issue as BTC inputs can be either segwit or legacy. By default segwit should be used. BTC change address would also be by default segwit (I think no option for user to change that is required).

PS: Instead using flags for indicating segwit support we could also add a capability. But not sure if the capability is exchanged between the peers before the trade protocol starts. Probably more safe to add a flag.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/226#issuecomment-679464096
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200824/548c9016/attachment.html>