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

Observations: A LOT of Fusion Transactions #146

Closed
michael-herwig opened this issue May 20, 2019 · 15 comments
Closed

Observations: A LOT of Fusion Transactions #146

michael-herwig opened this issue May 20, 2019 · 15 comments

Comments

@michael-herwig
Copy link

@michael-herwig michael-herwig commented May 20, 2019

Introduction

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.

Preliminaries

Transaction Strucure

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 x are mixed with a set of multiple outputs ((x, o_1),...,(x, o_n)), from previous transactions, with n-1 being the mixing factor used. Here o_i is an unsigned integer pointing to a specific output of a transaction with amount x, in the blockchain database.

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: I:=(e_1,...,e_m) with every of the mixin form previously mentioned plus a key image for double-spending protection (e_i:=(x_i, k_i, o_1,...,o_n_i)). Note that different inputs may use different mixing factors. This may vary based on the implementation and configuration of the blockchain itself. Some enforce the same mixin factor on all inputs, others may only accept transactions using a fixed mixin. In the case of the TRTL implementation, all inputs are checked against the configuration independently. In TRTL itself the mixing factor is fixed to a constant but this does not hold true for all forks.

Next, we need to address the output generation. Every output consists of an amount and a public key (a, p).

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 S:=(s_1,...,s_r) with r = SUM(n_1,...,n_w).

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 TX_FEE = SUM(x_i,...,x_n) - SUM(a_1,...,a_l).

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.

Fusion Transactions

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 TX_MAX_SIZE.

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.

  1. Fusion transactions have a different binary size threshold FUSION_TX_MAX_SIZE.
  2. There must be a minimum number of inputs used FUSION_INPUTS_COUNT > FUSION_TX_MIN_INPUTS.
  3. There must be less outputs than inputs TX_INPUTS_COUNT >= TX_OUTPUTS_COUNT * FUSION_TX_RATIO with FUSION_TX_RATIO > 1 being the fusion ratio.
  4. Outputs must conform to the canonical form of the amount decomposed into the sum of multiple predefined amounts (more on this later).
  5. There are no fees TX_FEE = 0.

Size Analysis

Inputs Size

The size of this input required in the transaction depends on the mixing factor.

  • The amount takes at most ROUND_UP(64 / 7) = 10 bytes (encoded 64-bit unsigned integer with variable integer representation).
  • A key image is a 32 bytes binary array
  • Every output index o_i requires ROUND_UP(32 / 7) = 5 bytes (32-bit, variable integer).
  • Every used output index requires a signature, which is a 64 bytes binary array.

We can conclude the size required for every input used as SIZE_INPUTS(n) = n * (10 + 32 + TX_MIXINS * (64 + 5)) with TX_MIXINS is a constant mixin factor for all inputs.

Outputs Size

Next, we need to analyze the number of bytes needed for a variable number of outputs.

  • The amount 5 bytes, as previously mentioned
  • A public key which is a 32 bytes binary array

Thus the size required for outputs is SIZE_OUTPUTS(n) = n * (5 + 32). Additonally we can use only amounts less than 16'384, in that case the size shrinks to SIZE_OUTPUTS_TINY_AMOUNTS(n) = n * (1 + 33) due to the variable integer representation.

Total Size

There are some additional fields required for a transaction that may vary.

  • Version: 1 byte (8-bit integer)
  • Unlock Time: 1 byte, assuming we set it to 0 (variable integer representation of a 64-bit integer)
  • Extra: At least requires 33 bytes for the ephemeral public key and the public key tag. However, we are free to make this extra larger up to a threshold 1024 bytes, filling the field with arbitrary extra data.

Finally we conclude the maximum size of a transaction with variable number of inputs/outputs as TX_SIZE_UPPER_BOUND(NUMBER_OF_INPUTS, NUMBER_OF_OUTPUTS) = SIZE_INPUTS(n) + SIZE_OUTPUTS(l) + 35.

Defusion

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 DEFUSION_OUTPUTS_MAX_SIZE = TX_MAX_SIZE - SIZE_INPUTS(1) - 37 = TX_SIZE_UPPER_BOUND - TX_MIXINS * 69 as bytes left to fill with outputs. With smallest output amount chosen we can calculate the maximum output of new amounts to DEFUSION_MAX_OUTPUTS = ROUND_DOWN(DEFUSION_OUTPUTS_MAX_SIZE / SIZE_OUTPUTS_TINY_AMOUNTS(1)).

As an example, we use the TRTL configuration to compute those values.

  • TX_MAX_SIZE = 100'000 - TX_COINBASE_RESERVED = 99'400
  • TX_MIXINS = 3
  • DEFUSION_OUTPUTS_MAX_SIZE = 99'400 - (42 + 3 * 69) - 37 = 99'112
  • DEFUSION_MAX_OUTPUTS = ROUND_DOWN(99'712 / 34) = 2'932

Hence, in the case of TRTL, you are able to create about 2.9k outputs in a single transaction.

De-Fusion Cycling

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.

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 1201 coins we are required to generate outputs according to the amounts (1, 200, 1000) (neglecting dust).

Ideally, we choose our inputs such that they sum up to some amount having exactly FUSION_TX_MIN_INPUTS / FUSION_TX_RATIO none zero decades such that we can generate the maximum number of outputs. For now, it is left to be shown that we can find such amounts in our defusion and that there is a configuration of fusion such that the fusion of fused coins again outputs the maximum number of outputs.

Further, we will assume that c = FUSION_TX_MIN_INPUTS / FUSION_TX_RATIO is reasonably low such that 1 * 10^c atomic coins are affordable.

Obviously generating MAX_DEFUSION_OUTPUTS different decades yields a valid solution but I consider that case not affordable and most commonly not tradable due to circulating supply or 64-bit overflow.

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.

  • FUSION_MIN_INPUTS: 12
  • FUSION_RATIO: 4
  • DEFUSION_IDEAL_OUTPUTS: ROUND_DOWN(FUSION_MIN_INPUTS / FUSION_RATIO) = 3

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 2648.64 TRTL (2 decimals).

Here is a table summarizing the process.

Wallet Balance: Usable Amounts Amounts Used For Fusion Transactions Outputs Generated
1 10 100 1000 10000 100000 Sum Usable Amounts 1 10 100 1000 10000 100000 #Fusion Transactions SUM(#Fusion Transactions) 1 10 100 1000 10000 100000 Total Balance Check
2464 0 224 20 22 0 2730 2464 0 224 0 0 224 224 224 224 224 0 0 0 264864
224 224 224 20 22 0 714 220 0 20 0 0 20 244 20 20 20 0 0 0 264864
24 244 224 20 22 0 534 22 0 2 0 0 2 246 2 2 2 0 0 0 264864
4 246 224 20 22 0 516 0 220 0 20 0 0 20 266 0 20 20 20 0 0 264864
4 46 244 20 22 0 336 0 44 0 4 0 0 4 270 0 4 4 4 0 0 264864
4 6 248 20 22 0 300 0 0 242 0 22 0 22 292 0 0 22 22 22 0 264864
4 6 28 42 22 0 102 0 0 0 0 0 0 0 292 0 0 0 0 0 0 264864

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 SIZE_OF_OUTPUTS := 2730 * 34 = 92.820 (an extra bit for higher outputs). We calculate bytes left for inputs used in the defusion transaction as DEFUSION_OPT_SIZE := 99'400 - 92'820 - MAX_TRANSACTION_HEADER_SIZE = 6545 which is more than sufficient to emplace multiple extra input/outputs to pay the fee and take the rest back.

Conclusion

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 0.1 TRTL). The approach is partially generic and can be adapted for other coins using similar patterns and different parameters.

Implications

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 1 TRTL costs about $0.00013073. The initial fusion state requires a total of 2'648.64 TRTL which sums up to about $0.35. For an additional $0.15 we can buy additional 1'147.40 TRTL to pay the defusion fee ~11'450k times. Every cycle takes about 8 blocks to perform taking approximately 4 minutes to complete (30 seconds block time). As a result, we are able to perform 20 cycles per hour for over 3 weeks until our $0.15 for fees are exhausted.

Bloating

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 300 * 2'029 = 608'700 bytes, or 11.6 megabytes per hour.

Denial of Service

The cycle generates a lot of inputs (300 * 12 = 3'600) each references mixins such that a total of 3'500 * 4 = 14'400 inputs are referenced. Each node hast to query those inputs for its transaction public key and verify the signature.

Locking Transactions

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.

Possible Solutions

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.

  • Include routines to ban malicious nodes/subnets from connecting (by hand or automatic).
  • Implement different block template generation strategies, favoring some kind of transaction format that does not look malicious.
  • Autoscale minimum transaction fees with the size of transactions in the pool.
  • Decline new fusion transactions pushed to the pool if there are too many.
  • Add parameters to configure an auto disconnect to malicious nodes spamming fusion transactions.

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.

@muffinmancfd

This comment has been minimized.

Copy link

@muffinmancfd muffinmancfd commented May 20, 2019

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.

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented May 20, 2019

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):

  1. ban malicious nodes/subnets from connecting (by hand or automatic).
  2. parameters to configure an auto disconnect to malicious nodes spamming fusion transactions.
  3. Autoscale minimum transaction fees with the size of transactions in the pool.
    KiFy goes live on the keg blockchain today(kify v1 already in and functional) and it has been tested on a testnet. it will be public shortly after and i will be opening a pr itno trtl with the code added or you to look over and review.
@SoreGums

This comment has been minimized.

Copy link
Collaborator

@SoreGums SoreGums commented May 20, 2019

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...

@brandonlehmann

This comment has been minimized.

Copy link
Collaborator

@brandonlehmann brandonlehmann commented May 20, 2019

@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.

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.

  • Include routines to ban malicious nodes/subnets from connecting (by hand or automatic).

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.

  • Implement different block template generation strategies, favoring some kind of transaction format that does not look malicious.

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.

  • Autoscale minimum transaction fees with the size of transactions in the pool.

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.

  • Decline new fusion transactions pushed to the pool if there are too many.

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.

  • Add parameters to configure an auto disconnect to malicious nodes spamming fusion transactions.

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.

@leocornelius

i will be opening a pr itno trtl with the code added or you to look over and review.

I advise you not to waste your time submitting a PR. It'll save us the hassle of closing it when you do.

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented May 20, 2019

@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

@brandonlehmann

This comment has been minimized.

Copy link
Collaborator

@brandonlehmann brandonlehmann commented May 20, 2019

@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.

@brandonlehmann

This comment has been minimized.

Copy link
Collaborator

@brandonlehmann brandonlehmann commented May 20, 2019

@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

Is this it? https://github.com/LeoCornelius/kify-protocol

@muffinmancfd

This comment has been minimized.

Copy link

@muffinmancfd muffinmancfd commented May 20, 2019

What follows are a series of pictures taken from the TurtleCoin block explorer, during the recent challenge.

  1. Wave entry
    Wave_entry_1

  2. Wave midlife
    Wave_midlife_2

  3. Wave exit
    Wave_exit_3

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.

@SoreGums SoreGums changed the title Attacking Vectors Based On Fusion Transactions Observations: A LOT of Fusion Transactions May 20, 2019
@muffinmancfd

This comment has been minimized.

Copy link

@muffinmancfd muffinmancfd commented May 20, 2019

Attacking Vectors Based On Fusion Transactions Observations - versus A LOT of Fusion Transactions

This may still be open for debate, I suspect. Perhaps a little premature to unilaterally alter the name? :)

@SoreGums

This comment has been minimized.

Copy link
Collaborator

@SoreGums SoreGums commented May 20, 2019

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...

@muffinmancfd

This comment has been minimized.

Copy link

@muffinmancfd muffinmancfd commented May 20, 2019

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. :)

@SoreGums

This comment has been minimized.

Copy link
Collaborator

@SoreGums SoreGums commented May 20, 2019

if people deploy 1Hz, 1KB ram nodes they will fail when more resources are required...
not sure what your game is now. this stuff isn't rocket science, it does require understanding and experience. ie "let's run a mining pool for fun" is not going to cut it.

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...

@muffinmancfd

This comment has been minimized.

Copy link

@muffinmancfd muffinmancfd commented May 20, 2019

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.

@kiyototomioka

This comment has been minimized.

Copy link

@kiyototomioka kiyototomioka commented May 20, 2019

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?

@turtlecoin turtlecoin locked as too heated and limited conversation to collaborators May 20, 2019
@brandonlehmann

This comment has been minimized.

Copy link
Collaborator

@brandonlehmann brandonlehmann commented May 20, 2019

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants
You can’t perform that action at this time.