[ANN][MOTO] Motocoin

[Spiky]

Soo let's fork from 199000 and    distress  the bot owner up to 100 000+ MOTO

Don't forget that he can fork too. If you fork him, he will definitely do it in return. We should play nicely.

He can't fork.. cause community against "fastbots".. C-Cex chain is delayed until we provide the right builds for community and we may choose the point of fork..

Maybe he can't do it now, but he can revenge later.


Meanwhile... I didn't measure carefully, just watched block index for some time, but:

199000-200000: 4 sec / block

200000-202000: 8 sec / block

202000-204000: 15 sec / block

204000-206000: 25 sec / block


206000-208000 will be around 50 sec / block I presume ie relatively human mineable again

[HunterMinerCrafter]

Maybe he can't do it now, but he can revenge later.

By what means?

Meanwhile... I didn't measure carefully, just watched block index for some time, but:
...
206000-208000 will be around 50 sec / block I presume ie relatively human mineable again

Yes, the anti-warp is functioning as an anti-bot, just much more slowly than we really want it to.  It doesn't actually seem to function well as an anti-warp at this interval (which we entirely expected, as discussed earlier) so we will certainly still want to do the fork to reduce the interval ASAP.

I can put together a new fork build today.

I'm thinking that we might want to eventually put some parameters, such as base hashing work requirement, up for a decentralized vote on-chain.  Is this something people would feel should be prioritized?

[HunterMinerCrafter]

He can't fork.. cause community against "fastbots".. C-Cex chain is delayed until we provide the right builds for community and we may choose the point of fork..

I'm not sure why C-Cex decided to remain stalled for the time being, but it is fine.  Probably even better that way, in some ways.

I think we are very close to having the network stabilized, in any case.  The fact that the anti-warp does function as an anti-bot would imply that at a more frequent interval it will also appropriately function as an anti-warp.  Total Difficulty target does seem to be balancing well between TT and work requirement.  The new work credit curve is proving to be a much more secure formula, despite the new bot still outpacing it some.

The dust is nearly settled and it seems that much of this drama will be behind us.  We will be able to safely start pushing for merchant and exchange adoption and actual usage as a currency over the next weeks, once hash-rate becomes more evenly distributed.

[Vz]

I'm thinking that we might want to eventually put some parameters, such as base hashing work requirement, up for a decentralized vote on-chain.  Is this something people would feel should be prioritized?

I really don't understand that phrase(
and google translate didn't help me..

HMC, Where you think the forkpoint need to be? 199 000? in the future 206 000? at the 198 000 as we plan early?



* I don't understand how the bot again reach such speed?? the needed work reduced?

[Spiky]

Maybe he can't do it now, but he can revenge later.

By what means?

He can make forks, double spends, reject foreign blocks and transactions etc. I don't understand why we should escalate the situation. We can just make normal fork at some future block (206000 for example)...

I'm thinking that we might want to eventually put some parameters, such as base hashing work requirement, up for a decentralized vote on-chain.  Is this something people would feel should be prioritized?

If you mean embedding voting system for choosing minimum map generation hash work I vote "yes"!)

[e1ghtSpace]

I'm thinking that we might want to eventually put some parameters, such as base hashing work requirement, up for a decentralized vote on-chain.  Is this something people would feel should be prioritized?

I think so. If there is a bot, everyone can vote and take him off.

[e1ghtSpace]

Thanks to WilliamLie2 I can now compile motocoin with gitian. I haven't tried yet but I will in 11.5 hours. (bedtime)
Do you want me to compile the current version or wait for the new version?

[HunterMinerCrafter]

Thanks to WilliamLie2 I can now compile motocoin with gitian. I haven't tried yet but I will in 11.5 hours. (bedtime)
Do you want me to compile the current version or wait for the new version?

Excellent!  If you build current master you should get binaries that match what I just uploaded here: https://github.com/motocoin-dev/motocoin/releases/tag/HMCtesting3

This build has the new fork point set to 210000.  However, with the bot running much more slowly now this could take us 2-3 days to hit.  If we think this is a concern we might be able to try and fork earlier, at 208000.

[e1ghtSpace]

This is slightly ironic since I'm running linux.

I can compile for windows but I get an error about glfw or whatever in the gitian builder.
I sent WilliamLie2 a pm about it.

This is what happens:

Code:

kyle@kyle-Laptop:~/motocoin/gitian-builder$ ./bin/gbuild --commit motocoin=master ../motocoin/contrib/gitian-descriptors/gitian.yml
sha256sum: glfw-3.0.4.zip: No such file or directory
sha256sum: glew-1.10.0.zip: No such file or directory
--- Building for precise i386 ---
Stopping target if it is up
Making a new image copy
qemu-img: target-precise-i386.qcow2: Could not open 'base-precise-i386.qcow2': Could not open 'base-precise-i386.qcow2': No such file or directory: No such file or directory
./bin/gbuild:21:in `system!': failed to run make-clean-vm --suite precise --arch i386 (RuntimeError)
	from ./bin/gbuild:57:in `build_one_configuration'
	from ./bin/gbuild:247:in `block (2 levels) in <main>'
	from ./bin/gbuild:242:in `each'
	from ./bin/gbuild:242:in `block in <main>'
	from ./bin/gbuild:240:in `each'
	from ./bin/gbuild:240:in `<main>'
kyle@kyle-Laptop:~/motocoin/gitian-builder$ 

I guess I need to download those zip files, but where do they go?

[HunterMinerCrafter]

I guess I need to download those zip files, but where do they go?

You get some of these from running the boost, deps, and qt gitian descriptor files before running the main build.  Everything else you will have to hunt down.

They go in gitian's "inputs" directory.  Here is everything that I have in mine right now:

Code:

bitcoin08-deps-win32-gitian-r11.zip
boost_1_55_0.tar.bz2
boost-mingw-gas-cross-compile-2013-03-03.patch
boost-win32-1.55.0-gitian-r6.zip
build/
db-4.8.30.NC.tar.gz
glew-1.10.0.zip
glfw-3.0.4.zip
libpng-1.6.10.tar.gz
miniupnpc-1.9.20140401.tar.gz
motocoin/
openssl-1.0.1h.tar.gz
qrencode-3.4.3.tar.bz2
qt-everywhere-opensource-src-4.8.5.tar.gz
qt-win32-4.8.5-gitian-r5.zip
qt-win32-4.8.5-gitian-r6.zip
result/
zlib-1.2.8.tar.gz

[e1ghtSpace]

Ok I can compile for windows and linux now!!!

Here is the sha256sum for the gitian builds:

Windows:
34a287fa236715926924531bf998c2a2982dae9c51b23e17518e1de733ff55bb  motocoin-qt.exe
85d14fe4acb8d534a2da2fdfd60376a711255480be1b547ced964ac83d036cea  motocoin-0.8.7.2-win32-setup.exe

Linux:
19c019e3ca2e78c10884d924178dffee9dea27c233e9a8cacbbdcd381129442f  motocoin-qt

If you need me to upload the files, just ask. (although it could take quite a while )

[HunterMinerCrafter]

Ok I can compile for windows and linux now!!!

Excellent work!  If Will also builds, that will make 3 of us for signing, which is a good start.

Here is the sha256sum for the gitian builds:

Ahh, but the big question is do all of your binary signatures match what is in my downloads?!?!? 

If you need me to upload the files, just ask. (although it could take quite a while )

As long as hashes match up on all of our builds we only need one upload.  If your builds match my builds then you are done until the next code change.  If your builds don't match my builds then you should bother me to find out why.

[HunterMinerCrafter]

It is again taking us an awful long time to get to our new fork point.  However, I don't think this time it is from the bot intentionally throttling itself, but is instead from the anti-warp targeting finally starting to converge.  The average amount of warp effect created by the bot has been steadily decreasing, and we're now coming closer to a point where the bot is not able to solve faster than the TT.

Is anyone human mining lately?  Is the difference very noticeable?

The past couple of days have mostly been spent assessing different approaches to on-chain voting for mining parameters.  I think we might best be served using something like the Heavycoin approach.  I might add one small feature to Heavycoin's implementation, allowing users to defer their vote to that of other users.  (So if you don't want to actively manage what parameters you vote for you could just tell your client to always "vote the way e1ghtSpace's address last voted" for example.)

I think we should allow voting over at least what are currently the two constants in the formula: min path length and base hashing work requirement.  Other things we could consider including are:

• Hashing work multiplier - in addition to adjusting base (minimum) hashing work target we could adjust number of rounds of hash required before collision check.  In this way the network could vote to multiply the anti-warp strength
  
• TT adjustment- We could allow for a vote on a number of bonus or penalty frames summed to TT.  With this, the network could vote to make TT easier/harder than what is set by target
  
• Block reward adjustment - Although I personally have some qualms with this one, I certainly understand the motivations.  With this, the network could decide to reduce/increase average subsidy distributed
  
• Block interval - I don't think this one has been tried on another coin (probably has and I just missed it) but we could vote on how often blocks are produced, allowing the network to increase/decrease security in trade-off with confirmation rate
  
• Work credit curve parameters - Instead of intermittently measuring the work curve and hard-coding the logistic parameters we could put all of the parameters up to a vote.  However, this runs a risk because it creates the possibility for the chain to "vote itself into an inecure configuration" which concerns me a bit.  (This might also be true of block interval voting?)
  
• Total coin cap - Another one that I don't recall seeing done in another coin yet (EDIT: this is actually done "indirectly" by heavycoin) we could have a vote on the total number of coins to be created.  This would have to be handled with some care, as once the set cap is reached the vote should only allow for the cap to be raised, not lowered.  It is possible, though, and would give us a nice way to approach the "should we leave MOTO uncapped" question.
  
• Map size - This one might be a little more difficult to implement correctly, but it should be hypothetically possible.  This would allow the network to increase/reduce the dimensions of the play area.
  
• Map seed density - Another one that would be difficult but hypothetically possible.  We could change how densely seeds are applied in the perlin function.  This would allow us to raise/lower the overall "entropy" of map generation.
  

Did I miss anything obvious?

(EDIT: We could of course also include some parameters over the physics itself, like gravity strength, acceleration force, friction, angular momentum applied when rotating, etc... but I'm not sure if that would be a really good idea or a really bad one, hehe.  I'm inclined just to "not even go there" for now.)

I will probably start by implementing votes over just the two constant values.  If there is significant demand demonstrated for any others, in particular, we will approach those after we prove out an implementation over the two basic requirement values.

Thoughts?

[WilliamLie2]

I think we should allow voting over at least what are currently the two constants in the formula: min path length and base hashing work requirement.  Other things we could consider including are:
...

Bots will vote for parameters to make bot-mining easier.

[HunterMinerCrafter]

I think we should allow voting over at least what are currently the two constants in the formula: min path length and base hashing work requirement.  Other things we could consider including are:
...

Bots will vote for parameters to make bot-mining easier.

For these two parameters we would only allow a vote to be additive.  In other words, the min path length could never be voted lower than what it is now and the base work requirement could never be voted lower than the min work set by target.  The network could vote to make the required path longer (cutting out more maps as valid) or make the base hashing work larger (basically enforcing more anti-warp work be done even when the network is not under more debt warp) but could never require the path length to cut less than 50% of maps as it does now and could only add to anti-warp work set by target, not reduce it.

(EDIT: In other words (for these 2 parameters at least) bots could only vote not to increase their difficulty, they could not vote to decrease it beyond what the base requirements already are.)

[Spiky]

Can you explain how exactly do you want to implement this voting system? I mean will it take into account only last 2000 blocks or all the blocks (will all already mined blocks have default voting parameters then?)

Also, I think maybe it's wiser to wait until mining distributes well and more exchanges add moto before implementing this voting system?

[HunterMinerCrafter]

Can you explain how exactly do you want to implement this voting system?

It would work the same as Heavycoin, with votes being proportional to hash-rate applied, and values applied by an average of votes over a look-back window.

I mean will it take into account only last 2000 blocks or all the blocks (will all already mined blocks have default voting parameters then?)

It will take into account only blocks within the set look-back period.  There would be an initial "seeding" round where parameters would be at default but with votes being collected into blocks before the first parameters get set.  Old blocks would not be considered.

Also, I think maybe it's wiser to wait until mining distributes well and more exchanges add moto before implementing this voting system?

This is all being speculated under an assumption that mining distribution will naturally continue to balance itself out over time, to a point, from the existing anti-warp, particularly after the target interval is made shorter at the block 210000 fork. I think the bot started to hit its limits around the 0x1F010000 anti-warp target, implying that we are already close to what the anti-warp will do "on its own" as an "anti-bot" mechanism.  (Of course we still need more miners to step up to the challenge and claim the hash-rate that is now available to them... or we need someone to publish a capable bot for broader use.)

How many exchanges we are on does not seem to be at all a factor in the decision.

[Vz]

I don't know why.. but I can't start on the WIN 64 bit the game... the wallet start, but nothing happened when i pressed the "play to mine" also i can't see the replays(

[e1ghtSpace]

I don't know why.. but I can't start on the WIN 64 bit the game... the wallet start, but nothing happened when i pressed the "play to mine" also i can't see the replays(

And you've installed the x86 runtimes even though your computer is compatible with the x64 runtimes?
The x64 runtimes aren't compatible with the game.

Download Link: http://www.microsoft.com/en-us/download/details.aspx?id=40784

[HunterMinerCrafter]

I don't know why.. but I can't start on the WIN 64 bit the game... the wallet start, but nothing happened when i pressed the "play to mine" also i can't see the replays(

Can you run motogame.exe by itself?