Topic: [ANN][MOTO] Motocoin - page 44. (Read 178225 times)

Ok, it's working normally now. I can mine and receive other's blocks so everything is ok (177152 blocks now)

Odd, that would imply that there are actually 3 soft forks active right now, and I only see the two.

I'm not sure that you'll need to resync entirely, but you probably need to at least reindex.  In theory the client should be able to recover blindly, but it largely depends on what sort of state your node ended up in during the stall.

Sure, but you should probably wait until after we stabilize from the fork, and start to build up hash-rate again.

I have 177114 blocks now, the last seven blocks are mine and it shows 1 active connection now, but it seems that nobody else sees my blocks so I've stopped mining

By the way, is it necessary to delete old database and make full resync with new client? (I did but not sure if it was necessary)

Would you like Moto dice game created?

Strange, is there anything that stands out in debug.log?  Is it logging any call(s) to CreateNewBlock?

Yes, what block does it show you on? The fork point is after 177107.


I don't see your blocks yet, perhaps we are not peered.  Are the trackers misbehaving?


Yes, old clients and new clients will basically consider each-other not sane, it seems.  I'm looking into this in more detail, but I think it might be somewhat unavoidable.


I'll put up a VPS node so we'll at least have something stable to peer against consistently.

And pressing the buttons "play to mine" and "watch" leads to nothing both in windows and linux versions.

I think it actually synced but showed you label "Out of sync" only because last block was made 5 days ago

Anyway, I've mined 3 blocks already) so it must sync now

But it seems that old clients constantly ban me (is it possible?)

So I have only 0-1 connections now

I've tried but it's not syncing

I asked a friend to do the windows motogame build for me in Visual$tudio and I put together binaries.

https://github.com/motocoin-dev/motocoin/releases/tag/HMCtesting

Gitian build hashes from current master

win32:
d062f955e489fedea68aeaf35dc5e37acd5ac8491847f7ddb4a516beb91fa169  daemon/motocoind.exe
b21e45d84f497d8c74198f4b23d7de0bf6fc80b3d5a861b5d240939b676f9822  motocoin-0.8.7.2-win32-setup.exe
536492098f350bbf02e169b99cd596a3add5fc2844c6b470d1ca42f61a625114  motocoin-qt.exe

linux64:
009c5e09a96e49de08bd31e47b645c59049c7c2a759149dcdd9fc0001dc65b1c  bin/64/motocoin-qt
0b39de9ae430357a4485bcee6dc5c429e0af3efdc9c2d35a6bf9c1b3697795d8  bin/64/motocoind
2eb9e22200f23b33218dd33027e88ddc2d48d2cd164cbe69c39828181d5463ca  bin/64/motogame


It occurs to me that we may want to append the version number, but I'll leave that up to William.

Also, am I correct in understanding that gitian doesn't build motogame for windows, so we can't sign that portion yet?

I've mined 1-3 blocks after each patch, to test that the chain is still moving, and nothing crazy is happening again with log2_work etc.

I am not bot mining at the moment, only mining by hand.  (If you look at the replays (and consider that each block takes me about 20 minutes, HEH) you can see how comically bad I really am.)

None of the patches since the addition of the map filter to motoCheck change protocol, only local work credit calculations, the small memory leak, and build process, so any version of these "unconfirmed" sources would be fine to mine with on the current chain, and everyone has had opportunity to be mining, with an unfortunate caveat that they'd have to build from source.  That is something I'd argue any miner should be doing with any coin they mine anyway!!!!!!!

About half of the coinbases I've mined I have also subsequently ditched from my db, just from testing resync, so the chain was technically soft-forked by me several times at first.  (There have been no tx on the post-fork chain yet, so this only affects my own coin-bases.  There have barely even been peers online, and none running the new version, so no-one even "saw" most of this.)  If people really have any problem with my having "pre-mined" as a side effect of testing on main net I'll gladly nuke my db and give up claim to those ~400 moto, and resume mining again from the fork point.  I doubt people will honestly care much about my having made some loose change while fixing the network.

So you are mining? Using unconfirmed sources that changes every few hours, without officially compiled and released binaries. Actually, I've expected this.

Master should build cleanly with gitian now, I think!

EDIT: Or maybe not.. I made a bad merge when WIll and I both fixed the NULL problem on win32, so when I tried gitian with a clean clone it failed on 'max' missing again. Silly C++11. XD  I'll re-merge that.

Agreed, and this is just one thing on a (growing) list of "missing niceties" that are part of the reason I had been holding off on doing the pathing.  It's livable for now, and there will always be some cases with some wait.  If we need to increase the path length requirement above the halfway mark this will become much more critical.

What is the worst wait you've seen?  I think the longest I've hit so far while playing manually was 6 or 7 seconds, but I've only done about 20 blocks.

Also, I'm surprised that nobody else is mining yet.  You'd think people would be jumping on the opportunity for easy coins again.  (Maybe everyone is just too lazy to build without gitian?)

This waiting between maps is annoying, it certainly shoud be parallelized in the future so that maps are pregenerated while you play.

in jps_grid.h need



I'm looking into other gitian build problems now too.

EDIT: I think that I have the whole gitian build flow sorted out now.  Things started going a lot faster once I realized that I could set more CPUs for the build VM. (Derp.)  I'm double-checking a few things and then will post binaries somewhere.

Hmm, Windows build, this is strange:

The memory leak was actually in the particular JPS library which I had decided to use.  Patch is up on githhub now.

I think gitian is going to start playing nice, as well.