anything goes wrong with SYNCHRONIZATION?
Nothing goes wrong, you're synchronising from scratch. If you want to avoid this you can use a blockchain bootstrap as indicated in the OP. |
|
|
|
This is the current Windows blockchain on the correct fork. |
|
|
|
Ok, all binaries updated, this is a mandatory update to 0.8.8.3 - ››› Windows 64-bit • OS X • Linux • Source code ‹‹‹SHA sums for each download: monero.win.x64.latest.zip - 7b89c14891cab57aa292d3826227c99bd2c8e203 monero.mac.x64.latest.tar.bz2 - 10854bbc549de5eff6609e102a8f778d6e99af29 monero.linux.x64.latest.tar.bz2 - a55945606238ce28f03079691619ae11ca18efc7 Please be advised that after releasing binaries we bump the build number up on github on the staging repo, so if you're building from github you will end up on 0.8.8.4. |
|
|
|
Ok - Windows blockchain has been updated with one that is synced up past the fork correctly - http://monero.cc/downloads/blockchain/win/blockchain.binsha: 8c23da70c1291a61444090d8d5127dd6c12efa81 We won't update that blockchain for a few days, although when it updates once the patch is fully tested and deployed that sha will obviously change:) Thanks for your patience! |
|
|
|
What's the status of XMR's collaboration with i2p?
Ongoing, we've formed a working group with i2p, Abscond, i2pd, and Anoncoin, called Privacy Solutions. i2pd is reaching a level of working-ness that should allow us to start integrating it soon. Given the number of moving parts it's extremely hard to put a timeframe on it. If we are talking in the broadest sense. Are we talking this year? I would imagine so, yes - I'm running i2pd in its current form to connect to irc2p, and now that most of the memory leaks have been squashed it's quite stable. There's still a lot of work to be done (the "moving parts" I mentioned), but it's way, way further ahead than when we first partnered up with i2p:) |
|
|
|
I have a problem with bitmonerod, here is log: 2014-Sep-06 13:52:18.139976 Starting...
2014-Sep-06 13:52:18.189979 bitmonero v0.8.8.2(0.1-g1b8a68f)
2014-Sep-06 13:52:18.223980 Module folder: F:\monero.win.x64.experimental.0526\bitmonerod.exe
2014-Sep-06 13:52:18.259983 Initializing p2p server...
2014-Sep-06 13:52:18.318986 ERROR c:\temp\monero\new\bitmonero-master-x64\src\p2p\net_node.inl:108 Exception at [node_server::init_config], what=input stream error
2014-Sep-06 13:52:18.318986 ERROR c:\temp\monero\new\bitmonero-master-x64\src\p2p\net_node.inl:239 Failed to init config.
2014-Sep-06 13:52:18.318986 ERROR ..\..\src\daemon\daemon.cpp:174 Failed to initialize p2p server.
2014-Sep-06 13:52:18.345987 Mining has been stopped, 0 finished Before ive cleared my temp directory Get the latest binary off the OP and try again Edit: and delete your p2pstate.bin and poolstate.bin, your p2pstate.bin is definitely corrupt. |
|
|
|
Still can't sync  It's been a while now... should have been sorted out by now? If you're stuck in the dead fork you have to either use a bootstrap blockchain download from us (see OP), or wait for our rollback fix, or try sync up from scratch. |
|
|
|
What's the status of XMR's collaboration with i2p?
Ongoing, we've formed a working group with i2p, Abscond, i2pd, and Anoncoin, called Privacy Solutions. i2pd is reaching a level of working-ness that should allow us to start integrating it soon. Given the number of moving parts it's extremely hard to put a timeframe on it. |
|
|
|
I did nothing like this, i simply downloaded the 30 day old bin file and it synced to the proer chain. Da fuq is the prob,devs??? Am i a moron here LOL.......
You did nothing wrong - you got lucky in terms of what peers you connected to:) From scratch it will *eventually* find consensus, but you also may be stuck with the wrong short_chain_history, and thus it *expects* the wrong block 202612. This is what we're patching. |
|
|
|
More soon.
Any update on the updated update regarding the updated update yet? Yeah. We tried a couple different things and this one seems to work. https://github.com/tewinget/bitmonero/commits/202612_exceptionWe may replace the tree-hash code still because that solution from CN isn't quite right either, but you can download this, build, and try syncing it to the main chain now if you'd like. Just to correct this - we're NOT going to be using the CN tree_hash.c change, because as you pointed out it's not entirely correct. Our correctly patched tree_hash.c is here: https://github.com/rfree2monero/bitmonero/blob/pr-fix-treehash2/src/crypto/tree-hash.c - we patched that two days ago, but it needs to be done in conjunction with the 202612 exception. |
|
|
|
Don't both blockchains technically have a corrupted block?
Kinda - but the longest chain is the one that we have to accept as "correct" and manually pin it. |
|
|
|
Seems people have many troubles with downloading blockchain. Still can't understand why devs won't upload blockchain to mega as a mirror. I'll never download blockchain from untrusted source these days and ever.
The trouble isn't with downloading it, that works just fine. The trouble is with us updating the Windows download to a non-forked one, which necessitates us first finishing off this block-pinning code. |
|
|
|
|
Brief update -
We're busy working on pinning the bad block as a sort-of checkpoint, so that you'll never end up on the bad fork even if you're catching up. As soon as this is out then everyone will be able to catch-up, including our poor Windows blockchain box that has tried a bunch of times:)
|
|
|
|
|
Does anyone want to buy this pile of NUGGETS I'm sitting on?
|
|
|
|
If I was a developer, I would always conceal my personal details at least for security reasons. I'm concerned about possible persecution by the government and abuse by hackers.
Just an observation. I've seen several people trying to throw shade on Bytecoin using developer's anonymity as an argument. Why in this world would anybody tell their real names when the coin is anonymous, moreover it's all about anonymity? As @Levis said before, staying anonymous is safer You're missing the point entirely. There is no problem with their real names not being known. What must be known is their identity. There are many, many people involved in cryptography projects whose real name is not known, but you can search for their nickname and find blog posts and comments and archived mailing list emails and forum posts from years and years back. In other words, they are known identities even if they're not known personally. So far we have not found anyone who can vouch for Bytecoin's pre-March 2014 existence who is a known identity. |
|
|
|
The scope of this attack clearly makes it an organized effort. While it is possible that some lone guy is figuring out the flaw and how to take advantage of it, the fact we are needing more than one skillset and resources more indicates a team is involved.
Theoretically if you guys didnt notice the strange stuff on the blockchain and polo went on a fork, could they have just made many small withdraws over a week and drained the polo acct? The timeframe and resources required for this doesnt seem like some statment attack to cause a fork and go "ha ha", but where financial gain is involved.
If so, the list if suspects as being involved in this would be polo accts that were involved in accumulating recently (which I remember seeing talked about) and probably these were also trying to do the double spend while on the fork.
So, maybe the attack was against polo?
James
Nope - bear in mind that basically without any action from us the "bad" fork died after 35 minutes. It still exists, it's just stuck at block 202647 and won't proceed. This would have happened even if we hadn't noticed it, so there's little they could have done to have any long-lived attack. |
|
|
|
But the fork, was that the purpose of the attack or accidental? Was he relying on the fact that it would be a while before anyone noticed?
Sounds to me as though mayhem was the intention.
The fork was the intention and the net-effect. They would have had to mine two of those blocks in parallel and dump them both on the network. It's such a bizarre, unknown, unidentified edge-case that I can't imagine someone stumbling across this AND figuring out how to exploit it (and to what end??). There's no monetary gain to the attacker, and with the hike in fees to mitigate the previous attack I can only imagine that this would've cost them a pretty penny. |
|
|
|
Any sign of a Win 64 blockchain download?
Just re-did mine from the one in the 1st post and it ended up on the wrong fork...
Just quoting to try and raise this request out of mire of squabbling.  I'm waiting for it to re-sync on the Windows box (also ended up on the wrong fork). As soon ask it's up I'll update the download. |
|
|
|
... kind of begs for a comment from the dev team.
We've discussed this through and through, and the general consensus is that the effort it would take to port everything over is huge, and then we'd be stuck inheriting a lot of other stuff that would make what we want to do in future more difficult. |
|
|
|
Everybody knows that Dingleberry (BBR) is crap.
Stop it. |
|
|
|
|
Show Posts
