Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
keystrike opened this issue Mar 17, 2017 · 5 comments

Comments

Projects
None yet
4 participants
@keystrike
Copy link
Contributor

commented Mar 17, 2017

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

This comment has been minimized.

Copy link
Member

commented Mar 17, 2017

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:

    // Secondly occasionally randomly pick a nLockTime even further back, so
    // that transactions that are delayed after signing for whatever reason,
    // e.g. high-latency mix networks and some CoinJoin implementations, have
    // better privacy.
    if (GetRandInt(10) == 0)
        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.

@pvasin2

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2017

Also affects hybrid full block SPV mode #9483 during IBD

@keystrike

This comment has been minimized.

Copy link
Contributor Author

commented Jun 27, 2017

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.

pvasin2 added a commit to pvasin2/bitcoin that referenced this issue Aug 19, 2017

@ryanofsky

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2018

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

@keystrike

This comment has been minimized.

Copy link
Contributor Author

commented Jan 15, 2019

This has been fixed with #15039.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.