bugfix: use enumerate instead of len reviewed estimation of transaction sizes estimates are still a bit conservative with room for improvement; signatures could still save up to one byte each if using low-r values. python-bitcointx==1.1.2-dev already supports grinding for low-r values so when it's stable and referenced version is updated, this should be reviewed again so as to utilize that benefit. added utility method `estimate_extra_bytes` the purpose of this method is for the computation of extra bytes when the coinjoin or direct send output type is different from that of the wallet updated tests to reflect new transaction size computation p2pkh transactions are now 1 byte larger for the inputs hence the change amount should be less 4 * 30 sats. add private keys for utxos that we may not be tracking some transactions (e.g. opt-in rbf) may require signing with private keys for utxos that we may have stopped tracking. this commit will search through all inputs and for those we own and retrieve their private keys so we can sign with them. added support for p2wsh output scripts in refactored the estimation of the transaction size when outputs of a different type is the target Previously, a different method was employed which was kind of kludgy considering the fact that the `extra_bytes` parameter is really for `OP_RETURN` outputs. This method modifies the `estimate_tx_size` method to accept an optional extra parameter called `outtype` which is used to estimate the correct transaction size if the target output is different from that of the wallet. added missing import added a note about preserving the order of wallet type constants Fix bug with timelocked addrs in receive payjoin Previously there would be a crash if the wallet receiving a payjoin had a timelocked UTXO. |
||
|---|---|---|
| .. | ||
| obwatch | ||
| snicker | ||
| add-utxo.py | ||
| convert_old_wallet.py | ||
| genwallet.py | ||
| joinmarket-qt.py | ||
| joinmarket-qt.sh | ||
| joinmarketd.py | ||
| qtsupport.py | ||
| README.md | ||
| receive-payjoin.py | ||
| sample-schedule-for-testnet | ||
| sendpayment.py | ||
| sendtomany.py | ||
| tumbler.py | ||
| wallet-tool.py | ||
| yg-privacyenhanced.py | ||
| yield-generator-basic.py | ||
Command line scripts for Joinmarket
(If upgrading to version 0.3.0+, don't forget to read this on upgrading the wallet.)
All user level scripts here.
(The phrase "normal Joinmarket" in the below refers to the existing repo.
The subdirectories logs and wallets have the same role as in normal Joinmarket.
The subdirectory cmtdata contains only your commitments.json storage of your used
commitments (ignored by github of course!). The filename is set in joinmarket.cfg.
The joinmarket.cfg will be created and maintained in this directory.
Brief explanation of the function of each of the scripts:
sendpayment.py
Either use the same syntax as for normal Joinmarket:
`python sendpayment.py -N 3 -m 1 -P wallet.jmdat 50000000 <address>`
or use the new schedule approach. For an example, see the sample schedule file. Do:
`python sendpayment.py -S sample-schedule-for-testnet wallet.jmdat`
Note that the magic string INTERNAL in the file creates a payment to a new address
in the next mixdepth (wrapping around to zero if you reach the maximum mixdepth).
To pay a fraction of the total in a mixdepth you can simply make the amount field in the schedule a decimal instead of an integer (0.0 < amt < 1.0 of course).
The schedule file can have any name, and is a comma separated value file, the lists must follow that format; see the comment in the sample file above (each list is length 5 items).
*This part can be ignored for a first run:
Additional fields in config: in the config section [DAEMON] you can specify whether
to run the daemon as a separate process or not. By default, the daemon will run in the
same Python process, for maximum convenience, so you needn't separately start joinmarketd.py (see below).
You can run the daemon separately by setting nodaemon=0 in [DAEMON]. You can choose to use ssl within this single-process configuration with use_ssl=true (again, see below for more on this).*
tumbler.py
This is an extension of the functionality of sendpayment.py in that it auto-generates
a schedule of payments to internal and external addresses, following the same algo
as in normal Joinmarket and described here.
For detailed information on how to use this, please read this.
wallet-tool.py
This is the same as in normal Joinmarket.
joinmarketd.py
This file is to be considered experimental for now. It only takes two arguments, the port it serves on (default 27183), and whether to use TLS for client-server communication (default 0=no tls, 1=tls):
`python joinmarketd.py [port number] [1/0]`
To use tls you must create a key.pem and cert.pem in a subdirectory /ssl, representing
a self-signed certificate. This needs some work to be cleaned up, but does work already.
add-utxo.py
This works exactly as in normal Joinmarket, with the exception of the location
of the commitments.json file, explained above.
sendtomany.py
As above.
genwallet.py
Non-interactively generate a wallet, giving only wallet name and password. Returns wallet seed as recovery_seed:. Useful for automating JoinMarket deployments.