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

[chimp1984]

@oscarguindzberg 
Thanks a lot for that excellent proposal!

May I throw in a few considerations/ideas/remarks?

## Regarding hardfork:
I think we should only consider a hardfork if we are sure that there is no feasible alternative. A hardfork would require that existing offers are removed and created newly which is a usability penalty and causes loss of maker fee and tx fee. The lost maker fee could be reimbursed but that causes quite a bit of administrative overhead and again is a usability penalty. If users update when they have an open trade it would lead to failed trades. With the trade protocol v2 hard fork we have learned that telling people to not update in such cases is not sufficient as most do not read warnings....It was quite a support mess as a result to deal with all those failed trades.

I would like to sketch out quickly the option for a non-hard fork solution:
We keep the existing wallet methods and use if for non-segwit trades. For segwit trades we use the new methods. A flag indicates which method to be used.
The maker fee tx and taker fee tx can be used to convert legacy address to segwit or the other way round. So we are not dependent on the way ho the user has funded his wallet.

A user who has updated will create new offers with a BECH 32 address. Such offers get an extra data field to mark them and a taker who requests to take the offer has to send a flag to signal that he has segwit support, otherwise he will get a reject message from the maker. If we roll out early enough the flag in the offer, we can detect that also in the offerbook so an not-updated user sees such offers as deactivated (with a popup to tell the user to update), avoiding wait time for the response of the maker. Only users who have not updated for longer time would get the reject message. We have even the version number as part of the offer ID so we could even use that to detect if the offer was created after segwit activation....
If an updated users wants to take an offer from an not-updated user he can still do that and the old wallet methods are used (legacy addresses). 
If an updated user has an open trade which was started before the update, they can still continue using the old wallet methods.

Once most users have updated, most offers will be segwit enabled and thus there is more pressure on not-updated users. Additionally we could support an offer-renewal method to make it easier for users to switch their existing offers to segwit. The maker fee and tx fee would still be lost, but I assume some users would at least not care too much for smaller offers (fiat). 

As said we can support the transition with early shipping of options which will help us at segwit activation time. 
I have not spent much time to think about all so I might miss some critical problems, but I have the feeling it is less of a pain overall to support both address types rather to enforce a hard fork with all negative consequences. The 2 hard forks Bisq had in the past cause each time a big disruption and loss of trade volume for several months.

## Tools for dealing with backward compatibility:
We have several "tools" to deal with backward compatibility and its a quite complex field. I will list here a few I remember but there might be more...
- Activation date: Use a defined date/time to activate certain behaviour. Roll it out earlier and make sure most users have updated to switch to the new behaviour at activation time.
- Filter: A core dev can publish P2P network data which triggers some actions like preventing trade if the user has not updated to a certain version. If needed we can add new fields there.
- Capabilities: Peers exchange at certain P2P network messages their capabilities. As implementation is not guaranteeing to have exchange the capabilities, this feature might be of limited usage in the current state.
- Trade messages: At take offer time trade messages could be used to detect if the peer has an updated version (e.g. if a certain field in the PB object is set or not).

## Alternatives/BitcoinJ future
I have not followed BitcoinJ but a year back it seemed its a "dead horse" and we should be careful to invest too much to stick with it. The past investigations for alternatives ended negative but I think it might be useful to make an update for that investigation for alternatives. Also as Bitcoin Core has deactivated Bloom filters by default we are even more locked up with our federated Bitcoin Core nodes which makes the whole wallet infrastructure much more a "federated server model" as it was intended initially. I am wondering if a federated Electrum server model would be a feasible alternative? But I am aware that this is another huge multi-month project. So nothing we should take lightly and we have to consider the benefits/costs specially with out budget constraints now. How difficult and risky it would be to migrate the BSQ wallet would be another hard challenge. 

-- 
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-633341917
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200524/74f44c5e/attachment-0001.html>