This change fixes an issue whereby dust change outputs are
inadvertently created during the trading process, unbenownst to the
user. The dust outputs cause the Bitcoin node to reject the
transaction and the trade then becomes stuck.
The solution taken here is to detect a dust TXO during the trade
process and remove it from the transaction before broadcasting.
Related to #4039
Provide UserThreadMappedPersistableList subclass for persistable lists
which need to implement UserThreadMappedPersistableEnvelope, instead of
putting the interface on the base class.
Make the (non-storage) classes MeritList and VoteWithProposalTxIdList
keep the original PersistableList superclass, deriving the remaining
subclasses of PersistableList from the new class instead. In this way,
further persistence-related changes are less likely to inadvertently
alter the behaviour of those two consensus-critical classes.
Removing the superfluous PersistableEnvelope interface from the two
classes (via the base class) will be done in a separate PR.
Until now, an error in the offer creation process is only reported
to the logs, the GUI times out after a while and shows a timeout
error and asks the user to report a bug.
Now, the actual error is reported.
Currently bisq desktop does not accept IPv6 addresses in the settings for
custom nodes or via the --btcNodes command line option. The separation of
address and port is handled incorrectly in core / BtcNodes::fromFullAddress.
This results in IPv6 addresses being ignored. Where Tor is enabled for
Bitcoin connections, we need to handle the IPv6 address response
from Tor DNS lookup.
Fixes#3990
Testing showed that the new mechanic for checking a local BTC node's
configuration is unstable. This commit reverts to just checking if the
relevant port is open. The recent refactoring and centralization of
logic is still in place.
Testing showed that the new mechanic for checking a local BTC node's
configuration is unstable. This commit reverts to just checking if the
relevant port is open. The recent refactoring and centralization of
logic is still in place.
This change substitutes use of memory efficient, OS supplied sleep/suspend
inhibitor utilties for the silent audio file player on Linux, merges
OSXStandbyModeDisabler functionality into AvoidStandyModeService, and
removes that class.
This change also stops Bisq from running the audio file on OSX; it is
currently running both caffeinate and the silent audio file, and the avoid
standby mode button in the the OSX settings view is currently toggling
the audio player on and off, but not caffeinate. (The only way to shut
down caffeinate is by shutting down Bisq.)
The OSX avoid standby mode button button has not been hidden so a cached
'do not avoid standby mode' preference does not leave the user stuck without
a caffeinate service the next time they start Bisq. (They can use it to
turn caffeinate on, but it can't be used to turn it off without shutting
down Bisq too.)
The avoid standy mode button is now displayed on Linux because the native
inhibitor can be toggled on and off.
There is no change to the avoid shutdown service on Windows and Unix.
Use excludeFromJsonDataMap to add an optional owner full name property
to Faster Payments (GBP) accounts, without affecting the trade JSON
contract (for backwards compatibility). This is to fix#3976, that some
banks have started checking the recipient name.
Make the name a non-optional field for _new_ accounts, but display the
details for old Faster Payments accounts in exactly the same way as
before, only showing the extra field in the info popup, account and
trade step views when it is present.
Also update the now misleading payment instructions in the buyer popup.
TODO: Update translations (which probably aren't needed anyway).
Make the default toPersistableMessage() method of PersistableEnvelope
simply delegate to Proto.toProtoMessage for speed, so that stores can
explicitly implement (Threaded|UserThreadMapped)PersistableEnvelope if
they actually need concurrency control.
As part of this, make PeerList implement PersistableEnvelope directly
instead of extending PersistableList, as it is non-critical & cloned on
the user thread prior to storage anyway, so doesn't need be thread-safe.
In this way, only PaymentAccountList & small DAO-related stores extend
PersistableList, so they can all be made user-thread-mapped.
After this change, the only concrete store classes not implementing
(Threaded|UserThreadMapped)PersistableEnvelope are:
AccountAgeWitness, BlindVotePayload, ProposalPayload, SignedWitness,
TradeStatistics2, NavigationPath & PeerList
The first five appear to erroneously implement PersistableEnvelope and
can be cleaned up in a separate commit. The last two are non-critical.
(Make NavigationPath.path an immutable list, for slightly better thread
safety anyway - that way it will never be observed half-constructed.)
Since this map is final and every PaymentAccountPayload constructor
initialises it to something nonnull, the @Nullable field annotation is
redundant, so remove it.
Further simplify the code by passing an empty map into the constructor
directly from each subclass constructor, rather than mapping empties to
nulls from each 'proto.getExcludeFromJsonDataMap()' result, then mapping
nulls back to empties in the base constructor. This is safe, since
getExcludeFromJsonDataMap() always returns a nonnull map.
Finally, tidy the code slightly by replacing 'Charset.forName("UTF-8")'
with StandardCharsets.UTF_8 in each PaymentAccountPayload subclass.
Add toProtoMessageSynchronized() default method to PersistableEnvelope,
which performs (blocking) protobuf serialisation in the user thread,
regardless of the calling thread. This should prevent data races like
the ConcurrentModificationException observed in #3752, under the
reasonable assumption that shared persistable objects are only mutated
in the user thread.
Also add a ThreadedPersistableEnvelope sub-interface overriding the
default method above, to let objects which are expensive to serialise
(like DaoStateStore) be selectively serialised in the 'save-file-task-X'
thread as before, but directly synchronised with each mutating op. As
most objects are cheap to serialise, this avoids a noticeable perf drop
without having to track down every mutating method for each store.
In all cases but one, classes implementing ThreadedPersistableEnvelope
are stores like TradeStatistic2Store, with a single ConcurrentHashMap
field. These require no further serialisation, since the map entries are
immutable, so the only mutating operations are map.put(..) calls which
are already synchronised with map reads. (Even if map.values().stream()
sees updates @ different keys happen out-of-order, it should be benign.)
The remaining case is DaoStateStore, which is only ever reset or
modified via a single persist(..) call with a cloned DaoState instance
and hash chain from DaoStateSnapshotService, so there is no aliasing
risk from the various DAO state mutations done in DaoStateService and
elsewhere.
This should fix#3752.
