There was an issue where webbrowser.open would invoke a program like
kde-open5 that loaded the systems libQt5DBus, which was not satisfied
with the AppImage's libdbus. To fix this we fork the process, unset
LD_LIBRARY_PATH and then open the URL.
fixes#5425
-----
taken from Electron-Cash/Electron-Cash@00939aafd1
ran "appimagelint" and apparently icon file needs to be a square
(could have just created another copy, but I guess a square icon
might make sense in other cases too)
Triggering needs two consecutive scripthash status changes
in very quick succession. Client gets notification from server,
but then response to "blockchain.scripthash.get_history" will already contain
the changed-again history that has a different status.
20190627T101547.902638Z | INFO | synchronizer.[default_wallet] | receiving history mwXtx49BCGAiy4tU1r7MBX5VVLWSdtasCL 1
20190627T101547.903262Z | INFO | synchronizer.[default_wallet] | error: status mismatch: mwXtx49BCGAiy4tU1r7MBX5VVLWSdtasCL
jsondb takes a copy of the whole self.receiving_addresses
good for avoiding race conditions but horrible for performance...
this significantly speeds up at least
- synchronize_sequence, and
- is_beyond_limit (used by Qt AddressList)
see bitcoin/bitcoin@217208a36d
-----
A lot of time was wasted on this... over the years actually...
Some notes and rant here, for future reference.
During the initial effort to try to make binaries reproducible,
out of the three windows binaries being distributed (standalone, portable, setup),
only the first two were successfully made deterministic.
Later, we started to use Docker-based builds. At that point ThomasV and I
could reproducibly build the same setup/nsis exe but Travis kept building a different one.
Recently I have noticed that if I do two subsequent builds of the setup exe on
the same machine, adding a new file in contrib/build-wine/ between the builds,
then I get different binaries. Playing around with this a bit, it seems:
- other files that are in the same folder as contrib/build-wine/electrum.nsi affect the binary
- only files that are in exactly the same folder matter (not recursively)
- only filenames matter (not permission, owner, timestamps, or file contents)
To see the difference in the binaries, use vbindiff, and disable the compression done
by nsis (SetCompress off).
There is a ~48 byte diff near the very beginning of the "Uninstaller" section.
I am only guessing it is the uninstaller section based on the sizes of the sections
printed by nsis during the build.
I have downloaded the binary built by Travis, and the diff is consistent with this
(i.e. it's the same kind of diff that manifests if I change the filename of one of
the supposedly unrelated files).
Commenting out the "WriteUninstaller" line in .nsi fixes the issue. i.e. if no
uninstaller is created then the binary becomes deterministic.
Commenting out the "!define MUI_ICON" line in .nsi also fixes the issue.
At this point I remembered the above referenced commit by bluematt; which I had
thought we had already followed up on...
Replacing the .ico file fixes the issue.
Note that it's not actually clear what the exact requirements for the .ico file are.
Removing any of the layers in the image seems to introduce non-determinicity.
The new .ico file has layers with resolutions and properties the bitcoin.ico file has.
I guess NSIS must have strict requirements for the icon size, and if a given size icon is missing
it might be creating it itself?? And during the downscaling it uses a non-deterministic
algorithm that initialises some RNG from the directory listing (bauerj's guess somewhat adapted :D).
Just crazy.
Calculate the effective value of buckets, and filter <0 out.
Note that the filtering is done on the buckets, not per-coin.
This should better preserve the user's privacy in certain cases.
When the user "sends Max", as before, all UTXOs are selected,
even if they are not economical to spend.
see #5433
There are now two internal strategies to bump the fee of a txn.
bump fee method 1: keep all inputs, keep all not is_mine outputs,
allow adding new inputs
bump fee method 2: keep all inputs, no new inputs are added,
allow decreasing and removing outputs (change is decreased first)
Method 2 is less "safe" as it might end up decreasing e.g. a payment to a merchant;
but e.g. if the user has sent "Max" previously, this is the only way to RBF.
We try method 1 first, and fail-over to method 2.
Previous versions always used method 2.
fixes#3652
The old change output was given to coinchooser
as part of possible UTXOs to use.
(Though the coinchooser was really unlikely to select it, as by
definition that UTXO is unconfirmed)
