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:

3EwkNyB6sqE1ypfW8NLGrX6ESs2omyvBmG

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?

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.

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.

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.

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.

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 wou…

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.

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.

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

I deposit 1 BTC to get pBCT

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?

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.

The core team pays the fees: not scalable when Incognito grows big enough (but this is a good to have problem ). 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!