At slow internet connections the current timeout make it impossible to
get the initial data and therefor to use Bisq.
The timeout is containing the request and response as well as the time
it takes to start up the network connection which can also be quite
slow.
In my scenario, it took about 6-10 sec for the connection and the
request is atm nearly 3 MB which takes about 24 sec on a 1 Mbit/s
connection (note that over tor connection is slower so if normal speed
is 3-5 Mbit tors speed can be considerable lower). The response data
depends on the missing data/last update but can be easily 6 MB which
adds about another 48 sec. So one can easily hit the 90 sec. limit.
There is work in development for optimizing the initial data request,
but as that is more complex and not clear when it will be deployed I
recommend that we increase the current timeout to 180 sec. to avoid
that critical issue that users get "locked out".
Based on user feedback, these exchanges are too illiquid and do not
accurately reflect the true price of the market. After research, I found
the user's feedback to be correct and this PR removes both exchanges.
Replace faulty cell update logic, which uses a ChangeListener<Scene>,
added in July 2017 (#73f21399) to keep the price column in the offer
book table up to date, as it appears to occasionally result in blank
cells. Also it seems only the prices, not the volumes, were being kept
in sync with the market price feed.
Make the price and volume cells stateless and keep them in sync with the
market feed by adding it as a dependency of each OfferBookListItem
Observable generated by the cell value factory, instead of directly
attaching listeners to it. In this way, TableCell::updateItem will be
called by the framework whenever the price/volume needs updating.
(This does have the disadvantage that if the price feed is unavailable,
causing Offer::getPrice to return null, then the cells will reflect that
immediately instead of showing any old, stale values, but that is
necessary for the UI to behave consistently anyway.)
The default bitcoind / bitcoin-cli rpcport option has been changed
from 18443 to 19443, to help avoid rpcport conflicts between apitest's
bitcoind instances and other bitcoind and/or bitcion-qt instances
which are probably using the bitcoin-core default (regtest) rpcport
18443.
However, this commit cannot include other changes for avoiding bind
address:port conflicts between apitest bitcoind instances and other
regtest bitcoin-core instances because bitcoinj's bind port is hardcoded
in RegTestParams.java as 18444.
In order to avoid bitcoin-core regtest mode bind address conflicts,
you must start or restart your bitcoind or bitcoin-qt instance with a
non-default bind port argument, e.g.
bitcoin-qt -regtest -port=20444
I do not agree that not allowing Throwable in a catch makes the code
better. Unknown exceptions can be easier found if there is an error log
at the code where it occurred.
I would prefer if there is some flexibility like it is the case with the
IDEA code analysis, where one can edit and customize the suggestions.
Ignore annotations would help.
There have been several long delays as well a wrong order of the
shutdown process (wallet got shutdown after network shutdown.
Shutdown is now pretty fast, but depends on open offers and connections.
Previous version had several performance issues:
- We kept tradeStatistics in a lookup map in memory (about 40 MB)
- We built up the StatefulAssets even if it was not used/needed.
Building the StatefulAssets was an expensive call.
- AssetTradeActivityCheck was only used for printing out statistics and
called on startup causing performance cost.
Optimized version:
- We call build the StatefulAssets only on demand (user activates
view). Method call takes now 22 ms.
- We create a optimized lookup map with a tuple of the data we need
and keep it as local variable.
- We removed AssetTradeActivityCheck.
Thanks to the profiling reporting from:
https://github.com/bisq-network/proposals/issues/199
This commit adds a -fallbackfee=0.0002 parameter to the start 'bitcoind'
command to keep bitcoin-core v0.20.1 working as v0.19.1 does -- with the
'fallbackfee' enabled.
Bitcoin v0.20.0 contains a fix for inconsistent behaviour related
to this fallbackfee configuration. Prior to v0.20, fallbackfee
was disabled (0) by default for the mainnet chain, but enabled
(0.0002) for the testnet and regtest chains.
A test case with bitcoin-core v0.20.1 was breaking on
the bitcoin-cli 'sendtoaddress' command, which was returning an
error message instead of a tx-id:
error code: -4
error message:
Fee estimation failed. Fallbackfee is disabled. \
Wait a few blocks or enable -fallbackfee.
Bitcoin-core v0.20.0 release notes contain info about this change:
https://bitcoin.org/en/release/v0.20.0#updated-rpcs-1
The Bitcoin-core PR is https://github.com/bitcoin/bitcoin/pull/16524
Converted sound file to a 10 second mono noise with lower volume.
Tested with max possible sound volume and it was hardly audible.
Tested a binary built with it and I could not observe the network
degradation issues.
File is not 800 kb instead of 42 MB.
As part of the Tor V3 upgrade, this PR adds 2 new V3 seednodes, and will
start the process to retire older V2 seednodes.
The V2 seednodes will continue operating for 2-3 months during the
retirement phase-out period, after which time we can filter it out from
the network for clients who have not upgraded if necessary.
Pending merge of #4315 and rough consensus to proceed with migration plan in bisq-network/projects#35
wizpriceje6q5tdrxkyiazsgu7irquiqjy2dptezqhrtu7l2qelqktid (@wiz)
emzypricpidesmyqg2hc6dkwitqzaxrqnpkdg3ae2wef5znncu2ambqd (@Emzy)
devinpndvdwll4wiqcyq5e7itezmarg7rzicrvf6brzkwxdm374kmmyd (@devinbileck)
aprcndeiwdrkbf4fq7iozxbd27dl72oeo76n7zmjwdi4z34agdrnheyd (@mrosseel)
ro7nv73awqs3ga2qtqeqawrjpbxwarsazznszvr6whv7tes5ehffopid (@alexej996)
