Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1532. (Read 4670622 times)

How does the XC anonymity feature trump the one of XMR?

Update:

Survey Link:

https://docs.google.com/forms/d/10FFq_viVaY_THsToPNEwgTxrBSGVxW1EzeYPHX_2nuQ/viewform?usp=send_form

Count     119
Average   7,935
Median   2,080

Very impressed with the swift action from the dev team. You win my respect more for every day, and I will donate after new missive is released.

Also, Bytecoin number 97 in the coinmarketcap volume today. Have our friendly competition given up?

any idea why the difficulty is up so much ?!

2014/08/24 Monero Blockchain Spam Attack - Post Mortem

Part II

As you know from yesterday's Part I of the post-mortem, the net-effect of the attack was an addition of 22mb of data to the blockchain. Because of the unnaturally sharp increase in transaction volume, some transactions experienced delays, mostly several minutes but a few up to an hour, during the heat of the attack. The total duration of the attack was around 13 hours.

The attack started on 2014-08-23 at 15:06:59 UTC with the three transactions in block 186102. It ended on 2014-08-24 at 03:56:07. There were a handful of transactions (15 of them) mined as part of a second attempted attack 12 hours later (starting at 16:51:16 on 2014-08-24). By the time this second attack started, however, the network was already mostly upgraded, and it would appear that the attacker had no desire to repeat the attack with a 0.1 XMR fee.

In total, 1361 malicious transactions were confirmed and mined, although there were several hundred transactions that fell out the mempool as the network upgraded and pool operators started with a clean mempool. Every malicious transaction used a fee of 0.01 XMR, presumably to stay ahead of fee hikes or to have some sort of priority for the transactions, resulting in a total cost to the attacker of 13.61 XMR. Whilst this is not much of a cost, it's important to consider that the 13.61 XMR actualised cost only resulted in 22mb of additional blockchain data, so it's a fair trade-off. If the attacker wanted to repeat the exercise it would cost him 10x as much right now.



You can see the attack plummet to 0 as most of the network and the major pools switch over, effectively cutting off the attackers supply of cheap transactions.

Timeline Summary

2014-08-23, 15:06:59 UTC - attack starts
2014-08-23, 16:12:07 UTC - core team begins to notice oddities
2014-08-23, 16:23:56 UTC - attack confirmed, mitigation begins
2014-08-23, 20:43:13 UTC - fee bump pushed to my (fluffypony) repo after internal testing, pools begin upgrading off that repo
2014-08-23, 21:12:39 UTC - fee bump merged into master
2014-08-24, 12:51:26 UTC - OS X binaries pushed to monero.cc and announced
2014-08-24, 01:10:05 UTC - Windows binaries pushed to monero.cc and announced
2014-08-24, 01:25:20 UTC - Linux binaries pushed to monero.cc and announced
2014-08-24, 03:56:07 UTC - attack ceases to function as the network soft-forks to the new fee

Thank you for your patience and support during this process. Work is underway to fix this permanently by switching to per-kb fees, and we expect to have this fully tested and deployed within the next 2-3 weeks, after which time transaction fees will go back to "normal"

Most certainly, if they want to hear what exposed BCN shills have to say about XMR. It is quite amusing.

EDIT: At least you aren't posting your lame trolling attempts in our thread any more. That's an improvement.





I found this one, does that count:

Ah yes, didn't think of that. Funny to consider that doing it "purely" would then actually raise the required fee as it would increase the transaction size.

Honest XMR users should probably take a look: https://bitcointalksearch.org/topic/unveiling-the-truth-over-the-major-monero-scam-755840

Thanks for the info (smooth as well). Nice reads and informative.

What is interesting (and pretty self evident I believe), is that a "bad" attack actually makes the currency stronger. We have heard the Napster analogy many times with reference to Bitcoin, in how the music industry attacked Napster which then led to torrent, which, quite clearly is connected to these cryptos. They truly are anti-fragile (with our help). So, these attacks on Monero, etc., if not properly done (and barring selfish motives to acquire), just make us stronger, which ironically enough, is needed. It is sort of like how companies pay hackers to attack their networks to find vulnerabilities. But in this case, some of the attacks are genuine and coming from competitors (e.g. Dark).

IAS

I agree it is stupid for bitcoin. However, (more) exact fees work worse for Monero than Bitcoin because it would create more dust (either small digit-denominated outputs that take up a lot of space or undenominated outputs that aren't mixable). We will still need to calculate fees in some increment.

I'm not sure I understand that last part, as the mining pool payouts are done in bulk. So, they are not charged .1 XMR for each individual payout but rather are charged .1 XMR for the bulk payout to all recipients. (I think I see your point anyway though, for if the mining pools were not being efficient here with their payouts they were forced to be.) The mining pools made out well with this change. BTW - If you didn't know that you can do bulk payouts, it is a great and easy way to send coins to different paper wallets at the same time as you are charged once, and not for each individual transaction. If you are curious here is how to do it with BTC and Electrum wallet - https://bitcointalksearch.org/topic/m.4982576

IAS

Please consider going directly for a "pure" fees per-kb, instead of the awkward way bitcoin is still designed nowadays (bitcoin core at least, but all clients follow it), which is floor(tx_size_in_bytes / 1000) * base_fee. That is, the fee is the same for a transaction of 1001 bytes and one of 1999 bytes (0.0001 btc), but different for one of 2001 bytes (0.0002 btc). I always found it stupid considering the miners if acting rationally will only consider the pure fees per-kb. (it's all that matters for them).

No need to go the bitcoin way, especially when btc design is bad.

Sidenote: I found this a bit similar to the emission curve of btc, with the reward abruptly divided by 2 from times to times. I only see drawbacks to this compared to the curve of Monero with the smooth decrease, seeking the same fundamental goal but just done properly.

A more useful fix is coming that won't require babysitting against this form of attack in the future. At the same time we have always been clear that we consider the coin to be alpha-quality and it will definitely require continued active and attentive development for some time to come. There may well be other attacks that will require a response until the coin is made more robust. Over it will indeed become more robust, but not immediately.

Prior to this attack you could send 24 KB of tx data for roughly 0.01 USD. That is much too low given the impact of these sorts of large transactions on the blockchain size. But most transactions are not 24 KB. The average seems to be something like 2.5 KB.

We will be adjusting tx fees to be per-kb like most other coins. Small or typical transactions will cost some small fraction of what large transactions will cost.

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.

Can you use the save command? If so use that before force exiting.

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!

It is temporarily twice the size in the moment you stop the daemon, and it stores blockchain in a temporary file.


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!

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

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

In future, tx fee will depend on tx size. Heavy tx = expensive transfer. Bank, institution? Why big holder will attack their own funds?