Prior to this commit, if the call to the bitcoin rpc
gettransaction resulted in an exception other than JsonRpcError,
the code would crash as the variable `res` was uninitialized.
This fixes that by always setting res to None in this case, and
also promotes the logging messages for such errors to warning.
While testing/debugging #105 we found that agora disconnects our taker about 1 minute after joining the pit, just before starting the CJ. Only that IRC server seems to be affected.
transaction from receiver to sender. Also add note about
implicit defence against attack mentioned in BIP79; we only
ever sign the predetermined set of inputs.
If the user manually chooses a bitcoin tx fee, it could end up below the bitcoin network's min relay fee.
This PR get the bitcoin core instance's configured min relay fee and uses it as a floor value (btccore) or uses 1000 as floor otherwise (btc as fallback when RPC call returns no good value and for electrum interface).
Prior to this commit, if at least one sender utxo was larger
than the payment amount, the algorithm used by the receiver
to attempt to find coins to avoid triggering the UIH2 condition
was wrong, resulting in UIH2 being triggered where it was not
necessary, in a reasonable fraction of cases. This fixes the
algorithm to be in line with what was written in the linked gist
(see comment to P2EPMaker.on_tx_received).
The code prior to this commit incorrectly only chose the
no-coins fallback in PayJoin on receiver side if the call
to wallet.get_utxos_by_mixdepth()[mixdepth] resulted in a
raised exception, but of course it returns an empty dict,
so after this commit the self.no_coins_fallback is called in
case an empty dict is returned; note that the prior case
still resulted in the same behaviour of publishing a non-CJ
transaction, but now the info messages/prompts are clear.
Prior to this commit, running joinmarketd as an isolated
process only supported serving the Joinmarket protocol;
attempting PayJoin would result in silent failure as the
receiver would reject the !pubkey message.
After this commit, the joinmarketd daemon serves both
protocols with the PayJoin protocol being served at port+1
- update mktx() to allow optional locktime setting (and sequence)
- add a mk_shuffled_tx method to the wallet module
- add a P2EPTaker and P2EPMaker class (inherit from Taker, Maker)
- add a -T option to sendpayment script for doing payjoins
- add a receive_payjoin script for receivers.
- add payjoin tests in jmclient/test/test_payjoin.py
- add a custom utxo selection method select_one_utxo to support.py
- support bech32 wallets (SegwitWallet, p2wpkh) with native=true
in config POLICY for PayJoin and direct send (not Joinmarket CJ)
- add a PayJoin.md usage guide in docs/
- include version bytes in pubkey message for forward compat
- taker pays fees but controls size (utxo number and fee/kB)
- add P2WPKH fee estimator
- Enforce INFO level logging in payjoin
- refactors regtest config settings into one place
- bugfix: script_to_address vbyte argument is bytes not integer
Bug introduced with c139067be4
Return empty string instead of None from wallet_fetch_history() as wallet-tool.py prints the result
all wallet_tool_main return vals as string
Noticed (rare) problem on my maker today: it announced a wrong size. Investigating this identified this root cause:
1. a taker was building a big coinjoin with 8+ counterparties and a rather large amount, which meant it had *lots* of inputs
2. Building that TX and receiving all signatures from all makers took longer than the default timeout, that any maker waits for a coinjoin transaction to be broadcast (90 sec). Especially because there's a rate throttling to decrease the load on the IRC servers built in - so the taker intentionally slows down.
3. After around 100 seconds it was indeed broadcast, but the maker was not polling for that TX any more.
4. The TX confirmed. But the maker has no knowledge of this transaction. This means (potentially) he announces amounts that are not correct any more.
This is not a huge problem, but super easy to fix.
Proposed solution: increase timeout. I've checked my logs, I have seen this 'faulty' behavior 3 times in the last 2 months. It always was between 90-130 sec in those cases. Going from 90 sec to 180 should fix this.
Downsides of this change: can't think of any problems with the change. Anyone else?
* parsing of scripts and addresses of all segwit types.
* ability to verify arbitrary tx inputs for all segwit types.
* simplify mktx syntax (only allow [],[] args)
* add p2wpkh and p2wsh spending test and fixes to sign calls in wallet
* simplify wallet signing calls in cryptoengine
* add p2wpkh engine, add bip84 wallet
Before this change with wallet-tool.py you would get "ValueError:
invalid padding byte" and "jmclient.storage.StoragePasswordError: Wrong
password." exceptions, joinmarket-qt would fail silently.
Prior to this commit, if a user chose cancel while selecting a
filename for a new wallet in Qt, the wallet name was set to the
default `wallet.jmdat`, which could lead to a crash or overwrite.
This fixes that by ensuring that the wallet generation code
recognizes the cancel operation.
Previous to this commit, the jmbitcoin package was accessed via
a file in jmclient `btc.py` which was originally added as an
interface to allow the client to use a non-jmbitcoin package to
provide the implementation; while this idea is useful, the way
it was implemented was not, moreover it is not currently used
and contained duplicated code that was unmanaged. Also, the
original usage of this was only by the electrum plugin, which
has currently been abandoned. This simplifies the code and
avoids spurious error messages. Note that most of the changes
are a result of pulling the logging function directly from the
jmbase package instead of indirectly via this interface (which
was unnecessary and not connected with jmbitcoin).
Prior to this commit, the test function test_tumble_tweak in
jmclient/test_schedule.py would occasionally fail due to the
creation of a schedule with less than 7 transactions, resulting
in an index error when trying to tweak the remaining schedule
entries (of which there were none). Here we bump the number of
mixdepths to make this probabilistically infeasible.
AdamISZ
James Hilliard
AlexCato
Kristaps Kaupe
Alex Cato
undeath
Kristaps Kaupe