It verifies checkpoints when loading off disk. It's a bad idea to treat the blockchain as a "file" (same with p2pstate and poolstate), as we have and will abstract these away from their physical files.

Checkpoints are a temporary measure that we're going to get away from eventually, so we're just doing the best we can with something we'll be stuck with for the next few years:)

So is Boolberry's "get ahead" plan to openly insult others in their thread? So much for jl777's claim of us being "cryptonote brothers".

Look, it's been a rough couple of days, and we're all completely exhausted from sitting on the edge of our seat waiting for some phantom attack. You go and drop this bomb-shell of a post on Bitcointalk about how you've found some breaking issue that affects every CN coin and say that you urgently need to alert all of the exchanges. Understandably, given the context and the apparent looming threat, we're going to look at the commit and assume this is something that needs urgent attention. We made a judgement call, added it, and reverted the commit within minutes.

Now you may say that we're not cautious enough. You may call us reactionary under pressure. You may even rightfully say that we are unfamiliar with a codebase we did not write. All of this is true. But to say we "have no idea what [we] do", and to personally insult me? That's uncalled for and unnecessary, and is a terribly weak attempt to make yourself look good. Let me save you the hassle for next time: you are a very accomplished coder. Clearly you can churn out code like there's no tomorrow. There, now next time you won't feel the need to insult me or insult us, you can just quote this post and pat yourself on the back.

You need to seriously give some thought to the way your very public actions reflect on the cryptocurrency that you and you alone control.

Point. So then the checkpoints.json thing is a convenience tool more than anything else.

That was me, I got frustrated with manually building static binaries...it's a pleasure:)

Yes, but time is not on our side

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.

You'll excuse the curt reply, but I'm just going to infodump from IRC, as we're quite tight on time -


[15:48:52] sarang: I can't prove a negative
[15:48:54] sarang: that's the trouble
[15:49:05] sarang: I can't say "there is no way to use three equations like that to recover x, here's proof"
[15:49:11] sarang: I can only say "there are no known ways to do so"
[15:49:36] sarang: The onus is on him. Unfortunately, if the world wants us to counter it with Magic Negative Proof, then they'll be disappointed
[15:50:37] sarang: But, let me review out loud
[15:50:45] sarang: We know I=xH(P) is one equation
[15:51:36] sarang: We know r=q-cx is another
[15:51:50] sarang: and we know x=H(aR)+b is a third
[15:52:00] sarang: You have, indeed, three equations for x
[15:52:19] sarang: How many unknowns is important here (though the security of ECDLP is important too)
[15:53:25] sarang: Unknowns are x itself, q, c, a, b, and technically r since it's indexed
[15:53:40] sarang: Given three equations and six unknowns, he can go right back to the drawing board
[15:56:43] sarang: So my answer to him would be that the private key is obscured in all cases by either the ECDLP or random affine goodness
[15:57:06] sarang: and that the three equations means that you STILL have three extra degrees of freedom
[15:57:41] sarang: and the degrees of freedom are carefully chosen from random distributions
[15:57:55] sarang: If he has an actual attack or a suggestion of how to reduce the parameter space, fine, share it
[15:58:21] sarang: But we don't spend our time proving negatives... we review carefully and hunt down any flaws we see that seem reasonable given our expertise
[15:59:42] sarang: If he wants to argue with linear algebra or the ECDLP, he can go right ahead
[15:59:48] sarang: Those are better listeners anyway
[16:00:28] sarang: We don't need to explain how linear algebra works anyway... it's assumed the whitepaper is written for someone who knows what all those little symbols mean
[16:02:56] sarang: Real mathematicians don't rub unknowns in people's faces. They point out flaws and offer constructive input
[16:06:31] sarang: Oh, and the equations use different base points, so you gain no benefit from a common base point

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.

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.

FTFY

Please note that new forum rules indicate that posts like yours must be signed with tildes around a 3-character representation of your nickname that adheres to the uppercase-lowercase-uppercase casing rule.

~FpY~

Yes - characters from the epic musical The Rocky Horror Picture Show would be appearing on your computer screen.

Proof: https://www.youtube.com/watch?v=sg-vgGuTD8A

We asked the exchanges to do this as a precautionary measure.

Had BCX been ethical and had there been responsible disclosure we would not have this situation.

When we had the block 202612 attack we asked exchanges to halt trading as well as deposits and withdrawals, as in the 20 minutes after it happened we were reeling and trying to figure out what had just happened. That emergency halt lasted longer than the 24 hours we've asked for. If you don't like the actions we took to protect our users then there are plenty of other cryptocurrencies for you to choose from.

So it looks like we've got a bit of movement - you may see this in your daemon:


2014-Sep-23 23:37:19.806279 [P2P5][95.215.44.178:34198 INC]Sync data returned unknown top block: 230879 -> 500 [230379 blocks (-159 days) ahead]
SYNCHRONIZATION started
2014-Sep-23 23:37:19.810744 [P2P1][95.215.44.178:34236 INC]Sync data returned unknown top block: 230879 -> 109899 [120980 blocks (-84 days) ahead]
SYNCHRONIZATION started
2014-Sep-23 23:37:21.642268 [P2P4][95.215.44.178:34665 INC]Sync data returned unknown top block: 230879 -> 105895 [124984 blocks (-86 days) ahead]
SYNCHRONIZATION started
2014-Sep-23 23:37:21.650641 [P2P5][95.215.44.178:34612 INC]Sync data returned unknown top block: 230879 -> 500 [230379 blocks (-159 days) ahead]
SYNCHRONIZATION started
2014-Sep-23 23:37:23.482062 [P2P8][95.215.44.178:35159 INC]Sync data returned unknown top block: 230879 -> 56462 [174417 blocks (-121 days) ahead]
SYNCHRONIZATION started
2014-Sep-23 23:37:23.482223 [P2P5][95.215.44.178:35105 INC]Sync data returned unknown top block: 230879 -> 500 [230379 blocks (-159 days) ahead]
SYNCHRONIZATION started


Those connections are being dropped, although 95.215.44.178 is aggressively reconnecting. So far we're not seeing any major issues, except the annoying message showing up each time that peer tries to reconnect.

Mitigation

There will be a new release shortly to ensure this is mitigated. We will continue to monitor to see what else is going on.

Since you're admitting I'm royalty I expect you to use the proper term when addressing me. It's Sir Pony to you.

I made the important bit bold. Trading is not suspended.

Hi guys - just a note that we have asked exchanges to suspend XMR deposits/withdrawals for 24 hours. Trading is not suspended. This is a precautionary move.

MEW is not part of the Monero core team, and we are not part of MEW. They have zero control over the decisions the Monero core team make, and no influence on us. They are always welcome to make suggestions (as anyone can) and we appreciate the financial support, but that is where the line starts and ends.

Hi windjc - just to clarify, none of us (the Monero core team) have had any direct contact from crypto_zoidberg or jl777 as part of the aforementioned taskforce. We have had some communication with AnonyMint, the bulk of which has been public.

At this juncture the Monero core team has, independently of anyone else, worked at mitigating this alleged attack. We will make a more formal announcement to that end shortly.

It's time you fucked off, Robert.