To reproduce:

• Have two IRC in joinmarket.cfg

[MESSAGING]
socks5 = true, true
socks5_host = localhost, localhost
socks5_port = 9050, 9050
channel = joinmarket-pit, joinmarket-pit
host = 6dvj6v5imhny3anf.onion, cfyfz6afpgfeirst.onion
port = 6698, 6667
usessl = true, false

• Replace one host with bad host (6dvj6v5imhn12345.onion)
• Start sendpayment.py or tumbler.py as normal (tested tumbler.py only)

Expected result:

• One IRC connection will work and one will fail
• Script will continue

Result:

[MainThread  ] [DEBUG]  building irc 
[MainThread  ] [DEBUG]  building irc 
[MainThread  ] [DEBUG]  (unhandled) noticed:  agora.anarplex.net Auth *** Looking up your hostname...
[MainThread  ] [DEBUG]  (unhandled) noticed:  agora.anarplex.net *** Skipping host resolution (disabled by server administrator)
[MainThread  ] [DEBUG]  (unhandled) noticed:  agora.anarplex.net Auth Welcome to ^Bagora-irc^B!
[MainThread  ] [DEBUG]  signedOn:
[MainThread  ] [DEBUG]  (unhandled) noticed:  [email protected] NICKNAME [^BLogon News^B - Sep 14 2011] PLEASE: Register with nickserv. (/query nickserv help register)
[MainThread  ] [DEBUG]  joined:  #joinmarket-pit

...10 minutes...

[MainThread  ] [INFO ]  STALL MONITOR:
[MainThread  ] [INFO ]  No stall detected, continuing

Script never continues.

Currently schedules dynamically update in the view pane during mutliple join run, however this is a flat view of CSV, should be (a) grid, (b) highlighting/bolding active entry, (c) explanatory notes e.g. headers. Perhaps other things. Low priority.

In tumbler.py if commitments are too new it just keeps trying.

A pecularity of the Qt approach is that the taker info callback is perceived as requesting SpendTab.abortTransactions() to be called if the info type is 'warning' ('ABORT' -> 'warn' messagebox type), so the tumbler aborts on the first failed commitment, even if the reason is 'too new'. Should be fixed to give better robustness. Fairly high priority.

If joinmarketd is run persistently with new clients connecting, new instances of JMDaemonServerProtocol are created, meaning that the member variable self.irc_config is reset to None, meaning a new IRC session + nick is created even though the IRC config is the same.

The parts of the class instance which manage the connection should therefore be class variables, but this requires a bit of work. At least the messagechannelcollection object must be thus, and also it seems the orderbookwatch related data. So this is a bit more of a rework than I'd thought it would be. Also there might be something simpler than moving to class variables, perhaps moving these elements to the JMDaemonServerProtocolFactory, not sure.

This isn't labeled as a bug because it does not break functionality, but any long running daemon used repeatedly by clients will create a bunch of useless IRC connections, so it nearly counts. Should be fixed soon.

Steps to achieve this:

1. Add maker client-server commands to jmbase/commands.py.
2. Add and refactor maker.py with Maker object to jmclient package. Refactoring means similar to what has been done for Taker; bundle stage 1 and stage 2 operations.
3. Refactor a base CJPeer class again to remove duplication between Maker and Taker (but note Orderbookwatch is already factored out to jmdaemon. Note that some part of the unconfirm/confirm callback handling might be refactorable into the base class here.
4. Add code to jmclient/client_protocol.py in line with step 1.
5. Re-add at least one yieldgenerator script to scripts/ instantiating Maker.

Currently considering this a longer term goal, it'll probably be the last step to complete the replication of functionality in the current Joinmarket repo.

Currently loadWalletFromBlockchain leaves gaplimit at default

code is stale, doesn't fit with current

To schedule multiple transactions for Electrum requires add_tx_notify to work in the jmclient.blockchaininterface.ElectrumWalletInterface; currently it is just a dummy do-nothing.

I haven't investigated but presumably it requires something like subscribing to an address, may be a non-trivial job.

Message in travis after tests end is "Coverage.py: warning no data" or similar. Saw this once locally, don't know the reason, perhaps something to do with versions (although they should have been fixed in the yaml).

Currently spamming up the Taker object, refactor to jmclient.podle, use template formatting to fill in utxos etc and return.

One first question: If a resilient tumbler client is developed from the clientserver code do makers need to be upgraded before it can be used?

On failure to source commitment in Qt, currently shows commitments_debug info in popup, but does not abandon the join.

Minor bug in display in the jmclient/jmclient/wallet_utils.py module.

Log messages are one-per-tx run, so in a schedule end up getting duplicated

Steps to Reproduce

blockchain_source = bitcoin-rpc

tx_broadcast = not-self
or
tx_broadcast = random-maker

Expected result:

Sends tx through other peer / maker.

Actual result:

Does sendrawtransaction using Bitcoin RPC.

Noting this here rather than fix immediately, not important (since user can look up txid), but obviously to be fixed in future.

Not strictly required, so not high priority, but this 'view' of progress is intended for readability so particularly applicable to GUI setup.

Unconfirm/confirm callback is already added, to re-implement tumbler functionality mostly just needs an easy way to generate schedules and add some features and options.

Since it can be (and usually is) a comma separated list, it must be string, no QIntValidator

Error:

exceptions.ValueError: Calculated transaction fee of: 2XXXXX is too large for our inputs;Please try again`

When using sendpayment.py script exits with fatal error.

When using tumbler.py:

STALL MONITOR:
Stall detected. Regenerating transactions and retrying.
Schedule entry: [0, 0.152566362877, 6, 'INTERNAL', 22.73, 0] failed after timeout, trying again
...
STALL MONITOR:
No stall detected, continuing

but does not make progress (only left running for 1 hour, maybe it would make progress later).

Input UTXO was small, amount sent was small, amount sent + transaction fee > amount of input UTXO. Other input UTXO were available.

To reproduce:

• Create wallet with coins in just mixdepth 1
• python tumbler.py --schedulefile schedule.schedule wallet.json <addr>

Expected result:

• Tumble starts, mixdepth 1 is the lowest mixdepth

Result:

TIMESTAMP_0000000000013 [MainThread  ] [DEBUG]  get_utxos_by_mixdepth =
{0: {},
 1: {u'TXID_INDEX_00000000000000000000000000000000000000000000000000000001': {'address': u'1ADDRESS_00000000000000000000001',
                                                                             'value': VALUE_0000000001},
     u'TXID_INDEX_00000000000000000000000000000000000000000000000000000002': {'address': u'1ADDRESS_00000000000000000000002',
                                                                             'value': VALUE_0000000002},
     u'TXID_INDEX_00000000000000000000000000000000000000000000000000000003': {'address': u'1ADDRESS_00000000000000000000003',
                                                                             'value': VALUE_0000000003}},
 2: {},
 3: {}}
TIMESTAMP_0000000000014 [MainThread  ] [DEBUG]  Coinjoin amount too low, bringing up.
TIMESTAMP_0000000000015 [MainThread  ] [INFO ]  Choosing a destination from mixdepth: 1
TIMESTAMP_0000000000016 [MainThread  ] [INFO ]  Chose destination address: 1ADDRESS_00000000000000000000004
...
TIMESTAMP_0000000000025 [MainThread  ] [INFO ]  rel/abs average fee = REL_FEE_00001 / ABS_FEE_00001
TIMESTAMP_0000000000026 [MainThread  ] [DEBUG]  INFO:Preparing bitcoin data..
TIMESTAMP_0000000000027 [MainThread  ] [DEBUG]  total estimated amount spent = EST_AMT_00001
TIMESTAMP_0000000000028 [MainThread  ] [DEBUG]  get_utxos_by_mixdepth =
{0: {},
 1: {u'TXID_INDEX_00000000000000000000000000000000000000000000000000000004': {'address': u'1ADDRESS_00000000000000000000005',
                                                                             'value': VALUE_0000000004},
     u'TXID_INDEX_00000000000000000000000000000000000000000000000000000005': {'address': u'1ADDRESS_00000000000000000000006',
                                                                             'value': VALUE_0000000005},
     u'TXID_INDEX_00000000000000000000000000000000000000000000000000000006': {'address': u'1ADDRESS_00000000000000000000007',
                                                                             'value': VALUE_0000000006}},
 2: {},
 3: {}}
TIMESTAMP_0000000000029 [MainThread  ] [DEBUG]  ABORT:Unable to select sufficient coins: Exception('Not enough funds',)
TIMESTAMP_0000000000030 [MainThread  ] [INFO ]  Taker not continuing after receipt of orderbook

Notes:

• tumbler seems like chooses mixdepth=1 but uses mixdepth=0 later
• mixdepth 1 has enough funds (> 0.5 BTC)
• Completes ok if mixdepth 0 only has coins or mixdepths 0,1 have coins

Currently on_JM_FILL_RESPONSE only returns "Makers didn't respond" in case of less than minimum_makers number of valid ioauth responses. Need client to see if there were specific error messages, or in any case get more fine grained information.

The list of offers delivered from the pit is now in the several hundreds, which creates a data blob too big to be sent over one response, amp limits the size to 65535 bytes. Current hack in the code to only deliver the first hundred offers just to allow it to work on mainnet (needed for testing Electrum already, because Electrum has no testnet interface).

Thus fairly urgent solution required, see https://amp-protocol.net/DontPanic/ , it should not be very hard to batch send, hopefully. Edit: or probably simpler to use the BigString solution suggested there.

Wallet sync between schedule entries should not be done, first because it's slow and unnecessary, but also because it resets the index; hence the tumble style multi-join's use of add/remove utxos should be replicated; slight current technical difficulty is that this code is folded into the tumbler's taker_finished_update code in tumble_support.py (to re-use with CLI version).

This trivial but slightly tangly situation is a result of an artificial distinction between the 'tumble' and 'multijoin from manually created schedule' cases, so the issue should probably be extended more broadly.

Worked before, fix

It may be possible to just drop-in most or even all of the current test suite in https://github.com/Joinmarket-org/joinmarket , but even if it is, will need to build some tests differently. Some ideas for now, since this will be a big job:

• Use a DummyMessageChannel as a way to test the functionality of MessageChannelCollection.
• Create a daemon tester using a dummy client to call its functions.
• Create a DummyBlockchainInterface with some tricks to allow testing of Taker functions like receive_utxos in isolation. In general, creating a suite of Taker tests that don't depend in any way on the blockchain interface would be a huge help (we already have the win that it no longer depends on the message channel).

I will add more here as I think of it.

Quote:

"
Thanks a bunch for putting out this initial qt. I've taken a look and have some initial feedback.

Most of my suggestions are just about making it simpler and easier for users who aren't familiar with coinjoins or joinmarket at all. Streamlining the interface to explain a bit more and otherwise keep things intuitive is my aim. I think the ultimate goal of the gui should be that someone only generally familiar with sending bitcoins to addresses should be able to run the qt and perform joins just by looking through options and following prompts, referring to documentation just to be certain. In that vein then, providing expanded descriptions of prompts and instructions and otherwise not showing particular elements until they become relevant can help a new user navigate the program without becoming too overwhelmed.

Switch the order of tabs to reflect the order a user would want to tinker with- JM Wallet, Coinjoins, TX History, Settings (eventually I think we'll want to use buttons similar to what's in the bitcoin-qt, so users will feel more familiar)

When Current Wallet=None, Blank out address/index/balance/used/new, do not show mixdepths.- In mixdepths field say- "No Wallet Loaded. Please create a new wallet to get started!"

Coinjoins- grey out fields/ box initially- "No wallet loaded. Please create or load a Joinmarket wallet to get started!"-> "Wallet loaded, but no funds present. Please send funds to an address listed in JM Wallet to get started!"

When a wallet with 0 BTC funds is loaded, show a column next to external addresses "Send funds to one of these addresses to begin using joinmarket!" or otherwise prompt with an address to send funds to.

Wallet- (use expanded descriptions) "Create New Wallet" "Load Wallet From Saved wallet.json file" "Recover Wallet Using Mnemonic Word Strings" "Export Private Keys" "Exit"

Settings- Put settings a novice is likely to tinker with up front, otherwise hide.

Add checkbox "Show Advanced Settings" to show these more advanced settings Add a "Restore Default Settings" in case the user screws up settings.

"Recover Wallet Using 12-Word Recovery Seed" "Enter your wallet recovery word string here to recover a lost Joinmarket wallet" (Separate fields for each word?)

Generate- "You are going to generate a new wallet. In a moment, a wallet recovery seed of 12 words will appear. It's VERY IMPORTANT you write this recovery seed down. If your computer crashes you may have no other way of retrieving your coins!" Continue/Cancel

New Recovery Seed Displayed Screen->Continue->Create Password Screen-> Recovery Seed Check Prompt->Name your wallet

Recovery Seed Check Prompt- "Please enter the 12 word recovery seed you were just shown. You must have this seed written down"->Continue/Retry With New Seed/Cancel (if the seed isn't correct, do not allow the user to proceed)

Recover from Seed "Enter the 12 words of your Joinmarket recovery seed separated by spaces:" (or just have separate fields for each word)

I would hope these changes should be relatively simply to implement. I'm still looking at the actual coinjoin options and flow for advice there. Let me know what you think. Really appreciate the work you're putting in.
"

Using python setupall.py installs packages into virtualenv site-packages directory. After that the changes made to local code are ignored because site-packages is used.

I'm not sure the best way to use the local code. This kind of works but only for one package at a time:

cd <package>; python setup.py develop; cd ..

Need scrollable (or at least resizable) message box ideally.

Fixed at 16.6.0 in jmbase setup.py for now.

Also, encryption/TLS. Not sure of the right approach here; it looks like it's fairly easy to add credentials to the AMP connection. The connection is currently hardcoded to localhost, but clearly it would be either nice or essential to add security to this inter process communication, depending on how you look at it.

Either with -N 0 or e.g. menu choice

Most likely a separate tab, or perhaps a separate window that can be chosen from the menu. User probably needs an at-a-glance view of current status re: commitments (already have a popup with commitments debug text if something goes wrong). Ideally includes GUI based tools for adding (replicating add-utxo.py functionality).

Exceptions are thrown when the client disconnects at the moment. It doesn't seem to cause functional problems (can reconnect and run OK), but should be fixed.

More generally there are places where addErrback needs to be used.

Needs to cycle mixdepths.

Easy enough, but needed.

may be some special case for it, but clearly shouldn't be default.