Thinking about ways to make it more difficult to link IP address to txn creator.

[btchris]

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 for this one day...

[1714958941]

1714958941

[1714958941]

1714958941

[DeathAndTaxes]

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.

[btchris]

I would add Armory to that list as well.

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.

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). 

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

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.

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.

[justusranvier]

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

[gmaxwell]

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).

[nambich]

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.

[spin]

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.   

[Cryddit]

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.

[laurentmt]

@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.

[justusranvier]

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.

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.

[laurentmt]

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.

Actually, it seems the vulnerability has already been identified in 2013:
- vulnerability description
- vulnerability description on the wiki
- related bitcointalk post

[hhanh00]

Wasn't that fixed 2 years ago?

[laurentmt]

Wasn't that fixed 2 years ago?

I hope so but I'm not sure why fix deployment is stuck at 97%

[Enzyme]

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

[gmaxwell]

Actually, it seems the vulnerability has already been identified in 2013:

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.

[laurentmt]

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

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.

Actually, it seems the vulnerability has already been identified in 2013:

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.

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.

[Cryddit]

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?  

[DeathAndTaxes]

       

• 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.

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).

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

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

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.

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.

[Rampion]

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) was funded by 1FactomGnNFTsTVx8jiGjcLKDpyL65GDsH.

Another IP discovery attempt? Is Factom somehow involved?

[djohnston]

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