If we do not get any BTC from a mediated payout tx we do not know about
the confirmation state so it would stay always in the unconfirmed state.
To avoid that confusion we prefer to hide the icon. This is a known
issue from BitcoinJ but we have not found a solution for that yet.
If we do not get any BTC from a mediated payout tx we do not know about
the confirmation state so it would stay always in the unconfirmed state.
To avoid that confusion we prefer to hide the icon. This is a known
issue from BitcoinJ but we have not found a solution for that yet.
With v1.2 we use 2of2 multisig for deposit tx. This commit changes the
manual payout window to reflect that.
- Remove unused code from legacy arbitration
- Fix comments
With v1.2 we use 2of2 multisig for deposit tx. This commit changes the
manual payout window to reflect that.
- Remove unused code from legacy arbitration
- Fix comments
Prevent the 'arrow' of a message bubble from being sporadically anchored
to the wrong side - appearing on the left instead of the right hand side
of the bubble. This is due to the same ListCell object being reused by
JavaFX for different bubbles as the user scrolls up and down the chat
pane, which requires that the anchors of each arrow be properly cleared
between ListCell.updateItem(..) calls.
To this end, move the block of AnchorPane.clearConstraints(..) calls to
the beginning of the updateItem(..) method, as the apparent assumption
that 'updateItem(item, empty = true)' will always be called to clear the
given ListCell before reusing it as a new bubble turns out to be wrong.
This prevents a scammer to use publicly known account details
(without being in control of the account) as a seller to get
signed by a buyer. The money received in the seller account might
not be detected by the legitimate owner and/or the money not sent back.
30 days later the scammer could use this signed account as seed to peer sign other stolen accounts.
Remove the type parameter from Popup<T>, as it appears to have never
been used or set anywhere in the code. (This mainly involves replacing a
lot of "new Popup<>" occurrences.)
* Implement installation path check on Windows
Prior to starting the installation, check if the install location
contains special characters and if so use a different default install
location as well as display a prompt to the user providing additional
details.
This is in response to #3605, for which a proper solution has yet to be
found.
* Ensure the destination location dialog is always shown
This resolves#552
* Show the Welcome dialog
Rather then potentially being greeted with the newly implemented
prompt on the destination location dialog if they have special
characters in their install path, greet the user with the Welcome
dialog when they initially launch the installer.
* Reorder/group setup items logically
Rather then potentially being greeted with the newly implemented
prompt on the destination location dialog if they have special
characters in their install path, greet the user with the Welcome
dialog when they initially launch the installer.