> There's basically an infinite number of ways to add opcodes to scriptSig, so we can't use the same trick as above of signing every possible backout transaction.

Further to this point, following up more feedback from arubi: non-push opcodes are not allowed in the scriptSig, but OP_NOP is allowed, as I understand it (please correct me if I'm wrong); if that's right, the issue is specifically related to the NOP opcodes, and extra data can be disallowed with OP_DEPTH (or does cleanstack cover that? only for standard?).

(Also logging any thoughts on this here: https://github.com/AdamISZ/CoinSwapCS/issues/25 ).

I was looking into this a few weeks back and there seemed to be a flaw in the original setup as proposed in the OP here. After some time I came up with this:

https://gist.github.com/AdamISZ/350bb4038834019eb0c06ec69446aec9

(It links at the top to a (apologies, poorly formatted) schematic; the last part of which has a diagram which may be a useful aid to understanding).

Would appreciate thoughts, a couple of people looked at it, so far comments included possibly replacing CLTV with CSV.

Update on electrum plugin:

https://www.reddit.com/r/joinmarket/comments/5zyn2h/electrum_plugin_update_a_few_extra_notes_in/

Another update re: joinmarket-qt binaries:

https://www.reddit.com/r/joinmarket/comments/5yekko/added_windows_and_tailsdebian32_binaries_for_new/

Mainly a call for any testers:

https://www.reddit.com/r/joinmarket/comments/5wit3s/release_for_testing_of_new_joinmarketqt_binary/

Well, that's confusing

First, I didn't even know joinmarket.io was still operating

Second, I recently removed the #agora pit from the ob at joinmarket.me because of spammers, see the recent reddit thread.

Third, there are some problems with getting the ob readings to be reliable. I don't have time to debug/check it (my sense is that there is a bug, but not 100% sure), it's not really interesting, partly because of what belcher mentions above (which both he and I religiously repeat every time this topic comes up!).

Relevant to the above point, announcement:

https://www.reddit.com/r/joinmarket/comments/5szb57/bots_with_large_numbers_of_offers_or_overlapping/

Yes, perhaps, and also the correlation may be due to a lack of judgement or patience to look into the details, even a lack of critical thinking skills ... (I mean seriously, some people are taking the fact that he refuses to offer evidence as some kind of proof it's him )

Not only is this false (he has not provided a single shred of evidence, when it would be easy for the real Satoshi to provide near-incontrovertible evidence), but the exact opposite is true: *substantial* evidence has been provided that he was falsifying data in an attempt to prove he was Satoshi.

Yes, it is, but multiple orders *over the same amount range* are redundant. The taker code simply drops all but one of them, so in this case, the maker gets no advantage from it. It is irritating, because it spams up the message channel, but apart from that, it's not harmful.

Franky is talking utter drivel. Whether LN is going to "work" is debatable, but the usual talking points against it (centralisation?! fees?!) are laughably far from reality.


The segwit *concept* itself, as you put it, has no drawbacks because it is a fix of a fairly serious design flaw in Bitcoin. Any particular implementation will always have risks and might have drawbacks; the soft-fork implementation chosen has tremendous benefits and some fairly minor risks, heavily ameliorated by a year of testing. There's no reason to assume it must have a reasonable share of benefits and drawbacks; you'd expect people to choose an implementation with a lot more of the former than the latter!

Everyone on here saying "well segwit is a bit crap but i guess i'll vote for it as the best for now" is for sure talking from a perspective of ignorance, and having listened to equally ill informed people. It's actually a brilliant piece of work and a huge step forward, and immediately gives us ~2MB blocks (whether that's a good idea is up for debate, but if that's what you want, you get it).

Segwit gives you 1.7-2MB blocks. People telling you otherwise are lying.

See https://github.com/JoinMarket-Org/joinmarket/wiki/Step-by-step-running-the-tumbler#before-going-further-a-few-words-on-fees

This has been done in Bitcoin, see BIP66: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki

> LN will be the only side-chain

LN is not a sidechain. The fact that you say this suggests you know very basically exactly zero about LN. You might want to educate yourself before offering an opinion on it.

> The point is that malleability is an edge case symptom that can be solved without adding a lot more complexity

This is wrong on two counts: 1, no it cannot be solved in a different way without adding a lot more complexity, and 2, segwit, at least in general terms, is the architecturally correct and simple solution to the problem. See the bip62 doc that you were already linked to for details on the first point.

Bitcoin's existing design for this is just wrong (or at the very least, not the best one): the signatures authorizing the transaction are included inside the final txid hash, which is being used as a transaction identifier; but it doesn't identify the transaction. The authorising portion (signatures) should be outside the hashed data/transaction as they are not part of the semantic content of the transaction, they are only an authorisation of that semantic content.

There is a huge amount of resources that explain what segwit is, it is nothing to do with the paranoid fantasies being spread about. Do some research.

blockr.io's certificate expired a couple of days back (on the 21st). Unfortunately they don't appear to have renewed it yet. You can verify by trying to visit https://btc.blockr.io.

In the case of Core, there is --fast to speed it up, but in the case of blockr.io it may indeed be some kind of connection problem to them. The only other possibility is if you've done a large number of transactions, which will slow it down for sure, but hopefully not "insane"-ly.

New release version 0.2.2
================

This is a minor release, but highly recommended with new features and bugfixes. See the release notes: https://github.com/JoinMarket-Org/joinmarket/blob/master/doc/release-notes-0.2.2.md

Latest version is always at https://github.com/JoinMarket-Org/joinmarket/releases/

Biggest thing is providing a feature that makes failure-to-complete transactions less likely, but there are other useful things, release notes summarizes these.

Thanks!

1. The plugin has not been updated for the new version of JM, so is not usable right now.
2. The new version of Electrum fixes the bug that had to be manually fixed in those install instructions, but for now this is irrelevant because of 1.
3. I am overwhelmed with working on Joinmarket itself, so I have no time to update this, I expect it will be a couple of months before this is re-addressed, and when it is, I'm not sure in what way. If someone else wants to do more work on it I'd be happy to answer questions.
4. I don't know about wallet file format changes; the plugin as-was was only supporting "Standard" wallets fwiw.

New release version 0.2.1
================

This is a bugfix release. See the release notes: https://github.com/JoinMarket-Org/joinmarket/blob/master/doc/release-notes-0.2.1.md

Latest version is always at https://github.com/JoinMarket-Org/joinmarket/releases/

The most important fixes are for Windows; the secp256k1 binding was broken for obscure reasons and didn't allow bots to run correctly. But there are a couple of other fixes that are important dependent on your exact use-case, so update ASAP.

Most important: if you haven't yet updated from pre-0.2, follow the upgrading instructions in the 0.2.0 (see previous post). If you are already on 0.2.0, you just need to git pull or download the new zip.

Thanks!

An additional point to make is about assumptions.

Consider that blockchain analysis pretty much started with what Meiklejohn et. al. called "Heuristic 1", which I guess should really be attributed to Satoshi:

"All inputs have the same owner."

The "first cut" of blockchain analysis is just that: clustering ownership based on that assumption. That's mostly what walletexplorer.com was/is all about, and although I don't pretend to know what other additional analysis it does, that's clearly the backbone of it.

Now, coinjoin breaks it of course, and for this reason I always say to people: "I use sendpayment for retail payments specifically to break automated clustering analysis". People who have got as far as the kind of thinking in this thread may counter: "well, but that's nearly useless since the Taker/Maker role behaviour distinction makes it almost always easy to isolate your output".

But, again, assumptions: if you're going to have automated, large scale wallet analysis, are you comfortable to start putting in a whole raft of assumptions about:

1. what is and is not a joinmarket transaction
2. that a person taking Taker role in TX1 is not taking maker role in TX2
3. the right way to handle cases where certain outputs have not yet been spent

etc etc. It is messy, and it gets messier the more different ways of operation exist; other coinjoin implementations than joinmarket, by-chance false positives, deliberate false positives, mixed role bots etc etc.

Something that Greg Maxwell has always been at pains to point out during discussions: there is no fixed "fact" about a coinjoin pattern, once heuristic 1 is dropped; even what looks like it couldn't possibly be a coinjoin, e.g. : inputs(1,3), outputs(3,1) could actually be a payment of 2 bitcoins from party A to party B, or two payments of 3btc A->C, 1btc B->D. Neither of these are likely today, but ... are they? How do we know?

Joinmarket's motivating philosophy is a bit "worse is better" (see gwern's article on bitcoin is worse is better) - that usage is what counts, because the set of near-watertight assumptions splinters and, in the most optimistic future, eventually collapses.