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

I think minim1ner filter is pretty bad. It computes perlin function values while good filter should look at values in the map array directly. How about your optimal filter?


I think he has a lot of motocoins.

It has occurred to me while working on repairing the work calculation functions that with a third re-target adjustment added (beyond the existing TT target and the upcoming minimum-hashing-work target) such as a dynamic minimum on path distance, the network should be able to correctly maintain the work curve automatically instead of requiring some best guess measurements from time to time.  However, I think that the math required to set this up is probably outside of my capabilities.  I'd very much like to see someone try it, though!

Anyway, having thought about this today I think I now agree that we should use something more than just Minim1ner's filter.  Does anyone have a good reason why requiring a fixed minimum A* distance, or similar, would not be a good idea?

I think some grid-based pathfinding algorithm should be used to determine minimum path length between start and finish points, cause simple filters will not eliminate maps with slightly higher or lower straight pathes.

Houston, we have a problem.

It seems that with an "ideal" map filter and a sufficiently capable optimization algorithm, the work requirement curve is almost entirely flat until you get very close to the minimal TT.  This means that, pragmatically, domob was more or less correct and also that we will have to make a slight change in our plans.

In order to be able to establish any meaningful work credit curve and avoid long runs of low quality solutions being able to overcome lower TT solutions with a surplus of work credit, we will need to enforce some map selection criteria in order to create a meaningful TT requirement.  A TT of ~8.78 is just downright too easy as a useful maximum on difficulty, so a work curve basically just breaks down into two sets, a few "easy" problems at ~8.78TT and a ton of "far too easy" problems at any value below there.  As things stand right now, even if we corrected the work credit curve to avoid attack we'd see, with any reasonable amount of network scale, blocks solving in fractions of a second, forks like crazy, and no meaningful transaction security.  It wouldn't seem to make sense to implement the current work curve and close both warps to establish a "secure" network with a far-too-easy challenge, only to have to go and re-establish an entirely new work curve against some changed network rules to increase difficulty requirements.

We will have to take measurements of map quality and disqualify "obviously too easy" maps.  I'm thinking it would be fine to just start with minim1ner's basic filter for a threshold, or something similar.  Because this will change the validity of maps themselves (instead of just adding work requirement to map generation) this will have a side effect of invalidating our TT history window for re-target, so we will have to either reset TT to max again after all or implement some other mechanism to make sure that we don't leave TT below the new threshold of solvable maps.

Thoughts?

Everything in this post was already covered quite a bit.


You answered your own question.

There really seems to not be much benefit in dwelling on these topics, for the moment.  None of these factors are likely to alter the course of events that should occur, and many of them will be obviated after the changes.  We'll continue to sort out the rest then.

Time frames have only been delayed by a small amount since my last rundown on the anticipated schedule.  I started sampling a new work curve, using a much more aggressive map filter.  This time I am also only measuring work requirement of the "winningest" solver from the set of optimizer implementations tested, which is specifically a hybrid "multi-level single linkage" algorithm with a local differential search.  Although I've restarted the sampling a few times now (as I keep adding small tweaks and optimizations in order to get the most accurate work curve that we can at this time) I think that the run currently churning along should be good.

Although I've started working out an implementation of the inverse work curve check for block credit (proceeding under an assumption that the new measurements will also fit to a logistic curve, so all that will need changed against the new numbers will be the parameters to the curve) there are still some things to be finished there.  I expect to have a good fit to the new curve within a day or two, and expect that finishing the implementation, polishing up the code, and testing will consume another couple of days beyond that.

All this being said, my hope would be to have a patch set proposed and ready for adoption before the next weekend hits, but we'll see how smoothly things go.  My goal is actually to have all of the motocoin specific "TODOs" addressed in some fashion in this patch, so that we can stop worrying and focus on more fun things, but if the couple of ancillary tasks hold things up I certainly wouldn't delay releasing the work measurement based fixes for the rest.

At this point it is difficult even for the bots.  With TT this low, *only* a "straight line" solution can be valid and even just filtering up a qualifying map quickly enough is a tall order.

However, I'm pretty confident at this point that we can, in a deterministic fashion, "disqualify" such "100% fall through" maps in the future.


Humans have NO shot right now, so don't feel bad.  After the introduction of work requirement per-map this should change a bit, and if we do introduce a threshold on acceptable maps this should change drastically.

I'm increasingly believing that between map work requirements and directly restricting maximal map filter quality allowed we can give LOTS of margin back to humans without approaching a more heavy-handed solution like "N heads."

HunterMinerCrafter, can you provide us with estimated patch release date! Please!!

Yesterday I've tryed to play the moto game another time to see if I can earn some blocks but unfortunately it was the last time because It's really impossible, guys :s haha

More than 2-3 hours trying it to obtain 0 MOTO... 

Maybe I'm not a good gamer, lulz

Curecoin etc are awesome (I've had it on watch list for some time now) in premise, and I very much agree that these projects that "do something" with their blockchain are very much the first steps in an awesomely bright future.  .

The present, however, is a much murkier situation.  I believe that these sorts of projects are going to need a novel sort of openness, transparency, and accountability, the sort that only a hard-core commitment to the principles of a block-chain ledger can produce.  For example, I love the notion of GRC, but can't bring myself to hold any GRC because of a simple (and, to many, seemingly innocuous) fact: it has centralized crediting servers. (They might be compromised at any given moment, potentially with no-one having much capacity to notice right away, and giving away "fake" grid credit.)

Until we can look at such an initiative end to end and and know (in the sense of it being indisputably proven) that it is operating fairly, we have to make some unfortunate assumptions.  Add some gaming aspects into the mix and things become even murkier.  Now you're asking people to play in a game where all of the details of the rules might not be reliable and/or even visible at all, and to do so with money involved.  Scary stuff, important to get it right and not cling too much to projects that have critical centralized components.


Unsurprisingly we drifted off of that equilibrium point, but likely will be heading back to a second equilibrium point as mining capacity redistributes again.


I like to think of this a little differently, but it really comes down to your definitions of this crazy thing called consciousness.  I'm going to step around this philosophical Turing Tar-Pit for the moment, unless it somehow becomes more directly relevant to MOTO. (It very well could, eventually!)    In any case, I agree that certain projects are arguably (crude, to date) codifications of a collective consciousness. (The phrase "Conscious Coins" springs to mind, embodying a few related meanings...)


Shhhh, don't wake the basilisk. XD

Yes, these games are just the beginnings of the inevitable.  Github (etc.) should take pause.  Before long the games the world will play with/against itself on these "conscious" block-chains will be redefining the very meaning of the concept of games, while simultaneously reshaping industries. A block-chain is awesome not because it democratizes money, but because it democratizes anything that you can codify with proof on a network, which is to say (at least) pretty much any useful computational process. :-|


No question, in my mind.  It has to do so in a way that is "just right" though, and this is difficult.


It is possible.  It has been discussed here in there, in various forms, since the very early days of the bitcoin.  To me it feels unavoidable and I think if it where not for exuberance, we would ("should") be there already.  

Every time I see another coin claiming to be a step in these directions it consistently falls short and usually turns out to be some form of scam.  Recently the coins that are making these claims are mostly even doing so without offering source as evidence to justify any of their claims, and I can only bear to spend so much time with IDA.

The fact that MOTO was almost as open and up front (about pretty much everything involved) as it could have been is a big part of why I've latched on.  (Even if there were shenanigans from the premine or whatever they were minor and I, for one, am fine with what the developers would seem to stand to gain even in the worst case scenario.)

We not only need "Conscious Coins" we need them to be conscious, in particular, of remaining radically open and "Free" software.  (In the sense of all of Stallman's contemporary interpretations of the notion, heh.)


I was quite happy to see the democratization of processing in action there, but I think "grab random dead alt and run with it" is an approach particularly fraught with potential trouble.  I suspect that such a network would likely need to be built a little differently from how things are done now, anyway, in order to really thrive.


We need something like a very basic "MOO on a blockchain" game where you mine by building useful things.  Then we need to show people how to world build, and how they get rewarded over time for building things that people find useful.  Then we just say GO.  (ikr? So much easier said than done.)

Or maybe something like Eliza-on-a-chain where you mine by conversing with it and teaching it to better converse.  There's no reason that the "programming work" itself couldn't be done in natural languages instead, I don't think.

The magic is all in how you define (and, more importantly, prove a measure of) the development.

We've scratched the surface with NMC/HUC type projects establishing rules structures in general, and MOTO/GRC type projects codifying some proofs over a measure of progress of some social contribution (slightly broken as they both might be) so I think that we are not far, now, from some thing(s) explosive, here.  (No seriously Github, you might be doomed.)


Lol "Conscious Coin Foundation" maybe?

Seriously though, I think this will all happen naturally in due time, even with the extra distractions introduced by short term greed in the interim.  More to the interesting point, I'm starting to have trouble seeing significant ways in which it could possibly *not* come to pass, short of some global disasters!


It does.  Since the day that I realized what the combination of a hash-collision secured log of merkle structures does in conjunction with "Secure Multiparty Computation" technologies established prior, I've had a rather incredible thirst to see certain events come to pass, and the sooner the better.  A fully democratized, auto-morphic coin is one of them, and should certainly be possible at this point in time.  By definition any such a thing would be a kind of game, so I think this certainly aligns with HUC/MOTO style experiments.


Not inappropriate at all, aside from perhaps the silkcoin elevator pitch, hehe.

These ideas/goals/ambitions are not entirely new to the crypto community.  Many of the things being discussed around these concepts lately just remind me of old conversations from many years back.  One thing that has always seemed to persist as a thread in those discussions are the (seemingly dual) notions that "it makes some AI inevitable" and "it would have to be, formally, a game."  BTC itself would seem to succumb to these properties, if you admit "faster sha hash collision" as a general optimization problem.  (Which it is, just a very noisy nonce space search.)

Or, to put this whole post another way: Look out because "in game currencies" are likely going to reshape our world rather drastically, once the definition of "in game" changes ever so slightly, and that change is (slowly) underway already.

Keep learning!  Just being able to grok control flow indicates that you certainly have capability to understand much about computing!  Python, drupal, and web are all cool, but you should take the plunge and learn a static language to start getting a little closer to how the machines really tick.


I see many (most? lately. :\) alt coins spring up talking big about "to the moon" and how this-or-that feature is going to rapidly accelerate the valuation and make everyone rich, and soon.  Time and again, I watch as hoards of (usually "relative newbie") bitcoiners buy into the notions of why the alt is going to be worth so much so quickly, and watch them get burned every time.

Then I like to go back and re-read some of the writings of Satoshi on the subject.  It has always been fascinating how much trouble he had in getting a few key points across to his audience as it grew.  He was pretty explicit on this particular matter, on several occasions.

A crypto-currency just "does not work that way."  Bitcoin et al MUST naturally grow slowly, or they will tend toward failure.  There is some debate that it might actually be optimal to grow as slowly as possible.  I'm not going to go into the details of all of this, as it has been covered to death elsewhere, but it is important to remember that this principle doesn't change just because we talk about some alt instead of BTC - regardless of what the features that alt offers are.


This is absolutely relevant, and certainly an aspect of the primary goal or mission statement of the project, as I understand it!  The problems there are many and varied, though, and will take time to sort out.  Unfortunately, those problems also have to play second fiddle to stabilizing the network, itself, in such a way that those goals can remain attainable.


MOTO, much like HUC, has a peculiar aspect to it.  I think that we can expect that the market value will have less volatility than most coins, except for when it doesn't.  What I mean here is that any given rules changes to the game which do get adopted by the network might significantly and suddenly impact the spot price!  I am curious to see how this plays out pragmatically in markets for projects that have such a caveat.


I'm told that "commerce bitcoin" php module for drupal can work with alts, probably including MOTO, out of the box.  There is just an array in the .module file that defines the currency names and such.  There are probably some other options out there that would more or less "just work."  Go nuts.  Make a site where people can wager MOTO on which submitter node will claim the next block, or something.

If anything the only modification you might need to make for modules that work against normal daemon rpc is in any code that checks address prefixes.


MOTO could follow the HUC model of "creating its own demand" through specialized transaction fees related to the game itself.  I imagine it could see self-creating demand in unique ways, as well.


NP.  Disparaging happens.  I certainly understand your frustrations.

Hi WilliamLie2, HunterMinerCrafter and others,

I am an early supporter of Motocoin and love the idea of a coin that rewards human participation.
If you look back at my history on this forum it has all centered around the vision about what cryptocurrencies mean for the future.
I got burned in a couple of scams because I thought I saw the possibilities of the start of an ecosystem and a self-fulfilling prophecy.
For example, I love the idea of Curecoin and using the energy to secure crypto to do something potentially useful.

With Motocoin the attraction point was the different mining method, enabling humans to mine.
Very quickly (much faster than expected for me) it turned instead into a competition to see who could design the best bots.
Then there was a period where the botbuilders had to develop an equilibrium so they would not destroy the coin.

Motocoin went from being Proof-of-Human to Proof-of-"being able to program a bot".
This is not a bad outcome.
HunterMinerCrafter said previously in a post: this might be the way true AI is born, in a botbuilding competition.

If I can expand on that idea a bit:
Think of humanity not as a collection of organisms but instead just one organism made up from many parts.
The internet is a new form of nervous system that has developed which means that the human organism can grow more efficient.
With the new nervous system the organism can react faster and its limbs can work in better concert.
A better nervous system allows for a new form of consciousness.

If you zoom into your body: as far as you know, your cells don't have individual consciousness.
If you zoom out of your body and try to comprehend humanity: as far as you know cities and countries of humans don't have consciousness.
My theory is that humanity as an organism acts like an entity with consciousness.
We can almost be seen as slime mold in this video> http://www.ted.com/talks/heather_barnett_what_humans_can_learn_from_semi_intelligent_slime_1

Cryptocurrency is a messaging protocol that is being developed that will enable the human organism to use its new nervous system a bit better.
Who knows where this will lead.
There is currently a form of natural selection happening to try and determine the best form this protocol will take, hence Bitcoin and all the alts, this is completely natural.
Soon the protocol will seem to consolidate and take on a mind of its own, directing its own development.
When people talk about the singularity, this is what I see.


How this relates to Motocoin?
As Motocoin turned into a competition not of a human's reflexes and coordination but instead their programming abilities, this future came a little bit closer.
What makes Bitcoin special is that it was the first coin that seemed to take on a life of its own, the creator left and the system still survives.
Recently I have been involved with another coin that seemed to take on a life of its own and it is fascinating to watch.
I believe that the first coin that has an inbuilt feedback system to direct its own development will be the one that goes viral.
The way I see this happening, is by having an idea platform, a voting system and a method of rewarding the successful product.
If the "nervous system" in my organism analogy can inherently evolve rather than having to be reborn with each iteration, we will see explosive growth and potential.

I basically want you: HunterMinerCrafter, WilliamLie2, and anyone else to help us build this system.
I don't particularly care which one we go for but I want it to be a collaboration and with the aspects described.
Currently it looks like Silkcoin has a good chance of becoming self directive (by proxy self aware) so this is where I want you to look first.
The idea is to have an inclusive coin economy built by developers to reward development.

I want to put my money where my mouth is and would be happy to spend 10 000 MOTO to further this cause.

Please let me know if the idea appeals to you.
I apologize in advance if you feel this post inappropriate but I am excited about the possibilities and want as many people as possible involved, especially developers with original thinking and abilities.

Two small updates on my efforts:

First, I'm currently running a new round of simulations, comparing different strategies for input selection for traversal.  Specifically, I'm comparing about 15 of the major, published, general optimization algorithms against my own annealing and the published bot.  Two algorithms from this new set are consistently crushing these "gen 2 bots" which in turn are just barely beating out the best of the other algorithms.  (I haven't taken any steps to tune any of the new algorithms, just running with their implementation defaults.)  This means not only will I be throwing my old work curve data out with the garbage (for a couple of reasons beyond just having an improved curve) but we'll also be able to say approximately what the "last word" on "gen 2" bots (these "ideal gen 2" bots are what are currently competing on the network) looks like in terms of work expenditure.

Secondly, I've been working on what is arguably an "optimal" map filtering process, and I believe I have a way to explicitly define map filtering work requirement.  From this, I believe we could possibly derive a measure of map "quality" (how far it is from a straight-line solution) and encode a rule that the network would exclude as options any maps below a certain threshold.  In other words, I have the beginnings of some fun math that may let us formally eliminate fall-through maps entirely, if we chose.

Why wouldn't it?

At this point I'm starting to wonder if you're serious, or just trollin.


Stake based mining is both fundamentally flawed as a premise in general, and antithetical to the intent of MOTO specifically.

We might have some use in the future for something more like a PoA mechanism, but coinbase claim should always remain strictly driven by proof-of-play.


Transaction fees are already redistributed to miners, so I'm not sure what you're on about here...


Nobody can accurately predict the future and accuracy of predictions obviously decreases over time.  We can't possibly guess whether the production rate will sit above or below the rate of coin loss on the long tail, so we can't reasonably speculate as to if MOTO will be inflationary or deflationary "in the end" because the "end" is so far after all of us will be long dead.

If we were to speculate, the sensible speculation would be to assume that it will not hyper-inflate, on average.  The diminishing production is highly likely to overcome natural coin loss rate well before the end of the diminish period.

I think it is probably only natural that at some point the parameters of this formula would be "adjusted" to further increase the probability that these creation/loss curves do cross, and personally I'd even like to see it go so far as to introduce a finite supply to force the issue, but even if the supply is left infinite we will likely introduce a sink at some point to encourage (or maybe even give direct incentive for) more intentional coin loss.

In any case, it is a question that "doesn't matter" for hundreds of years anyway, so why dwell on it at?  Even if we do decide it is a problem (I'm not really convinced and I think Will is very far from convinced) we have a LOT of time to rectify it!


Whoa, I think I missed something.  How did you make a jump from the inflationary/deflationary curve to tx fees?  Fees don't impact the coin production.  How is a change to TX fees even a factor here?


Now you've lost me entirely.  Increasing or reducing fees makes no change in how many coins are created in any time-frame.


Miners probably care very little about fee amounts, and likely will care very little about them for quite some time.  We are not even through the first halving yet.  Anyone mining today (and for many years to come) is doing so to collect block rewards, not fees.


This doesn't make sense to me.  Rarity of the coin in total depends only on the work subsidy function as encoded, and liquidity of the coin on the behavior of speculators.  Increasing or decreasing mining activity does not affect coin production rate in anything but the immediate term - difficulty target adjustment enforces, specifically, this.


Better graphics will probably be done at some point, but this is quite a way down on the priority list.


You're still beating this dead horse?  As has been explained to you several times (both publicly and in PM) this cannot reasonably be made to work in any way that doesn't explicitly give huge advantage to bots, which could use an indefinite "look ahead" on the level to play at a significant advantage.  No game mechanic which predicates a challenge on the premise of "surprise the user" can ever really work, since we cannot "surprise a bot" by any means known to date.


If anything, terrain should be made much more difficult!  Much (arguably "all" at this juncture) of our current woes stem directly from the fact that maps are currently far too easily traversed by bots.


While possible, we (again) want to avoid doing things that add challenge to a human player while at the same time giving advantage to the machines.  A bot could trivially be made to have "perfect targeting" aim, so all this would serve to do is further decrease human margins.


We hear you, we don't disagree.  We've heard you, and we haven't disagreed.  Our position hasn't changed.  We need suggestions on improvements to play-ability that are both possible and don't give wide margins to machines.  So far all you have done is repeatedly offer the same two suggestions which don't fall into that category.


I'm sure we would all heavily encourage adoption of the currency by any site or service wishing to.  I'd even be willing to personally assist people with making the necessary modifications to not only this drupal module, but any random btc payment gateway code.  Usually such changes are not difficult at all.


"Cyber currency" or "digital currency" are both super-sets of "crypto-currency" and as such are valid, though generalized, labels.


While I might have agreed with you back when I first got into BTC, I think this is increasingly less true today.


You can already do this on c-cex today, no?


I don't see anything you've brought up here as a significant "obstacle" for MOTO to overcome.  Can you clarify this statement for me?


Again, I'd like to know by what reasoning you think the coin might "disappear?"  As long as the chain keeps hashing (and boy, is it!) then MOTO can't disappear.  A crypto network can only be killed by stopping its chain, and that is generally pretty hard to do by any mechanism other than all of the miners simply stopping their mining of it.  I don't see any reason that this would happen any time soon, aside from the potential of a successfully executed warp attack of significance.  Given the current state of the network, this would probably be extremely difficult to pull off.  (Creating the deficit warp would require beating an already-inexplicably-fast map filter and creating the credit warp would require an in-feasibly fast traversal solver.  It is possible but, at this point, would be an astonishing feat of engineering for anyone but the current dominant miner to pull off.)


Again, MOTO is not your average quick-pump, 1-2 month max lifespan coin.  If you were expecting some magical overnight return from riding some volatile momentum manipulations then you put your money behind the wrong coin, maybe you should have bought some HTML for a few days or something.  If you invested in MOTO without intending the long game, you might not have made a good investment.

On the other hand, if you wanted in very early on a coin that is actually different, has (multiple, independent) committed developers who are doing real research science and engineering work to better their offering, is building something truly novel in the industry to date, is going to make an effort to persist and compete, isn't subject to being "hash raped" by the mining cartel, and that stands to survive long after the scam coins have all absconded and the crap coins have all died off, then just hold steady and confident in your wise outlay.

We're playing the long game, and we're playing for keeps.  If you're looking for some higher risk and shorter term venture in this technology space then go talk to Bitfrog or HYPER (edit: or SVR, lol) guys, I'm sure they'd both just love to sell you some coin.

If you do end up selling your MOTO for something else please don't forget that I'm buying, just PM me and I'm sure we can work out a better priced and more immediate liquidation than you could get on the open market right now!  


Jamaica mon!

Why?  MOTO isn't at risk of being unlisted as far as I'm aware, or at least c-cex hasn't said anything of the sort and I don't see any reason that they would "ninja remove" it.  Volume has decreased slightly but MOTO remains one of the few coins consistently sustaining some liquidity.  In the very short lifespan of MOTO so far we've seen a whole slew of other junk coins listed that have already been removed or are up on the chopping block for the next round of cuts.  MOTO is not just another flavor-of-the-week coin.


As we've already detailed in the thread, this is the intent.


This, however, will probably not happen.  What would it accomplish, besides likely just giving a few thousand "easy" blocks to bots again?

Personally, I think it will be better to leave TT as it is and use it as a measure of how effective our minimum work increase is.  If we add a certain work requirement and find that TT still stays at near-minimum value like it is now then we'll know that our minimum work value is still too low and would need to be increased further.


It likely will, but the current plan is still to release both patches together and do a single hard fork instead of two.  I'm willing to be convinced to stagger the releases, if a good argument is made for it, but I don't see any reason as yet to deviate from the standing plan.


I'm not sure what "other controversial changes" you refer to.  On our current course we will release the three changes already planned and agreed to (My prior patches for second-order work requirement, an increase to the minimum work requirement in those patches in order to slow map generation, and the pending work curve definition change to resolve several of the moto "TODOs" in the code - all three of which are far from controversial) unless some good reason not to is brought up in the mean time.  No other changes are intended/planned at this time, beyond those, controversial or otherwise.

I'm a little worried about moto. I think it could be removed from c-cex soon (due to low trading volume). Maybe it would be wise to release some patch as soon as possible. Just slow down map generation to ~0.1 sec and reset TT to 60 sec. I think it will stop bots for a few days (or even weeks) and slightly improve current situation. And all other controversial changes can be done later.

Some more comments on the data.

Objectively, this is an obvious "misfit" by several arguments.  While the logistic curve over only the "interesting" challenge area (below 30 seconds) shows the best fit, R-squared is still barely breaking 0.25 to 0.3 and the parameters of the data set itself are debatable.  A lower variance simulation will certainly find a better curve to fit, but may under-represent some network conditions.  In any case it is undeniably closer to the reality than the current implementation, since it both correctly considers solutions in the "easy range" to all be of approximately the same work, and quickly requires a vast number of "actually low" difficulty solutions to be able to overcome even a small number of high difficulty solutions.

Subjectively, I find it particularly telling that a logistic curve is not only the best fit but nearly the only viable fit, even though it is such a rough approximation, and in particular that an exponential did not fit well even to the "interesting data set" alone, even though we are still in a state where we cross the TT=0 point in the "nearly just exponential" portion of the hypothetical logistic curve so far.  I expect that we will "see the rest of the sigmoid" emerge in this sort of plot, over time, as bot AI technology progresses and is measured.  I also found it most interesting that, contrary to my expectations going into the experiment, the humans and bots appear to be almost indiscernible in the data.  In other words, humans and bots (at least the bots measured) appear to have approximately the same "cognitive load" requirement to finding a solution at any given TT.  They analyze roughly the same total amount of (not map filtering) information to arrive at a solution for any particular TT, the computers are just able to work through the information much more quickly, and don't have any other particular advantage.  If humans weren't limited by our reflexes in both picking a map and entering our inputs, we could likely still be competitive with the AIs on the path-finding itself even at these ridiculously low TTs.  (I doubt anyone will still claim to be mining by hand these days.) This would imply that if we have the same filtered maps available to both, and sufficiently bias the "map selection lottery" toward humans by increasing the minimum hashing work per map (to effectively make the "same quality of maps available at the same rates") that alone will indeed put humans and bots back on a very even playing field for a time, at the cost of potentially making humans wait some amount of time to see each new map even without any deficit warp occurring.  The game would likely "feel" very different from what it was at this low TT, with the game-play itself now being much faster paced and failures/deaths carrying a much steeper penalty, but the overall experience being a bit slower due to waits between rounds.

Thanks, but it is only a starting point.  Quite a few assumptions were made, and the R-squared is still much lower than what I'd really like to see!


A ha, the operative question.  This is only a measure of average work credit based on solution time, and we consider map generation as independent.  In other words, all maps offered to all participants were generated with one of the three "published" map filters, those being the "none" filter which only checks first frame head and coin ground collisions, and some parameter variations of minim1ner's two (direct or gradient) perlin-depth checks.

(EDIT: I realized upon re-reading that I never actually answer the question.  The overall difficulty is a composite product of the two curves at any point, and the hash-collision curve is well defined as doubling for each consecutive bit. This is how I intended to implement the work credit logic, as it also fits nicely with our modified compact nBits representation.  We can expect that mostly there will just be a corresponding increase in base added to this curve relative to whatever we set our minimum hashing requirement to, but under a work deficit scenario the slope of the total difficulty curve of course increases by an additional exponential factor of 2.  (This is all modulo anything like the "maximum 1/4 adjustment per step" originally enforced by LTC, which we may or may not choose to replicate as we implement.)  This makes for a really steep work requirement at high difficulty under deficit!)

(EDIT2:  An argument might be made that additional map filtering work might be done by miners (but not "accounted for" by these measurements) to further reduce total work requirement for the solver.  While this is true, I expect that there is not a huge gain to be had there anymore, since we moved well below 16 second TT.  It would be interesting to see how this curve is affected by varying the number of sample points in the public filters to estimate a potential impact, but in my experience there is not a huge difference between running the original 18 point curve or running with thousands of points sampled, so I suspect we would find it to be more or less a non-issue at these low TTs.  (Or in other words the maps are probably "already as good as they can get.") YMMV here, and there may very well be some more clever aspects to map filtering that I'm not considering.)


Yes, net work does behave with such a dependency, both in theory (for hopefully self-evident reasons beyond just what you touched on here) and as evidenced in practice, both on-chain and in simulation.  The idea here is that we want to assume map generation and/or filtering as a distinct type of work, not a part of the "TT challenge" work.  You can think of map generation as isomorphic to nonce-range selection on other networks (map selection could be done by a mining pool instead of miners, for example) and not strictly as part of the work function itself.  Or, to put this another way more in fitting with my three-way synchronization model, the work requirements for one "side" of the synchronization are distinct from the work requirements for the second "side" of the synchronization, and should (must?) be so!  (Someone with much better prover skills than mine should certainly try to formalize this notion! (Socrates1024 I'm looking at you, buddy.  (We'll talk privately, we need to catch up anyway.)))

It is precisely this point which is why this three way synchronization can not only work but can be controlled, wrt security threshold, in the first place; we can systematically constrain the search space of allowable nonces as an independent difficulty scale from the work function itself, dependent on that nonce search space.  By doing so we can keep a synchronization of three time scales with the this two-part synchronization consensus processes held targeted at a specific threshold by a composite of two relative security thresholds, instead of the normal two time scale synchronization with consensus security targeted at one specific threshold.  (We can assume this could work for any challenge function accepting some "entropy seed" input which could be generated by a requirement of some rounds of hashing.  To synchronize more then 2 artificial time-scales against the wall clock a cascade of such entropy based work requirements could be used.)

We assume that the particular "split" in the ratio of work contributed in map generation to work contributed in solution time will be naturally self-correcting, for the reasons I've described earlier in the thread.  Rationally, miners will do as little work as is required by whatever we make our set minimum on the map generation work side, to not create a deficit ("difficulty time") warp, and will still "push as far to the right on our graph above" on the solution work side to maximize profits won which will (with the work curve appropriately implemented) serve to secure against creation of a surplus ("cumulative work credit") warp.  It does not matter if miners do not behave rationally as deficits are self correcting and surplus will be assumed sufficiently difficult to create.  (With a confidence in that assumption equal to whatever confidence we have in our implementation of our best fit over our best work curve measurements at any given time.  So if anyone can contribute a better curve fit to better measurements (Mystery bot operator) please, please do!  Between the difficulty in solution at lower TTs and the high variance of the challenge function itself getting a good fit is non-trivial. Eventually we might even want to coordinate mining pools all donating some work to keeping ongoing simulations running, to continuously optimize our confidence in security threshold?!)

Neat stuff, huh?

Hopefully after this explanation it might be clearer why I refer to this as a second order chain, as well.

Great work!

This is for the case when we have only one target (target time), but what happens when we add second target for the map generation? If it becomes 2x slower to generate new map how this will affect overall difficulty? I think it depends on the percentage of the time bots spend in a map filter and in actual replay generation. If bot spends 1% of the time in a map filter then slower map generation will have smaller impact on it then for the bot which spends 99% of the time in a map filter.