Bug/attack vector: fixed 60,000 sat tx fees

Incognito pays a fixed 60,000 Satoshi transaction fee on outbound Bitcoin transactions.

this is a very serious issue

I disclosed it to @andrey privately as soon as I found it. He has once again requested that I write it up as a post here on the forum. These two issues combined means that it’s fairly trivial to financially attack incognito. An attacker would not need to work hard to exploit this in a deeply damaging way. The team is showing a remarkable degree of transparency here, and I wouldn’t have thought less of anyone or the incognito project if they didn’t want me to make this post public.

While I was looking into my ability to dramatically underpay fees by paying these in PRV or PBTC, I discovered something much more serious.

Exact issue
It seems that whatever system or process incognito is using to sign Bitcoin transactions is paying a fixed fee of 60,000 satoshis.

So for example, when I send myself 20,000 satoshis, It costs incognito three times that for the transaction fee.

This has several effects.

One: it means that the attack that I documented in my earlier post is in fact very serious. That attack wasn’t so very serious on its own, if incognito were paying regular Bitcoin transaction fees. However, incognito was paying 60,000 satoshis for each transaction.

Incognito wasting a lot of Bitcoin needlessly, tossing it to the miners.

I’ve done this five times now. I’ve cost incognito 300,000 sats.

If I kept doing if over and over, even just from the Android walllet, I could easily cost incognito a million sats. I got a third of a way there just demonstrating.

If an attacker automated this, kiss your hot wallet goodbye. They could cost you 60,000 per tx and get one transaction in each 40 second block (I think).

Then they could parallelize the attack.

And if they weren’t too tech savvy but very mean spirited the could parallelize it very cheaply by having friends put incognito on their phones and just hammer on it. And it costs the attacker only time and inbound tx fees.

this includes the transaction that I made yesterday to ensure that I could take PBTC out of my wallet and into a real Bitcoin wallet. so so far, I am at five out of five transactions paying 60,000 satoshis for each transaction. I am testing a fifth transaction like this now. After that, I will stop spending incognito satoshis on my transaction fees until this has been resolved. I think that five out of five is sufficient. I am sharing the four that I did with my testing address here:





And I’m done. Not going to withdraw any more Bitcoin until this is fixed. I’m happy to pay the miners on my own :slight_smile:, and pay them my usual 1sat/vbyte.

Still holding pBTC, this bug doesn’t threaten my pbtc (I think. I imagine you guys don’t keep everything in one giant hot wallet but if you do… This attack could eat all of it)

There are various ways of estimating an appropriate Bitcoin transaction fee, none of them work perfectly. They are all based on the history of people’s transactions, and how long they took to clear the mempool. Basically, the more that you pay, the faster your transaction is going to get out of the mempool.

Currently the cost to be included in the next block is 1 Satoshi per byte, which works out to about 138 satoshis per transaction, with variances that depend on the exact size/type/construction of the transaction.

Paying a fixed tx fee of 60,000 sats per transaction (about 269 sats per byte) is grossly overpaying. Even when the mempool is fairly full, I typically pay 1 Satoshi per byte unless I am in a hurry.

This is a far higher priority issue than the other one! Incognito currently pays a few hundred times more than is needed for inclusion in the next block.


Step one: Triage-- do this or an equivalent now. It is urgent.

Go directly to the system or process that is currently signing outbound BTC transactions, and go to it now. If it’s currently unable to take advantage of fee estimation for inclusion in the next block, no problem. Set the fee to three hundred satoshis per transaction, it should be fine for getting into the next block in the majority of circumstances. Now you’ve reduced the severity of the problem by 200x.

Step two: fix the problem (long-term. Do the triage first. The triage is very important.)

Several ways to approach this–

  1. let the user set the fee level, as is common in many wallets.
  2. estimate the fee needed to get into the next block somewhere and base the fees on that.
  3. some wallets feature a combination of an automated estimation and manual setting of the transaction fee.

The triage alone will be enough to bring you to safety. There are other ways to do the triage, I listed the one that would be fastest to execute based on the evidence at hand.

If you want help with either the triage or long term solution, I’m around.

neither bug I reported today can harm users of incognito* **. They are both a threat to the founders/foundation/“the Bitcoin wallet that is paying for fees” only.

*We are all harmed if incognito loses its BTC, because we like incognito.

**As mentioned above, if all BTC is in a giant hot wallet, we can lose the BTC that backs our pBTC and end up with nothing. But I’ve met incognito team members in person twice, and my impression is that wallet management is much better than “giant hot wallet with all BTC”… I have that impression because of their demeanor and knowledge.

Second note
Other big issue here is that this is asymmetric. It costs an attacker only the inbound tx fee to force you to spend 60,000 sats, and the attacker only needs to have, let’s say 1,000,000 sats to run it on several devices in parallel.

Imagine what they could do with 100,000,000 sats or more or they wrote code to automate this.

…but as mentioned above, this doesn’t even require automation to be dangerous. It’s quite dangerous as it currently is.

Third note:

A malicious person with one Bitcoin and zero tech skills could do like:

Shield 1 Bitcoin for a transaction fee of 200ish sats.

Recruit 100 lieutenants with mobile devices. Let’s just assume they’re trusted. Give a million pBTC sats to 100 guys for almost no fee. Each of the 100 guys makes 50 20,000 Satoshi outbound transactions, one by one, and sends the 20,000 satoshi transactions back to the attacker.

Attacker cost: 140-250 sats for the inbound transaction

100 (guys) * 50 (transactions per guy) = 5000 transactions

5000 transactions * 60,000 sats = 300,000,000 sats (3 BTC, which would end up in miners pockets)

So, assuming the attacker can get a hundred guys who will actually send his funds back to him, he can drain 3BTC in maybe a day or so.

It gets a lot worse with automation. If the attacker has tech skills…

Fourth note

Some of the kinds of people and organizations that don’t like privacy, aren’t financially motivated. They’re motivated by their desire to preserve their control. They don’t care about acquiring the Bitcoin, they only care about ensuring it no longer belongs to incognito, because incognito supports privacy. They’d love to see something like incognito fail, because it makes their lives easier.

I am of course talking about:


What I mean is-- the folks who might attack incognito, might either have 100 employees to do something like this, tech skills, or not care if their 100 lieutenants never returned the 1,000,000 sats.

Pretty sure they’ve actually got far more than 100 employees, high end tech skills, and don’t care at all if the attack costs them one Bitcoin, provided it costs incognito 3btc.

But due to their high end tech skills, they could probably do this with 1-5 programmers, and a few Bitcoin, and get all the Bitcoin back. Only cost is labor and the inbound transaction fee.

5th note
I got today’s wallet update, and did another test transaction of 20k sats to myself.

The fee is now much lower, but it is still not acceptably low. Certainly it’s still many times what I’d normally pay myself to make a BTC transaction. It’s still much more than the current rate to be in the next block-- 8,000 sats instead of 60,000 sats.

This attack is still viable at 8000 sats per transaction. An attacker could just grind on it. The attack would now be much slower. Users need to pay fees.

Doing a final transaction and heading to bed.


@jacob, we are redeploying the code with the triage you suggested as of now (the exact sats/byte might differ a bit because we want faster confirmation). FYI, we increased the fee as a hotfix for black Thursday. Somehow we messed up and didn’t revert the code after everything went back to normal. Lesson learnt!

Thanks for bringing our attention to this.