[ANN][XMY] Myriad | Multi-Algo, Fair, Secure

[Phorna]

As someone who mines both gpu and asic, I must say that my asics are currently making a KILLING with this coin in comparison to my gpu's.  From an investment standpoint, they've cost me about the same (~$2500 usd for asics, ~$2500 worth of gpus), but my asics clear ~25k myr a day while my gpus get around 2500 myr (roughed in numbers, just illustrating my point).

What algo do you mine with your GPU rig?

[1715403391]

1715403391

[1715403391]

1715403391

[1715403391]

1715403391

[1715403391]

1715403391

[killermonkeys]

As someone who mines both gpu and asic, I must say that my asics are currently making a KILLING with this coin in comparison to my gpu's.  From an investment standpoint, they've cost me about the same (~$2500 usd for asics, ~$2500 worth of gpus), but my asics clear ~25k myr a day while my gpus get around 7000 myr (roughed in numbers, just illustrating my point).

What algo do you mine with your GPU rig?

Just had a look at the pools my gpus are on, and adjusted the numbers.  was a little off!
one nvidia rig pulling ~40mh on groestl ~2000 myr/day
one rig with a 280x and 7970 on skein  ~5000 myr/day
yesterday my solo 1th sha-256 pulled 23k myr.

[Phorna]

Just had a look at the pools my gpus are on, and adjusted the numbers.  was a little off!
one nvidia rig pulling ~40mh on groestl ~2000 myr/day
one rig with a 280x and 7970 on skein  ~5000 myr/day
yesterday my solo 1th sha-256 pulled 23k myr.

Yeah, I was asking because rig for $2500 is at least 3,5 MH. You should be able to get at least 10K MYR a day.

[killermonkeys]

Just had a look at the pools my gpus are on, and adjusted the numbers.  was a little off!
one nvidia rig pulling ~40mh on groestl ~2000 myr/day
one rig with a 280x and 7970 on skein  ~5000 myr/day
yesterday my solo 1th sha-256 pulled 23k myr.

Yeah, I was asking because rig for $2500 is at least 3,5 MH. You should be able to get at least 10K MYR a day.

Ya, probably less since half of them are nvidia.  Running a modded ccminer.  Groestl seems to work best for them.

[HR]

Do you really think so? Where are you getting your data? Blocks are being mined at an equal rate (more or less) regardless of the algo being used.  http://myriad.theblockexplorer.com  And the block reward is the same.

Yes I have used this page. On that page you have an information how many coins you are getting per unified MH unit.

340 MYR / MH day by Sricpt
2805 MYR / MH day by Skein

Of course this data fluctuates with every block a bit.

My SKEIN GPU rig has power usage 300 W / 1 MH = 2805/300 = 9,35 MYR / W
My SCRIPT ZEUS Blizzard miner has 38 W / 1 MH = 340/38 = 8,94 MYR / W

Okay, I’ve been going over the numbers, and your numbers are looking better and better, but . . .

Should it be the case that you are correct, the ASIC issue would be mute since effective reward adjustment would  be already happening on an individual miner, per MH/s, basis.

Looking at things from the total number of coins mined and their distribution to individual miners on a 1 MH/s basis, we move in your direction, but are unable to arrive at a similar conclusion with respect to Scrypt (on the other hand, the numbers suggest that SHA-256 should be effectively neutralized).

I’m going to use the numbers taken from the following snapshot.



Let’s divide the 120,000 coins mined each hour by the 5 algos doing the mining.

That leaves us with 24,000 coins, per hour, for each algo.

If we then divide those 24,000 coins by the respective algo hashrates, we come up with the following results:

Scrypt = 14.916096 coins per hour per MH/s   
SHA-256 = .0011722 coins per hour per MH/s
Groestl = 2.2573363 coins per hour per MH/s
Skein = .3992414 coins per hour per MH/s
Qubit = 8.4299262 coins per hour per MH/s

That’s simply dividing the reward by the collective hashrates. The per hour, per MH/s distribution is what it is.

Same machine DAILY results would be roughly the following:

Scrypt = 357.9863 coins @ 1 MH/s   
SHA-256 = 28.1328 coins @ 1 GH/s   
Groestl = 920.9932 coins @ 17 MH/s   
Skein = 1197.7242 coins @ 120 MH/s   
Qubit = 1143.0979 coins @ 5.65 MH/s   

That’s how the global numbers are divvyed up (give or take a few KH/s).

Why would the SHA-256 settle for so little? Do they really have much choice? Anywhere else to go? . . . instead of turning their ASICs into very expensive paperweights . . .

By these numbers, Scrypt ASIC is still hauling them in (on a relative basis) and have a long way to go before falling below breakeven (when using the 7 watt gridseed as electricity cost basis, even more so).

So, is this issue a non-issue with respect to SHA-256? Or still an issue since they are so desperate as to keep mining when it’s a losing proposition and throwing good money after bad?

These numbers suggest to me that the Scrypt ASIC continues to be an issue - until their numbers grow sufficiently so as to reduce their per MH/s rewards below profitability. Just where that equilibrium lay is still an unknown, but we can be quite sure it’s at some lower price rather than a higher price . . . as long as ASIC is part of the picture (unless their numbers and crowd herding gets as crazy as the SHA-256 crowd).

BTW, what are the components of your SKEIN GPU rig?

[HR]

I would like to make this clear here for anyone interested. ASIC miners have the least dump risk of all. Right now the biggest dumping is being done by two entities:
1. multipools because that's what they do.
2. gpu miners because of the high costs of running a gpu mining operation.

Asic miners have the least power consumption and best $/mh ratio so thei have the smallest incentive to mine and dump at these prices.


This is just my reasoning if you feel I'm wrong please comment.


PS: I'm a gpu miner too so there's no need for me to defend asics but I just think that the current schema is the best possible solution to include everyone.

I would take issue with your assumption that ASIC miners have the smallest incentive to mine and dump at these prices. In fact, they are the only ones who can do so at a profit at these prices. I would suggest that the only long term holders among miners at this time would be the GPU miners, or how else could we justify their mining at a loss (short term loss in their minds since they are thinking long term). It would just make no rational economic sense at all to be mining and immediately selling at a loss. That's tantamount to giving your money away to strangers. The GPU miner who is looking to support GPU mining operations currently does so at a guaranteed loss and would be better advised to shut down if not holding for the long term.

My assumptions are based on classical economic theory: if you can produce something at a lower cost, you can also profitably sell it at a lower cost, meaning the price of the product adjusts lower accordingly.

And a 20:1 differential is nothing to shake a stick at.  

(An adjusted block reward would also solve the multipool issue as well.)

As someone who mines both gpu and asic, I must say that my asics are currently making a KILLING with this coin in comparison to my gpu's.  From an investment standpoint, they've cost me about the same (~$2500 usd for asics, ~$2500 worth of gpus), but my asics clear ~25k myr a day while my gpus get around 7000 myr (roughed in numbers, just illustrating my point).

I agree with foodies' notion that we shouldn't really shut the door on any type of mining gear.  
I also think that we shouldn't change myriads block reward system (my prior post was talking about offset block rewards for MERGED coins, big distinction there).
But what about adjusting the difficulties?

edited numers

Difficulties seem to be joined at the hip. It's roughly a .0349:1 ratio per MH/s. Still think an adjusted reward for each algo is the easiest way to go . . .

Thanks for sharing your personal mining numbers. It's good to have corroborative data. Hopefully others will also post theirs.  

[novag]

It's not only in the ASIC, the fact that the developers have stopped listening to the community of people, and when there is no connection to the trust coin falls and falls, as a result, developers are left alone with a coin. Coin should always evolve and it will not matter right or wrong! And our goal as a community to reach out to developers, because they do not let the coin for himself and for us!

[Phorna]

BTW, what are the components of your SKEIN GPU rig?

The rig I was referring to is:

Intel Pentium G3220
Asus H81M-PLUS
Patriot Blue HS 2x2GB kit
4 x Gigabyte Radeon R9 270 OC (GV-R927OC-2GD)
4 x 16 <-> 1riser
Platinum 800W PSU

This mini rig was doing script at 1.85 MH at ca. 680W. For skein power usage was 580W (so I was off by 100W quoting from memory).

Anyway the conclusion is following: Profitability of mining tends to electricity costs regardless of used device. By 5 algos, each with separate difficulty - situation is the same. There may be some fluctuations but amount of MYR per 1 kWh for all algos should be similar in the long run. So this coin makes us all equal, regardless if you have powerful ASIC or GPU rig and I like this concept very much. ASICs work for the community but are not dominating over GPU miners like by script coins. They compete in their own category dirven by their own difficulty like categories in boxing.

[menu74]

It's not only in the ASIC, the fact that the developers have stopped listening to the community of people, and when there is no connection to the trust coin falls and falls, as a result, developers are left alone with a coin. Coin should always evolve and it will not matter right or wrong! And our goal as a community to reach out to developers, because they do not let the coin for himself and for us!

The developers team answered  your questions and rejected your proposal in previous posts. No accept your ideas do not mean stopping listening to  community members. MYR has no serious problems,  if we community members still spread any stupid or scam ideas, the price of MYR would fall down into hell, maybe you guys are trying to lower the price and absorb it more.  

[menu74]

Why would anyone want to remove the "ASIC-algos"? It's completely stupid. Let's say you go ahead with that - what will you do once the algos in place get ASICs created for them? Will MYR be forked every time ASICs are created for an algo? MYR isn't being dumped because of that - it's because there is no perception of solidity in the project as it stands right now. Lots of brilliant ideas, a true anti-51% attack system in place which will be utilised by Bitcoin sooner or later - but there is no proper driving force in place. Using cuss words on twitter or bla-blahing any criticism which is leveled at the Development team is a huge turn-off for investors. Start pulling your own weight - and this applies to all the whiners on here as well. There is a dire need for developers to step up the pace on the current projects - why not try searching for any potentially interested guys instead of complaining on here? Why not spread the word positively instead of harming your own investment and spreading FUD? I understand that some of you might be 17-year olds with a bit of money made off Doge or some other crapcoin - but it's high time you realised what the world of investment is like and what it entails. Never, ever harm your own investment.

+1

reddit and twitter should be clean/professional.

totally agree with apesconcert's ideas, clear and reasonable.

[killermonkeys]

Do you really think so? Where are you getting your data? Blocks are being mined at an equal rate (more or less) regardless of the algo being used.  http://myriad.theblockexplorer.com  And the block reward is the same.

Yes I have used this page. On that page you have an information how many coins you are getting per unified MH unit.

340 MYR / MH day by Sricpt
2805 MYR / MH day by Skein

Of course this data fluctuates with every block a bit.

My SKEIN GPU rig has power usage 300 W / 1 MH = 2805/300 = 9,35 MYR / W
My SCRIPT ZEUS Blizzard miner has 38 W / 1 MH = 340/38 = 8,94 MYR / W

Okay, I’ve been going over the numbers, and your numbers are looking better and better, but . . .

Should it be the case that you are correct, the ASIC issue would be mute since effective reward adjustment would  be already happening on an individual miner, per MH/s, basis.

Looking at things from the total number of coins mined and their distribution to individual miners on a 1 MH/s basis, we move in your direction, but are unable to arrive at a similar conclusion with respect to Scrypt (on the other hand, the numbers suggest that SHA-256 should be effectively neutralized).

I’m going to use the numbers taken from the following snapshot.

http://i61.tinypic.com/24l8v1w.jpg

Let’s divide the 120,000 coins mined each hour by the 5 algos doing the mining.

That leaves us with 24,000 coins, per hour, for each algo.

If we then divide those 24,000 coins by the respective algo hashrates, we come up with the following results:

Scrypt = 14.916096 coins per hour per MH/s   
SHA-256 = .0011722 coins per hour per MH/s
Groestl = 2.2573363 coins per hour per MH/s
Skein = .3992414 coins per hour per MH/s
Qubit = 8.4299262 coins per hour per MH/s

That’s simply dividing the reward by the collective hashrates. The per hour, per MH/s distribution is what it is.

Same machine DAILY results would be roughly the following:

Scrypt = 357.9863 coins @ 1 MH/s   
SHA-256 = 28.1328 coins @ 1 GH/s   
Groestl = 920.9932 coins @ 17 MH/s   
Skein = 1197.7242 coins @ 120 MH/s   
Qubit = 1143.0979 coins @ 5.65 MH/s   

That’s how the global numbers are divvyed up (give or take a few KH/s).

Why would the SHA-256 settle for so little? Do they really have much choice? Anywhere else to go? . . . instead of turning their ASICs into very expensive paperweights . . .

By these numbers, Scrypt ASIC is still hauling them in (on a relative basis) and have a long way to go before falling below breakeven (when using the 7 watt gridseed as electricity cost basis, even more so).

So, is this issue a non-issue with respect to SHA-256? Or still an issue since they are so desperate as to keep mining when it’s a losing proposition and throwing good money after bad?

These numbers suggest to me that the Scrypt ASIC continues to be an issue - until their numbers grow sufficiently so as to reduce their per MH/s rewards below profitability. Just where that equilibrium lay is still an unknown, but we can be quite sure it’s at some lower price rather than a higher price . . . as long as ASIC is part of the picture (unless their numbers and crowd herding gets as crazy as the SHA-256 crowd).

BTW, what are the components of your SKEIN GPU rig?

Awesome.

I think one of the missing pieces of the puzzle is the current market prices of the gear to get these hashrates.  A quick look online at one of the local (Toronto) vendors in my city gives me these rough estimates (please correct my math if I'm wrong!!) :

bitcoinware.net


prices in cad:

1mh worth of scrypt (gridseeds): $180 --> .018 per hash
2gh worth of sha-256 (antminer u2): $20 (or ~$10 per gh) --> 0.0002 per hash
17mh worth of groestl (750ti x 3): $525 --> 0.003 per hash
120mh worth of skein (270x): $240 --> 0.002 per hash
5.65mh worth of qubit (280x): $390 --> 0.007 per hash


Ok lets look at the other end of the spectrum:

~400mh of scrypt (knc titan): $6420 --> .0016
~1th of sha-256 (any 1th miner): ~$2000  --> 0.0002
~240GH skein (~10 x 280x + other parts, not assuming wholesale): ~$5000 --> 0.002

So, unless I've entirely messed this up, the most profitable mining solution is sha-256 at this current point in time.  Second to this is a large scale scrypt miner.  Problem is the spread between small and large scrypt rigs.

From what I can see, it's a bit of a catch 22.  If we try to adjust the difficulties to balance the numbers (say a higher difficulty ratio for scrypt, sha-256)  it might actually screw over the little guys while curbing the big guns (with scrypt only).  Either way there is a definite skew in scrypt asics, to the point where it is a problem that is being overly exacerbated by multipool contribution.

Any thoughts on how to address it? some kind of dynamic localized difficulty retarget?  Drop scrypt because of it's inherent unfairness and support it through polymyr instead?  Some other awesome idea?

We probably shouldn't mess with the sha-256 difficulty either though, if the goal is to one day have the myriad platform pulled into the bitcoin repository.
   

[infofront]

Why would anyone want to remove the "ASIC-algos"? It's completely stupid. Let's say you go ahead with that - what will you do once the algos in place get ASICs created for them? Will MYR be forked every time ASICs are created for an algo? MYR isn't being dumped because of that - it's because there is no perception of solidity in the project as it stands right now. Lots of brilliant ideas, a true anti-51% attack system in place which will be utilised by Bitcoin sooner or later - but there is no proper driving force in place. Using cuss words on twitter or bla-blahing any criticism which is leveled at the Development team is a huge turn-off for investors. Start pulling your own weight - and this applies to all the whiners on here as well. There is a dire need for developers to step up the pace on the current projects - why not try searching for any potentially interested guys instead of complaining on here? Why not spread the word positively instead of harming your own investment and spreading FUD? I understand that some of you might be 17-year olds with a bit of money made off Doge or some other crapcoin - but it's high time you realised what the world of investment is like and what it entails. Never, ever harm your own investment.

I also +1 this post.

It's not the ASICs. It's not the mulitpools (when the hell have multipools ever been a problem for this coin?). It's a lack of confidence in the coin, which includes the community, the dev team, the whole ecosystem. And yeah, part of that is due to the developers. I appreciate all the work foodies has done for this coin, and I think he's an awesome dev overall, but the profanity-filled rants are a huge turn off for investors. It really makes it look like this project is run by an idiot kid.

[infofront]

Furthermore, I propose we move forward the first block halving to 7/31/14. Keep the total # of coins at 2 billions.
You obviously can't cut the block reward every time the price dips, but I believe something drastic should be done while everyone is waiting on upcoming projects/events. The community is slowly becoming more toxic, and potential investors/project creators are turning to other coins. There is a dangerous lack of enthusiasm and support for MYR at this early stage.

[neuroMode]

Furthermore, I propose we move forward the first block halving to 7/31/14. Keep the total # of coins at 2 billions.
You obviously can't cut the block reward every time the price dips, but I believe something drastic should be done while everyone is waiting on upcoming projects/events. The community is slowly becoming more toxic, and potential investors/project creators are turning to other coins. There is a dangerous lack of enthusiasm and support for MYR at this early stage.

Have you been on our subreddit at all? That place is way more lively than our bitcointalk thread here. There's definitely still a ton of enthusiasm.

I don't agree we need to do something drastic while everyone is waiting. Maybe it's just the word choice - "drastic". I think we definitely need to rally and come up with a solid plan of action going forward while the devs work. PR is definitely #1 on the list, but we need to assess the state of all our developments before we throw Myriad into the PR machine--we need to all be on the same page so there isn't any disinformation being spread to the public through born from miscommunication or lethargy.

[neuroMode]

This was a recent blog written by Mike Hearn. I cannot help but think about Myriadcoin the whole time reading this and how the decentralization problem already has been answered via Myriad. However, Bitcoin has the "first-mover's" advantage, so Myriad will climb an uphill battle. But we have one thing Bitcoin never will have--5 algorithms with which to mine the blockchain. There is no way Bitcoin hardforks--whether it is a consensus problem or a technical problem.

Mining Decentralization - The Low-Hanging Fruit

In recent days the Bitcoin community has engaged in vigorous debate about how to solve the problem of a small number of players, and GHash.IO specifically, dominating the network’s hash rate. In light of GHash.IO’s decision to do nothing, many suggestions have been made for possible solutions. This blog post will review some and outline what can be done to help rectify the situation.

Firstly let’s put aside solutions that don’t address the problem, or that would make things worse. Many alt coins identify “ASIC resistance” as a design goal. It’s tempting to think about rewinding the clock by changing the proof of work algorithm. But this is fraught with difficulty. Firstly, there’s really no such thing as an ASIC-resistant algorithm. Almost by definition, the only way to force someone to use a CPU instead of an ASIC is to use “run an arbitrary computer program” as your proof of work, otherwise, you are doing a specific task and an application specific integrated circuit can always have the advantage. But nobody knows how to design a Bitcoin-like system which requires execution of arbitrarily complex and ever changing programs as the proof of work. Secondly, before the ASIC era Bitcoin had to tackle a different kind of problematic miner: botnets. Several botnets stole electricity to mine coins, which had nasty side effects. For instance, at least one of them mined only empty blocks, which is worse than the situation we have now. Losing ASICs would bring them back. Thirdly, invalidating the huge investment in ASIC farms already made would have profound consequences for the future of the project and people’s willingness to mine in future.

So if changing the proof of work algorithm is not a solution, what is?

We don’t know for sure, but we can identify useful tasks that help us move towards a more decentralised future. None of them are silver bullets, but most of them are quite easy: they’re what developers call low hanging fruit. By working together and picking enough of this fruit, we might be able to tip the balance in favour of decentralised mining. To save keystrokes, from now on I’m going to call this freemining.

Freeminers, unite!

Let’s define what this word means. It does not mean no pooling. The problem we face with mining is not pooling to reduce payout variance, it’s that in the process of doing so miners give up their ability to select their own block contents. The purpose of mining is to create blocks, thus answering the question of what happened first. When miners give up control of the blocks they mine en-masse, double spending becomes possible, as does going back into the past and maliciously rewriting the block chain. It’s effectively a form of selling your vote.

There are two ways to do pooled freemining. The problem is, both routes are riddled with potholes and speed bumps that cause many miners to not bother.

1. You can use p2pool, a peer to peer decentralised mining pool
2. You could (in future) use the getblocktemplate protocol with a regular pool that supports it

Freeminers mine in such a way that they both reduce their payout variance but also create their own blocks, a process that always requires running a fully validating p2p node like Bitcoin Core. To repeat: freemining inherently requires running a full node, and today that means Core. If you aren’t running one, you aren’t decentralising the mining process. This requirement puts people off and later I’ll discuss ways we can make it less painful.

p2pool’in

P2Pool is the best solution currently available. But it faces numerous small yet resolvable problems. Smart volunteers could tackle any of them:

1. Problem: installation is too difficult

Installation on Windows is possible via a one click installer, but on Linux and MacOS X no such easy setup exists. P2Pool is a Python program and some miners get stuck in dependency hell trying to simply install it.

Solution: One click installers need to be developed for both Linux and OS X. Distro-specific packages on Linux are not always sufficient, as they can fall behind upstream or be unavailable for the users specific distribution. Ideally p2pool would have a selection of packages well maintained by the project, and also a generic Linux installer or tarball usable by everyone else.

2. Problem: the p2pool website is hard to find

Confusingly the P2Pool website is at p2pool.in as p2pool.org was already taken. The .org page dominates the real p2pool.in website on Google. Worse, the website at p2pool.org is merely a proxy to P2pool that encourages people to mine on it without actually running a full node, and charges a 2% fee in the process. Remember, if you aren’t running Core, you are not freemining. This website confuses people into mining in such a way that they think they’re helping decentralise the network, but are not.

Solution: The bitcoin.org website needs a slick, simple miners introduction that links to the right website, explains how to use p2pool properly, and shows miners how to get started. Major bitcoin related websites could link to p2pool.in to try and boost the PageRank of the real site. The owner of p2pool.org could be contacted or bought out to try and fix the flow of miners who are getting misdirected.

3. Problem: P2Pool feels clunky compared to centralised pools

One reason for the popularity of GHash.IO is it presents nice, professionally designed stats pages and monitoring. P2Pool has nice frontends available too, but they aren’t bundled so don’t give users the same slick experience.

Solution: the best of the existing p2pool frontends needs to be located and bundled out of the box.

4. Problem: P2Pool has an increasingly high share difficulty

P2Pool is a single pool and because of how it works, the more people who mine on it the harder it becomes to find a share. This can be discouraging.

Solution: P2Pool could split itself into multiple independent p2pools, amoeba style, whenever it gets too large for small miners to benefit.

P2Pool has other problems too: it can use a lot of memory and bandwidth, and it needs more miners committing to it for the long haul to reduce the variance. But the above issues are the lowest hanging fruit for improving it.

getblocktemplate

The getblocktemplate protocol allows miners to mine at a client-server pool but without losing control over the blocks that they are mining. It represents a useful middle ground between the pure decentralisation of p2pool and the centralisation of traditional pools. A GBT pool calculates the coinbase transaction that contains payouts in a centralised manner, and then lets the miner select the rest of the block. Quoting Gregory Maxwell,

“Effectively p2pool is getblocktemplate plus a distributed system to compute acceptable coinbase transactions”

But there’s a problem: although the protocol theoretically allows for miner-side block creation, the actual software implementations of it don’t do so yet. Nobody has implemented support for freemining with GBT, so pools that support GBT today still do the block creation themselves. This in turn means that with only minor real advantages over its main competitor (Stratum, which doesn’t allow freemining), some pools and mining tools don’t support it.

We need volunteers to step up and help make getblocktemplate a competitive solution:

1. The software that implements the getblocktemplate protocol needs to be upgraded and finished off, so miners can connect their own copy of Bitcoin Core to the tools and select their own blocks. Fortunately libblkmaker (the reference GBT implementation) is designed with support for this in mind, so it should not require any major refactorings or other surgery to enable. If you’re serious about this, please contact Luke Dashjr (“Luke-Jr” on IRC).

2. Mining tools and ASIC systems that don’t natively support GBT can be bridged using a local Stratum-to-GBT proxy, but this is one more system that has to be set up. Ideally this wouldn’t be necessary, or if it must be so, then the proxy should be bundled as well so there’s no setup cost.

3. Tutorials and websites need to be created to teach miners how to configure this: ideally, with everything bundled “out of the box” so setting it up can be a one click process after selecting a GBT supporting pool.

4. More pools need to be lobbied to support GBT once it’s a suitable solution for freemining. This would reduce the pool’s role to that of tracking share submissions and calculating payouts, but they would have no real power over what blocks are mined.

Making Bitcoin Core less hardcore

What all the above solutions have in common is that you must run a full node implementation, which should be Bitcoin Core today. You can’t claim to be a decentralised miner if you don’t, because otherwise you aren’t validating blocks and thus have to follow the instructions of someone else who has.

Thousands of volunteers around the world run Core for free: node operators, we love you! But we also hear your pain. Core combines many tasks into one: it processes and validates transactions, but it also serves the block chain to newcomers who don’t have it yet. This latter process can consume large amounts of upstream bandwidth, which is often a limited resource.

In the short term, miners can stop their bandwidth being used for block chain uploads by blocking inbound connections on port 8333 or using the -nolisten flag. The next version will have a checkbox in the GUI for it. But that means the node won’t contribute to the p2p network at all. A long-term wish of the Core development team has been to teach the software how to use resources more effectively, so making Bitcoin less costly to run. As an example nodes could advertise that they can serve only parts of the block chain instead of all of it. This would allow people to give Core as much bandwidth and disk space as they want to.

This is an advanced project that requires work on the guts of Bitcoin Core and the peer-to-peer protocol. The existing developers all have their hands full with other tasks, so we’re looking for someone to step up and prototype. It means extending the IP address broadcasting mechanism so nodes can advertise how much of the chain they’re willing to serve, teaching the software how to find them, and then allowing users to tune things so they can reduce their bandwidth usage to levels they can tolerate. This should make it much less painful to run a full node at home, or in other places where upstream bandwidth is constrained.

For developers who want to get their feet wet, there’s an easier piece of low hanging fruit. Some jerk thought it would be funny to put virus signatures into the block chain, and now on Windows a few anti-virus scanners are corrupting Bitcoin Core’s database files. A simple fix is to store data obfuscated with a per-machine key so it’s no longer possible to put particular byte sequences into the database on disk. This would help freeminers who use Windows.

Building a community

There’s one last way pools like GHash.io build loyalty amongst their userbase: humans are tribal and we love to join a team. GHash/CEX run wallpaper contests and other things to help build their brand. We need a community of people who feel passionately about freemining, and help other people to get started. T-Shirt designers, this means you! But also we need forums and support networks to help people navigate the issues: no matter how easy we make the path, having someone walk it with you will always be better

[novag]

This was a recent blog written by Mike Hearn. I cannot help but think about Myriadcoin the whole time reading this and how the decentralization problem already has been answered via Myriad. However, Bitcoin has the "first-mover's" advantage, so Myriad will climb an uphill battle. But we have one thing Bitcoin never will have--5 algorithms with which to mine the blockchain. There is no way Bitcoin hardforks--whether it is a consensus problem or a technical problem.

Mining Decentralization - The Low-Hanging Fruit

In recent days the Bitcoin community has engaged in vigorous debate about how to solve the problem of a small number of players, and GHash.IO specifically, dominating the network’s hash rate. In light of GHash.IO’s decision to do nothing, many suggestions have been made for possible solutions. This blog post will review some and outline what can be done to help rectify the situation.

Firstly let’s put aside solutions that don’t address the problem, or that would make things worse. Many alt coins identify “ASIC resistance” as a design goal. It’s tempting to think about rewinding the clock by changing the proof of work algorithm. But this is fraught with difficulty. Firstly, there’s really no such thing as an ASIC-resistant algorithm. Almost by definition, the only way to force someone to use a CPU instead of an ASIC is to use “run an arbitrary computer program” as your proof of work, otherwise, you are doing a specific task and an application specific integrated circuit can always have the advantage. But nobody knows how to design a Bitcoin-like system which requires execution of arbitrarily complex and ever changing programs as the proof of work. Secondly, before the ASIC era Bitcoin had to tackle a different kind of problematic miner: botnets. Several botnets stole electricity to mine coins, which had nasty side effects. For instance, at least one of them mined only empty blocks, which is worse than the situation we have now. Losing ASICs would bring them back. Thirdly, invalidating the huge investment in ASIC farms already made would have profound consequences for the future of the project and people’s willingness to mine in future.

So if changing the proof of work algorithm is not a solution, what is?

We don’t know for sure, but we can identify useful tasks that help us move towards a more decentralised future. None of them are silver bullets, but most of them are quite easy: they’re what developers call low hanging fruit. By working together and picking enough of this fruit, we might be able to tip the balance in favour of decentralised mining. To save keystrokes, from now on I’m going to call this freemining.

Freeminers, unite!

Let’s define what this word means. It does not mean no pooling. The problem we face with mining is not pooling to reduce payout variance, it’s that in the process of doing so miners give up their ability to select their own block contents. The purpose of mining is to create blocks, thus answering the question of what happened first. When miners give up control of the blocks they mine en-masse, double spending becomes possible, as does going back into the past and maliciously rewriting the block chain. It’s effectively a form of selling your vote.

There are two ways to do pooled freemining. The problem is, both routes are riddled with potholes and speed bumps that cause many miners to not bother.

1. You can use p2pool, a peer to peer decentralised mining pool
2. You could (in future) use the getblocktemplate protocol with a regular pool that supports it

Freeminers mine in such a way that they both reduce their payout variance but also create their own blocks, a process that always requires running a fully validating p2p node like Bitcoin Core. To repeat: freemining inherently requires running a full node, and today that means Core. If you aren’t running one, you aren’t decentralising the mining process. This requirement puts people off and later I’ll discuss ways we can make it less painful.

p2pool’in

P2Pool is the best solution currently available. But it faces numerous small yet resolvable problems. Smart volunteers could tackle any of them:

1. Problem: installation is too difficult

Installation on Windows is possible via a one click installer, but on Linux and MacOS X no such easy setup exists. P2Pool is a Python program and some miners get stuck in dependency hell trying to simply install it.

Solution: One click installers need to be developed for both Linux and OS X. Distro-specific packages on Linux are not always sufficient, as they can fall behind upstream or be unavailable for the users specific distribution. Ideally p2pool would have a selection of packages well maintained by the project, and also a generic Linux installer or tarball usable by everyone else.

2. Problem: the p2pool website is hard to find

Confusingly the P2Pool website is at p2pool.in as p2pool.org was already taken. The .org page dominates the real p2pool.in website on Google. Worse, the website at p2pool.org is merely a proxy to P2pool that encourages people to mine on it without actually running a full node, and charges a 2% fee in the process. Remember, if you aren’t running Core, you are not freemining. This website confuses people into mining in such a way that they think they’re helping decentralise the network, but are not.

Solution: The bitcoin.org website needs a slick, simple miners introduction that links to the right website, explains how to use p2pool properly, and shows miners how to get started. Major bitcoin related websites could link to p2pool.in to try and boost the PageRank of the real site. The owner of p2pool.org could be contacted or bought out to try and fix the flow of miners who are getting misdirected.

3. Problem: P2Pool feels clunky compared to centralised pools

One reason for the popularity of GHash.IO is it presents nice, professionally designed stats pages and monitoring. P2Pool has nice frontends available too, but they aren’t bundled so don’t give users the same slick experience.

Solution: the best of the existing p2pool frontends needs to be located and bundled out of the box.

4. Problem: P2Pool has an increasingly high share difficulty

P2Pool is a single pool and because of how it works, the more people who mine on it the harder it becomes to find a share. This can be discouraging.

Solution: P2Pool could split itself into multiple independent p2pools, amoeba style, whenever it gets too large for small miners to benefit.

P2Pool has other problems too: it can use a lot of memory and bandwidth, and it needs more miners committing to it for the long haul to reduce the variance. But the above issues are the lowest hanging fruit for improving it.

getblocktemplate

The getblocktemplate protocol allows miners to mine at a client-server pool but without losing control over the blocks that they are mining. It represents a useful middle ground between the pure decentralisation of p2pool and the centralisation of traditional pools. A GBT pool calculates the coinbase transaction that contains payouts in a centralised manner, and then lets the miner select the rest of the block. Quoting Gregory Maxwell,

“Effectively p2pool is getblocktemplate plus a distributed system to compute acceptable coinbase transactions”

But there’s a problem: although the protocol theoretically allows for miner-side block creation, the actual software implementations of it don’t do so yet. Nobody has implemented support for freemining with GBT, so pools that support GBT today still do the block creation themselves. This in turn means that with only minor real advantages over its main competitor (Stratum, which doesn’t allow freemining), some pools and mining tools don’t support it.

We need volunteers to step up and help make getblocktemplate a competitive solution:

1. The software that implements the getblocktemplate protocol needs to be upgraded and finished off, so miners can connect their own copy of Bitcoin Core to the tools and select their own blocks. Fortunately libblkmaker (the reference GBT implementation) is designed with support for this in mind, so it should not require any major refactorings or other surgery to enable. If you’re serious about this, please contact Luke Dashjr (“Luke-Jr” on IRC).

2. Mining tools and ASIC systems that don’t natively support GBT can be bridged using a local Stratum-to-GBT proxy, but this is one more system that has to be set up. Ideally this wouldn’t be necessary, or if it must be so, then the proxy should be bundled as well so there’s no setup cost.

3. Tutorials and websites need to be created to teach miners how to configure this: ideally, with everything bundled “out of the box” so setting it up can be a one click process after selecting a GBT supporting pool.

4. More pools need to be lobbied to support GBT once it’s a suitable solution for freemining. This would reduce the pool’s role to that of tracking share submissions and calculating payouts, but they would have no real power over what blocks are mined.

Making Bitcoin Core less hardcore

What all the above solutions have in common is that you must run a full node implementation, which should be Bitcoin Core today. You can’t claim to be a decentralised miner if you don’t, because otherwise you aren’t validating blocks and thus have to follow the instructions of someone else who has.

Thousands of volunteers around the world run Core for free: node operators, we love you! But we also hear your pain. Core combines many tasks into one: it processes and validates transactions, but it also serves the block chain to newcomers who don’t have it yet. This latter process can consume large amounts of upstream bandwidth, which is often a limited resource.

In the short term, miners can stop their bandwidth being used for block chain uploads by blocking inbound connections on port 8333 or using the -nolisten flag. The next version will have a checkbox in the GUI for it. But that means the node won’t contribute to the p2p network at all. A long-term wish of the Core development team has been to teach the software how to use resources more effectively, so making Bitcoin less costly to run. As an example nodes could advertise that they can serve only parts of the block chain instead of all of it. This would allow people to give Core as much bandwidth and disk space as they want to.

This is an advanced project that requires work on the guts of Bitcoin Core and the peer-to-peer protocol. The existing developers all have their hands full with other tasks, so we’re looking for someone to step up and prototype. It means extending the IP address broadcasting mechanism so nodes can advertise how much of the chain they’re willing to serve, teaching the software how to find them, and then allowing users to tune things so they can reduce their bandwidth usage to levels they can tolerate. This should make it much less painful to run a full node at home, or in other places where upstream bandwidth is constrained.

For developers who want to get their feet wet, there’s an easier piece of low hanging fruit. Some jerk thought it would be funny to put virus signatures into the block chain, and now on Windows a few anti-virus scanners are corrupting Bitcoin Core’s database files. A simple fix is to store data obfuscated with a per-machine key so it’s no longer possible to put particular byte sequences into the database on disk. This would help freeminers who use Windows.

Building a community

There’s one last way pools like GHash.io build loyalty amongst their userbase: humans are tribal and we love to join a team. GHash/CEX run wallpaper contests and other things to help build their brand. We need a community of people who feel passionately about freemining, and help other people to get started. T-Shirt designers, this means you! But also we need forums and support networks to help people navigate the issues: no matter how easy we make the path, having someone walk it with you will always be better

Very, very promising!

[neuroMode]

Exhumed Race Kickstarter - One of the first 3rd person action/ adventure games to include almost exclusively Digital Currency (Myriadcoin)!

• Kickstarter direct link
• Kickstarter Reddit thread
• Kickstarter bitcointalk thread
• Pledge BTC or MYR here!

Exhumed Race

Exhumed Race is a PC/Mac/Web based game. Made from the Unity3d Engine, Exhumed Race will immerse players in a beautiful apocalyptic world were man has destroyed themselves and machines have made a new world. Filled with challenges and puzzles, players will have to be skillful and cautious in their adventures to bring human kind back to the top and discover the real causes of their destruction, so they don't repeat the same mistakes.  

How Digital Currency plays a part:

DigitalCurrency, or DC, will be taken as payment for the game. As well DC can also be used to buy skills, powerful abilities, and helpful additives to propel players past any difficult areas within the game. Players will also be able to earn DC from playing the game. Weekly speed runs and points runs will prove once and for all who is the best, and rewarded accordingly.

Pay2Win?

Absolutely not! The extra in game items that can be purchased will vary, however their will be two sets of items: Items that alter the gaming experience level and items that alter the cosmetic experience.

Example:

• In solo(single player mode) you might be able to purchase additional ammo, more health, extra bullet protection.
• In Multi-player you might be able to purchase a panda suit, squirt gun that shoots real bullets, etc.

The above is an example and what you can purchase is only used as a reference to make the point. However in Multi-player every player will be given the exact same suits, items, weapons etc. but what those suits, items, weapons etc look like is up to you!

T-Shirt Preview



Why Myriad?

Why have we partnered with Myriad as our leading in game currency? Take a read for yourself here.

Questions/Comments

Any comments, concerns and questions? Please feel free to email us at FrostAmationStudios@gmail.com . To date we have responded in less than 24 hours on ALL emails!

[tigerwood0432]

Exhumed Race Kickstarter - One of the first 3rd person action/ adventure games to include almost exclusively Digital Currency (Myriadcoin)!

• Kickstarter direct link
• Kickstarter Reddit thread
• Kickstarter bitcointalk thread
• Pledge BTC or MYR here!

Exhumed Race

Exhumed Race is a PC/Mac/Web based game. Made from the Unity3d Engine, Exhumed Race will immerse players in a beautiful apocalyptic world were man has destroyed themselves and machines have made a new world. Filled with challenges and puzzles, players will have to be skillful and cautious in their adventures to bring human kind back to the top and discover the real causes of their destruction, so they don't repeat the same mistakes.  

How Digital Currency plays a part:

DigitalCurrency, or DC, will be taken as payment for the game. As well DC can also be used to buy skills, powerful abilities, and helpful additives to propel players past any difficult areas within the game. Players will also be able to earn DC from playing the game. Weekly speed runs and points runs will prove once and for all who is the best, and rewarded accordingly.

Pay2Win?

Absolutely not! The extra in game items that can be purchased will vary, however their will be two sets of items: Items that alter the gaming experience level and items that alter the cosmetic experience.

Example:

• In solo(single player mode) you might be able to purchase additional ammo, more health, extra bullet protection.
• In Multi-player you might be able to purchase a panda suit, squirt gun that shoots real bullets, etc.

The above is an example and what you can purchase is only used as a reference to make the point. However in Multi-player every player will be given the exact same suits, items, weapons etc. but what those suits, items, weapons etc look like is up to you!

T-Shirt Preview



Why Myriad?

Why have we partnered with Myriad as our leading in game currency? Take a read for yourself here.

Questions/Comments

Any comments, concerns and questions? Please feel free to email us at FrostAmationStudios@gmail.com . To date we have responded in less than 24 hours on ALL emails!

Please donate to the game = it will boost myriadcoin price to the sky and bring gaming community to buy myriad .

youtube video :




http://youtu.be/3f4jq5nXAQU

[akabane]

Nice to see some real usage of one of my favorite coin, will surely try to use my MYR when the game will come out !

[HR]

Here’s a Radical [Not So Novel] Idea (please don’t laugh)

Would you be interested hearing an idea that could take MYR ballistic and worldwide (in the truest sense of the word)? Well, sit back and read on if you answered yes.

This is an idea that could really cause MYR to go 'viral'. Can you imagine people from all over the world automatically mining MYR on startup of their PC? What could possibly get millions of people all over the world (including the underdeveloped world) doing that?

Let’s step back for some background and start out by remembering and taking into account some of my logical anti-ASIC arguments (I haven’t been too bad with my predictions in recent months either) and then move forward going one step further by looking at the opposite end of the spectrum.

Just like at one end of the spectrum we have an ever more concentrated and centralized network in combination with price under serious pressure, at the other end we also have an authentic widely distributed network with a stable and generally rising price, and if hardware specialization leads to the first, then, the opposite, namely, hardware generalization, should logically lead to the second.

Economies of scale are generally a good thing when referring to competitive markets; the only problem exists when those markets become concentrated (centralized) in a few hands, and then economies of scale can work against the common good. We need look no further than the fiat banking system to see what eventually happens.

One of the most important ideas at the heart of the crypto ethic was the idea that decentralization was key for creating a viable 'alternative' storage of wealth that could compete with the traditional fiat system.

Have we by some chance become sidetracked with our obsessions for short term profit? What with, hey, we’ve even got a website dedicated to this extreme distraction. What’s the name? Oh, yeah, here it is, Crypto Pump of course (how could it be named anything else?). http://cryptopump.com Was this what we all had in mind when starting out with cryptocurrencies?

Decentralization is all about making something as available as possible to as many people as possible. Are we really going in the right direction to accomplish that by favoring specialized and centralized economies of scale? Okay, a large market cap would be great for PR, but how long lived would it be if it’s not built on a real foundation. Selling out to short term specialization and centralization is nothing more than assured short term gain in exchange for long term pain.

So, if centralized specialization leads to ruin, then generalization, or decentralization as it were, should lead to system health and vitality – exactly what is desired for a solid and authentic vehicle for storage of wealth. And just what do I mean by “generalization”? I’m referring to making something as “generally” available as possible, and not just in words, but in real deeds as well. It’s one thing to say that even CPUs can mine, and it’s quite another altogether to say (and make real) that they can do so competitively (and we all know that the little guy can only be competitive in a “little guy world” where the rules are fair and designed to protect the little guy, and not one where major competitors are swallowing up what little guys are still left).

Have you guessed where I’m going with this?

CPU mining that is just as profitable as GPU mining, and also with ASIC?

Had you guessed?

Yes, CPU on par with ASIC!

If you do that, if you make MYR the cryptocurrency that everyone who owns a computer could competitively mine (seriously now, everyone), you’d have millions of users all over the world configuring their MYR wallets to launch on system startup!

Okay, there are some details to work out, like having a launch on boot setting in the wallet, and, of course, the automatic mine on launch 'plug and play' coding as well.

The wallet would need pre-configured mining parameters so that the new user could mine with a simple click, either solo, or better yet, with an official MYR worldwide P2P (worldwide really meaning worldwide with scores of active nodes all over the world).

The pre-configured, in wallet, miner would only mine using the CPU, or CPU equivalent that would be limited by a throttling mechanism that either matched the most powerful end-user CPU, or an average of the most common CPUs in active use (meaning that it would be possible to mine with a GPU miner, but never at a hashrate that exceeded the CPU throttling level per address, and never independent or outside of the wallet).

Rewards would look something like this:

Throttled Qubit CPU pre-configured wallet restricted mining = 4000 coins per block
Groestl = 450 coins per block
Skein = 450 coins per block
SHA-256 = 50 coins per block
Scrypt = 50 coins per block

And, with that, you'd put MYR on the world map as the first truly fair cryptocurrency in the world where everyone who owns a computer is looked at funny if their MYR wallet isn’t running 'in the background'.

How’s that for an idea for taking MYR mainstream?

You’re right. This would be even beyond mainstream!

Isn’t that what we really had in mind when getting involved in cryptos?



Now, let all those specialized, short term profitability obsessed, miners tell us why this is a bad idea (and GPU miners as well, for that matter) . . . something which should also tell us a lot.