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.
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).
This removes any reference to the `key-type` parameter on the
`importprivkey` wallet command from the code and from the help output.
This parameter was already effectively being ignored, the key type would
always default to the key type of the wallet. This brings the help info
and the code comments in line with the existing functionality.
Fixes#797.
Adds `custom_change_addr` argument to `direct_send()`
joinmarket-qt: Adds input field for optional external change address
joinmarket-qt: Better handle PayJoin/CoinJoin state changes for changeInput widget
Adds `custom_change_address` argument to Taker constructor and use it in joinmarket-qt
Custom change also allowed in sendpayment CLI with `-u` flag (not
supported in tumbler).
Explicitly disallows using custom change with BIP78 Payjoin, though that
could change later.
Both sendpayment and CLI provide detailed warnings to avoid misuse. In
particular, they have an extra warning for using a nonstandard or
non-wallet scriptpubkey type.
Setting custom change to the recipient address is explicitly forbidden.
Tests: Adds custom_change usage test in test_taker.
darkscience actually already running a v3 address, just the website isn't updated yet. you can try darkirc6tqgpnwd3blln3yfv5ckl47eg7llfxkmtovrv7c7iwohhb6ad.onion
This commit fixes two minor bugs encountered in
running create-snicker-proposal.py. First, the
port for AMP connections was not correct (by
convention it is now the Joinmarket proto main port
minus 1000), second in the above mentioned script,
the reactor startup client side was not disabling
the Joinmarket protocol, as it should.
Prior to this commit, the receiver code was assuming only
2 inputs always, when it decided how to change the input
ordering (randomly doing a reversal), but this is not correct
according to the BIP78 spec, which requires that the
receiver's inputs are *inserted* randomly, without changing
the ordering of the existing (sender) inputs. After this
commit, the BIP78 protocol is adhered to for any number of
inputs.
Added test for random_insert and for payjoin with 3 inputs
Verification of message signatures against segwit addresses
is not currently functional/possible in Core, and additionally
the signing function used for messages in jmbitcoin, derived
from coincurve, was not compatible with Electrum either.
This commit uses the functionality in python-bitcointx's
signmessage module, and now the wallet method `signmessage`
creates signatures on messages against segwit addresses that
are verifiable in Electrum.
Test cases of p2sh and native are added.
This completes the task of enabling
network isolation by running the receiver
side using a hidden service in the daemon,
and communicating over AMP, as is already
the case for the sender.
Updates test_payjoin for daemon receiver.
Qt BIP78 receiver update for daemon.
In case of all-in-one (client and daemon in same process,
the default), this commit ensures that if there was a port
conflict and the port number for the daemon was incremented,
the client connects to the newly created protocol instance.
And this applies to all three protocols (jm, snicker, bip78).
This PR creates a client-daemon protocol for
the BIP78 sender, using the base protocol
`HTTPPassThrough` which provides tor and non-tor
agents with POST and GET request functionality.
As for Joinmarket coinjoins, the use of an in-process
daemon is the default option, but it can be isolated
by changing the `[DAEMON]` section of the config.
The receiver side of BIP78 will be addressed in a
future PR.
Before this commit, if receiving payjoin (BIP78) via
JoinmarketQt, after the payjoin was successfully broadcast
by the sender, and the new utxo(s) recognized in the wallet,
the Qt app nevertheless attempted to broadcast the initial
payment transaction as the delayed call was not getting canceled
by the JMBIP78ReceiverManager (this attempt of course always
failed as the coins were spent, so was not dangerous, but merely
confusing). This is now fixed.
Before this commit, the check of receiver inputs in the
proposed PSBT from the receiver was erroneously failing,
if the number of sender inputs was greater than 1, because
the list of receiver input indices was not populated correctly
before the check. This commit fixes this bug.
Prior to this commit, several test functions were using
"True" to flag internal and "False" to flag external for
the HD branch for the wallet, but we now use BaseWallet vars
ADDRESS_TYPE_[IN/EX]TERNAL (1/0), so this
is changed to explicitly reference those. There is no change
to the live code (which calls get_[internal/external]_addr).
In addition _index_cache updates in wallet are protected
with a wrapper function to ensure that the branch requested
is valid.
Tests pass both before and after this change.
... with wallet-tool method `signpsbt`. Specifically,
supports co-signing of PSBTs prepared elsewhere (so,
basic Updater/Signer and Finalizer roles, but not
Creator).
Provides detailed user feedback, command line only, and
supports broadcast of finalized transactions.
Supports native and p2sh segwit (and mixed, of course).
Also adds tests using externally prepared PSBTs.
Documentation of PSBT function added to USAGE.md.
See #772. This is likely a partial fix but that issue
may be more complex.
More generally, while we may have to process multiple
entries in the return of `listtransactions`, with the
same txid, because they may have different wallet labels,
we do not want to call `gettransaction` repeatedly on
the same txid in the same monitor loop call. Note however,
that we *do* need to call `gettransaction` again in
the next monitor loop, since the state (confirmations)
updates, so we cannot permanently cache those results.
Additionally removed redundant old_txs entries with set().
Adam Gibson
chris-belcher
Kristaps Kaupe
Daniel McNally
csH7KmCC9
unofficial bisq contributor
PulpCattel
undeath
Gálli Zoltán