Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Observations: A LOT of Fusion Transactions #146
In recent days, multiple chains, forked from TurtleCoin, got flooded with tiny transactions to DOS the network benefiting a subset of pools not affected. I were consulted to take a look and analyzed the structure of fusion transaction more deeply and tried to come up with a, more or less, formal description of how such an attack could be implemented. In the following, I describe how an attacking vector could be implemented using fusion transactions, how this can be exploited for personal benefits and point out some possible solutions.
CryptoNote is based on the UTXO model without CTs and the usage of ring signatures to obfuscate coin flow using so-called mixins. Therefore used coins of amount
As a result of a transactions consists of multiple input vectors of coins being used, every vector contains the real output and the mixins. Formally such transaction input would look somewhat like this:
Next, we need to address the output generation. Every output consists of an amount and a public key
Lastly, the inputs need to be signed such that the integrity of the transaction can be checked. Therefore each input, including mixed inputs, is signed against a hash of the transaction excluding the signature itself (prefix hash). As a result the transaction gets multiple signatures attached
Note this information is sufficient to derive the transaction fees. Fees are coins not reused in the output and therefore burned. The miner can sum all fees up, mined, and generate new coins accordingly. The fee of a transaction is given by
There are also some additional fields required to setup but that won't scale with inputs/outputs used and we will neglect them for now as they are not needed for now.
A fusion transaction is a mechanism to generate higher outputs for new transactions such that next time you use those you do not need to take too many inputs, to sum up to a larger amount you want to send. Without fusion transactions, you end up with hundreds of small outputs and once you want to send a large amount the number of inputs required is so large that the underlying transaction exceeds a binary size threshold
To overcome this you send multiple transactions to yourself with small inputs and a larger output (changing your cents to dollars). This would require to pay fees every time you want to fuse some of your inputs. Therefore CryptoNote has a special form of transactions called fusion transactions.
In contrast to normal transactions, a fusion transaction does not require any fees. To protect the chain, it requires additional properties, the transaction must fulfill.
The size of this input required in the transaction depends on the mixing factor.
We can conclude the size required for every input used as
Next, we need to analyze the number of bytes needed for a variable number of outputs.
Thus the size required for outputs is
There are some additional fields required for a transaction that may vary.
Finally we conclude the maximum size of a transaction with variable number of inputs/outputs as
We describe defusion as a normal transaction with a single input (or just a few) and many outputs. For further explanation, it is required to analyze how many outputs can be generated for a single transaction with minimum fees.
First, we need a minimum transaction size we are allowed to push into the network. The maximum typically varies over time and with the medium size of the last blocks but for the sake of simplicity we always just use the guaranteed minimum transaction size accepted.
We will need approx a single input for the defusion transaction thus we can deduce
As an example, we use the TRTL configuration to compute those values.
Hence, in the case of TRTL, you are able to create about 2.9k outputs in a single transaction.
The previous analysis is sufficient to create a schema for extensive transaction generation. I will now derive a template for fusion transactions such that the output of one defusion transaction can be fused again and again until we reach a point where we cannot generate any fusion transaction anymore and are forced to defuse again.
In order to do so, it is crucial to generate the maximum amount of new outputs eligible for fusion transactions such that we can reuse them for new fusions after. However, this gets a bit tricky with the canonical form.
The canonical decomposition enforces us to use output amounts according to the decades of the sum of our inputs. For example, if we fuse
Ideally, we choose our inputs such that they sum up to some amount having exactly
Further, we will assume that
It turns out that choosing the optimal defusion strategy is more tricky than expected. Therefore I will present a more simple approach, none optimal, with crypto note parameters taken from TurtleCoin.
My approach defuses amounts to a set of multiple of ten and then fuses them such that they can be reused in kinda the same manner. It is far from perfect but shows a sequence of 292 fusion transactions made with an amount of
Here is a table summarizing the process.
The fusion transaction size threshold is neglected here because every fusion transaction uses the minimum amount of inputs and is far away from its threshold.
Closing The Cycle
Please note that during the fusion process no coins get lost as we do and must not pay fees. The final 102 outputs are fusioned again into 8 usually formed fusion transactions yielding at most 26 new usable outputs.
Based on the previous example we can conclude the size of our defusion transaction. We are required to generate 2730 outputs for the fusion cycle
I showed a cycle of a defusion transaction and multiple fusion transactions. This cycle generates a total of more than 300 transactions for single fee payment (in case of TurtleCoin
In this section, I want to mention three attacking scenarios this approach could be used for. Before doing so I want to shortly give an economic perspective of the costs of running a cycle. At the time writing
This is the most obvious one where the attacker simply wants to push as much data into the blockchain as possible to increase the block size. Every fusion transaction in the cycle uses 12 inputs and 3 outputs generating 1'004 bytes or 2'029 bytes with a filled transaction nonce header. This sums up to a total of approximately
Denial of Service
The cycle generates a lot of inputs (
This attacking vector does not apply to TRTL but the legacy code in many forks are still applicable to this. The default routine to fill a block mined prefers fusion transactions over normal ones. With that amount of transactions, the entire block would be filled with fusions all time long and other transactions will not get mined meanwhile.
First the most obvious is the removal of fusion transactions, replacing the current transaction structure with moneros RCTs or byte coins amethyst for example. However this may be no feasible as a hotfix, is not the intention of a TurtleCoin based blockchain or maybe just out of scope for the developers of the blockchain.
Another solution would be increasing the fusion ratio, but this may disadvantage other users and may not be as constructive, especially for low-value coins with high supply. The minimum fee could be increased, which would increase the investment for every cycle, again these disadvantage users using the coins for micropayments. A scaling fee with transaction size may also not work as fees are only paid at the end of a cycle.
To be honest there comes no fundamental solution into my mind with the usage of fusion transactions. However, I can give some suggestions for general good practice that may strengthen the network in case of an attack.
Please note that all those configurations should be configurable or disabled. Especially auto banning is a difficult one, any bug in the implementation could be exploited to force the node to ban regular nodes. However, in my opinion, having different security strategies and different configuration running strengthens the network as it gets less attackable by a single point of failure.
Thank you for an excellent review of this Fusion-based attack vector. Kudos.
Your analysis provides a great deal of food for thought. imho, the use of this attack vector, or similar, over recent days, has disabled, or greatly challenged a number of related networks.
Right i know you guys hate me here but i have fixed this issue. You may have heard rumors but i have developed kify, a protocol that makes 51 attacks next to impossible and tx spam attacks severely blunted. it uses 3 of the methods you prevented plus two custom ones (this is for the tx spam attack prevention):
Overall what I've read is "business as usual" if a pool goes down then that to me is "pool operator doesn't know what they're doing or how anything works" can't really mitigate that at the network level.
I had three nodes running during this
Influx of transactions
Two of them running on the same Linux host, they kept on working.
As for the ideas about killing off nodes sharing transactions, really? Kind of defeats the purpose of a network of transactions...
Scaling transaction fees based on n transactions in the pool. This isn't needed, again a pool operator has the source code, they can alter it however they need. One way I'd alter it is by reducing the size of the pool and simply keep higher fee tx and keep popping off tx at the bottom, as miner i don't need to include all tx in every block, this is a network of miners and if the person doing the tx wants their tx in a block and the pool is full, well they have a lever they can pull.
A large influx of transactions is what happened to call this an attack is disingenuous...
@michael-herwig You've provided a good write up of the symptoms the network sees when there is a large influx of transactions. The detail you've provided is good information for those that haven't spent considerable time working in the core software. However, I refuse to call it an attack on the network itself as the network is designed to handle such transaction traffic.
I'm going to take a quick moment to discuss each of the possible solutions you've outlined.
How does one label a particular node as "malicious"? What stops an attacker from spinning up dozens if not hundreds of nodes to bounce this around? What protects public nodes from being labeled as malicious due to such use thereby causing larger disruptions to the user experience? Banning nodes in this way does not prevent the actual problem from occurring and as you said, this isn't really a viable mechanism. This is also very likely to cause issues with consensus as of the high risk of mistakenly banning a "good" node.
Again, how do we determine what isn't malicious without causing issues with normal multiple output scenarios (ie. pools, service, etc)? This is a slippery slope that would cause major issues with how transactions are handled across the network at the detriment of the network as a whole. As I'm sure you saw, we recently put through code updates to prefer regular transactions over fusion transactions in the block template construction to help make sure that normal transactions move through despite transaction pool load.
We've started that discussion once already and it is not going to happen any time soon. Even if we did so, that only addresses one small piece of the symptoms of the underlying issue itself.
How can I say this delicately. No, just no. All this does is delay the inevitable whereby the fusions come later rather than right now. It's literally robbing peter to pay paul. Not to mention that huge amounts of hands on hips that we'd see from users who were trying to perform regular transactions and are waiting on fusions to complete to do so. This results in a very poor user experience.
Again, what is a malicious node? What constitutes spamming? If you start disconnecting peers like this you're forcing nodes to come off chain and if those nodes are operated by pools (or other miners) then you're going to cause a whole lot of alarmist measures as the chain forks all over until the network resolves itself.
All this being said -- none of the above do anything to actually work towards rectifying the cause of the problem. The problem itself is defined as the node's inability to properly keep up and respond when it receives a large influx of any types of transaction. It's far better to work to fix the real problem versus trying to manage symptoms. I (as well as a few others) firmly believe that the best course of action is to refactor/rewrite the core node software such that the validation and handling of new transactions/blocks/etc does not, in any way, interfere with the node's ability to perform it's other critical functions including responding to RPC requests, maintaining it's local copy of the chain, etc. Anything short of working to solve the real underlying issue is, in my opinion, an ill-fated effort that causes more harm than good.
I advise you not to waste your time submitting a PR. It'll save us the hassle of closing it when you do.
@brandlonlemham - so you point blank close PRs without even considering the code inside? It's a revolution protocol that makes TXs resurrect only 1 confirmation, TX spam attacks impossible and 51 attacking next to impossible. Don't be indifferent because you hate me, it might help
Perhaps you skipped over the rest of my post. I'm indifferent to who submits such a PR whether be you, Z, michael, satoshi himself, or pick your favorite deity. The fact of the matter is based on the comments I posted above the solution you've outlined above belongs nowhere near the TurtleCoin mainnet.
Is this it? https://github.com/LeoCornelius/kify-protocol
What follows are a series of pictures taken from the TurtleCoin block explorer, during the recent challenge.
The network response appears to be substantial, considering the pre-existing hash in the order of 300-380 MH/s.
Q: Is this considered to be a normal situation that the network must be able to cope with?
It will be interesting to receive comments and observations of the effect of these data waves, on the network hash rate.
If you are a miner or operate a mining pool, learn what you are actually doing and then proceed accordingly. Expect hundreds of thousands of transactions and keep making blocks every 30seconds as per the network consensus rules. that. is. it.
as has already been clearly pointed out, the root cause is the code and how it works. there is no problem with the consensus rules or what TurtleCoin mainnet is supposed to do with regards to which nodes are permitted to send transactions...
it's not an attack - have you run a testnet? I've done it and filled up the transaction pool with 30 thousand (30,000) transactions, it works fine... IF you have the hardware to support it, an i7 @ 4GHz + 64GB RAM + SSD backed by RAMDrive was fine - all transactions made it into blocks. the transactions I increased the fees on got in first....
is it a bunch of data to carry, sure - not an attack - that is a whole other area of work that could be worked on. doesn't have anything to do with which nodes are allowed to send transactions...
Valid comment with respect to suitable node specification for the TRTL network - under Testnet conditions.
Would this then perhaps need to be conveyed to the community as the minimum acceptable specification for future TRTL network nodes?
An ever-so-gentle reminder that TestNet and MainNet conditions can sometimes be rather far apart, in terms of the challenges faced by a large network. This is actually true of any test environment versus real-world deployment. It is the unexpected challenges that often have the system designers left scratching for updated solutions. :)
if people deploy 1Hz, 1KB ram nodes they will fail when more resources are required...
Anyone that has run internet connected services in production knows how to do this and is aware that monitoring is mandatory, actually knowing what the situation is and responding accordingly is required.
a lot of transactions is not an attack...
From what I've seen - on virtually any alt-coin/networks I've come across - are the numbers of small-end systems used to support the network/s. Enthusiasts love getting involved in pushing the limits of these small systems - it is great fun. In fact, these small-end systems are arguably the back-bone of many new coins.
Perhaps, as the technology and network size grows, there may need to be an awareness of an acceptable minimum node standard suitable for the network?
I think that large coins like BTC are over this challenge, for a number of reasons - huge ASIC-driven hash rates that could mask many of the network anomalies. I also don't know if BTC/clones use Fusion technology.
Not sure how far back this Fusion technology goes in the CryptoNote/ByteCoin family history , but, surely it would/could pay to take a closer look at how to further improve the algorithms? It could only assist to make the TRTL base stronger, imho.
From what I am reading it sounds simple. Cryptonote coins were NOT ATTACKED recently. There were many (too many) transactions and the systems in place were overloaded. That coupled with inexperienced pool operators and cheap VPS servers caused a massive problem. The 2nd thing I read is that LEO said "You guys hate me." And I read that this is indeed a fact. Why?
The problem has been clearly stated, its a software problem, not a network issue. It's not the fusion algorithm, it's not how big transactions are, it's not the number of inputs or outputs, it's the core software itself that needs quite a bit of work meaning a full overhaul and rewrite. There's no point in continuing to drag the conversation out. There's no amount of system resources that can be assigned to solve this issue. It's going to take putting our heads down and rewriting the daemon.
@michael-herwig Based on your initial post, and the quality of analysis you've performed in the past, I'm confident you'd love to help us rework the daemon. You're more than welcome to hop on discord and chat about it.
That being said, this thread is now locked as the topic has been well covered on what the underlying issue is, the method to resolve the issue, and dispelled any myths.