Setting nLockTime on all transactions allows offline clients to be fingerprinted

keystrike commented at 6:59 am on March 17, 2017: contributor

An unsynchronized client sets nLockTime to its current height (or possibly slightly further back). There is a privacy implication which was not discussed in pull #2340. Since offline clients have a different chainActive.Height(), it is possible to link different wallets to individual clients. This additional metadata can tie everything back to the client’s blockchain state even when different wallets are swapped in.

One possible fix would be to not set nLockTime on a transaction if the client has not recently connected to the network.

laanwj added the label Privacy on Mar 17, 2017

laanwj added the label Wallet on Mar 17, 2017

laanwj commented at 9:08 am on March 17, 2017: member

This was one of my gripes as well when nLockTime was started to be added by default. Note that there is some mitigation for this by randomizing the nLockTime in one of then cases:

0    // Secondly occasionally randomly pick a nLockTime even further back, so
1    // that transactions that are delayed after signing for whatever reason,
2    // e.g. high-latency mix networks and some CoinJoin implementations, have
3    // better privacy.
4    if (GetRandInt(10) == 0)
5        txNew.nLockTime = std::max(0, (int)txNew.nLockTime - GetRandInt(100));

So up-to-date nodes will occasionally send older locktimes as well.

There might be additional privacy improvements possible, of course.

ghost commented at 10:55 pm on March 22, 2017: none

Also affects hybrid full block SPV mode #9483 during IBD

keystrike commented at 12:10 pm on June 27, 2017: contributor

I found a total of 33 old locktimes in the blockchain in 94 transactions, which indicate offline wallets which can potentially be fingerprinted using this technique.

One example is locktime 267128 which can be found in 7 transactions including these two: 37077fdf90be0db661deacd4e2ebf0b786e820782757bd1f18e25159840b9e8d cf6ba6f7896426e6c2137118482b2e09a55bae1384e565dc40685e75014fa527

My output is here: https://www.jamesevans.is/locktime.txt The first column contains the locktime and the subsequent columns are the differences between that locktime and the block each transaction was mined into. Adding the first column with the other columns will yield the block containing the transaction. My main goal was to get a feel for the scope of this issue, so although this work can be easily replicated, I haven’t included further analysis due to privacy concerns.

ryanofsky commented at 9:22 pm on January 9, 2018: member

The current implementation of #10040 (984e7ae2fc6319fbd1071fa36efa416a8321d62b) purports to fix this issue, but I’m not sure if the IsCurrentForAntiFeeSniping function there would return false if the node is offiline.

keystrike commented at 3:20 pm on January 15, 2019: contributor

This has been fixed with #15039.

keystrike closed this on Jan 15, 2019

DrahtBot locked this on Dec 16, 2021

Setting nLockTime on all transactions allows offline clients to be fingerprinted #10020