[ANN][MOTO] Motocoin

[HunterMinerCrafter]

The buy side doesn't look too optimistic eh.

You can say that again.

It looks like it was mostly a single seller dumping into a thin market on low volume.  Buoyancy in response is quite low, however. 

Interestingly, network hashrate and market price seem less coupled than with many other coins, so far.

[HunterMinerCrafter]

So, how's the patch coming along?

Well, I was hoping to get some more feedback/criticism/comments on the gist outline, but this doesn't seem to be happening.

I've been preparing a proposal release.  I have had a build of it running/mining on the real chain for a couple of days now, and it seems stable.  It has the following "feature branches" included so far:

• TwoTargets

The full patch for the difficulty time warp fix, still enabled only on testnet, and without the Median change.

• GetChains

A trivial port of Domob's getchains patch from HUC, used for monitoring soft fork lengths. This is a great tool for monitoring network fork behavior, and checking for double spend attempts.  HUC has seen some epic soft forks and this has become an indispensable tool on MOTO as well, to monitor for attempts to use the time warp.

• MoreWarp

Allows time to be sped up or slowed down by up to three orders of magnitude more than the reference client

• MapSeeker

Two variants of Minim1ner's map filter(s), tuned for human mining.

• TxReplay

Allows you to quickly launch a replay of a block from the context menu of a transaction.  This makes it easy to replay blocks you've mined.

• TestnetBox

The bitcoin-testnet-box setup modified for convenient moto testing

• LtcUpdates

Gitian openssl (etc.) updates merged from upstream

I'll push these branches to my github today for more people to try.  I think whether the others step in with feedback on the patch or not we should go forward with launching the change as a community, and make improvements later.  IMO, it is important to at least address the attack vector with "something" ASAP, even if that something is not the ideal. Worst case we end up having to hard fork after all, but I see this as an unlikely outcome.

I also have Minim1ner's full bot cleanly merged in, tweaked/optimized, and using the original wallet's build files so it builds cleanly/easily on windos and *nix.  I'm assuming OSX will build with the other pullreq that is hanging out there, but I can't test it as all of my mac hw runs linux.  However, these patches won't be released until after some fix for the warp is adopted by the network.

@WilliamLie, if I pullreq these patches (with TwoTargets enabled for live net) do you think that you'd merge them?  I think the soft fork for the fix will likely go much more smoothly if we're not forced into "forking against" the reference client.

In the future, after the warp attack issue shakes out, I'd like to work on improving the game physics, addressing the question(s) of what happens when we hit the ltc coin caps, and adding some more interesting elements to the competitive aspects.

[psychocoin]

Sounds great! So, we gotta wait for the merge?

[WilliamLie2]

@WilliamLie, if I pullreq these patches (with TwoTargets enabled for live net) do you think that you'd merge them?  I think the soft fork for the fix will likely go much more smoothly if we're not forced into "forking against" the reference client.

Most probably, I just need to look at them.

improving the game physics

What for? I think that bots don't care.

when we hit the ltc coin caps

What does that mean?

[HunterMinerCrafter]

@WilliamLie, if I pullreq these patches (with TwoTargets enabled for live net) do you think that you'd merge them?  I think the soft fork for the fix will likely go much more smoothly if we're not forced into "forking against" the reference client.

Most probably, I just need to look at them.

Ok, https://github.com/HunterMinerCrafter/motocoin/commits/master most of them are up.  I need to rework a few minor things with the testnet and ltc backports a bit, but I'll get them up today as well.

The most recent commit there is entirely untested so far, heh.

improving the game physics

What for? I think that bots don't care.

Sure, but humans care.  I've had multiple people mention that the physics feel off.

when we hit the ltc coin caps

What does that mean?

Right now there are a few issues with the total subsidy.  There are quite a few "motocoin TODO" notes around the source related to it.  Personally I think we should actually cap total supply, but this would need discussion.

[WilliamLie2]

Right now there are a few issues with the total subsidy.  There are quite a few "motocoin TODO" notes around the source related to it.  Personally I think we should actually cap total supply, but this would need discussion.

I don't see any issues.

I merged your pathes. I don't have much time to fully review them, do you think that new version can be released as is?

EDIT: where is "game/debug.h"?

[HunterMinerCrafter]

Right now there are a few issues with the total subsidy.  There are quite a few "motocoin TODO" notes around the source related to it.  Personally I think we should actually cap total supply, but this would need discussion.

I don't see any issues.

We'll come back to it.  It isn't anything critical or that has much impact on protocol, but some other functions of the wallet fail for related reasons like progress/lnwork calculations.  In any case, I think we should have a finite cap, otherwise we might be particularly susceptible to 'mudconomic' effects.  There are a couple of ways that we can make a finite supply without ending up in a "wait around for a block to compete just on tx fees" situation.

I merged your pathes. I don't have much time to fully review them, do you think that new version can be released as is?

It could, but the warp fix is still conditional to testnet and the map filter should probably be made optional with a key binding or something.  I'll further polish the changes as I have time available today/tomorrow.
EDIT: Also the second (and more useful) part of the getchains patch got missed in the merge.  I'll push this in a bit as well.

EDIT: where is "game/debug.h"?

HEH, I hope this doesn't become a running joke with moto.  It got stuck into different commit than what got merged, for silly reasons. You can grab it from m1ner's fork and I'll also push it to my master when I get back to a real PC.

[WilliamLie2]

You included bignum.h in moto-engine-cpp, game now becomes depended on boost and openssl. How were you able to compile it if makefile isn't changed? Compiling for windows will become much more complicated with such dependencies.

EDIT: It isn't actually used so I just commented it out.

EDIT2: Generated maps are good but still not anywhere near human mineability.

[HunterMinerCrafter]

You included bignum.h in moto-engine-cpp, game now becomes depended on boost and openssl. How were you able to compile it if makefile isn't changed? Compiling for windows will become much more complicated with such dependencies.

EDIT: It isn't actually used so I just commented it out.

Probably I messed something up in the merge.  I was in a hurry when I pushed it.

EDIT2: Generated maps are good but still not anywhere near human mineability.

I just meant that it had some small parameter tweaking to make it generate better maps than what it searches with the bots.  Human mining will not really be able to become approached by most humans (except the most skilled and dedicated) until we do something like the "N heads" concept.  Interestingly the way I am bot mining now there is actually an optional human mining element to operating the bots, where you can help nudge your bots along at your discretion.  This makes for a fun sort of meta game in the mean time.

[e1ghtSpace]

when we hit the ltc coin caps

What does that mean?

I assume hope he means when we hit the Litecoin Market Cap.
Although ltc could stand for something else.

When will you release the compiled client with all of the patches all of the current patches that you've completed? Or are you going to work on it more and add in the N heads or whatever it is?

[domob]

• GetChains

A trivial port of Domob's getchains patch from HUC, used for monitoring soft fork lengths. This is a great tool for monitoring network fork behavior, and checking for double spend attempts.  HUC has seen some epic soft forks and this has become an indispensable tool on MOTO as well, to monitor for attempts to use the time warp.

Cool, I'm glad you like it!

[coinclown]

Right now there are a few issues with the total subsidy.  There are quite a few "motocoin TODO" notes around the source related to it.  Personally I think we should actually cap total supply, but this would need discussion.

 Any doubts? Really? This is the must for real crypto. Please, respect our prothet (Satoshi) and cap the total supply.

[WilliamLie2]

Right now there are a few issues with the total subsidy.  There are quite a few "motocoin TODO" notes around the source related to it.  Personally I think we should actually cap total supply, but this would need discussion.

Any doubts? Really? This is the must for real crypto. Please, respect our prothet (Satoshi) and cap the total supply.

Yeah, I have doubts. Why whould we cap the total supply?

[HunterMinerCrafter]

when we hit the ltc coin caps

What does that mean?

I assume hope he means when we hit the Litecoin Market Cap.
Although ltc could stand for something else.

I'm referring to this

Code:

/** No amount larger than this (in satoshi) is valid */
static const int64 MAX_MONEY = 84000000 * COIN; // Motocoin-FIXME: max amount
inline bool MoneyRange(int64 nValue) { return (nValue >= 0 && nValue <= MAX_MONEY); }

This section of code (and some related control flow changes elsewhere, also) affects, in relatively small ways, things like fee calculation, transaction validity, network work statistics, and more.  They are all minor problems, but a lot of the things that "just don't work quite right" in the wallet/daemon (and in particular the rpc commands) hit this particular group of changes relative to upstream Litecoin.

(EDIT: I should also point out that the set of things that don't quite work right increases quite a bit if you do something like give yourself 100million coins on a testnet!)

When will you release the compiled client with all of the patches all of the current patches that you've completed? Or are you going to work on it more and add in the N heads or whatever it is?

I don't think it is my place to release reference client builds, so for now I'll defer to WIlliam on this.  Right now the patches are not entirely broadcast quality, but they are not far off.  I've made a few more tweaks and will push a new set of patches out shortly, after I clean a few things up with the last merge..

Once there is a patch set that everyone seems happy to go ahead with, I'll be calling for all of the bot operators to make the switch at around the same time.  Although I would think it likely that the majority of the miners will adopt the changes outright, some might disagree with the changes and may try to "vote against" the soft fork.  Possibly some might even try to apply the attack vector "post mortem" and warp the old-rules branch to keep it perpetually longer (even after it would not be accepted as valid by the majority of the upgraded network) to confuse/trick old clients.  This is why I think we would be wise to bump version number in block header soon, so users who are not following the situation get prompted to upgrade.  If this is a particularly serious concern to anyone, we can enforce a hard fork, but I don't think the user-base is likely large enough to really necessitate it.

[HunterMinerCrafter]

• GetChains

A trivial port of Domob's getchains patch from HUC, used for monitoring soft fork lengths. This is a great tool for monitoring network fork behavior, and checking for double spend attempts.  HUC has seen some epic soft forks and this has become an indispensable tool on MOTO as well, to monitor for attempts to use the time warp.

Cool, I'm glad you like it!

It is, IMO, sort of the "missing link" in the common rpc command set for doing any sort of double spend checks.

[WilliamLie2]

when we hit the ltc coin caps

What does that mean?

I assume hope he means when we hit the Litecoin Market Cap.
Although ltc could stand for something else.

I'm referring to this

Code:

/** No amount larger than this (in satoshi) is valid */
static const int64 MAX_MONEY = 84000000 * COIN; // Motocoin-FIXME: max amount
inline bool MoneyRange(int64 nValue) { return (nValue >= 0 && nValue <= MAX_MONEY); }

This section of code (and some related control flow changes elsewhere, also) affects, in relatively small ways, things like fee calculation, transaction validity, network work statistics, and more.  They are all minor problems, but a lot of the things that "just don't work quite right" in the wallet/daemon (and in particular the rpc commands) hit this particular group of changes relative to upstream Litecoin.

Can you give me examples of what works wrong? I can't find any single issue.

(EDIT: I should also point out that the set of things that don't quite work right increases quite a bit if you do something like give yourself 100million coins on a testnet!)

Try to give yourself 100 million on Litecoin testnet and you will have the same issues, so what?

[HunterMinerCrafter]

Right now there are a few issues with the total subsidy.  There are quite a few "motocoin TODO" notes around the source related to it.  Personally I think we should actually cap total supply, but this would need discussion.

Any doubts? Really? This is the must for real crypto. Please, respect our prothet (Satoshi) and cap the total supply.

It is well understood that scarcity is a necessity, but it is largely an open question as to what parameters this scarcity can/should have for a successful coin.  Did Satoshi ever give strong criteria for a finite bound?  Is 42 or the "one" coins inherently better because they are more finite?  Personally, I'm not so sure.  I think as long as the security parameters "fit together" to establish an appropriate security threshold on the consensus the actual numerical values chosen for this cap (and some (but not all) other factors) are not so relevant.  If, as long as there is relative scarcity, we can accept that there is no pragmatic difference between having the one coin, the 42 coins, the 21million-ish coins, the 84million coins, the 969 quadrillion coins, why not extrapolate out to "the virtually infinite coins?"  Of course it can also be said that nothing is ever really without some finite bound, even when we say the total supply is not capped it is of course a little white lie, there is and will always be some finite bit-width to balances which cannot be exceeded.  There is only so much accessible energy in our universe.

Yeah, I have doubts. Why whould we cap the total supply?

MOTO does have a scarcity function and although it is relatively less scarce than, for example, btc it will at least attempt to meet some measure of scarcity criteria, as is.  I think it is, however, a bit of a discomfort to many people (particularly cryptocurrency speculators) to not know ahead of time this measure or the very-long-term net effect of that scarcity.  With a finite cap, it is very easy to point to a particular span of time and declare a relative scarcity.  With a scarcity function as moto has currently it is left as something of an open question as to how effective the utility of that scarcity function will actually be, over time.  To compound the psychological impact of this, the utility becomes even more questionable at ever increasing scales of time, so when people naturally extrapolate out to "at some point in the ridiculously distant future there will be more of this token than anyone could ever possibly want" they conclude that the token must ultimately be of virtually zero value, and as such they should not hold it.  Even if they concede that it only asymptotically approaches zero, they will still devalue the coin simply because it will, eventually, overcome the utility of the scarcity function and approach that zero.

Never mind that they may be extrapolating well beyond any meaningful scale.  By the time we are down to 10% of the relatively scarcity of btc, a few hundred years from now, everyone reading this thread today will likely be long gone.  (From there down to less than 1% of relative scarcity is a mind boggling time-frame, in financial terms.)  If you consider scarcity alone to be the primary source of value, and really do use a decades-per-candle chart to trade on, looking hundreds of years out (maybe you are investing to build a college fund for great great great grandchildren or something) you should still conclude that this puts moto at around $60 without any other factor.  Anyone extrapolating all the way out to "this coin is not scarce enough on a long curve so I'm going to value it at one satoshi" (yes, some/many people really do think this way) is probably not considering just how long of a curve we are really talking about!

And yet they extrapolate.  Because of this natural (and arguably even rational, maybe the investor really is considering his lineage generations out) risk-aversion behavior many coin developers feel it best to simply put the whole question to bed and enforce finite supply.  The ones that don't tend to be the ones that also, for one reason or another, don't "take themselves seriously" which further leads speculators to feel that they shouldn't take seriously any coin that tries to go against the grain.

I entirely understand why moto chose to go the other direction, and leave the question open.  It will not be trivial to cap the supply, and not create an eventual (though still likely decades-to-centuries away) alternative problem, where we hit a bit of a catch-22 where no-one is left with motivation to mine the coin until a large set of transactions reach mempool, but at the same time no-one would want to use the coin because tx processing will be slow because there are no active miners until tx records come in!  This problem is solvable, but I'm personally not surprised that the implementation did not attempt to solve it.  Any of the things that you can do to solve it will take a lot of work.

From a purely intellectual perspective, I find it entirely reasonable that a coin with a scarcity function like MOTO's could/should/would work just fine.  From a "let us make moto a successful experiment" perspective I tend to agree that it is likely best to simply not leave the question open in the first place and declare a final, total block subsidy cap.

[HunterMinerCrafter]

Can you give me examples of what works wrong? I can't find any single issue.

Just try sending yourself 100million moto, for example.

(EDIT: I should also point out that the set of things that don't quite work right increases quite a bit if you do something like give yourself 100million coins on a testnet!)

Try to give yourself 100 million on Litecoin testnet and you will have the same issues, so what?

On ltc there will never be 100million coins, because the subsidy stops.

Further, it introduces some funny questions in protocol.  Our network might currently accept a block of larger than the max block size (which could create all kinds of ancillary problems) as long as you're willing to pay an 84million coin transaction fee.  If you want to send someone more than 84million coins, it is allowed but you can only do so if you pay an 84million coin tx fee in addition.  (I'm not making this stuff up!  Look at the control flow of GetMinFee, I LOLed.)  Sure, these are problems that no-one would/could hit for a very very long time, but they are bugs to be fixed none the less.

In terms of more immediate term needs, things like "work progress" are relative to this 84 mil cap number, so even today some tools which expect to see reasonable values for these rpc calls can't work with the reference daemon.  Either some meaningful definitions for these things need to be established, or the "extra meaningless data" should be removed.

[WilliamLie2]

Can you give me examples of what works wrong? I can't find any single issue.

Just try sending yourself 100million moto, for example.

(EDIT: I should also point out that the set of things that don't quite work right increases quite a bit if you do something like give yourself 100million coins on a testnet!)

Try to give yourself 100 million on Litecoin testnet and you will have the same issues, so what?

On ltc there will never be 100million coins, because the subsidy stops.

Further, it introduces some funny questions in protocol.  Our network might currently accept a block of larger than the max block size (which could create all kinds of ancillary problems) as long as you're willing to pay an 84million coin transaction fee.  If you want to send someone more than 84million coins, it is allowed but you can only do so if you pay an 84million coin tx fee in addition.  (I'm not making this stuff up!  Look at the control flow of GetMinFee, I LOLed.)  Sure, these are problems that no-one would/could hit for a very very long time, but they are bugs to be fixed none the less.

I would recommend you to think about more immediate issue - year 2106 problem. But this is probably irrelevant because all current cryptocurrencies will be destroyed by quantum computers much sooner.

In terms of more immediate term needs, things like "work progress" are relative to this 84 mil cap number, so even today some tools which expect to see reasonable values for these rpc calls can't work with the reference daemon.  Either some meaningful definitions for these things need to be established, or the "extra meaningless data" should be removed.

Can you be more specific, what are "these rpc calls"? I'm not an expert in all of the bitcoin rpc calls, which call depends on total supply? What "these things" except total supply are you talking about?

[HunterMinerCrafter]

I would recommend you to think about more immediate issue - year 2106 problem. But this is probably irrelevant because all current cryptocurrencies will be destroyed by quantum computers much sooner.

Things like the 2106 problem are easily addressed with very trivial changes that don't even need to be changed at the protocol level, for example simply allowing the overflow.  These things are also not specific to moto, so we can expect some solid patch will come along from upstream long before it is an issue, so we probably shouldn't even need to expend any effort on thinking about it.

Things that are specific to our coin, like "so just how does the network's subsidy behave in 200+ years, assuming things like crypto primitive changes to handle quantum etc..." are still valid questions regardless of anyone's opinion on if a total cap is best or not.  When it comes down to issues like "this bug means X for this coin network specifically, on some future date" the existence of that bug factors into an assessment of the coin.  As I've illustrated already, some very silly conclusions like "sell all at 1 SAT now!" can be erroneously drawn from some of this, but some valid conclusions can be drawn as well.  Should moto happen to persist, I wouldn't want to be the guy sitting here a couple 1000s years from now cursing my ancestors for making some silly rule that to send 84million+ coins one has to also spend 84million+ coins.  As an investor today, I might wonder how others would perceive the developer's "shrugging off" such oversights in the implementation (which are usually "standard bullet point items" for an alt.  Most any ANN post on this board will have a bullet listing total subsidy details, and you really want what is announced and advertised there to be truth!) and might wonder what else they've overlooked in their fork from ltc.

What is most troublesome right now, though, is that both camps in the "should it be capped" debate would be dissatisfied with the current state.  We have an infinite subsidy, but an effective cap at an 84million coin denomination, at which it becomes impractical to spend.  Pragmatically, the network fails to meet either proposition.  (EDIT: and my real concern is in what other still unknown ways it might fail to meet either. IMO it really needs to pick one or the other and implement it as such, completely and correctly, end to end.)

In terms of more immediate term needs, things like "work progress" are relative to this 84 mil cap number, so even today some tools which expect to see reasonable values for these rpc calls can't work with the reference daemon.  Either some meaningful definitions for these things need to be established, or the "extra meaningless data" should be removed.

Can you be more specific, what are "these rpc calls"? I'm not an expert in all of the bitcoin rpc calls, which call depends on total supply? What "these things" except total supply are you talking about?

My apologies, I was confused.  I guess there aren't any of these work details exposed in the stock rpc set.  From a quick skim over some things, it looks like the only thing directly affected in the reference wallet right now would be the block/tx handling.

(EDIT: But on a related note, we might want to look very closely at GetBlockWork before we do any check-pointing...)