907f1b0603 Signal BIP125 opt-in RBF for non-cj sends by default (Kristaps Kaupe)
Pull request description:
This seems to be direction where everybody is going. Wasabi Wallet 2.0 does this, Electrum does this. I see no downsides here.
Before this you could signal opt-in RBF only from `sendpayment.py`, but not Qt GUI.
Will be more useful after #1019 is merged, but power users already can use other tools to construct replacement transactions.
ACKs for top commit:
AdamISZ:
tACK https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/1457/commits/907f1b060353dfbbfdf31ebc85f2ecb3c3b209fe
Tree-SHA512: 8909263e983fb17bac8cfea17532b391ad502f1a69e3079b1e1361177659628ede5de2eb85ed8fbbb7395bfd270a8b5f3d8916817033baa0b81561787bffe876
refactoring to improve readability and testing
added support for taking the fee from multiple owned outputs as needed
added unit tests
removed same mixdepth restriction for inputs
added option for specifying which output to deduct fees from
added additional test cases
refactoring: moved tx_vsize to jmbitcoin package
added a sanity check to ensure that the transaction id supplied belongs to our wallet
fixed a linting error
Prior to this commit, the tumbler algorithm assumed that destination
mixdepths of INTERNAL transactions were incremented by 1, but the
underlying taker code uses (mod maxmixdepth) logic always. This commit
takes the decision to make the usage of the wallet "purely" cyclic, that
is, not only the Taker object but also the tumbler algorithm now always
treat the wallet as a cycle. This is not problematic in a tumbler
algorith (or any other schedule generation algorithm), as long as we use
the strict rule of "always exit each mixdepth with a sweep", which the
tumbler always did and this commit does not change.
Also, and importantly, several much more detailed tests of the tumbler
schedule generation have been added.
Add a new helper module to calculate fidelity bonds values and stats, and a script to use it.
The goal is to give as much information as possible to the user before
committing to a fidelity bond.
when checking for timed-out counterparties (or refreshing the
orderbook), stale entries are preserved because those peers
disconnected prematurely. This fix prevents that issue by
first removing all entries before requesting for the orderbook.
For frozen balances, display a label "FROZEN" in the status notes.
For unconfirmed balances, display a label "PENDING" in the status notes.
Both FROZEN and LOCKED balances are considered unavailable balances, while PENDING balance is considered available balance.
Because it is possible to broadcast a transaction that spends unconfirmed balance, while a user has to manually unfreeze
the balance or wait until the timelock has expired before they can use FROZEN or LOCKED balances.
Closes#1247.
This consists of an inclusion of the bond value exponent into the config
that the user can alter, and a change of that from 2 to default 1.3.
Also updates the fidelity bond documentation to account for those
changes, including the units used in ob-watcher, but not the calculation
of fidelity bond attack resistance (which remains a TODO).
Prior to this commit, running ob-watcher with
an onion-type message channel configured would result
in the bot attempting to connect to all the makers,
which is bad. This happened because the internal logic
of the onion message channel is that receivers of privmsgs
will be sent peer info from the directory, so that they can
immediately respond p2p if they succeed in outward connecting.
But for bots who do not intend to engage in a coinjoin interactive
protocol, like ob-watchers, this is absolutely not the desired outcome.
After this commit, a bot can specify mode "PASSIVE" in the call to
get_mchannels(), which results in the OnionMessageChannel object only
creating non-directory remote peer objects of type OnionPeerPassive,
instead of OnionPeer, which means they never try to connect to those
remote peers.
Also, exports JMMakerClientProtocol for custom directory node scripts
(stored in the custom-scripts repo).
Modify default config with 2 signet and mainnet directory nodes to
start.
Handles unreachable directory nodes with a human readable error and
adjusts connection timeouts to be realistic.
Changes wording in Qt notifications from "IRC" to message channel.
Updates docs, new directory node information.
5132342f57 update install.sh to build tor on macOS (jules23)
7a88781648 Add support to build and autostart local Tor instance in jmvenv (Kristaps Kaupe)
Pull request description:
See https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/1000#issuecomment-957379435 for context.
This adds new option `--with-local-tor` to `install.sh` which builds Tor locally inside jmvenv. Then, when starting JM scripts that might need Tor connection, it is started automatically if nobody already listens on `127.0.0.1:9050`.
If no problems are found with his approach in testing, we could switch to this as a default and remove all clearnet IRC configs from default config.
Top commit has no ACKs.
Tree-SHA512: caa7fcac88e57321f65a3f9fc09def94f9659855977026a19e1ac8f2f160a01237fe90220b986561bd622b05534f201ea5a29a9cdbc71013e40301992ed59e4d
In the previous commit, all peers served an onion.
After this commit, taker client instances will automatically
send a config var to the jmdaemon backend that instructs
the OnionMessageChannel instance to not start an onion service,
and the handshake messages sent by these peers replace the
onion location with a placeholder string NOT-SERVING-ONION.
Directories and maker peers will not therefore to connect outbound
to them, but privmsging still happens p2p with connections from
takers to makers after the directory has communicated their
reachable .onion addresses.
This change reduces the configuration requirement for takers and
is better for their privacy and security (without sacrificing
the gain we get from having p2p connections).
The above comments re: takers also apply to ob-watcher bots.
This commit also fixes a large number of minor bugs and errors in
documentation, as well as many Python cleanups after review from
@PulpCattel. A few concrete items are:
It fixes the ob-watcher functionality to work with the new subclass
of MessageChannel (OnionMessageChannel).
It corrects the on_nick_leave trigger to make dynamic nick switching
between MessageChannels (as implemented in MessageChannelCollection)
work correctly.
It corrects the order of events in the add_peer workflow to ensure that
a handshake can always be sent so that the activation of the connection
always works.
It sets a default messaging config with onion, 2 active IRC servers and
one inactive IRC server. The onion config has 2 signet directory nodes,
so this will change to mainnet after the PR is merged to master.
Joinmarket bots run their own onion services allowing inbound connections.
Both takers and makers connect to other makers at the mentioned
onion services, over Tor.
Directory nodes run persistent onion services allowing peers to
find other (maker) peers to connect to, and also forwarding
messages where necessary.
This is implemented as an alternative to IRC, i.e. a new
implementation of the abstract class MessageChannel, in onionmc.py.
Note that using both this *and* IRC servers is supported; Joinmarket
supports multiple, redundant different communication methods,
simultaneously.
Messaging is done with a derived class of twisted's LineReceiver,
and there is an additional layer of syntax, similar to but not the
same as the IRC syntax for ensuring that messages are passed with
the same J5.. nick as is used on IRC. This allows us to keep the
message signing logic the same as before. As well as Joinmarket line
messages, we use additional control messages to communicate peer lists,
and to manage connections.
Peers which send messages not conforming to the syntax are dropped.
See https://github.com/JoinMarket-Org/JoinMarket-Docs/pull/12 for
documentation of the syntax.
Connections to directory nodes are robust as for IRC servers, in
that we use a ReconnectingClientFactory to keep trying to re-establish
broken connections with exponential backoff. Connections to maker
peers do not require this feature, as they will often disconnect
in normal operation.
Multiple directory nodes can and should be configured by bots.
Fixes#1162.
Prior to this commit, the default argument [] was provided
to the bitcoind RPC listunspent call, which means only confirmed
unspent coins are returned. This is in contrast to the display
in wallet_tool, which deliberately updates listunspent_args to [0]
in order to default to showing unconfirmed coins, as users will
expect.
This commit adds the same listunspent_args = [0] in case the user
has not edited this variable in the config, for the same reason.
a1bcac99cc Fix tumble log dir after load_program_config (Adam Gibson)
Pull request description:
Fixes#1060.
Prior to this commit, the extra log for tumbler.py
was created in the local directory, because it was
set before running load_program_config (which defaults
to the user's default joinmarket config location), this
is now corrected.
ACKs for top commit:
kristapsk:
ACK a1bcac99cc
Tree-SHA512: 69085ef50bdbe6a7f420df8c9384e21855df1fdad377b968714b70cefed4db558a66d7afc4f8cba1efd8dc41447564578c466d9d7ebea3b1a2cef9a4d7b069a2
