f7180b8 Emphasize that ygen uses only single UTXO as fbond (chris-belcher)
Tree-SHA512: b6aeee067273f57688d71c87059f5d53492769f9a69c98908421b6abba88d824e8366df1916e29615e7416de0b79e1c8949167ae8ac5033928c1968ad4917277
At least two people have been burned by creating two transactions
sending bitcoins to two timelocked addresses, and then finding that
yield-generator announces only one of them.
This commit expands the section talking about how only one UTXO will
be used. It also edits the text to refer to yield-generator's fidelity
bonds only in the singular, as previously they were referred to in
the plural (i.e. "fidelity bonds"), which possibly added to user's
confusion.
Fixes#976. Joinmarket will allow, but warn, when
non-zero change values (which are not included in
the transaction) result from sweeps (due to the
impossibility of knowing the exact value in advance).
However, prior to this commit, if that estimation
inaccuracy resulted in a negative change value that
was to be ignored, there was a crash due to the fact
that `jmbitcoin.amount_to_str` does not allow negative
values. Hence we instead print the number in the warning
without going through this formatting function.
Adds tests case for negative sweep change.
Before this commit, attempting to spend in a taker-
side Joinmarket coinjoin, a utxo which is of the
tiemelock type (after its timelock expired), had
a potential to crash, because it would be selected
for the generation of a PoDLE but this cannot be
supported (even with taker-side code changes, the
maker could not reconstruct it).
After this commit, any non-standard wallet-type
scriptPubKey is filtered out of being a candidate
for PoDLE generation.
Also a trivial variable name typo is fixed (too-old).
Also the test framework `DummyWallet` now inherits
from `LegacyWallet` because its utxos are of that
type; a future commit should update to `SegwitWallet`.
Also add tests cases for no custom-script PoDLEs.
Before this commit, while sending from mixdepth
zero in a sweep, where 1 or more p2wsh timelock
type outputs (now past their timelock), were present,
was working correctly, non-sweep sends in the same
circumstances were failing due to a key error.
This is now fixed.
ce08a0c Fix year 2038 problem in ob-watcher /fidelitybonds (chris-belcher)
58d3e59 Fix Export Orders page on ob-watcher (chris-belcher)
Tree-SHA512: 77db761eb325d8bda363015414aa8b8c947f4c809be8ce06f730fbe7bff17c92c66ac31d54d820b48df8ff52efb6a324a6c0640bd155dfbb3426102526fa07ab
1bf9f85164 Update link to irc logs to https (Luke)
Pull request description:
Since few months the website offers HTTPS
ACKs for top commit:
kristapsk:
ACK 1bf9f85164. Trivial, tested, so merging.
Tree-SHA512: aa8702e7f41d79c1b6d9383dbed2cd0d47de17aabb3ecb6ef2b90af5b1d80115a6f2d8eba6dd90df1210dfe7aa598e35af4d88d1ccc4e7c6158b24198055391e
a090293 Emphasize the sybil protection gained by takers (chris-belcher)
cea80e2 Suggest use of coin control in fidelity-bond.md (chris-belcher)
87f36c2 Fix error in simplified equation in fidelity-bond (chris-belcher)
Tree-SHA512: 1802be8e3879d2ba8f3da7a0baa97f5209cec4d5726c96382ac5f65af026df01b340f54584be3c051a7699d2e0eb2f785e8ecfd5149d75da626cc88cf065b03d
f9ea973be9 fix overflow error on 32bit ARM (openoms)
Pull request description:
Fixes#953
Tested on a 32bit Odroid running Armbian:
`Linux odroidxu4 4.14.222-odroidxu4 #2 SMP PREEMPT armv7l GNU/Linux`
based on #857 as suggested in https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/953#issuecomment-890519047
ACKs for top commit:
kristapsk:
re-ACK f9ea973be9
Tree-SHA512: a8c1e46c7350b8871f88a92b111b1d77c2ac817d6357da852c055849206bd53bbbf8b90000a88fc8198e85a3b7eaab48fc5970c80f5072d10a785632f72f704e
Fixes#899.
Before this commit, the dust threshold used to filter
orders in `jmdaemon.OrderbookWatch` was different than
that used in `jmclient`. This is corrected by setting
the threshold in client config and passing this as a
parameter in the `JMInit` command (since the daemon
does not know the client config).
Previous to this commit, the Qt app had a monitoring
loop that triggered every 5 seconds, recalculating the
wallet view; this turns out to be expensive enough to
create a CPU bound that is noticeable to the user, for
any reasonably large wallet.
After this commit, the view is only updated when a new
transaction comes into the wallet.