Looks like we've got some house cleaning to do too.

ahmed_bodi
https://bitcointalk.org/index.php?action=profile;u=85405
Trust:    -6: -1 / +0(0)
Warning: Trade with extreme caution!

http://www.reddit.com/r/myriadcoin/comments/2ah9x7/both_the_main_p2pool_groestlmyriad_are_downany/


Who can be trusted in this world of pump and dump scammers? (Trust is part of the "base product", the very coin itself, even before getting to the wallet and the network. The network is basically made up of miners. Shouldn't Myriad take care of monitoring the pools, and even providing official pools? Wouldn't that be part of a serious cryptocurrency?)

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

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

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.

If you're in this coin for a quick pump and dump, you're not going to get it. We're not going to make announcements like we're working on anon, and then release a whitepaper so the price skyrockets and then plummets a few days later.

We are running this like any software or hardware company would, we develop behind the scenes and then make announcements when products/services are done and ready to be released. Let's take Apple as an example, they work on iPhones generations ahead, but only talk about them when they are ready to be demoed and released shortly thereafter.

It's unusual for crypto, we get that, but that's the approach we're taking.

First of all I'd like to appologize for teasing yesterday and not delivering. Working with 3rd parties is difficult. Be it as it is, not everything I wanted/needed to make the announcement is in place so I'm forced to half-ass it because I don't like building up tension and pre-anns.
Enough introduction. I promised a partnership, a tech release and a little bonus for the waiting:

The partnership: it's prypto ... big surprise (yayyy info leaks). The details: it's true we're going to run a promo with them involving 1000 MYR-Prypto scratch cards that will be used as gift vouchers and distributed to [undisclosed] via [undisclosed]. This kind of promotional campaign has never been done before and has global reach, yeah ... global. Although it is quite big and it will instantly be copied by other coins because ... copy/paste hype coins ... it will be a pilot campaign, a test before the real campaign that's going to be EPIC. I censored some of the details because like I said not everything is in place and I'd rather have a complete disclosure later along with a donation campaign to fund the promo ... because you know ... no premine

The feature/tech release: it's an electrum plugin, a prypto redeeming electrum plugin: https://i.imgur.com/ush9U7E.png [1] , (written by yours trully, yayyy my first pyqt code)the plugin is open source, it's already on our electrum git (has been for a few days but I was sure you guys wouldn't think to look. It's a very usefull plugin for new and old users and will come in really handy when the promo campaign commences. Being an open source plugin we'll probably see a lot of copies (electrum & qt copies since it's pyqt and it can easily be ported). As of yet I did not have any test redeem codes to test the latest changes made to the plugin (I have tested it on other prypto available coins) and to top it off our windows compiler is on vacation. Sigh ... 3rd party partnerships. )

The bonus, this is a long term feature and will be carefully implemented but I made a professional infographic to explain the gist of it. The feature is : cue drum roll ..... sms wallet prypto redeeming. Can you figure out why ? Let my award winning infograph explain:
https://i.imgur.com/bc4OXif.png

This is only a first step towards building the required infrastructure needed to bring cryptocurrency to the underbanked. There are far great plans rolling out but they require intensive thought and work and should start to bare fruit in Q3 of this year. As a teaser just think about how the reseller network would logically function: resellers buy myr to create cards, reseller sells cards to end users, end users buy the cards, users send the myr to let's say families at home (let's imagine the end user is working abroad), families at home go to a local prypto reseller and sell their myr to get cash at the current exchange rate, reseller buys myr to create cards, ... [infinite loop detected]. We're working slowly but surely working on creating an economy, not a trading economy, a real world economy.

I stop mining QCN :/ Too much bug in the Wallet, everything i send in the exchange never arrive. Before there was no problem.... What's going on ?

Edit:
Here are my transaction who never arrived:

1)                  transfer 0 1VQpANF1pcKHPRAsZpeyG4jLDd1kbPn32YMeXkr9n8jNFvf8aaJdecB3FyAvo7X1DWJDQt3nii9eUTP 5kJSfRpL5AwT72FM 1.84 c046ad7272438caf683833d2f0a6fde7b7bdb1eac8b8ef7d53456618cd1c70d1
2014-Jun-17 17:09:19.882917 Money successfully sent, transaction <c6b4282ce6a2b77d50e5551ce92ce80a6b79c7f0c710e615514b4525d4bca3b7>

2)                  transfer 0 1SEtGDSVATrNhXQdSa3Burcigx126HyMuczFQJby3NsQf5xTuzQwUuvGvnfqDHNDXkSVG7DmHeJJMb3 Tj3Vi2NXb6ecfLeR 0.54 06946aa78d0a4cffa9c7c163a2ea257af0db8b242b64474881aa90ce48374fef
2014-Jun-17 18:01:33.557647 Money successfully sent, transaction <1721ebe7931686feb5cc644d935d5b2857f317084ef92104089d20946db9e2f2>



Try to send at poloniex and bittrex....

Obviously not.

They would either go towards the developers or some sort of community pool.

In fact, we're setting up a system on MyriadcoinPool.com already where I'm not even touching the advertising revenue, its going right into a script that trades on mint pal.

I'm trying to do something good here, and do have lots of people already willing to help. I know the crypto currency community in general has a knee jerk reaction to this, but I'm not directly benefiting in any way.

When can i start merge mining this with my antminer s1. Please let me know

Thanks