That is incorrect. We are already seeing centralization due to the enormous costs of running a full node. The number of full nodes in operation is declining, despite increased awareness of bitcoin. And currently the network propagation time is too small to have any meaningful impact. The trouble spots in scaling bitcoin are elsewhere at this time, I'm afraid.

No. Block finding is a Poisson process. You are always 10 minutes (or whatever the current nethash & difficulty commands) away from the expected arrival of the next block.

There is no possibility for non-convergence. The most-work tree eventually wins out. Always.

It would need to be post-pruning to prevent DoS attacks.

EDIT: But to be clear, it gives ~0 benefit until you hard-fork to significantly increase the transaction rate.

iddo, I think there are two things to point out with respect to that wizards' conversation (where we didn't really reach consensus):

1) The DoS danger can be avoided with some trivial heuristics, for example: drop or ignore orphaned blocks with less than factor X of the difficulty of the currently accepted best block, and drop blocks furthest from the current best block when orphan storage exceeds Y megabytes/gigabytes. In reality there are a spectrum of possibilities between nodes having omniscient knowledge about all forks (pure GHOST), and nodes blindly following the most-work chain (bitcoin current). Even a heuristic-limited, DoS-safe version somewhere in the middle of that spectrum would be an improvement over today.

2) This is a local-only change that does not require consensus. It's okay for light nodes to still follow the most-work chain. What this change does is provide miners specifically with a higher chance of ending up on the final chain, by better estimating which fork has the most hash power behind it.

3) What this patch actually accomplishes is a little obscured by the hyperbole of the OP. There are alt coins which had a constant difficulty, and those which had incredibly low block intervals. I'm speaking in the past tense they basically imploded when their network size increased and the propagation time approached the block interval. This patch wouldn't fix that problem (because eventually you run out of bandwidth), but it does let you get a lot closer to the network's block propagation time before witnessing catastrophic consequences. This is important because when we increase the maximum transaction processing rate of bitcoin, it will be by either dropping the block interval or increasing the maximum block size (both of which are hard forks), and how far we can safely do that is bounded by this limit, among others.

Because Naoshi Sakamoto is not even a remotely related name to Satoshi Nakamoto, and if you spoke Japanese you would know that. Please don't give this poor guy the nightmare of public scrutiny.

Beyond the valid points made by gmaxwell and Peter Todd, you are making one serious mistake in your reasoning: you are assuming that other clients will behave like your client does. The *only* transaction-selection behavior that is enforced by protocol is proof-of-work confirmation of transactions in blocks. You have no guarantees that any other node will handle double-spends the same way you or a future version of the reference bitcoin client does.

Example: a site like blockchain.info tries to connect to every single node on the bitcoin network, and keeps all transactions, including double-spends. If it were configured to forward transactions, or if miners scraped the bc.i update pages for transactions it hadn't seen (a not unlikely possibility), then it does not matter in the slightest what the default relay rules are of the rest of the network. Anyone can perform a double-spend by sending the transaction to bc.i, and one way or another a major mining pool with promiscuous replace-by-fee settings will accept it.

The bitcoin protocol offers absolutely no hard guarantees about consensus until a transaction finds its way into a valid block. Placing any trust in unenforced and unenforceable relay rules is a recipe for disaster.

OpenCXP does nothing and can do nothing to prevent a double-spend with higher fees from replacing the transaction you agreed upon once you walk out that door.

Once replace-with-fee is deployed, I could rip off that coffee shop with near 100% reliability, every time until they stop serving me coffee. Don't accept zero-conf transactions.

Yes, because when faced with a classic machine learning problem, the tried and true techniques of machine learning are not what you'd want to use.

Bitcoin-Qt is not the only wallet application...

If it were me, I'd do prime decomposition on the amounts, calculate their relative magnitude, a boolean value indicating whether they'd been seen before, etc., label a number of training examples, and have a support vector machine generate a classifier.

There's a million other ways you can do it and get decent results. Doesn't stop it from being a WAG though.

It makes a wild-ass guess.

No, no, and no. None of those precautions you mention do anything to protect you against a double spend. There is nothing you can do to provide significant protection except wait for a confirmation. Do not trust zero-confirmation transactions, ever*.

(* Unless you are extending pre-existing trust you've placed in the person sending the coins, or have some mechanism for obtaining restitution in the case of a double-spend. Either way, that's side-stepping, not solving the problem.)

Yes, it's exactly MMR applied to the Chaum token double-spend db. This solves the problem of maintaining that ever-increasing list of unblinded, spent tokens by pushing the problem out of the validators and onto the people holding the coins. Proof size grows with log2 the number of spent tokens, but the proofs can be thrown away once validated (as they can be reconstructed from the block chain history).

It doesn't link the spend to the original coin however, as we're only dealing with revelation of the unblinded tokens. You still need some sort of ZKP that the unblinded token was out of the original set of blinded tokens.

I should have chosen a better lower bound than 10s, because yes at that scale network propagation has measurable effects on the security. But a 1-minute confirm would not be significantly less secure than a 10-minute confirm (and a 2-week confirm wouldn't be much more secure than that).

Zero-confirmation transactions have no security beyond your trust in the person you are interacting with. Full-stop.

I've found away around this limitation using a variant of the UTXO proof tree structure. A tree containing all spent tokens is constructible from the spend history visible in the chain history. Anyone holding an unspent token maintains an insertion-proof into this tree, which is included as part of the spend. Validating nodes need only keep the root hash for a given series, which is updated after validating each spend.

But the other two points remain as major obstacles...

This is a commonly held belief here, but incorrect. One 10-second confirmation provides exactly the same security as a a single 10-minute confirmation. A coin with block coming 10x as quickly would allow you to wait less time for confirmations. It would also be a terrible idea for a whole host of other reasons, many of them mentioned above.

You can't. There is no way to do it. The blockchain does not hold that information.

Michael, your examples indicate bad coin control and insufficient anonymity sets, not in inherent unknown weakness in CoinJoin.