c70b12f For timelock addrs use new pubkey foreach locktime (chris-belcher)
3dc8d86 Fix importprivkey on fidelity bond wallets (chris-belcher)
bbd3d1b Print privacy warning when showing timelocked addr (chris-belcher)
1ea62a7 Fix bug with timelocked addrs in receive payjoin (chris-belcher)
4868343 Fix showutxos wallettool method for fidelity bonds (chris-belcher)
81bade7 Update ygrunner to use fidelity bonds (Adam Gibson)
a3b775b Increase default fee by 4x (chris-belcher)
e970a01 Create release notes section for fidelity bonds (chris-belcher)
6cf4162 Add fidelity bond protocol tests (chris-belcher)
199b571 Consider fidelity bonds when choosing makers (chris-belcher)
97b8b3b Show fidelity bonds on orderbook watch html page (chris-belcher)
7a50c76 Announce yieldgenerator's fidelity bond (chris-belcher)
6b6fc4a Handle fidelity bonds in client-server protocol (chris-belcher)
662f097 Write and update fidelity bond docs (chris-belcher)
eb0a738 Add interest rate option to config file (chris-belcher)
d4b3f70 Enable creation of fidelity bond wallets on cli (chris-belcher)
b9eab6e Increase max locktime of fidelity bond wallets (chris-belcher)
a3b3cd4 Make fidelity bond wallets be native segwit (chris-belcher)
9a372fd Add getblockhash RPC method (chris-belcher)
e6c0847 Add calculate fidelity bond value function + tests (chris-belcher)
Tree-SHA512: d2ffde2b752f66c5fd0d3100670e69d0357fc27bd3c50f9438cef9b261a17b0554c14ee56567ca1980937f889ac8be75ecc96517b1a77c7370ed33f8b5650cc7
This commit changes how timelocked addresses are created from the seed and bip32 tree.
A good thing to do would be to have each locktime (e.g. 1st jan 2020,
1st feb 2020, 1st march 2020, etc) actually use a different pubkey from
the HD tree (i.e. ("m/84'/1'/0'/2/0" + 1st jan 2020) ("m/84'/1'/0'/2/1" + 1st feb 2020), etc).
This now means that the sync code doesnt need to know what keys have been associated with
a fidelity bond to scan for the next one. Previously when a user funded a single timelocked
address, the wallet will generate _another_ pubkey and import _another_ ~960 addresses, so
funding one address would actually mean watching and generating ~1920 addresses not ~960.
This should help with the problem found by some people that fidelity bond wallets are slower
to sync. Other optimizations are possible but the structure of fidelity bond wallets will
probably be fixed for decades, so this change is worth doing now.
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.