[GUEST ACCESS MODE: Data is scrambled or limited to provide examples. Make requests using your API key to unlock full data. Check https://lunarcrush.ai/auth for authentication information.]  Radiant Blockchain [@Planet_Radiant](/creator/twitter/Planet_Radiant) on x 2176 followers Created: 2025-07-12 14:20:19 UTC MAJOR ANNOUNCEMENT: While working out the root cause of the Mexc withdrawal issue, it’s become apparent the Dragonball A11 probably cannot mine transactions over 2mb. This can be interpreted as an attack on the network, which can handle 8mb & scales beyond 8mb txns. In light of the fact that Dragonball has put a machine on the network which creates a stranglehold on growth, action needs to be considered. Some background: There is a bug within the node code preventing it from sending and receiving txns over 2mb, only send/receiving is affected, everything else is set to 8mb as designed. All of those Mexc transactions were above 2mb, which is why their txns got “stuck”. We were able to get around this by loading the txn directly into the mempool of a mining pool node and then they could mine the block containing the transactions without needing to send or receive the txns unconfirmed. During the course of this effort, we discovered that the A11 cannot mine a block if it contains a large txn. When the Mexc transaction was loaded in the mempool, the miners could not find any blocks at all, even on a pool having ⅓ of the network hashrate, most of that being A11s from DB. Their effort rose to over XXX% before the txn was removed and then they started finding blocks again. When the txns were loaded into pools with hashrate consisting entirely of RX0s, the blocks were able to be mined. We are currently experimenting with a single A11 to reproduce this issue and test various solutions. Many thanks to all those who have assisted with this process, especially Vipor, Blockminerz, and ICminers for their extensive and direct support with identifying and testing this issue. We are looking at ALL options to fix this issue to assure that network rules are followed and will be in the future. We would like everyone in the community to share their thoughts on this situation and potential solutions. #RXD #ASIC  XXX engagements  **Related Topics** [mexc](/topic/mexc) [blockchain](/topic/blockchain) [Post Link](https://x.com/Planet_Radiant/status/1944039119593619498)
[GUEST ACCESS MODE: Data is scrambled or limited to provide examples. Make requests using your API key to unlock full data. Check https://lunarcrush.ai/auth for authentication information.]
Radiant Blockchain @Planet_Radiant on x 2176 followers
Created: 2025-07-12 14:20:19 UTC
MAJOR ANNOUNCEMENT:
While working out the root cause of the Mexc withdrawal issue, it’s become apparent the Dragonball A11 probably cannot mine transactions over 2mb. This can be interpreted as an attack on the network, which can handle 8mb & scales beyond 8mb txns. In light of the fact that Dragonball has put a machine on the network which creates a stranglehold on growth, action needs to be considered.
Some background:
There is a bug within the node code preventing it from sending and receiving txns over 2mb, only send/receiving is affected, everything else is set to 8mb as designed. All of those Mexc transactions were above 2mb, which is why their txns got “stuck”.
We were able to get around this by loading the txn directly into the mempool of a mining pool node and then they could mine the block containing the transactions without needing to send or receive the txns unconfirmed.
During the course of this effort, we discovered that the A11 cannot mine a block if it contains a large txn. When the Mexc transaction was loaded in the mempool, the miners could not find any blocks at all, even on a pool having ⅓ of the network hashrate, most of that being A11s from DB. Their effort rose to over XXX% before the txn was removed and then they started finding blocks again. When the txns were loaded into pools with hashrate consisting entirely of RX0s, the blocks were able to be mined.
We are currently experimenting with a single A11 to reproduce this issue and test various solutions. Many thanks to all those who have assisted with this process, especially Vipor, Blockminerz, and ICminers for their extensive and direct support with identifying and testing this issue.
We are looking at ALL options to fix this issue to assure that network rules are followed and will be in the future.
We would like everyone in the community to share their thoughts on this situation and potential solutions.
#RXD #ASIC
XXX engagements
Related Topics mexc blockchain