But not too long the first deliverable is well under way and I'm free all week with it being my primary focus.

new best=a7cb18858ca68f1f34eb7c08def0ceed4e790549c1560ba6e2e643d484038f1e  height=1072687

Thank you, and hopefully over the coming weeks I can prove that statement unambiguously   Happy to be working with you all.

I created the new 0.9.4 codebase for GameCredits, and will be maintaining the core.

I am also creating a Game Payment Platform / API in conjunction with the Multi User Wallet API that Project Bitmark requires. This component will enable GMC to be adopted quickly by game companies / developers and users without them requiring any detailed knowledge of crypto currencies.

For the foreseeable future you can consider me one of the primary developers on GameCredits, in addition to Bitmark.

Marking and the Multi User Wallet API will both be completed and released.  Bitmark and Pfennig will be updated to 0.10 codebase.  I do not need help, guidance, discussion, speculation, technical or social input to do them.

Melvster, it's a bad enough situation already, without you constantly try to make it appear even worse still and inferring that's it's just the tip of the iceberg.  Este, kenny, thank you.

Yes, web marking will be completed by myself, even if others get their first, or everybody abandons the project.  It will be done.

Some 0.9.4 nodes on the correct chain

Can you add me on skype, mark.bitmark, and I'll help you resolve this now.

As you may know Bitmark uses the Bitcoin codebase adapted for Scrypt, we also have a forkable project Pfennig which can be used for new projects.

Recently I swapped GameCredits GMC from an old Litecoin code base (modified 0.8.x) to the Bitcoin 0.9.4 codebase, successfully.

This gives an opportunity for other coins with older codebases and problems, to be moved to a shared codebase using Pfennig, which is maintained and up to date.  In this manner many different coins could all be updated with Bitcoin Core upgrades over time, lowering overhead to maintain, increasing reliability, and making alt coin advancements easier to port back to Bitcoin in the future should they be adopted.

Currently Scrypt with traditional diff, or KGW are supported by pfennig.  More adaptations could be added in different branches.

Any scrypt coin could be moved over to it, including litecoin itself.

If you know of any candidate coins or communities which may benefit from this, or have any questions, please let me know.  I have limited availability currently to do the codebase swaps myself, but may have ability in the future if anybody would like to employ me to do this for them.

Richiela, All,

The new client only accepts correct blocks (as it should!), there are currently some clients and people mining on the old 30 second prefork chain, the client, and you, should ignore that.

To ensure you are on the correct chain, as of a few minutes ago:

getblockhash 1055250
0105c0e6470d5ff08dc9ba8c67ab974b154782f711c5c9fc427d25fe49f89f9d

If your hash matches and you have that height, everything is fine, your client is working and on the right chain, safe to use.

I have no idea.  However I am creating a block explorer for GMC on the correct chain today, starting in a few minutes.  I will post here and ask somebody to message you when it is ready.

Correct, the instructions for upgrading are all on the release page.  Simply copy your wallet.dat over.

Shavers, please inform the exchanges and pools, I have informed Poloniex.

Dear GMC Community,

Major Release - New Codebase

This release of GameCredits migrates the codebase from old Litecoin to new Bitcoin.

The code is based on Pfennig 0.9.4, equivalent to Bitcoin 0.9.4 adapted for Scrypt+KGW and configured for the new GameCredits HardFork Chain.

There are too many upgrades to list, consider this release the best known version of GameCredits, and the only version to use if you want to successfully partake in the network.

All parties are advised to upgrade immediately.

github gamecredits v0.9.4

Self Builders, exchanges, and mining pools, please build from source and update.

To normal users who install from binaries, please wait an hour whilst I cross compile for Linux, Windows and Mac and upload the binaries. I will update this post when they are ready.

This release is fully tested, and checkpointed to work on the correct (new hardfork) chain, it resolves all previous GMC issues.

Warmest Regards,

Mark

I hope I have not conveyed things incorrectly.

I personally am committed to seeing Bitmark to fruition. Many others are also committed.  The status change is that rather than me being reliant on the project, I'm going to be doing it in spare time (which will be far more productive), with others from the community taking a lead and joining in.

To me this secures Bitmarks future, rather than destroying it.

Dear Community,

Over the past few months I have acted unethically and dishonestly.  I have repeatedly borrowed from trading funds and those around me, mismanaged my time, taken on too much, and as a consequence hurt many good people who didn't deserve it.  Family, friends, associates.  I used the funds for living expenses having (foolishly) no other source of income, and due to mismanagement and overcommitment also managed to devalue the projects (BTM, GMC) I am involved with many times, which has caused even greater harm to associates and stakeholders.  To you reading this.  I am not a victim of circumstance, I created the circumstances and am directly responsible for them. Had I made different decisions along the way things would have been very different.

Over the coming weeks and months I will be working by day for income to repay those I am owing, and by night and weekend to create value on BTM and GMC, to restore value to those projects and to their stake holders.

I would like to clarify that this has been a pitiful situation, everybody is at a loss. This isn't a case of somebody absconding with lots of money and having a great life at others expense, I have had a very financially poor year, and so has everybody around me, which is far worse and for which I am responsible. Any good which has been done along the way is greatly overshadowed by these negative aspects.

Other than the above, I believe my biggest mistakes were as follows:

1. Not having a secure source of income whilst doing the project.

2. Trying to make money by trading profit, rather than by being a stakeholder and creating value. Profit from trading is little more than gambling, and when the stock (alt coins) have little real value (in terms of merit) it's an even higher gamble, and moreover any gains are always somebody else's loss.

3. Being unrealistic in what could be achieved in any given time, and negating needs, project needs and personal needs, letting them pile up rather than resolving them early or ahead of time.

To any observers, please take something from my situation and try to avoid these mistakes yourself, and if you do make any address them early.  Take note that there are some genuinely great people around this community, most of them in this thread, work with them and enjoy time creating value. Crypto, and the world, needs people on projects like this, each doing a small part.  All will get on far better doing this than you will from any involvement in trading or market activities.

I firmly believe Bitmark is a great concept, and it has an incredible community, it's only failing was in having me at the helm. I sincerely hope with others leading the project, and myself constrained to technical input and work only, that it reaches even part of it's full potential.

To those affected by my actions, I can only apologise. I will work hard to put things right, to ensure these two projects grow in value.

Once all is square and the projects are being operated successfully by their communities I will personally step away fully from the opensource and crypto spaces. I get too wrapped up in projects, take on too much, forget about normal things like living and earning, and everybody around me ends up in a mess, friends, family, acquaintances.  I may have some technical skill, but it isn't so special and certainly doesn't outweigh the negative consequences of me having any involvement in projects.

You all deserved far better from me, I have let you down.

From here on, communications from me will be limited to making payments to people, and to making releases of things done.  I am still available to answer technical questions in the evenings.  Finally if you feel I am owing you, and we are not in communication currently, please make contact so that I can arrange to make you whole.

Sincerely,

Mark

There is rough consensus between those actively involved in Bitmark that:

1: Any decision on whether to implement this should come after Marking is Ready for Market.
2: Feedback on the proposal should be collated, and reviewed at our Sunday meetings.
3: Discussion should not detract from our key focus, which is marking.

Thanks,

I do not wish to preclude the slow supply when demand is low, I have always valued it.

The block maturity would remain at 720 blocks, going through two diff changes rather than one.
The diff could still change +/4x over 720 block periods.
The proposed change is nothing to do with miner profitability, it's entirely to enable the network and market to find an equilibrium that is fair in the future.

We currently have two difficulties, 500 and 2000
this corresponds to 17.5 GH/s and 70 GH/s network speeds
which corresponds to roughly 4.35 BTC to 17.5 BTC per day production cost
which corresponds to roughly 30k satoshi to 120k satoshi market price if everything is sold
take in to account miners holding some, and you get 43k to 175k satoshi market price.

Our current status is:
that if the market price is above 43k on low difficulty, the difficulty will rise back up 4x and effectively stop the supply
or if the  market price is below 43k on low difficulty, the supply will start again at 14,400 btm created per day.

Now, what has happened, and will happen again, is that price will go above 43k in high diff period (due to constrained supply), and force the 4x rise in difficulty back up, and stall the supply again.

The only way we can break this cycle without changing the constraints of the diff algo, is for one of the following to happen:

1. keep the market below 43k satoshi during high and low difficulty, then provide enough market liquidity to buy 10k+ BTM per day
... this would require about 15 BTC volume daily minimum and 4BTC of that purely to swallow new coins. The market price and diff would likely both keep dropping until high demand nudged it up a little bit.

2. get the market to be stable at about 175k satoshi, which would require daily volume of about 70 BTC, and about 17 BTC purely to buy newly mined coins. Again the market price and diff would likely both keep dropping until high demand nudged it up a little bit.

Due to the cycle, neither of these will happen under any circumstance, during the high diff period and given rarity, it only takes a small amount of BTC orders in that full time (now 3 months) to push the market price in to the 43-175k range.  Look at the market you'll see it now, this rise has ensured we're about to enter a high diff straight after the low diff.

Why does the high diff happen? Mining profitability calculators, when low diff occurs mining cost will be about 30k satoshi, market price will be about 60k, so miners will see "200% profitability" and jump on network with 100GH/s upwards, pushing the diff back up to 2000 within hours.

So what does the proposed change do?
The proposed change allows the difficulty to change half way through a cycle, by half the max amount. Diff 1000. Practically this means that mining profitability calculators will show 80-120% profitability after 360 low diff blocks. This should have the effect of some network jumping miners switching off, and bring us to a difficulty of about 1500 for 360 blocks.

When diff hits about 1500, we'll enter a new slow production phase, which won't be quite as extreme or quite as long, maybe 1 month with 10-20 blocks per day, followed by a low diff at 750.
If that subsequent low diff at 750 equates to a product cost below market price we'll hit high diff again and slow supply, if not diff will lower further to meet the market. The same pattern as now but more constrained, and with the opportunity to find equilibrium.

Supply and demand will not be changed by this, nor will mining profitability, if marking isn't out we'll have a high diff and low supply, if it is out we'll have a medium diff and started supply.

More likely is that it will allow this extreme high low cycle to reign itself in over say 6 months to equilibrium, with supply gently increasing as demand grows, and knock on of network slowly becoming more usable for transactions as that demand raises.  Which is what we want, and what is currently precluded by our extreme cycle.

DrBob and I have been modifying the code ready for the hardfork.  I'm building and testing it now ready for release.

We have implemented the new Difficulty Algorithm Configuration on a pfennig clone called ZMark, and tested it.

The target for success was to have ZMark change difficulty to 0.018331695 at block 13680 and 0.03666338676 at block 14040

at block 13680, diff = 0.01833169, it worked: http://explorer.zmark.org:3030/block/dbb9553d686bec42bd0c1c7af42a01ca27f4ee34c6006139fb04d476d336b805
at block 14040, diff = 0.03666339, it worked: http://explorer.zmark.org:3030/block/7ed46ccad7ade4474d0205eba9e68755aa1c8428d3a146381db105d68ecabdc4

Test Passed, we can now move to implementing this in bitmark.

If you object to us making this change, please state why publicly so we can discuss.