Attack: Paying Bitcoin miners for "free" with incognito up

I think I’ve found a way to economically exploit incognito, and I think that I could run this attack much more effectively if I were using CLI tools.

Here it is:

Open up your wallet, and click send from the home screen. This won’t work if you first go to your pbtc wallet and try to send from it.

Click out network and select pbtc.

Next, set the payment amount to one Satoshi.

Choose a wallet address of yours or a friend’s. Can’t be randomly firing off satoshis, they’ll be worth a dollar each before all this is over and crypto rules the world.

Then, pay your transaction fee in PRV. The wallet has quoted me fees from .00000001 - 0.00000007 PRV for this task.

So, this attack steals satoshis from… I guess the foundation. The PRV price of a BTC transaction should always be at least equal to one Satoshi per vbyte.

There’s some rate limiting. I can’t fire off these transactions rapidly, but I’ve fired them off nonetheless. They do show up in my transaction history.

I haven’t seen any of them hit the Bitcoin mempool yet. So if I’m not actually making these transactions successfully, then there’s another bug, because from the wallet, they look successful.

If I were familiar with the command line tools, I could automate this attack, and if I had a number of machines doing it at once, it could have an impact despite rate limiting.

The PRV fee for out network transactions must be equal to or greater than their cost in satoshis otherwise an economic attack is possible.

If these transactions are not actually going through, then the software is malfunctioning by reporting to me that they are going through.


For ease of diagnosis, here is a throwaway BTC address I used for this:


I am also able to pay trivial Satoshi amounts for Bitcoin transactions, which would also effectively steal satoshis from… Well, I don’t know who but…


Sometimes the wallet shows me this:


But other times it does not and I am able to complete the transaction, as you can see in the screencap of my transaction history above.

Keep in mind:

if I were sufficently motivated and equipped with enough BTC, this minimum transaction amount would be meaningless. I could shield a whole Bitcoin and make many, many transactions for free, or spread that Bitcoin over many accounts, and do the same thing. This is a bug with fee amounts, not minimum transaction sizes.

Another successful tx:


And another:


Do the CLI tools I’d need to demonstrate this attack at speed exist? Happy to show how that could work, too.

I imagine I would need either multiple incognito addresses or multiple machines to make it go really fast, but it should be possible.

Note: I disclosed this attack to @andrey before beginning, and he requested I make this post in the interests of full transparency. I do not encourage anyone to exploit this attack, and I do not know if I will ever recover the sats that I have paid fo demonstrate it. Please use this information to strengthen Incognito, not to harm it. It is likely not very difficult to resolve.

Recommended resolution:

Some wallets don’t let me send a single sat transaction… but this is why we have transaction fees. From Samourai, the smallest I can send is 1000 sats. From Green Wallet, it’s the same. Electrum lets you do 1 sat transactions, if you have attached if to your own node, I think. Otherwise it’s rejected due to “dust outputs”. But just like “taint”, dust is just another made up idea.

Of course, dusting while not paying a transaction fee of 136 sats for a 1 sat transaction, that’s an actual problem.

There are various reasons for wallets and nodes not permitting “dust” I’m sure. But my thinking is: if I’m willing to pay for a transaction, my wallet should let me make it, even if it’s for a silly small amount. Maybe I’m using the transaction itself to trigger a software process… Who knows?

  1. remove the minimum amount, because it doesn’t help anything. Let users send 1 sat transactions any time, and pay the full fee for them.

  2. ensure that the tx fee in PRV is always higher than or equal to the equivalent fee in sats. Could even use the pdex as a reference point for this.

  3. ensure that the tx fee in pbtc is always higher than or equal to the Bitcoin network fee in sats.

Update, and how I realized this was an issue

Yesterday I took some pbtc and sent it to a BTC wallet of mine, just to check that I could get it out, once I had put it in.

It worked, and I paid my fee in PRV, so it was next to nothing.

Well, here’s my 20,000 Satoshi transaction. Like my transaction from yesterday, I think it’s going to hit the mempool, unlike all my 1 sat transactions.


Now, imagine I wanted to harm the project. I could automate this, and do it very, very rapidly.

I just did two transactions to the address above:

20k sats

**Very serious problem. You are paying 60,000 satoshis per transaction. It is far, far too much.
Paying 60,000 sats per transaction transforms this attack into something devastating. **

100k sats

This one is very bad. Please look at it carefully. Incognito paid 267.9 sats/vbyte! (I did not do anything different to cause this. You’re dramatically overpaying miners somehow. I usually pay 1 sat/vbyte.

I think that these will actually arrive in my wallet. This also means that I can send them back to incognito combined with a single fee, and run the attack again, probably in 20,000 Satoshi segments.

So, there’s no issue with the minimum amount and I even suggest that you lower it to 1 Satoshi.

Be the wallet/node that fully supports Bitcoin and doesn’t censor transactions smaller than 1000 sats. Give users the full power of Bitcoin.

The only issue is with the fee pricing. It lets me spend your money.

Researching for this issue led me to discover a second and much more serious issue

My 1 Satoshi transactions never arrived at my wallet, which is a third, but not too serious issue

Except that’s kinda serious too, because I no longer have those sats and they never arrived.


So at first you have no satoshi but send Out Network still successfully. Am I get it right?


I have just tried but cannot …

No, I have satoshis in my pbtc wallet, and am spending them.

In fact I do not benefit from this attack in any way, except that I do not have to pay fees to the miners. I am freeloading off incognito’s payment of the fees.

The risk from this attack is that someone begins doing it at scale and drains Bitcoin from whatever account is used to pay transaction fees.

1 Like

Try again.

It works intermittently.

Oh, i got this kind of attack. But we still cost PRV fee right. Although is very small in USD price compared to BTC. At first stage this could be a wonderful idea to attract user like sale off transaction fee, if user use Incognito to transfer BTC.

Ok, I got your point. I think the external transaction fee is now covered by the foundation.

1 Like

I just did it again:


Maybe the txs are being rejected at some level because they’re under 20000 sats, which seems the minimum the ux inconsistently reports.

Let me demonstrate this at 20000 sats, how it is still very harmful.

Next, imagine that this attack was scaled.

I disagree. It creates a serious risk from a motivated attacker. Watch what happens next, when I change the amount from 1 sat to 20,000 sats.

I predict it is going to hit the mempool, unlike all my 1 sat transactions. And that’s where the real trouble begins.

Hi @Jacob,

After reading your post here, I can see a trouble about the economic fee.

  1. I deposit 1 BTC to get pBCT
  2. On the other hand, I make a send out network tx to my friend BCT address wallet with a little bit 0.000000xxx BTC, and repeat a lot of time

In this way, 2nd tx will get a little PRV fee from you. But to send BTC to your friend, “founder” need to spend BTC fee a lot of time for only 1 tx of small tx 0.000000xxx BTC. And PRV value is less than BTC a lot, right? That means although I don’t have any incentive for that, but I only spent a little BTC, and PRV, I can make founder lose a lot of BTC for fee, right?

1 Like

Yes. If this attack were scaled, I could spend significant founder/foundation BTC on transaction fees.

I couldn’t steal founder/foundation BTC, but I could drain it.


Yeah, @Jacob, I understand the point you are making. Thanks bro.

@phuong @binh @duc, I think we need to discuss this further to have a better solution for the economic impact of this issue.

Please contact me when you guys have time


Any time. I’m a huge fan of incognito!


Fee pricing is malfunctioning in pbtc also. If I pay my fees in pbtc, they’re much lower than the usual 140ish for 1sat/vbyte.

So no matter if I pay fees in prv or pbtc, you will experience this problem every time.

Also, the transaction size doesn’t really matter. An attacker could use 10,000 BTC and send one full Bitcoin each time, and still successfully execute this attack and drain foundation/founder BTC stash that’s being used to pay for fees now.


hi @jacob, you were correct to assume that it’s the foundation that paid for those txs. To be more precise, it’s from the Incognito DAO fund that fuels the core team’s expenses.

When we designed the bridges (both trusted and trustless), we prioritized UX as one of the most important factors.

There’s a trade-off between the 2 approaches:

  1. Letting the users provide the fee themselves: complex UI/UX (which denomination is allowed, fee level, miner’s preference, etc)

  2. The core team pays the fees: not scalable when Incognito grows big enough (but this is a good to have problem :smile:). When it comes to that, we will have the resources to implement a better mechanism.

As you can see, we went with the 2nd approach. The implementation is not perfect as hackers can burn a lot of tokens by depositing and withdrawing repeatedly. The hotfix for now is to impose a minimum amount of tokens per withdrawal. This increases the required capital to perform the attack.

For long-term solutions, there’s an ongoing discussion about possible ways for users to supply the tx fee themselves. We’re looking for the best solution that won’t result in an overly complicated UX.

Nice job finding these issues. The whole Incognito community is moving at a rapid pace, so not everything is perfect. Keep hacking away and if you find anything of interest, do let us know!