When creating or taking an offer the user gets the choice to fund the
trade from an external wallet for potentially better privacy (avoid
coin merge if inputs from ext. wallet are kept separated). From
feedback it seems that most users are not using that option and then
they need to do that extra click on the "Fund from internal Bisq
wallet" button.
We offer a way to avoid that extra step if the user chooses
to use the internal wallet. We show at the first time a popup
with background info why funding from an external wallet could
improve privacy and if the user prefers to not use that to give them
an option to skip that step in future. In the settings we could add
a toggle to re-enable it again.
The review screen can be skipped if user chooses this feature,
leading to data entry > confirm rather than
data entry > fund > review > confirm.
This is useful in cases where a user did not receive the ticket
closure message:
The user messages the arbitrator asking for clarification.
Arbitrator re-opens the ticket and re-sends the closing message.
Previously the dispute message would only be sent once the DPT had
finished propagation. To a user it would appear as if nothing
happened and they would attempt to initiate the process again.
That would cause the DPT logic to fail (we already have an
open timer etc..) and the logic failing would result in no
happy path therefore no Dispute message being sent.
Testing confirmed there is no requirement for the dispute to be
chained on the successful propagation of the DPT to nodes.
Both the DPT and the dispute can be attempted again by the user
if necessary. Rebroadcasting an already published DPT causes
no harm. Re-sending the dispute message also causes no harm
as there is logic to detect if it already exists and handle it
gracefully.
Do not create a new observableArrayList in filterPaymentAccounts.
The reason why the wrong account gets selected is not completely clear to me. The selection handler gets called when the combobox gets filled and that overwrites the selected account from the data. It seems that the new observableArrayList in filterPaymentAccounts triggered that un-expected behaviour.
