Bitcoin Forum

The recent sybil attack on the network by Chainalysis got me thinking about identity being leaked by the high correlation between the first relayed IP address and the original creator.  IP can be a very powerful piece of identity information.  It alone can be useful but then combined with other measured can be used to build a real world identity and link transactions to it.  Granted the first relayed node may not be the sender but with enough nodes and some heuristics and multiple datapoints it becomes possible to start seeing the information from the noise.

The good news is that Chainanlysis created non-responding nodes and used a sequential range of IP addresses from a given subnet.  So it was both suspicious and did not appear as normal nodes to other nodes on the network.  A smarter attacker however would use a few high capacity nodes hidden behind a larger number geo diverse IP addresses acting as transparent proxies.  It would be possible to aggregate the same information without appearing any differently than other bitcoin nodes.  So I guess we can be thankful that Chainalysis did such a horribly bad job out of the gate that they brought attention to the issue before someone competent tries.  Hiding the creator's IP address alone does not provide perfect privacy but it is a start.  

1) Nodes should support split routing
TOR, I2P, and VPN proxy are options to decouple your IP address from your transactions but bitcoin generates a lot of traffic when only a tiny portion of that is privacy related. Routing all of it through privacy protecting services is inefficient.  Split routing would allow the client to be configured to relay some of its traffic (like locally created transactions) to one network and the rest of the traffic (like relayed blocks) to another network.  By routing only a node's outbound txns the bandwidth requirements over the secure network can be reduced significantly.  It may be more secure to randomly pick a small portion of the received transaction to relay over the secure network and then add locally created transactions to that stream.  This makes exit node analysis more difficult in the event the exit node is compromised.   Still it should be possible to reduce the TOR bandwidth requirements by 99% or more.  Likewise users of VPN proxy services could take advantage of split routing to reduce cost as their bandwidth requirements will be low.

2) Merchants and payment service providers should directly accept signed transactions.
The person you are paying already knows 'you' are paying.  How much of you they know depends on the circumstances it may be a little or it may be a lot but there is some element of trust with any counterparty.  If I buy a gold coin from an online dealer who accepts bitcoins they already know at a minimum my name, address, and probably my IP address unless I used privacy protecting service.  It would leak less information to provide the signed transaction directly to the recipient rather than to an anonymous peer who may be malicious.

3) Wallet developers should consider making it possible for a user to create a signed transaction without broadcasting and to import a signed transaction.
Armory already makes it easy to sign a transaction without broadcasting in offline mode (cold storage) but this could be useful feature for an online wallet as well and also implemented in Bitcoin core.  User creates a transaction in the wallet, checks an option to not broadcast and when signed receives the hex encoded raw transaction which he can send directly to the receiver.  Merchants and other service providers will likely use automated system to accept and process this transactions but end users may not.  Clients should make it easy to 'import' a signed transaction for validation and relaying.

You seem to assume that noone else did this in the past. What this assumption is based on?

POS terminals accepting signed transactions over NFC, wifi, and bluetooth will help here. It would be great if some enterprising POS terminal manufacturer would develop a transaction-signing protocol and write up a BIP that mobile bitcoin wallet developers could easily implement.

How does this help if the mixed coins and the original coins can be associated back to the same IP address? At the very least you would need to use the mixed coins from a different node.

I always use a VPS for sending coins, so that's at least 1 problem for me that I don't have to deal with.

But that's not the same story for my full node that I used to run on my home pc.

Plenty of transactions from around the world were connected to my node IP address. Which I am not happy with.

Now I run the full node on another VPS to avoid all this connecting.

This is perhaps a risk it should be warned against? Could users possibly "incriminate" themselves?

I'm no expert in how transactions are relayed, but let's say Joe Student runs bitcoin-core on his dorm computer and leave it runnnig. Then some other bitcoin user running node software is connected to his node and issues a tx.

Afaik, it's possible to limit the bitcoin-code connections to 1, and also to set up which node to connect to. I'm unsure whether the "orginating IP" shown will be the node sending the tx, or the relay-node. But if it's the relay-node, then it's very easy for someone to just connect to someone random and send their "nasty payments" through them.

That tx then enters the network with an orginating IP of Joe Student. This other user bought some nasty stuff on some black market, and was the "victim" of a honeypot operation by law enforcement. These law enforcement officers might as well look up the transaction on blockchain.info, or with some other tool, and seeing this is their only "lead", they go for a raid..

We have an unconfirmed story (https://github.com/bitcoin/bitcoin/issues/2653) of this happening already. I've also been told by someone I used to know how police took all his electronics without even talking to him or asking him about anything, all because of a mistake, much like the one above, with a false lead.

As for how accurate law enforcement is.. Old story (http://www.techrepublic.com/blog/tr-dojo/fbi-seizes-servers-reminds-it-admins-to-have-a-back-up-plan/), but still relevant:


So it's no wonder that someone's electronic equipment can be taken if they run a full node at home, and they pop up in a "suspicious transaction list". Of course, if the officers in question had proper knowledge about technology.. However they do as they please, it seldom gets them in trouble, so why not break down the door and take all the computers? What fun is it to ask nicely?

I won't be surprised if several people go to jail because of this. http://en.wikipedia.org/wiki/Money_transmitter

Probably crap ideas:

1. Why not make the tx appear like a typical relayed tx in a special inv that's only revealed to one "selected" peer.  "selected" could be random or outbound only, or any other feature that could indicate some more trust in the node.  This should be private with the probability of 1-a/n where a=attacker nodes I'm connected to n=total nodes i'm connected to.  Doesn't help if a=n though.  This does help if the attacker is connected to every single node in the network as this would mean that they first see the tx from some other node unless you happen to pick one of their nodes.

This could then be redone in x minutes if the my client hasn't heard about this tx from other nodes.  I.e. the tx hasn't effectively been rebroadcast.

2. Another point is if I get an addr message for a node from every single node I'm connected to does that not indicate a node that is trying to connect to too many nodes.  Should I not trust such a node less?  I guess this might be difficult to determine an optimal point?  Plus the attacker would work round whatever heuristic get's used.

3. Nodes under 1. can be selected based on behaviour (am I receving useful info/tx/addresses).  Is it behaving like a regular node etc.  Attacker could probably work around this.

4. I suppose one could also "select" a new random node out there to connect to, just to broadcast this tx.  Then it depends on how good your selection process is.

I had an idea related to my project JoinMarket.


Regarding the Chainalysis deanonymizing sybil attacker (https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/).

CoinJoin doesn't directly deal with IP-address based attacks.

However, because CoinJoin has multiple people, the final fully-signed transaction could be broadcast by any of them. This passive-monitoring sybil does not know that the different IP addresses are co-operating to create a CoinJoin.

For JoinMarket right now, it is always the liquidity-taker who broadcasts the tx from their IP or through a blockchain explorer. This could be improved by having taker be able to send the fully-signed tx hex to one of the market-makers who will then broadcast it. The taker would choose to broadcast the txhex himself, or send it to one randomly chosen maker to broadcast. In this way the coinjoin tx could come from many IPs instead of just the taker's.
It could work quite well. The makers are already incentivized to allow their bitcoins to be coinjoined with, now they can be incentivized to allow their IP address to broadcast coinjoins. They don't earn their coinjoin fee unless they broadcast.

From https://bitcointalk.org/index.php?topic=919116.msg10772130#msg10772130

For this kind of idea, we probably need to come up with a good format for serializing bitcoin transactions. The current hex string style does not include error detection or other desirable characteristics. Of course, wallets should accept the current hexstring style too.

I suggest a simple base64 encoded string with the first 4 bytes of double-sha256() appended as a checksum. Maybe the string BITCOIN TRANSACTION should appear there somewhere too.

2 and 3 have the added advantages.  Merchants can validate the tx, ensure sufficient fees and broadcast it widely, to reduce double spend probability.

Along the same line, we should be able to use pushtx services to broadcast transactions

There is no form of additional "broadcast it widely" work beyond the ordinary operations of the network that meaningfully reduces the probability of a double-spend.

The JoinMarket market-makers could be one of the things which do that. Push everyone's transactions instead of only their own coinjoins.

An important point often missed is that this privacy stuff should be automatic to the user. Very few users will be inclined to copypaste transactions around when they can just click "Send" and have the tx go from their own IP.

Agreed it provides no additional security against double spends but it could be useful to prevent "stuck" payments.  At least the merchant will gain immediate visibility of the payment which may not be the case if user is running a wallet which creates non-standard txns (primarily due to size, dust, or fee).  If parent pays child becomes more common a high capacity merchant may even be willing to accept such non-standard payments bundle them together with sufficient fees in child transaction and push to miners.  

From a merchant standpoint one downside is customer satisfaction.  When Bitcoin works it works great but when it doesn't (primarily due to issues created by the user) the merchant can't do anything.  Most merchants don't like to be in this position.    The ability to accept the txn directly at least gives them the ability to resolve user issues transparently and thus improve customer satisfaction and merchant reputation.

Agreed.  However as a first step the ability to do it 'at all' is a first step.  To make it more transparent and seamless, BIP70 could be extended to support a privacy enhancing 'direct to merchant' option which transmits the payment only to the merchant.

https://raw.githubusercontent.com/bitcoin/bips/master/bip-0070/Protocol_Sequence.png

This shows standard BIP protocol sequence.  Notice in the second to last step the payer's wallet broadcasts the txn to the network.  However the protocol could be extended to optionally remove this step.  If the 'payment request' sent by merchant (step 2) had a 'direct to merchant only' flag which indicated the merchant would relay the txn and the user's wallet was both aware of this flag and the user elected 'direct to merchant' payments then the wallet would not broadcast the txns.  Instead the merchant would and the user would see the txns when his wallet received it from the network.  This would provide a way to enhance privacy in a transparent manner.  An existing BIP70 wallet (which is unaware of 'direct to merchant' flag) would fall back to normal txn broadcast and acting on the flag could be a user defined option (default to enable?) so even newer wallets could still fallback to the existing mode.

That probably is not a requirement although it can't hurt (more compact in terms of symbols than hex).   Bitcoin transactions are signed.  Changing bytes either intentionally or accidentally in any part of the txn except the ScriptSig will simply result in an invalid txns.  The ScriptSig is malleable (the txn malleability issue) however even a change here will either result in an invalid txn or a valid txn with a new txn id.  It is very likely the later would happen due to accident so it is no different than any other transaction in this respect.

I would recommend using base58checked instead of base64.   The non-alpha symbols in base64 make copying and pasting a pain.

Hi DnD

i like your recommendation to develop a standard for payments directly with a signed TX.
that would also allow offline devices to do payments (if they have the UTXO set of the current user)

regarding your point that a salesman can do nothing when a payment is stuck: i though it was planned / supported that if a merchant immediately spends this new transaction with a higher fee it has a higher probability to get included?

and i expect bigger merchants to make agreements with pools too (like mtgox and eligius did a long long time ago (AFAIK at the the time of the gox scam this wasnt the case anymore))

That is true but most txns that are 'stuck' become so because they do not fully propagate the network.  As an example say you are using a poorly coded wallet which allows you to create an output below the dust threshold.  Most nodes will not relay that txn.  From your end it looks like you 'paid' the merchant but most nodes are just dropping the transaction and refusing to relay because it failed the IsStandard() check.

Even if one of your immediate peers does relay it unless there is an unbroken line of peers between you and the merchant it will be dropped at some point along the way.  In a situation like that the merchant simply doesn't see your txn.  Even if you give them the txId their local bitcoind will say the txn doesn't exist.  Now if you paid a 'normalish' fee and some node relayed it to a pool which mines non-standard txn it may get included in a block at which point the merchant would see you 'paid' when the block publishes which may be hours or even days later.   However if you also decided to be cheap and make it both non-standard and free it may never be included in a block.

If the merchant can't 'see' the txn they have no ability to fix your problems even if they want to.  By transmitting directly to the merchant the at least be guaranteed they will get a copy of the txn.  Now if it is some massive bloated spammy garbage that some unknown wallet allowed you to create they may not want to fix your problems using 'child pays parent' but they at least have the option (especially as you indicate if the merchant has an existing agreement with one or more pool).

It isn't a perfect analogy but think about how CC works.  In theory CC could operate on a model that when you want to pay your smartphone contacts the CC network directly including all the routing and payment details.  The merchant would then see the txn when they are notified by the processor.  It doesn't work that way however.  You provide the payment to the merchant directly via POS terminal who then pushes that to the network and both you are the merchant are notified.  The merchant has a very vested interest in making sure the payment goes through so it makes sense for them to handle the transmission of the payment.

True the network itself doesn't track originator IP addresses and couldn't in any provable manner.  You are right the 'relay IP address' is just the IP address the snooping node first saw the txn from.  The idea is that if there are say 8,000 full nodes and you create 2,000 full nodes and the average user has 8 connections the odds are you will connect to at least one snooping node.  When all the nodes share information on the backend there is a high probability that 'relay IP address' is the originator's IP address at least for default behavior of most wallets if the user is not using some privacy enhancement.  Using TOR, I2P, or VPN proxy today would defeat these types of attempts (unless exit nodes are poisoned).  The reality is most users will not go beyond the default configuration so the thread was looking for ways to make privacy easier for the average user.

Your single connection scenario doesn't work as well as you might think.  In case it isn't understood having only a single connection to the network is very dangerous.  It can allow you to be isolated and fed false information by a malicious node.  That could lead to a loss of funds if you are tricked into thinking a txn is on the main chain when it is not.  The foundation of blockchain security is that your node will connect to at least one honest peer and thus can determine the longest valid chain. If you are connecting to 8 or 20, or 80 peers the probability that they will all be the attacker is low but if you connect to a single node especially at random the odds are much greater.  I am not saying there aren't niche uses but the node you connect to should be trusted and you should understand the risks.

Connecting to a single random node means there is a good chance you will connect to one of the 'snooping node' and thus you haven't accomplished anything.   The other thing to consider is that any snooping like this is pretty much useless for a single transaction it would use heuristic algorithms.  While sometime you may not connect to a snooping node, sometimes you will and each txn provides another piece to the puzzle.  By doing blockchain analysis looking for probable change address and correlating those to IP addresses the privacy can be eroded.   Sure it won't be 100% of the txn 100% of the time but that isn't really the goal.

Practically speaking, if some wallet were to implement D&T's split routing, it would probably be a wallet which currently takes privacy seriously. AFAIK, there are only three wallets which seem to fit into this category:

• Bitcoin Core
• MultiBit HD
• Darkwallet

These are the only wallets I could find which avoid address reuse, can be used relatively easily with Tor, and do not depend on any centralized service. (I don't think Darkwallet has implemented Tor/SOCKS yet, but it's on their roadmap.)

So if anyone were serious about this, that's where they should probably be looking.

Also worth noting that the latter two aren't yet considered stable enough for general use by their devs, so I'd guess (it's just a guess) that a new feature request such as split routing probably wouldn't be very high on their priority list....

Edited to add: It looks like bitcoinj might consider adding support (https://bitcoinj.github.io/limitations#security-issues) for this one day...

I would add Armory to that list as well.   Still I think split routing can even enhance the privacy of SPV nodes.  Download headers through public channel and send bloom filter requests and outgoing txns through the private channel (tor/i2p/vpn). 

The one thing I would agree with you is that users of these wallets tend to be 'prosumers' and thus are more interested in stuff like privacy and enhanced security.  It is my understanding that most lite clients today don't even use SPV model but instead use a proprietary 'trust the server' model or if the use SPV they don't use bloom filters.  The fact that users continue to use them would indicate they don't really care about privacy concerns.

I didn't because doing so seemed redundant... it's dependent on Bitcoin Core for all if its networking needs, so if Bitcoin Core gained split routing, Armory would "inherit" it.


Completely agree, e.g. with MultiBit HD and/or other bitcoinj-based wallets if bitcoinj adds Tor & split routing support.


I think the situation isn't quite that bad. Mycelium uses a 'fully trust the server' model, and Electrum uses a 'query the server for an address' model (but Electrum does do SPV). Even with these two, Tor could help a little (although if they maintain long-term connections to the server, then they're leaking information related to addresses that are associated with one another, despite not leaking the actual IP addresses).

On the other hand, MultiBit (Classic and HD), Bitcoin Wallet for Android, and breadwallet are all pretty popular, and they're all "real" bloom-filter-using SPV clients.

Also to be fair, multisig wallets w/2FA trade privacy for security, and for some people that's a fair trade. E.g. GreenBits, even though it's a "real" bloom-filter-using SPV client, still needs to get the GreenAddress.it servers to sign their half of a 2-of-2 tx.

http://sourceforge.net/p/bitcoin/mailman/message/33607215/

I implemented what is effectively 'split routing' for Bitcoin Core some time ago (just a switch that makes it not relay transaction; so an additional utility can getrawtransaction and handle it some other way).  But it's not currently compatible with the conflicted detection in Bitcoin core because the transaction says out of the mempool until its heard over the network and erroneously shows as conflicted, so I've been waiting for that to change.   If someone is interested in working on this in Bitcoin Core, feel free to lemme know and I can point out what needs to be done.  Primary difficulty is just in writing test harnesses and test cases, because this area of the software is under-tested currently so we're not comfortable taking changes without accompanying tests.

It would be straight-forward on top of that to provide a small sidecar daemon that handled your broadcasting for you (including by using fancy things like a high latency mix network).

I always use a VPS for sending coins, so that's at least 1 problem for me that I don't have to deal with.

If you trust your vps provider.   

While we're discussing ways to make it harder to link IP address to txn creator, I have a related issue. 

How can we make it harder to link IP address to both creator (whose wallet still contains the address of the spent txOut) and recipient (whose wallet contains the address of the newly created unspent txOut)? 

Anytime somebody wants to know who owns a particular txOut (or for that matter who owned it and spent it a long time ago, since the wallet doesn't throw old addresses away)  they can easily find out.

You know those weird one-satoshi transactions that people have been getting spammed with for months and months now?

I knew it was an effort to track users, but today I was elbows-deep in the source code and I just figured out exactly how it works. 

Somebody is using this to figure out who (which IP address) owns (or owned) what txOuts.

Here's what's going on. 

• First, they send a tiny txOut to the address on the block chain whose owner (or former owner) they want to know.
• Second, they connect to a bunch of different nodes and send them bogus transactions that spend that txOut without fees.  Repeatedly.
• They don't know the address's private key, so they can't provide a good signature for that tx.  But they don't need to.
         
  • If they've connected to a machine that has the wallet containing the key of the original txOut whose owner they're trying to find, that node will disconnect them as a misbehaving node, because the keys they provide don't match.
  • If they've connected to a machine that doesn't have the wallet containing the key to the original txOut, That node will just reject the transaction due to penny-flooding prevention and no fees.
       
• Because they can tell which thing happened, they can tell whether the node at this IP address owns, or owned, the address corresponding to the original txOut.

@Cryddit: If your theory is correct, we have a huge privacy problem...
Also note that dust spamming is only required to link "zero balance" addresses to ip addresses since the same method could be applied to current utxos.

Bitcoin Core will sometimes respond differently to a peer sending it invalid transactions based on whether or not it hold the private keys for the inputs in that transaction?

If so, that's a bug which should be fixed.

It illustrates a good reason to separate the node functionality from the wallet functionality. Disable the wallet functionality in bitcoind and use Armory for your wallet and that attack won't work.

Actually, it seems the vulnerability has already been identified in 2013:
- vulnerability description (http://www.cvedetails.com/cve/CVE-2013-2272/)
- vulnerability description on the wiki (https://en.bitcoin.it/wiki/CVEs#CVE-2013-2272)
- related bitcointalk post (https://bitcointalk.org/?topic=135856)

Wasn't that fixed 2 years ago?

I hope so but I'm not sure why fix deployment is stuck at 97% (https://en.bitcoin.it/wiki/CVEs#CVE-2013-2272)

Send the BTC via a VPN or Internet client connected with Tor / VPN.

That isn't what Cryddit is describing at least not precisely, and of course that was fixed years ago. (The 97% thing is just because there are long forgotten nodes left running on old software that no one maintains; they likely don't have wallets.)

I don't believe Cryddit is correct; but his description isn't precise enough for me to tell for sure.  I /think/ what he's saying is that I first tell all nodes a dust output that nodes won't mempool and likely won't get mined, then later I give nodes a transaction spending that transaction with an invalid signature. To most nodes this second transaction will be an orphan (spends an input they don't know about).  But Cryddit believes the recipient of the transaction will DOS ban you.   I think this is incorrect: first, if the transaction was mempool rejected then it wouldn't end up in their wallet unless it gets mined (in which case it would be available in the utxo set to all nodes), secondly even if it was in their wallet the wallet is not consulted for lookups on incoming transactions.  But perhaps Cryddit would be kind enough to clarify his thinking?

There are ways we know those dust txn could be used to reduce users' privacy though... send them to nodes that don't implement a dust check and then observe them rebroadcasting them when they don't get mined for a long time. This is part of why the anti-dust rules were implemented.

Yup. Tor should prevent the issue with ip addresses.
This kind of attack might also have been used to clusterize bitcoin addresses and, if I'm right, it should work even if the node is connected with Tor.
It's less concerning than leaked ip addresses but it's still a leak.

Thanks for the info ! I assume that Cryddit talks about txos already mined (ref. to 1 satoshi txs spamming the blockchain) but better to let him confirm.

I may be misreading the source, but: there is definitely an observable difference between a DoS ban and a penny-flooding disconnection with a rejected transaction.  

And those 1-satoshi transactions, AFAIK, are still getting mined and into the block chain somehow; I would presume that either some node operated by the attacker is mining them, or they are taking advantage of some bug in the security of one of the existing pools.

And it looks to me like a node that repeatedly sends tiny transactions with no fees, at a high rate, eventually gets disconnected due to a "penny flooding rule" - but not DoS banned.  The transaction is rejected, the sender is disconnected, but if the sender tries to reconnect, say, six hours later, they won't be rejected.

And it looks to me like a node that repeatedly sends a tx with an invalid transaction, gets disconnected AND DoS banned, and if the sender tries to reconnect any time in during the next 24 hours, the connection gets rejected.

If this has been fixed, which of these things am I wrong about? Is it not the case any more that the client identifies an incoming tx with a bad signature as an invalid tx?  

A txn with an invalid signature will be invalid to all nodes.   All nodes validate signatures of txns and will not relay invalid txns.  A node sending invalid txns will be seen as misbehaving and will be banned.  Wallet behavior is different than node behavior.  A node should respond consistently based on what is known publicly (regardless of what private keys are in the local wallet or even if there is a local wallet).  If that isn't the case then there is an information leaking bug.  There was a 'penny flood' bug in the past but it didn't involve invalid signatures and has been patched consistently as of v0.80 (plus some earlier versions).


Exactly.  All nodes verify txns before relaying thus all nodes will ban a node sending a txn with an invalid signature.


Transactions which have outputs less than the dust threshold are valid. They are non-standard but any miner can include non-standard but valid txns in the block to be solved.  Some pools will accept non-standard txns.

I've just received dust from an address that seems to be linked with factom.

The transaction: https://blockchain.info/tx/a1b0b0019961b7906d8982416693d5868505aa8b38f5cc13028499a5ac555c85

The dust-sender (12HDgJEGdf3Wqr3ha5iUL2r8RcPa7BnBj2 (https://blockchain.info/es/address/12HDgJEGdf3Wqr3ha5iUL2r8RcPa7BnBj2)) was funded by 1FactomGnNFTsTVx8jiGjcLKDpyL65GDsH (http://1FactomGnNFTsTVx8jiGjcLKDpyL65GDsH).

Another IP discovery attempt? Is Factom somehow involved?

Rampion,

Congratulations you are first person to notice / post about the little surprise the Factom team sent out today!

We purposefully sent a little bitcoin to your address from the 1Factom vanity address.

The reason the Factom team sent these bitcoins out is to recognize you as an early adopter / supporter of new blockchain technology projects. (Your address was among many on the bitcoin ledger who previous supported other community projects)

We hope you will check out the Factom Software Sale and use this bit of bitcoin to claim your first Factoid(s) and thus be able to join our community as a beta tester / early adopter.

https://koinify.com/#/project/FACTOM

If you aren't interested, that's cool just keep the BTC as a small tip for being an active part of the community.

You rock.

Love Team Factom

Thanks djohnston, I supposed it could be advertising but it seemed strange the dust didn't come directly from the vanity address (https://blockchain.info/es/address/1FactomGnNFTsTVx8jiGjcLKDpyL65GDsH), I guess it was sent from a change address

This isn't the right thread for advertising scamcoins, but I suppose it is on topic in a kind of meta sense.

I assume the sidecar daemon needs to be notified somehow? So it doesn't have to poll.
Would -walletnotify fire?

I believe it would-- but I wouldn't bother with wallet notify. Why not poll? the whole idea is to be private-- obscuring exact timing would help, and polling even once per few seconds would be inconsequential work.

Pond protects its users from traffic analysis by running every (IIRC) 10 minutes against the server (connecting over Tor, of course) and moving a constant amount of data, regardless of if there are any messages. There is also a transact-now button if you're being impatient.

Glad to see this discussion. Cross posting something that may be helpful:
https://bitcointalk.org/index.php?topic=1083961.msg11561739#msg11561739


It sounds like you are saying that if I am using both Tor and a VPN for example, that bitcoin protocol could be configured to support some of the traffic going off along Tor and some of it going off along my VPN. 

(...)


If the user would be creating a signed transaction (or indicate preferences for the wallet to create a transaction that would be broadcast at a later time when a certain threshold is met) without broadcasting immediately and could specify that the basic conditions as to where and when the broadcasts should occur and let the wallet handle the rest, this sounds good, so long as the recipient does not have trouble receiving what is being sent. 

Posting an update here:

"Barclays partnering with Chainalysis in October and Coinalytics raising a $1.1m seed round in September. In August, Elliptic won "Security Project of the Year" after launching a blockchain visualization tool for the bitcoin blockchain.

Currently, Coinalytics... (blah blah blah)"

see http://www.coindesk.com/juan-llanos-blockchain-analytics-coinalytics/ for details. 

Once again, this calls to mind the necessity of implementing better privacy and / or anonymity solutions in bitcoin, which have not yet been actually implemented in Core ~ see as example:
https://github.com/bitcoin/bitcoin/issues/3226