This is in the best interests of takers because it will incentivize
more and greater fidelity bond usage. Takers are still asked what they
want their maximum fee to be, this commit only changes the randomly
generated suggestion.
Add two new pages for the orderbook watch html server. One displays
each fidelity bond individually, the other shows calculations about
how expensive a successful sybil attack would be against the current
fidelity bonds in the orderbook.
If a yield generator is run with a fidelity bond wallet then the
most-valuable bond will be found and announced.
The announcement includes a proof of a UTXO and its locktime. Also a
proof that the maker's IRC nickname controls the UTXO.
There is also an intermediate signature called the certificate
signature which can later be used when holding fidelity bond UTXOs in
cold storage without the protocol needing to change. Right now this
feature is unused so certificates are generated dynamically on each
request. The certificates have an expiry block height, which is defined
as the number of 2016-block retargeting periods since the genesis
block, so to check if the expiry was passed the taker will check
`current_block_height > cert_expiry*2016`.
Parse incoming and announce outgoing fidelity bond messages
Fidelity bond proof messages will be checked and added to the internal
database just like offers. Such messages are not announced in public
but only directly to takers who ask for them, this is because the
signature proofs must commmit to the maker's and taker's IRC nicknames
in order to avoid replay attacks.
The default minfeerate in payjoin is 1.1 sat/vbyte,
however the randomization of 20% for all transactions
created with direct_send means that the previous value
of 1.3 could fall to below 1.1 probabilistically, it
is therefore bumped to a value that never falls below
1.1 after randomization.
912b4d5140 add missing whitespace to log (unofficial bisq contributor)
Pull request description:
Beforehand, nick string was appended with `totalin=`
ACKs for top commit:
kristapsk:
utACK 912b4d5140
Tree-SHA512: e93e7d6420584ba58f7f789fe866bc1d448e7c9205c9673eff3aa2be2a3e96cd4c2dd183a76480301ca16ff03e85d2c2bce3c1682a431c2fc7a51d9b06fc9cdf
f361c98dba Better handling of non-standard tx'es, less extra output for csv and other small improvements (Kristaps Kaupe)
Pull request description:
* Better handle non-standard (in JM context) transactions and try normal output also for "unknown". Fixes#839.
* Fully handles non-standard internal transactions, where all outputs go to JM wallet (previously didn't work if there was more than two outputs to our wallet).
* Rename "unknown type" to "unknown", for better alignment.
* Don't output summary and line about increasing verbosity for CSV, it makes it more valid CSV (only extra output now is "User data location: ..." line, but that's easy to filter out, as it is the first line).
* Output absolute value for "amount/btc" column. Improves alignment, and sign is already present in next "balance-change/btc" column.
Example below.
Testnet wallet with some manually crafted transactions (used Electrum to create them, all inputs and outputs were from / to same wallet), before:
```
tx# timestamp type amount/btc balance-change/btc balance/btc coinjoin-n total-fees utxo-count mixdepth-from mixdepth-to
" 0" "2021-06-04 20:07" "deposit " "0.00500000" "+0.00500000" "0.00500000" " #" "N/A " " 1" " #" " 0"
our utxos: 1 in, 3 out
this is wrong TODO handle non-coinjoin internal
"N= 1" "2021-06-04 21:41" "cj batch " "0.00100000" "-0.00000200" "0.00499800" "1.0" "N/A " " 4" " 0" " 0"
2021-06-05 07:58 best block is 000000000000003806d395c49ffadda52a07f2583e8e978f2a01b0d4f7e5e009
total profit = -0.00000200 BTC
continuously compounded equivalent annual interest rate = -29.57414924985335 %
(as if yield generator was a bank account)
BUG ERROR: wallet balance (0.00499600) does not match balance from history (0.00499800)
```
After:
```
tx# timestamp type amount/btc balance-change/btc balance/btc coinjoin-n total-fees utxo-count mixdepth-from mixdepth-to
" 0" "2021-06-04 20:07" "deposit " "0.00500000" "+0.00500000" "0.00500000" " #" "N/A " " 1" " #" " 0"
" 1" "2021-06-04 20:16" "internal " "0.00499800" "-0.00000200" "0.00499800" " 2" "N/A " " 3" " 0" " 0"
" 2" "2021-06-04 21:41" "internal " "0.00499400" "-0.00000200" "0.00499600" " 1" "N/A " " 4" " 0" " 0"
2021-06-05 08:38 best block is 0000000000000017ded6660eccf9fe57a05e9c5e397fd1c4df1e9e8b09e2dda1
total profit = 0.00000000 BTC
```
Top commit has no ACKs.
Tree-SHA512: db28c212fd24943178ae8540c3e1c48eebecc5a40fda278f08e6b79e3b23f7aec891c6e5387dff6476818799a1a5614cef5d8425a55704e8f9d76929c3f91ad1
Before this commit, if the sender specified
the additionalfeeoutputindex as 0, the receiver
incorrectly treated this as meaning it could not
decrement the change value at all (treating zero
as false in Python `if`), meaning that the feerate
was reduced more than intended, or in extreme
cases, the payjoin fell back incorrectly because
the feerate fell below the specified minfeerate.
After this commit, the additionalfeeoutputindex
value specified by the sender is correctly used
by the receiver in all cases.
Fixes#889.
Prior to this commit, it was possible for the
yg-privacyenhanced.py script to go into an infinite
loop of attempting to halve the txfee setting, in case
the user selected (a) reloffer, (b) an absurdly low
minsize like 1 sat, and (c) a txfee of zero.
This occurred partially due to the randomization of minsizes
included in the yg-pe algorithm, which could lead to a
pathological zero value for minsize.
After this commit the minsize is automatically bumped to
the `DUST_THRESHOLD` value if it falls below it, preventing
the possibility of a nonsensical value.
Additionally, the loop which halves the txfee is no longer
allowed to continue beyond 20 iterations, as an extra sanity
check.
4599bd75a8 Fix autofreeze warning on Qt (Adam Gibson)
Pull request description:
The autofreeze utxo callback takes a `utxo` as argument, not a utxo string, so convert here in `joinmarket-qt.py`, just as in `WalletService.default_autofreeze_callback`.
ACKs for top commit:
kristapsk:
ACK 4599bd75a8, tested before / after, merging.
Tree-SHA512: ddb13cc98bd6a116636a8e863f93696537402be71de17e169152537425b28cdb062288b442489e03f02fbcd76134269b33e49495078fff7c206f9c12543b91c2
The above commit added custom change addresses, however it
introduced a bug for multiple transaction schedules on the same
Taker object, as happens with tumbler for example: a new
change address would not be created for new transactions.
This commit fixes that and ensures a new change address is always
chosen when a custom change address was not specified for the
Taker object instantiation (which is always the case for tumbler).
chris-belcher
Adam Gibson
Kristaps Kaupe
undeath
Lobbelt
unofficial bisq contributor