[XMR] Monero - A secure, private, untraceable cryptocurrency

[TheCoinFinder]

If its a timewarp attack, and has just begun... I presume he first has to catch up with the current blockchain with his own private mining pool? Ultimately, I thought checkpoints made that pointless.. so Im not sure what his attack is.

In a temewarp attack the attacking chain has to be built up first in private over a period of time. It is then released in the visible portion of the attack. Every time a checkpoint is added this process of building the attacking chain has to be restarted from scratch again, effectively delaying the visible portion of the attack.

Edit: Complacency while the attacking chain is being built, the non visible portion of the attack, becomrs the biggest enemy of the defence. This quote summarizes this very well.

Yawn.. this isn't nearly as entertaining as I thought it would be.

Is Monero being attacked or not? If someone is performing a TW attack is there any way to tell?

From my experience with time warps attacks it takes a couple of days before the symptoms start to occur, but when they do....the chaos is sweet.


~BCX~

So if, by BCX's admission, it takes a couple of days for the timewarp symptoms to occur (presumably while building up the attacking chain), a viable mitigation strategy may be to checkpoint daily. This then results in him having to continually restart the attack before it builds up a long enough chain to go anywhere. Could do it at a random point each day to keep it unpredictable. If I understand the situation correctly.

Any everyday, people would need to download a new wallet? Of course, you could make it so that the wallet ignores any blockchains that reorganise more than X blocks maybe? However, in this case - i'm not even sure if that is the issue here.

[pa]

BCX says a time warp will show its effects after a few days, does this mean he is currently attacking us?

It certainly means he is currently threatening us. I guess in a sense that is itself an attack.

so now we are kept in captivity?

I still cannot see bcxs agenda

His agenda may be to simply buy low and sell high. Anyone with asymmetric information can profit by manipulating the market. Another possibility is that he was paid (or manipulated) by the Bytecoin/CryptoNote scammers to harm XMR relative to the other CN coins. A twist on that scenario is that, at some point the B/CN scammers will realize (or have already realized) that it is better to join XMR than to fight it. Perhaps this was their way to board the train on advantageous terms. Note that none of this would require any actual flaw in XMR; it could all be smoke and mirrors. If so, then the scammers adroitly exploited TFM/AM to amplify the FUD. I doubt he would wittingly participate in such a scheme. He has apparently helped to identify and characterize some possible vulnerabilities in all the CN coins, though the significance of his findings has not yet been dispassionately analyzed. Whatever comes of TFM's discoveries, I doubt BCX truly had grounds to believe XMR to be flawed, until TFM surprisingly seconded the claim and then went on to doggedly pursue BCX's red herring. TFM is a brilliant and imaginative guy who stumbled into a pre-planned hoax, assumed that there must be something to BCX's claims, and then devoted himself to analyzing XMR's anonymity. That he didn't come up with anything resembling BCX's initial claim is reassuring, but not surprising. I am impressed with the XMR devs and community.

[Hotmetal]

So if, by BCX's admission, it takes a couple of days for the timewarp symptoms to occur (presumably while building up the attacking chain), a viable mitigation strategy may be to checkpoint daily. This then results in him having to continually restart the attack before it builds up a long enough chain to go anywhere. Could do it at a random point each day to keep it unpredictable. If I understand the situation correctly.

Unless I am missing something obvious, doing so delays the attack and makes it considerably worse.
You want the attack to come as quickly as possible. The longer it is prolonged, the greater the effect.

[puck2]

OK, I'm thoroughly confused. But I do know that if XMR survives this thorough thrashing, it will rise like a Pheonix. I commend those who would protect the ring signatures from the time warp.

[ArticMine]

It can literally become a war of attrition; however if the defence is in the process of developing a permanent fix then time is on the side of the defence. I compiled bitmonerod 4x over the last 24 hours on different computers.  

[fluffypony]

So if, by BCX's admission, it takes a couple of days for the timewarp symptoms to occur (presumably while building up the attacking chain), a viable mitigation strategy may be to checkpoint daily. This then results in him having to continually restart the attack before it builds up a long enough chain to go anywhere. Could do it at a random point each day to keep it unpredictable. If I understand the situation correctly.

Unless I am missing something obvious, doing so delays the attack and makes it considerably worse.
You want the attack to come as quickly as possible. The longer it is prolonged, the greater the effect.

You're almost correct. By checkpointing daily for a bit (till he/she/it loses interest and it realises that it is both unethical and incompetent) we prevent it from being able to produce a non-checkpointed chain of any length.

[myagui]

Correct on checkpointing as regular (but temporary mitigation). I would kindly request that the dev team release binaries as well, to ensure that the checkpoints are further distributed. Presumably, exchanges & pools will take the checkpoints from source at regular intervals, but compiling is not accessible to the average user.

From what I understand, the dev team is working on additional preventive measures, aiming for a more permanent solution to this type of attack. This experience should also highlight the importance of a healthy (read: strong/fast) Monero mining network. An open source AMD miner is perhaps one important measure in this regard.

Reminder: There's still an open bounty to this effect, and Wolf0 has generously posted some partial code towards this goal, so someone taking up the task, will not need to start from scratch.
https://bitcointalk.org/index.php?topic=656841.0

PS: Please edit/remove text when quoting the troll(s), as this partly defeats the ignore function. Better options are:

... I am a troll ...

Now SomeTroll, show me on the doll where Monero touched you.

Is it true?

^{Edit: Credits due to the community members who came up with these creative responses. Thank you!}

[Nekomata]

XMR is the future.

[Hotmetal]

So if, by BCX's admission, it takes a couple of days for the timewarp symptoms to occur (presumably while building up the attacking chain), a viable mitigation strategy may be to checkpoint daily. This then results in him having to continually restart the attack before it builds up a long enough chain to go anywhere. Could do it at a random point each day to keep it unpredictable. If I understand the situation correctly.

Unless I am missing something obvious, doing so delays the attack and makes it considerably worse.
You want the attack to come as quickly as possible. The longer it is prolonged, the greater the effect.

You're almost correct. By checkpointing daily for a bit (till he/she/it loses interest and it realises that it is both unethical and incompetent) we prevent it from being able to produce a non-checkpointed chain of any length.

What effect would checkpointing every hour cause vs daily? Is it correct in saying that checkpoints have to be manually recovered from?

[OrientA]

Does checkpointing make XMR more like a centralized currency?

[ArticMine]

Does checkpointing make XMR more like a centralized currency?

no

There is actually nothing preventing a user from adding a checkpoint to the code they are using and recompiling. All they are actually saying is that they trust, as part of the consensus making process, a chain that matches up to the checkpoint over a longer chain that differs before the checkpoint.

[fluffypony]

Does checkpointing make XMR more like a centralized currency?

no

Well, actually, to some degree it is a form of centralised control. I'll quote from IRC -


[11:28:52]  fluffypony:    the best way to prevent this sort of attack is to have a very, very large network hashrate
[11:29:01]  fluffypony:    ours is still relatively small
[11:29:36]  Myagui:    yeah, which begs for more/better miner software - particularly opensource for AMD (of which I have none, btw)
[11:29:57]  fluffypony:    attacking Monero now using brute hashrate alone is a cop-out, because our network isn't strong enough to be considered "safe" by decentralised standards
[11:30:08]  dnaleor_:    Myagui, bitcoin solved this problem exactly like xmr: https://en.bitcoin.it/wiki/Checkpoint_Lockin
[11:31:19]  Myagui:    dnaleor_: got it, but just as fluffypony and I were getting too, that's not really a "solution", it's mitigation (and requires babysitting)
[11:31:29]  fluffypony:    Myagui: yes
[11:31:41]  fluffypony:    remember, Monero isn't a decentralised cryptocurrency yet
[11:31:54]  fluffypony:    it *can be* one in the future when the network is bigger / stronger
[11:32:17]  fluffypony:    so anyone buying Monero now isn't buying it because it's a perfect example of a decentralised cryptocurrency
[11:32:25]  fluffypony:    they're buying it because it can potentially be one in future


A poor use of "perfect", but you get the drift.

[Dogeshop_eu]

I still cannot see bcxs agenda

1 - spread fud
2 - buy XMR
3 - pretend to attack
4 - buy XMR
5 - say that the flaw has been fixed by devs
6 - sell XMR
7 - repeat on an other coin
8 - ??

Hmm sounds like a businnessplan

[xulescu]

[11:28:52]  fluffypony:    the best way to prevent this sort of attack is to have a very, very large network hashrate
[11:29:01]  fluffypony:    ours is still relatively small
[11:29:36]  Myagui:    yeah, which begs for more/better miner software - particularly opensource for AMD (of which I have none, btw)
[11:29:57]  fluffypony:    attacking Monero now using brute hashrate alone is a cop-out, because our network isn't strong enough to be considered "safe" by decentralised standards
[11:30:08]  dnaleor_:    Myagui, bitcoin solved this problem exactly like xmr: https://en.bitcoin.it/wiki/Checkpoint_Lockin
[11:31:19]  Myagui:    dnaleor_: got it, but just as fluffypony and I were getting too, that's not really a "solution", it's mitigation (and requires babysitting)
[11:31:29]  fluffypony:    Myagui: yes
[11:31:41]  fluffypony:    remember, Monero isn't a decentralised cryptocurrency yet
[11:31:54]  fluffypony:    it *can be* one in the future when the network is bigger / stronger
[11:32:17]  fluffypony:    so anyone buying Monero now isn't buying it because it's a perfect example of a decentralised cryptocurrency
[11:32:25]  fluffypony:    they're buying it because it can potentially be one in future

Is it plausible to make clients checkpoint themselves regularly? This would require the checkpoints to be saved in some external file that is integrity-verifiable.

[OrientA]

Is it plausible to make clients checkpoint themselves regularly? This would require the checkpoints to be saved in some external file that is integrity-verifiable.

Are we going to have nightly build of the wallet file? That is quite inconvenient.

[ArticMine]

Does checkpointing make XMR more like a centralized currency?

no

Well, actually, to some degree it is a form of centralised control. I'll quote from IRC -


[11:28:52]  fluffypony:    the best way to prevent this sort of attack is to have a very, very large network hashrate
[11:29:01]  fluffypony:    ours is still relatively small
[11:29:36]  Myagui:    yeah, which begs for more/better miner software - particularly opensource for AMD (of which I have none, btw)
[11:29:57]  fluffypony:    attacking Monero now using brute hashrate alone is a cop-out, because our network isn't strong enough to be considered "safe" by decentralised standards
[11:30:08]  dnaleor_:    Myagui, bitcoin solved this problem exactly like xmr: https://en.bitcoin.it/wiki/Checkpoint_Lockin
[11:31:19]  Myagui:    dnaleor_: got it, but just as fluffypony and I were getting too, that's not really a "solution", it's mitigation (and requires babysitting)
[11:31:29]  fluffypony:    Myagui: yes
[11:31:41]  fluffypony:    remember, Monero isn't a decentralised cryptocurrency yet
[11:31:54]  fluffypony:    it *can be* one in the future when the network is bigger / stronger
[11:32:17]  fluffypony:    so anyone buying Monero now isn't buying it because it's a perfect example of a decentralised cryptocurrency
[11:32:25]  fluffypony:    they're buying it because it can potentially be one in future


A poor use of "perfect", but you get the drift.

It can be a form of centralised control but it does not have to be. If the location of checkpoints is left to the developers then checkpoints become trusting the developers over the longest chain. There is however no reason in principle why this has to be the case, if the function of deciding where the checkpoints are, is separated from that of implementing the checkpoints in code. A POW currency can function perfectly well with different users, miners etc., disagreeing on this point and implementing checkpoints at different locations in the chain. One must recognize that the only barrier preventing end users miners etc., from choosing the location of checkpoints independently of the developers is coding skills.

I for example may choose to disagree with fluffypony on the appropriate location of checkpoints while trusting his coding skills in implementing them.

[NewLiberty]

[11:28:52]  fluffypony:    the best way to prevent this sort of attack is to have a very, very large network hashrate
[11:29:01]  fluffypony:    ours is still relatively small
[11:29:36]  Myagui:    yeah, which begs for more/better miner software - particularly opensource for AMD (of which I have none, btw)
[11:29:57]  fluffypony:    attacking Monero now using brute hashrate alone is a cop-out, because our network isn't strong enough to be considered "safe" by decentralised standards
[11:30:08]  dnaleor_:    Myagui, bitcoin solved this problem exactly like xmr: https://en.bitcoin.it/wiki/Checkpoint_Lockin
[11:31:19]  Myagui:    dnaleor_: got it, but just as fluffypony and I were getting too, that's not really a "solution", it's mitigation (and requires babysitting)
[11:31:29]  fluffypony:    Myagui: yes
[11:31:41]  fluffypony:    remember, Monero isn't a decentralised cryptocurrency yet
[11:31:54]  fluffypony:    it *can be* one in the future when the network is bigger / stronger
[11:32:17]  fluffypony:    so anyone buying Monero now isn't buying it because it's a perfect example of a decentralised cryptocurrency
[11:32:25]  fluffypony:    they're buying it because it can potentially be one in future

Is it plausible to make clients checkpoint themselves regularly? This would require the checkpoints to be saved in some external file that is integrity-verifiable.

This is the germ of what I wrote up and offered to the devs last weekend after working through the ideas with ArticMine.  The idea is the TW killer, a polymorphic perpetually self-checkpointing client
However it brings other issues, the aging of the CP until when they are useful, and until when they are no longer useful.  The integrity verifiability you mention is another, the CP frequency, dealing with error recovery, and other variables.  It would be easy to get this wrong or render it useless or simply be redundant with the existing block chain.

It isn't something that ought be implemented in 'forced evolution' mode, but there may be something really good here.

[fluffypony]

Is it plausible to make clients checkpoint themselves regularly? This would require the checkpoints to be saved in some external file that is integrity-verifiable.

We had this discussion a little while ago.

If we provide a reasonably fast way of deploying run-time checkpoints, should the application verify them as being from us (the core team) or not?

If they're verifiably from us (on the app side) we're centralising "control". If they're not verified, then a malicious attacker could send his own checkpoints.

But if a malicious attacker has access to your .bitmonero / %APPDATA%/bitmonero folder, or he can convince you to put a file there, why bother with fake checkpoints? He can give you a fake p2pstate.bin or a fake blockchain.bin, so this is a nonsensical attack vector. Plus open checkpoints evaluated at runtime allow us to disappear off the face of the earth and a new group could still deliver checkpoints (ie. a reduction in centralisation).

Thus, flat-file checkpoints seem to answer the immediate need for on-demand checkpointing. There's still a bit of work to do to manage periodic updates, but we're almost there - https://github.com/monero-project/bitmonero/pull/155

With regards to rapidly delivering emergency checkpoints (which is, frankly, a different use-case) we're working on a solution for that too. We expect all of these to be temporary solutions that last for a few years only, after which we can remove them.

[ArticMine]

Is it plausible to make clients checkpoint themselves regularly? This would require the checkpoints to be saved in some external file that is integrity-verifiable.

We had this discussion a little while ago.

If we provide a reasonably fast way of deploying run-time checkpoints, should the application verify them as being from us (the core team) or not?

If they're verifiably from us (on the app side) we're centralising "control". If they're not verified, then a malicious attacker could send his own checkpoints.

But if a malicious attacker has access to your .bitmonero / %APPDATA%/bitmonero folder, or he can convince you to put a file there, why bother with fake checkpoints? He can give you a fake p2pstate.bin or a fake blockchain.bin, so this is a nonsensical attack vector. Plus open checkpoints evaluated at runtime allow us to disappear off the face of the earth and a new group could still deliver checkpoints (ie. a reduction in centralisation).

Thus, flat-file checkpoints seem to answer the immediate need for on-demand checkpointing. There's still a bit of work to do to manage periodic updates, but we're almost there - https://github.com/monero-project/bitmonero/pull/155

With regards to rapidly delivering emergency checkpoints (which is, frankly, a different use-case) we're working on a solution for that too. We expect all of these to be temporary solutions that last for a few years only, after which we can remove them.

Once could also give the end user the choice between requiring the application verify the checkpoints as being from the core team or not.

[fluffypony]

Once could also give the end user the choice between requiring the application verify the checkpoints as being from the core team or not.

Yes, but time is not on our side