|
|
primer-
Legendary

Activity: 1092
Merit: 1000
|
 |
August 25, 2014, 01:49:54 AM |
|
|
|
|
|
|
|
Toninho
|
 |
August 25, 2014, 03:20:50 AM |
|
|
|
|
|
|
exciter0
Member


Activity: 115
Merit: 10
|
 |
August 25, 2014, 03:34:36 AM |
|
2014/08/24 Monero Blockchain Spam Attack - Post Mortem
Everyone, if you appreciate how the A-Team devs handled this situation as much as I do, please consider sending a small donation their way: https://bitcointalk.org/index.php?topic=700400.0 
|
|
|
|
cAPSLOCK
Legendary

Activity: 4494
Merit: 8172
Balakay2b edition!
|
 |
August 25, 2014, 06:27:25 AM |
|
Idiot.
There are probably far less embarrassing ways to introduce yourself, but I suppose if accuracy is your thing then who am I to judge.
|
|
|
|
|
mmortal03
Legendary

Activity: 1762
Merit: 1011
|
 |
August 25, 2014, 06:48:47 AM |
|
The mean is ~$19.4k now, and the median is ~$6.7k.
|
|
|
|
|
|
sleepdog
|
 |
August 25, 2014, 11:24:41 AM |
|
2014/08/24 Monero Blockchain Spam Attack - Post Mortem Blockchain growth over August was 6.684mb per day. Because of the attack, blockchain growth over the past two days was 20.326mb (23rd) and 15.05mb (24th). This is a net effect of 13.642mb extra + 8.366mb extra = 22mb more than average over the period. My blockchain.bin is double the size indicated by your graph (2.15GB), any idea why this might be? Is there any connection here to why the daemon uses 3.5GB memory? I've had to upgrade my PC from 4 - 6GB so it's usable when the daemon is running.
|
|
|
|
|
|
zarton
|
 |
August 25, 2014, 11:32:33 AM |
|
The windows and linux systems have virtual memory so if you only have 4 gb the system takes hard disk space to use as memory ram. Its not mandatory upgrade the ram to keep loaded the monero blockchain.
|
|
|
|
|
sleepdog
|
 |
August 25, 2014, 11:57:22 AM |
|
The windows and linux systems have virtual memory so if you only have 4 gb the system takes hard disk space to use as memory ram. Its not mandatory upgrade the ram to keep loaded the monero blockchain.
It's not mandatory, but by my experience it is necessary to retain a responsive system.
|
|
|
|
|
|
wedgy2k
|
 |
August 25, 2014, 12:01:03 PM |
|
My blockchain.bin is double the size indicated by your graph (2.15GB), any idea why this might be? Is there any connection here to why the daemon uses 3.5GB memory? I've had to upgrade my PC from 4 - 6GB so it's usable when the daemon is running.
Mine is 2.31 GB and not double, bitmonero v0.8.8.2 (OSX 10.9.4) (just for reference)
|
|
|
|
Miller0
Newbie

Activity: 35
Merit: 0
|
 |
August 25, 2014, 12:02:52 PM |
|
My blockchain.bin is double the size indicated by your graph (2.15GB), any idea why this might be? Is there any connection here to why the daemon uses 3.5GB memory? I've had to upgrade my PC from 4 - 6GB so it's usable when the daemon is running.
Mine is 2.31 GB and not double, bitmonero v0.8.8.2 (OSX 10.9.4) (just for reference) THX
|
|
|
|
|
Its About Sharing
Legendary

Activity: 1442
Merit: 1000
Antifragile
|
 |
August 25, 2014, 12:37:14 PM |
|
The ramp up to 0.1 XMR fees stopped the attacker dead in their tracks, and gives us a bit of time to regroup and finalise the changes we were making that will permanently prevent this in future.
Thanks for the detailed update fluffypony. I have a general question that would seem to apply to all alts, but perhaps more to XMR. What if there is an attacker (e.g. bank, large institution or even State) with relatively limitless pockets? It seems to me, there is a bell curve of optimal disruption they can cause, then beyond that, their buying is going to raise the price too much (and even then that might not be so bad). I'm talking worst case scenarios here and again, it would apply to all coins. I just think it is something, of course, we need to watch out for especially, due to the larger blockchain, at least at this time. I understand no coin can perhaps stop a full on attack, due to their design, at least at this time, but it would still be nice to have an understanding of the ramifications (which in part, you have just given us - I'm just talking about amplitudes greater in the attack vector.) Related, if BTC, Monero, etc. do experience such attacks in the future, is there a way to just prune the attack transactions out of the blockchain? Or another solution? Thanks in advance, IAS ps - Of course I am a holder of Monero. 
|
BTC = Black Swan. BTC = Antifragile - "Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Robust is not the opposite of fragile.
|
|
|
|
sleepdog
|
 |
August 25, 2014, 12:50:23 PM |
|
My blockchain.bin is double the size indicated by your graph (2.15GB), any idea why this might be? Is there any connection here to why the daemon uses 3.5GB memory? I've had to upgrade my PC from 4 - 6GB so it's usable when the daemon is running.
Mine is 2.31 GB and not double, bitmonero v0.8.8.2 (OSX 10.9.4) (just for reference) It's not exactly double, true. As of an hour ago mine is 2.15 GB ( 2,315,602,066 bytes). No doubt yours is the same. I'm asking if this is normal seeing as the graph provided by the devs shows a size of roughly 1 GB.
|
|
|
|
|
sammy007
Legendary

Activity: 1904
Merit: 1003
|
 |
August 25, 2014, 01:05:16 PM |
|
The ramp up to 0.1 XMR fees stopped the attacker dead in their tracks, and gives us a bit of time to regroup and finalise the changes we were making that will permanently prevent this in future.
Thanks for the detailed update fluffypony. I have a general question that would seem to apply to all alts, but perhaps more to XMR. What if there is an attacker (e.g. bank, large institution or even State) with relatively limitless pockets? It seems to me, there is a bell curve of optimal disruption they can cause, then beyond that, their buying is going to raise the price too much (and even then that might not be so bad). I'm talking worst case scenarios here and again, it would apply to all coins. I just think it is something, of course, we need to watch out for especially, due to the larger blockchain, at least at this time. I understand no coin can perhaps stop a full on attack, due to their design, at least at this time, but it would still be nice to have an understanding of the ramifications (which in part, you have just given us - I'm just talking about amplitudes greater in the attack vector.) Related, if BTC, Monero, etc. do experience such attacks in the future, is there a way to just prune the attack transactions out of the blockchain? Or another solution? Thanks in advance, IAS ps - Of course I am a holder of Monero.  In future, tx fee will depend on tx size. Heavy tx = expensive transfer. Bank, institution? Why big holder will attack their own funds?
|
|
|
|
|
fluffypony
Donator
Legendary

Activity: 1274
Merit: 1069
GetMonero.org / MyMonero.com
|
 |
August 25, 2014, 01:24:05 PM |
|
My blockchain.bin is double the size indicated by your graph (2.15GB), any idea why this might be? Is there any connection here to why the daemon uses 3.5GB memory? I've had to upgrade my PC from 4 - 6GB so it's usable when the daemon is running.
Mine is 2.31 GB and not double, bitmonero v0.8.8.2 (OSX 10.9.4) (just for reference) It's not exactly double, true. As of an hour ago mine is 2.15 GB ( 2,315,602,066 bytes). No doubt yours is the same. I'm asking if this is normal seeing as the graph provided by the devs shows a size of roughly 1 GB. At the moment it's not stored efficiently - the key image set and the utxoset are both duplicated separately from the blockchain. This will be more efficiently stored in the database:)
|
|
|
|
fluffypony
Donator
Legendary

Activity: 1274
Merit: 1069
GetMonero.org / MyMonero.com
|
 |
August 25, 2014, 01:31:15 PM |
|
The ramp up to 0.1 XMR fees stopped the attacker dead in their tracks, and gives us a bit of time to regroup and finalise the changes we were making that will permanently prevent this in future.
Thanks for the detailed update fluffypony. I have a general question that would seem to apply to all alts, but perhaps more to XMR. What if there is an attacker (e.g. bank, large institution or even State) with relatively limitless pockets? It seems to me, there is a bell curve of optimal disruption they can cause, then beyond that, their buying is going to raise the price too much (and even then that might not be so bad). I'm talking worst case scenarios here and again, it would apply to all coins. I just think it is something, of course, we need to watch out for especially, due to the larger blockchain, at least at this time. I understand no coin can perhaps stop a full on attack, due to their design, at least at this time, but it would still be nice to have an understanding of the ramifications (which in part, you have just given us - I'm just talking about amplitudes greater in the attack vector.) Related, if BTC, Monero, etc. do experience such attacks in the future, is there a way to just prune the attack transactions out of the blockchain? Or another solution? Thanks in advance, IAS ps - Of course I am a holder of Monero.  It's been done before, even recently with Bitcoin (see the 1Enjoy 1Sochi attack last year). A highly motivated, highly skilled attacker with near limitless resources would benefit far more by combining market manipulation with an organised disinformation / smear campaign. At the moment, those who seek to disrupt little ol' Monero are able to do the latter, but lack the resources to do the former. The only thing you can hope for in future is that market manipulation, controlling more hashrate than half the network, spam attacks, and attempted DoS attacks become so expensive that even our proverbial attacker chooses to walk away from those options. We can't prevent the disinformation / smear campaign, but given how poorly it's going for certain-other-parties right now I don't suspect it to be terribly successful in the future;)
|
|
|
|
e-coinomist
Legendary

Activity: 2380
Merit: 1085
Money often costs too much.
|
 |
August 25, 2014, 01:34:11 PM |
|
It's not exactly double, true. As of an hour ago mine is 2.15 GB (2,315,602,066 bytes). No doubt yours is the same. I'm asking if this is normal seeing as the graph provided by the devs shows a size of roughly 1 GB.
It is temporarily twice the size in the moment you stop the daemon, and it stores blockchain in a temporary file. bitmonero-master/src/cryptonote_core/blockchain_storage.cpp blockchain_storage::store_blockchain() const std::string temp_filename = m_config_folder + "/" CRYPTONOTE_BLOCKCHAINDATA_TEMP_FILENAME; For my personal use I changed that, simple added removal of the former chain copy. If that ever failes me, system would have to download whole chain back from beginning. The database is a milestone still ahead, and much awaited (even more so then any GUI) What if there is an attacker (e.g. bank, large institution or even State) with relatively limitless pockets? It seems to me, there is a bell curve of optimal disruption they can cause, then beyond that, their buying is going to raise the price too much (and even then that might not be so bad). I'm talking worst case scenarios here and again,...
Strange, how the Bad Guy faces have changed. But maybe there wasn't only an attack, but more use of the network? Remember that some mining pools payout in 0.1 XMR slices. So that got perfectly bummed by raising transfer fees onto exactly the same amount!
|
|
|
|
|
|
sgi02
|
 |
August 25, 2014, 01:34:56 PM |
|
I've updated to the latest bitmonerod and simplewallet and now when I try to exit the bitmonerod (with the exit command) it just hangs and I have to manually close the window causing me to have to resync every time I reopen. I deleted the poolstate and p2p files, and the issue still persists. I'm running Windows 64-Bit, any workarounds for this? Thanks!
|
|
|
|
|
drawingthesun
Legendary

Activity: 1176
Merit: 1018
|
 |
August 25, 2014, 01:45:41 PM |
|
I've updated to the latest bitmonerod and simplewallet and now when I try to exit the bitmonerod (with the exit command) it just hangs and I have to manually close the window causing me to have to resync every time I reopen. I deleted the poolstate and p2p files, and the issue still persists. I'm running Windows 64-Bit, any workarounds for this? Thanks!
Can you use the save command? If so use that before force exiting.
|
|
|
|
|
AlexGR
Legendary

Activity: 1708
Merit: 1049
|
 |
August 25, 2014, 01:53:36 PM |
|
The ramp up to 0.1 XMR fees stopped the attacker dead in their tracks, and gives us a bit of time to regroup and finalise the changes we were making that will permanently prevent this in future.
Thanks for the detailed update fluffypony. I have a general question that would seem to apply to all alts, but perhaps more to XMR. What if there is an attacker (e.g. bank, large institution or even State) with relatively limitless pockets? It seems to me, there is a bell curve of optimal disruption they can cause, then beyond that, their buying is going to raise the price too much (and even then that might not be so bad). I'm talking worst case scenarios here and again, it would apply to all coins. From a game theory perspective, the game can be played in a number of unorthodox ways. Even 0.1 XMR is nothing for a determined attacker. For if he shows that he doesn't care about the fee as he has "tons of monero to spend", then he gets to achieve his aim by acting corrosively to confidence. Investors must be able to see that the devs are on top of the situation and if countermeasures don't work it's like "oh oh, these attackers will actually destroy monero"... so you can have an attacker, whether with the intent to destroy monero or to benefit financially, where he might sell before the attack, start the attack, wait for the price to lower due to lost confidence and then buy back. He can either win financially, win in terms of eroding trust (if he is from a competing coin), or win in terms of making Monero more centralized than it needs to be. If the currency itself is vulnerable to such attacks, then it creates a problem of centralization-response where, for example, fees must be changed every now and then to deal with an attack. This creates the perception that the currency needs babysitting to operate. And high fees also defeat the purpose of the currency itself, as it becomes unusable with too high fees.
|
|
|
|
|
|