How To Find Bitcoin Mining Cost? - Bitcoinik

Slush won 14 of the last 144 blocks yet none of them were BU blocks. BU should be at least around 30% of their mining hash power. What is going on? Is this just variance?

I have been looking at blocks recently due to Antpool starting to mine unlimited and noticed that Slushpool was getting quite a few blocks there didn't seem to be many that were BU blocks. Then when I looked into it, none of the 14 blocks the published in the last 144 blocks were BU. This could just be variance but it seems a little off to me.
Currently the hashrate stats on Slushpool are as follows:
Bitcoin Core - 29.12% Pool Decides - 28.08% Bitcoin Unlimited - 21.59% Not Voted - 21.27%
Not voted apparently gets shared proportionally between Core and BU.
( 21.7 / (21.59+29.12) ) * 21.59 = 9.23% ( 21.7 / (21.59+29.12) ) * 29.12 = 12.46%
Therefore Core should have 29.12% + 12.46% = 41.58% and BU should have 21.59% + 9.23% = 30.82% and Pool Decides is 28.08%
So assuming Slush is giving 100% of the "Pool Decides" vote to Core, BU should still be getting almost a third of the hashrate, yet it seems it is getting little to none. Yes, I know it could be variance, but what is the likelihood of this from the numbers? Also I'm not sure how to use a dataset of more than the last 144 blocks without going and looking into the coinbase of each block.
Any ideas?
submitted by singularity87 to btc [link] [comments]

r/Bitcoin recap - April 2019

Hi Bitcoiners!
I’m back with the 28th monthly Bitcoin news recap.
For those unfamiliar, each day I pick out the most popularelevant/interesting stories in Bitcoin and save them. At the end of the month I release them in one batch, to give you a quick (but not necessarily the best) overview of what happened in bitcoin over the past month.
You can see recaps of the previous months on Bitcoinsnippets.com
A recap of Bitcoin in April 2019
Adoption
Development
Security
Mining
Business
Education
Archeology (Financial Incumbents)
Price & Trading
Fun & Other
submitted by SamWouters to Bitcoin [link] [comments]

Asicpower AP9-SHA256 Review


Asicpower AP9-SHA256 Review

Bitmain is regarded as one of the most influential companies in the ASIC mining industry. It is estimated that they have manufactured approximately 53% of all mining equipment.Without including their mining profits, that’s around $140 million dollars in sales. These figures are staggering, but Bitmain’s monopoly of the Bitcoin ASIC market may come to an end, following the release of PowerAsic’s asicpower AP9-SHA256.

About the asicpower AP9-SHA256

Designed with brand new technology and boasting 94 TH/s per miner, the AP(-SHA256 is the most powerful and efficient Bitcoin miner to date.PowerAsic claims they spent $12 million dollars on research, development, and prototypes.PowerAsic also noted that their miners take advantage of ASICBOOST, an exploit of Bitcoin’s algorithm which improves mining efficiency by 20%.An unusual approach separate Powerasic’s miner to the other manufactures is the implementation of copper heat-sink claimed to have a superior thermal conductivity 69% better than aluminium. Don’t take their words for it but confirm the facts are correct on widely well known and published science documents as this one.The first batch of miners were announced and made available for order in August of 2019, with start scheduled for shipment in September, 2019.
Powerasic claims that the machines are around 40 percent more productive than the most proficient ASIC on the market, Bitmain’s Antminer S17.According to PowerAsic, they started a mining project with the aim to bring much needed competition to the market…We want to ‘make SHA256 great again.Sitting at the hefty price of $2,795.00, the powerasic AP9-SHA256 is far from affordable for the average person. Fortunately, due to the newly born rivalry between Bitmain and Powerasic, the price will probably lower with time and competition.The power supply for this unit is included and integrated in the top-box also including the controler card as a one unit. You will also get standard power cable, network cable, manual and software in the packet. In comparison to the price of the Antminer S17 , the Powerasic AP9-Sha256 is a better value.

Power Supply

The integrated PSU 3300W has a inputVoltage 220V 50Hz 30A. There are 2 fan 40mm., 1 fan 60mm to keep it cool and the power cable 3 legs following CEE 7 standard.Professional mining hardware runs optimally at 220-240V, hence why mining farms step down their own electricity supply to 220-240V. Note that 220V current is only found outside of the US – American outlets are 110V by default. Unless you want to hire an electrician, this could cause some people trouble adapt to the eficient and recomended 220V power needed, still 110V will get the job done, but they are not ideal for optimum mining performance.

Power Consumption

Thanks to the powerasic AP9-HA256’s new 7nm generation of ASIC chips, the AP9-SHA256 has become the most electrically-efficient miner on the market.Consuming merely 30.J/TB, or 2860W from the wall, the 16T is 30% more electrically-efficient than the Antminer S17.

Profitability

Powerasic ’s new ASIC technology is impressive. When compared to its closest competitor, the Antminer S17, the powerasic AP9-HA256 is the clear winner. It hashes at 94 TH/s, as opposed to the S17’s 56 TH/s. Moreover, the the AP9-HA256 consumes 30J/GH, whereas the S17 consumes 39-45J/TB.The difference in power consumption is miniscule, but when it comes to large-scale mining, the the AP9-HA256’s edge will drastically increase the profitability of a mining operation. This ASIC is profitable not only for mining on a large scale, but for the individual miner as well.Take a look at the projected mining profitability of a single miner:Note that is appears profitable even with high electricity costs ($0.1 per KW/h). With $0.05 / KW/h it’s even more profitable:📷Each powerasic AP9-HA256 will generate about $6,009 per year (calculated with 1 BTC=$10,141.5). Mining profitability may vary. You can usethis free profitability calculator to determine your projected earnings.

Is powerasic AP9-HA256 a Scam?

There is been a lot of talk on Twitter that powerasic AP9-HA256 is a scam. It appears it is not, as many users are already claiming to have received their miners.Slush, the creator ot Slush Mining Pool and the TREZOR hardware wallet, claims on Twitter that he has seen units and knows people who have had their miners delivered:

Verdict: Is The Antminer S17 Outdated?

When the first batch of Bitmain’s Antminer S17 ASICs reached the eager hands of miners, they were all the rage. The S17 was renowned as the most efficient ASIC miner on the market. Many used the S17 as the industry’s golden standard.Up until the launch of the powerasic AP9-HA256, it was the golden standard.But, now?Things have changed.Not only is the powerasic AP9-HA256 more powerful than its predecessor from Bitmain, but also more efficient, and therefore, more profitable.Ever since the announcement of the new ASIC, there was widespread speculation of its legitimacy – and rightly so.The Bitcoin community has been plagued with small, phony companies manipulating images of preexisting antminers as a ploy to hype up their fake products. Nevertheless, powerasic AP9-HA256 is taking things seriously, and their first batch of miners have lived up to expectations.The fact of the matter is, Bitmain’s most powerful and efficient antminer has been dethroned by the new reigning king of ASICs: The powerasic AP9-HA256.

Conclusion

Bitmain has dominated the ASIC market since its inception in 2013.There are a few other companies producing ASICs. However, before the creation of PowerAsics AP9-SHA256., Bitmain was the only company with a proven track record that sold efficient miners directly to the public.Powerasic AP9-HA256 has the potential to bring Bitmain’s monopoly to an end. Powerasic AP9-HA256 has a bright future ahead of them. Now that Bitmain has noteworthy competition, it will be interesting to see how it affects the market. The powerasic AP9-HA256 is the best option (for now) for anyone getting started with mining. Powerasic’s innovation should force other ASIC producers to innovate and force other companies to release new miners with better efficiency. So whether you’re buying a miner now or soon, you’re likely to benefit from the development of this new miner. For more, Visit Us: https://asicpower.net/product.php
submitted by farwa786 to u/farwa786 [link] [comments]

The Origins of the Blocksize Debate

On May 4, 2015, Gavin Andresen wrote on his blog:
I was planning to submit a pull request to the 0.11 release of Bitcoin Core that will allow miners to create blocks bigger than one megabyte, starting a little less than a year from now. But this process of peer review turned up a technical issue that needs to get addressed, and I don’t think it can be fixed in time for the first 0.11 release.
I will be writing a series of blog posts, each addressing one argument against raising the maximum block size, or against scheduling a raise right now... please send me an email ([email protected]) if I am missing any arguments
In other words, Gavin proposed a hard fork via a series of blog posts, bypassing all developer communication channels altogether and asking for personal, private emails from anyone interested in discussing the proposal further.
On May 5 (1 day after Gavin submitted his first blog post), Mike Hearn published The capacity cliff on his Medium page. 2 days later, he posted Crash landing. In these posts, he argued:
A common argument for letting Bitcoin blocks fill up is that the outcome won’t be so bad: just a market for fees... this is wrong. I don’t believe fees will become high and stable if Bitcoin runs out of capacity. Instead, I believe Bitcoin will crash.
...a permanent backlog would start to build up... as the backlog grows, nodes will start running out of memory and dying... as Core will accept any transaction that’s valid without any limit a node crash is eventually inevitable.
He also, in the latter article, explained that he disagreed with Satoshi's vision for how Bitcoin would mature[1][2]:
Neither me nor Gavin believe a fee market will work as a substitute for the inflation subsidy.
Gavin continued to publish the series of blog posts he had announced while Hearn made these predictions. [1][2][3][4][5][6][7]
Matt Corallo brought Gavin's proposal up on the bitcoin-dev mailing list after a few days. He wrote:
Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell...
So, at the risk of starting a flamewar, I'll provide a little bait to get some responses and hope the discussion opens up into an honest comparison of the tradeoffs here. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase.
Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler).
This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo
Shortly thereafter, Corallo explained further:
The point of the hard block size limit is exactly because giving miners free rule to do anything they like with their blocks would allow them to do any number of crazy attacks. The incentives for miners to pick block sizes are no where near compatible with what allows the network to continue to run in a decentralized manner.
Tier Nolan considered possible extensions and modifications that might improve Gavin's proposal and argued that soft caps could be used to mitigate against the dangers of a blocksize increase. Tom Harding voiced support for Gavin's proposal
Peter Todd mentioned that a limited blocksize provides the benefit of protecting against the "perverse incentives" behind potential block withholding attacks.
Slush didn't have a strong opinion one way or the other, and neither did Eric Lombrozo, though Eric was interested in developing hard-fork best practices and wanted to:
explore all the complexities involved with deployment of hard forks. Let’s not just do a one-off ad-hoc thing.
Matt Whitlock voiced his opinion:
I'm not so much opposed to a block size increase as I am opposed to a hard fork... I strongly fear that the hard fork itself will become an excuse to change other aspects of the system in ways that will have unintended and possibly disastrous consequences.
Bryan Bishop strongly opposed Gavin's proposal, and offered a philosophical perspective on the matter:
there has been significant public discussion... about why increasing the max block size is kicking the can down the road while possibly compromising blockchain security. There were many excellent objections that were raised that, sadly, I see are not referenced at all in the recent media blitz. Frankly I can't help but feel that if contributions, like those from #bitcoin-wizards, have been ignored in lieu of technical analysis, and the absence of discussion on this mailing list, that I feel perhaps there are other subtle and extremely important technical details that are completely absent from this--and other-- proposals.
Secured decentralization is the most important and most interesting property of bitcoin. Everything else is rather trivial and could be achieved millions of times more efficiently with conventional technology. Our technical work should be informed by the technical nature of the system we have constructed.
There's no doubt in my mind that bitcoin will always see the most extreme campaigns and the most extreme misunderstandings... for development purposes we must hold ourselves to extremely high standards before proposing changes, especially to the public, that have the potential to be unsafe and economically unsafe.
There are many potential technical solutions for aggregating millions (trillions?) of transactions into tiny bundles. As a small proof-of-concept, imagine two parties sending transactions back and forth 100 million times. Instead of recording every transaction, you could record the start state and the end state, and end up with two transactions or less. That's a 100 million fold, without modifying max block size and without potentially compromising secured decentralization.
The MIT group should listen up and get to work figuring out how to measure decentralization and its security.. Getting this measurement right would be really beneficial because we would have a more academic and technical understanding to work with.
Gregory Maxwell echoed and extended that perspective:
When Bitcoin is changed fundamentally, via a hard fork, to have different properties, the change can create winners or losers...
There are non-trivial number of people who hold extremes on any of these general belief patterns; Even among the core developers there is not a consensus on Bitcoin's optimal role in society and the commercial marketplace.
there is a at least a two fold concern on this particular ("Long term Mining incentives") front:
One is that the long-held argument is that security of the Bitcoin system in the long term depends on fee income funding autonomous, anonymous, decentralized miners profitably applying enough hash-power to make reorganizations infeasible.
For fees to achieve this purpose, there seemingly must be an effective scarcity of capacity.
The second is that when subsidy has fallen well below fees, the incentive to move the blockchain forward goes away. An optimal rational miner would be best off forking off the current best block in order to capture its fees, rather than moving the blockchain forward...
tools like the Lightning network proposal could well allow us to hit a greater spectrum of demands at once--including secure zero-confirmation (something that larger blocksizes reduce if anything), which is important for many applications. With the right technology I believe we can have our cake and eat it too, but there needs to be a reason to build it; the security and decentralization level of Bitcoin imposes a hard upper limit on anything that can be based on it.
Another key point here is that the small bumps in blocksize which wouldn't clearly knock the system into a largely centralized mode--small constants--are small enough that they don't quantitatively change the operation of the system; they don't open up new applications that aren't possible today
the procedure I'd prefer would be something like this: if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk. Hardfork changes should only be made if they're almost completely uncontroversial--where virtually everyone can look at the available data and say "yea, that isn't undermining my property rights or future use of Bitcoin; it's no big deal". Unfortunately, every indicator I can think of except fee totals has been going in the wrong direction almost monotonically along with the blockchain size increase since 2012 when we started hitting full blocks and responded by increasing the default soft target. This is frustrating
many people--myself included--have been working feverishly hard behind the scenes on Bitcoin Core to increase the scalability. This work isn't small-potatoes boring software engineering stuff; I mean even my personal contributions include things like inventing a wholly new generic algebraic optimization applicable to all EC signature schemes that increases performance by 4%, and that is before getting into the R&D stuff that hasn't really borne fruit yet, like fraud proofs. Today Bitcoin Core is easily >100 times faster to synchronize and relay than when I first got involved on the same hardware, but these improvements have been swallowed by the growth. The ironic thing is that our frantic efforts to keep ahead and not lose decentralization have both not been enough (by the best measures, full node usage is the lowest its been since 2011 even though the user base is huge now) and yet also so much that people could seriously talk about increasing the block size to something gigantic like 20MB. This sounds less reasonable when you realize that even at 1MB we'd likely have a smoking hole in the ground if not for existing enormous efforts to make scaling not come at a loss of decentralization.
Peter Todd also summarized some academic findings on the subject:
In short, without either a fixed blocksize or fixed fee per transaction Bitcoin will will not survive as there is no viable way to pay for PoW security. The latter option - fixed fee per transaction - is non-trivial to implement in a way that's actually meaningful - it's easy to give miners "kickbacks" - leaving us with a fixed blocksize.
Even a relatively small increase to 20MB will greatly reduce the number of people who can participate fully in Bitcoin, creating an environment where the next increase requires the consent of an even smaller portion of the Bitcoin ecosystem. Where does that stop? What's the proposed mechanism that'll create an incentive and social consensus to not just 'kick the can down the road'(3) and further centralize but actually scale up Bitcoin the hard way?
Some developers (e.g. Aaron Voisine) voiced support for Gavin's proposal which repeated Mike Hearn's "crash landing" arguments.
Pieter Wuille said:
I am - in general - in favor of increasing the size blocks...
Controversial hard forks. I hope the mailing list here today already proves it is a controversial issue. Independent of personal opinions pro or against, I don't think we can do a hard fork that is controversial in nature. Either the result is effectively a fork, and pre-existing coins can be spent once on both sides (effectively failing Bitcoin's primary purpose), or the result is one side forced to upgrade to something they dislike - effectively giving a power to developers they should never have. Quoting someone: "I did not sign up to be part of a central banker's committee".
The reason for increasing is "need". If "we need more space in blocks" is the reason to do an upgrade, it won't stop after 20 MB. There is nothing fundamental possible with 20 MB blocks that isn't with 1 MB blocks.
Misrepresentation of the trade-offs. You can argue all you want that none of the effects of larger blocks are particularly damaging, so everything is fine. They will damage something (see below for details), and we should analyze these effects, and be honest about them, and present them as a trade-off made we choose to make to scale the system better. If you just ask people if they want more transactions, of course you'll hear yes. If you ask people if they want to pay less taxes, I'm sure the vast majority will agree as well.
Miner centralization. There is currently, as far as I know, no technology that can relay and validate 20 MB blocks across the planet, in a manner fast enough to avoid very significant costs to mining. There is work in progress on this (including Gavin's IBLT-based relay, or Greg's block network coding), but I don't think we should be basing the future of the economics of the system on undemonstrated ideas. Without those (or even with), the result may be that miners self-limit the size of their blocks to propagate faster, but if this happens, larger, better-connected, and more centrally-located groups of miners gain a competitive advantage by being able to produce larger blocks. I would like to point out that there is nothing evil about this - a simple feedback to determine an optimal block size for an individual miner will result in larger blocks for better connected hash power. If we do not want miners to have this ability, "we" (as in: those using full nodes) should demand limitations that prevent it. One such limitation is a block size limit (whatever it is).
Ability to use a full node.
Skewed incentives for improvements... without actual pressure to work on these, I doubt much will change. Increasing the size of blocks now will simply make it cheap enough to continue business as usual for a while - while forcing a massive cost increase (and not just a monetary one) on the entire ecosystem.
Fees and long-term incentives.
I don't think 1 MB is optimal. Block size is a compromise between scalability of transactions and verifiability of the system. A system with 10 transactions per day that is verifiable by a pocket calculator is not useful, as it would only serve a few large bank's settlements. A system which can deal with every coffee bought on the planet, but requires a Google-scale data center to verify is also not useful, as it would be trivially out-competed by a VISA-like design. The usefulness needs in a balance, and there is no optimal choice for everyone. We can choose where that balance lies, but we must accept that this is done as a trade-off, and that that trade-off will have costs such as hardware costs, decreasing anonymity, less independence, smaller target audience for people able to fully validate, ...
Choose wisely.
Mike Hearn responded:
this list is not a good place for making progress or reaching decisions.
if Bitcoin continues on its current growth trends it will run out of capacity, almost certainly by some time next year. What we need to see right now is leadership and a plan, that fits in the available time window.
I no longer believe this community can reach consensus on anything protocol related.
When the money supply eventually dwindles I doubt it will be fee pressure that funds mining
What I don't see from you yet is a specific and credible plan that fits within the next 12 months and which allows Bitcoin to keep growing.
Peter Todd then pointed out that, contrary to Mike's claims, developer consensus had been achieved within Core plenty of times recently. Btc-drak asked Mike to "explain where the 12 months timeframe comes from?"
Jorge Timón wrote an incredibly prescient reply to Mike:
We've successfully reached consensus for several softfork proposals already. I agree with others that hardfork need to be uncontroversial and there should be consensus about them. If you have other ideas for the criteria for hardfork deployment all I'm ears. I just hope that by "What we need to see right now is leadership" you don't mean something like "when Gaving and Mike agree it's enough to deploy a hardfork" when you go from vague to concrete.
Oh, so your answer to "bitcoin will eventually need to live on fees and we would like to know more about how it will look like then" it's "no bitcoin long term it's broken long term but that's far away in the future so let's just worry about the present". I agree that it's hard to predict that future, but having some competition for block space would actually help us get more data on a similar situation to be able to predict that future better. What you want to avoid at all cost (the block size actually being used), I see as the best opportunity we have to look into the future.
this is my plan: we wait 12 months... and start having full blocks and people having to wait 2 blocks for their transactions to be confirmed some times. That would be the beginning of a true "fee market", something that Gavin used to say was his #1 priority not so long ago (which seems contradictory with his current efforts to avoid that from happening). Having a true fee market seems clearly an advantage. What are supposedly disastrous negative parts of this plan that make an alternative plan (ie: increasing the block size) so necessary and obvious. I think the advocates of the size increase are failing to explain the disadvantages of maintaining the current size. It feels like the explanation are missing because it should be somehow obvious how the sky will burn if we don't increase the block size soon. But, well, it is not obvious to me, so please elaborate on why having a fee market (instead of just an price estimator for a market that doesn't even really exist) would be a disaster.
Some suspected Gavin/Mike were trying to rush the hard fork for personal reasons.
Mike Hearn's response was to demand a "leader" who could unilaterally steer the Bitcoin project and make decisions unchecked:
No. What I meant is that someone (theoretically Wladimir) needs to make a clear decision. If that decision is "Bitcoin Core will wait and watch the fireworks when blocks get full", that would be showing leadership
I will write more on the topic of what will happen if we hit the block size limit... I don't believe we will get any useful data out of such an event. I've seen distributed systems run out of capacity before. What will happen instead is technological failure followed by rapid user abandonment...
we need to hear something like that from Wladimir, or whoever has the final say around here.
Jorge Timón responded:
it is true that "universally uncontroversial" (which is what I think the requirement should be for hard forks) is a vague qualifier that's not formally defined anywhere. I guess we should only consider rational arguments. You cannot just nack something without further explanation. If his explanation was "I will change my mind after we increase block size", I guess the community should say "then we will just ignore your nack because it makes no sense". In the same way, when people use fallacies (purposely or not) we must expose that and say "this fallacy doesn't count as an argument". But yeah, it would probably be good to define better what constitutes a "sensible objection" or something. That doesn't seem simple though.
it seems that some people would like to see that happening before the subsidies are low (not necessarily null), while other people are fine waiting for that but don't want to ever be close to the scale limits anytime soon. I would also like to know for how long we need to prioritize short term adoption in this way. As others have said, if the answer is "forever, adoption is always the most important thing" then we will end up with an improved version of Visa. But yeah, this is progress, I'll wait for your more detailed description of the tragedies that will follow hitting the block limits, assuming for now that it will happen in 12 months. My previous answer to the nervous "we will hit the block limits in 12 months if we don't do anything" was "not sure about 12 months, but whatever, great, I'm waiting for that to observe how fees get affected". But it should have been a question "what's wrong with hitting the block limits in 12 months?"
Mike Hearn again asserted the need for a leader:
There must be a single decision maker for any given codebase.
Bryan Bishop attempted to explain why this did not make sense with git architecture.
Finally, Gavin announced his intent to merge the patch into Bitcoin XT to bypass the peer review he had received on the bitcoin-dev mailing list.
submitted by sound8bits to Bitcoin [link] [comments]

Updated charts of SlushPool voting and mined block percentages

Updated charts of SlushPool voting and mined block percentages submitted by hwolowitz to btc [link] [comments]

The Origins of the (Modern) Blocksize Debate

On May 4, 2015, Gavin Andresen wrote on his blog:
I was planning to submit a pull request to the 0.11 release of Bitcoin Core that will allow miners to create blocks bigger than one megabyte, starting a little less than a year from now. But this process of peer review turned up a technical issue that needs to get addressed, and I don’t think it can be fixed in time for the first 0.11 release.
I will be writing a series of blog posts, each addressing one argument against raising the maximum block size, or against scheduling a raise right now... please send me an email ([email protected]) if I am missing any arguments
In other words, Gavin proposed a hard fork via a series of blog posts, bypassing all developer communication channels altogether and asking for personal, private emails from anyone interested in discussing the proposal further.
On May 5 (1 day after Gavin submitted his first blog post), Mike Hearn published The capacity cliff on his Medium page. 2 days later, he posted Crash landing. In these posts, he argued:
A common argument for letting Bitcoin blocks fill up is that the outcome won’t be so bad: just a market for fees... this is wrong. I don’t believe fees will become high and stable if Bitcoin runs out of capacity. Instead, I believe Bitcoin will crash.
...a permanent backlog would start to build up... as the backlog grows, nodes will start running out of memory and dying... as Core will accept any transaction that’s valid without any limit a node crash is eventually inevitable.
He also, in the latter article, explained that he disagreed with Satoshi's vision for how Bitcoin would mature[1][2]:
Neither me nor Gavin believe a fee market will work as a substitute for the inflation subsidy.
Gavin continued to publish the series of blog posts he had announced while Hearn made these predictions. [1][2][3][4][5][6][7]
Matt Corallo brought Gavin's proposal up on the bitcoin-dev mailing list after a few days. He wrote:
Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell...
So, at the risk of starting a flamewar, I'll provide a little bait to get some responses and hope the discussion opens up into an honest comparison of the tradeoffs here. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase.
Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler).
This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo
Shortly thereafter, Corallo explained further:
The point of the hard block size limit is exactly because giving miners free rule to do anything they like with their blocks would allow them to do any number of crazy attacks. The incentives for miners to pick block sizes are no where near compatible with what allows the network to continue to run in a decentralized manner.
Tier Nolan considered possible extensions and modifications that might improve Gavin's proposal and argued that soft caps could be used to mitigate against the dangers of a blocksize increase. Tom Harding voiced support for Gavin's proposal
Peter Todd mentioned that a limited blocksize provides the benefit of protecting against the "perverse incentives" behind potential block withholding attacks.
Slush didn't have a strong opinion one way or the other, and neither did Eric Lombrozo, though Eric was interested in developing hard-fork best practices and wanted to:
explore all the complexities involved with deployment of hard forks. Let’s not just do a one-off ad-hoc thing.
Matt Whitlock voiced his opinion:
I'm not so much opposed to a block size increase as I am opposed to a hard fork... I strongly fear that the hard fork itself will become an excuse to change other aspects of the system in ways that will have unintended and possibly disastrous consequences.
Bryan Bishop strongly opposed Gavin's proposal, and offered a philosophical perspective on the matter:
there has been significant public discussion... about why increasing the max block size is kicking the can down the road while possibly compromising blockchain security. There were many excellent objections that were raised that, sadly, I see are not referenced at all in the recent media blitz. Frankly I can't help but feel that if contributions, like those from #bitcoin-wizards, have been ignored in lieu of technical analysis, and the absence of discussion on this mailing list, that I feel perhaps there are other subtle and extremely important technical details that are completely absent from this--and other-- proposals.
Secured decentralization is the most important and most interesting property of bitcoin. Everything else is rather trivial and could be achieved millions of times more efficiently with conventional technology. Our technical work should be informed by the technical nature of the system we have constructed.
There's no doubt in my mind that bitcoin will always see the most extreme campaigns and the most extreme misunderstandings... for development purposes we must hold ourselves to extremely high standards before proposing changes, especially to the public, that have the potential to be unsafe and economically unsafe.
There are many potential technical solutions for aggregating millions (trillions?) of transactions into tiny bundles. As a small proof-of-concept, imagine two parties sending transactions back and forth 100 million times. Instead of recording every transaction, you could record the start state and the end state, and end up with two transactions or less. That's a 100 million fold, without modifying max block size and without potentially compromising secured decentralization.
The MIT group should listen up and get to work figuring out how to measure decentralization and its security.. Getting this measurement right would be really beneficial because we would have a more academic and technical understanding to work with.
Gregory Maxwell echoed and extended that perspective:
When Bitcoin is changed fundamentally, via a hard fork, to have different properties, the change can create winners or losers...
There are non-trivial number of people who hold extremes on any of these general belief patterns; Even among the core developers there is not a consensus on Bitcoin's optimal role in society and the commercial marketplace.
there is a at least a two fold concern on this particular ("Long term Mining incentives") front:
One is that the long-held argument is that security of the Bitcoin system in the long term depends on fee income funding autonomous, anonymous, decentralized miners profitably applying enough hash-power to make reorganizations infeasible.
For fees to achieve this purpose, there seemingly must be an effective scarcity of capacity.
The second is that when subsidy has fallen well below fees, the incentive to move the blockchain forward goes away. An optimal rational miner would be best off forking off the current best block in order to capture its fees, rather than moving the blockchain forward...
tools like the Lightning network proposal could well allow us to hit a greater spectrum of demands at once--including secure zero-confirmation (something that larger blocksizes reduce if anything), which is important for many applications. With the right technology I believe we can have our cake and eat it too, but there needs to be a reason to build it; the security and decentralization level of Bitcoin imposes a hard upper limit on anything that can be based on it.
Another key point here is that the small bumps in blocksize which wouldn't clearly knock the system into a largely centralized mode--small constants--are small enough that they don't quantitatively change the operation of the system; they don't open up new applications that aren't possible today
the procedure I'd prefer would be something like this: if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk. Hardfork changes should only be made if they're almost completely uncontroversial--where virtually everyone can look at the available data and say "yea, that isn't undermining my property rights or future use of Bitcoin; it's no big deal". Unfortunately, every indicator I can think of except fee totals has been going in the wrong direction almost monotonically along with the blockchain size increase since 2012 when we started hitting full blocks and responded by increasing the default soft target. This is frustrating
many people--myself included--have been working feverishly hard behind the scenes on Bitcoin Core to increase the scalability. This work isn't small-potatoes boring software engineering stuff; I mean even my personal contributions include things like inventing a wholly new generic algebraic optimization applicable to all EC signature schemes that increases performance by 4%, and that is before getting into the R&D stuff that hasn't really borne fruit yet, like fraud proofs. Today Bitcoin Core is easily >100 times faster to synchronize and relay than when I first got involved on the same hardware, but these improvements have been swallowed by the growth. The ironic thing is that our frantic efforts to keep ahead and not lose decentralization have both not been enough (by the best measures, full node usage is the lowest its been since 2011 even though the user base is huge now) and yet also so much that people could seriously talk about increasing the block size to something gigantic like 20MB. This sounds less reasonable when you realize that even at 1MB we'd likely have a smoking hole in the ground if not for existing enormous efforts to make scaling not come at a loss of decentralization.
Peter Todd also summarized some academic findings on the subject:
In short, without either a fixed blocksize or fixed fee per transaction Bitcoin will will not survive as there is no viable way to pay for PoW security. The latter option - fixed fee per transaction - is non-trivial to implement in a way that's actually meaningful - it's easy to give miners "kickbacks" - leaving us with a fixed blocksize.
Even a relatively small increase to 20MB will greatly reduce the number of people who can participate fully in Bitcoin, creating an environment where the next increase requires the consent of an even smaller portion of the Bitcoin ecosystem. Where does that stop? What's the proposed mechanism that'll create an incentive and social consensus to not just 'kick the can down the road'(3) and further centralize but actually scale up Bitcoin the hard way?
Some developers (e.g. Aaron Voisine) voiced support for Gavin's proposal which repeated Mike Hearn's "crash landing" arguments.
Pieter Wuille said:
I am - in general - in favor of increasing the size blocks...
Controversial hard forks. I hope the mailing list here today already proves it is a controversial issue. Independent of personal opinions pro or against, I don't think we can do a hard fork that is controversial in nature. Either the result is effectively a fork, and pre-existing coins can be spent once on both sides (effectively failing Bitcoin's primary purpose), or the result is one side forced to upgrade to something they dislike - effectively giving a power to developers they should never have. Quoting someone: "I did not sign up to be part of a central banker's committee".
The reason for increasing is "need". If "we need more space in blocks" is the reason to do an upgrade, it won't stop after 20 MB. There is nothing fundamental possible with 20 MB blocks that isn't with 1 MB blocks.
Misrepresentation of the trade-offs. You can argue all you want that none of the effects of larger blocks are particularly damaging, so everything is fine. They will damage something (see below for details), and we should analyze these effects, and be honest about them, and present them as a trade-off made we choose to make to scale the system better. If you just ask people if they want more transactions, of course you'll hear yes. If you ask people if they want to pay less taxes, I'm sure the vast majority will agree as well.
Miner centralization. There is currently, as far as I know, no technology that can relay and validate 20 MB blocks across the planet, in a manner fast enough to avoid very significant costs to mining. There is work in progress on this (including Gavin's IBLT-based relay, or Greg's block network coding), but I don't think we should be basing the future of the economics of the system on undemonstrated ideas. Without those (or even with), the result may be that miners self-limit the size of their blocks to propagate faster, but if this happens, larger, better-connected, and more centrally-located groups of miners gain a competitive advantage by being able to produce larger blocks. I would like to point out that there is nothing evil about this - a simple feedback to determine an optimal block size for an individual miner will result in larger blocks for better connected hash power. If we do not want miners to have this ability, "we" (as in: those using full nodes) should demand limitations that prevent it. One such limitation is a block size limit (whatever it is).
Ability to use a full node.
Skewed incentives for improvements... without actual pressure to work on these, I doubt much will change. Increasing the size of blocks now will simply make it cheap enough to continue business as usual for a while - while forcing a massive cost increase (and not just a monetary one) on the entire ecosystem.
Fees and long-term incentives.
I don't think 1 MB is optimal. Block size is a compromise between scalability of transactions and verifiability of the system. A system with 10 transactions per day that is verifiable by a pocket calculator is not useful, as it would only serve a few large bank's settlements. A system which can deal with every coffee bought on the planet, but requires a Google-scale data center to verify is also not useful, as it would be trivially out-competed by a VISA-like design. The usefulness needs in a balance, and there is no optimal choice for everyone. We can choose where that balance lies, but we must accept that this is done as a trade-off, and that that trade-off will have costs such as hardware costs, decreasing anonymity, less independence, smaller target audience for people able to fully validate, ...
Choose wisely.
Mike Hearn responded:
this list is not a good place for making progress or reaching decisions.
if Bitcoin continues on its current growth trends it will run out of capacity, almost certainly by some time next year. What we need to see right now is leadership and a plan, that fits in the available time window.
I no longer believe this community can reach consensus on anything protocol related.
When the money supply eventually dwindles I doubt it will be fee pressure that funds mining
What I don't see from you yet is a specific and credible plan that fits within the next 12 months and which allows Bitcoin to keep growing.
Peter Todd then pointed out that, contrary to Mike's claims, developer consensus had been achieved within Core plenty of times recently. Btc-drak asked Mike to "explain where the 12 months timeframe comes from?"
Jorge Timón wrote an incredibly prescient reply to Mike:
We've successfully reached consensus for several softfork proposals already. I agree with others that hardfork need to be uncontroversial and there should be consensus about them. If you have other ideas for the criteria for hardfork deployment all I'm ears. I just hope that by "What we need to see right now is leadership" you don't mean something like "when Gaving and Mike agree it's enough to deploy a hardfork" when you go from vague to concrete.
Oh, so your answer to "bitcoin will eventually need to live on fees and we would like to know more about how it will look like then" it's "no bitcoin long term it's broken long term but that's far away in the future so let's just worry about the present". I agree that it's hard to predict that future, but having some competition for block space would actually help us get more data on a similar situation to be able to predict that future better. What you want to avoid at all cost (the block size actually being used), I see as the best opportunity we have to look into the future.
this is my plan: we wait 12 months... and start having full blocks and people having to wait 2 blocks for their transactions to be confirmed some times. That would be the beginning of a true "fee market", something that Gavin used to say was his #1 priority not so long ago (which seems contradictory with his current efforts to avoid that from happening). Having a true fee market seems clearly an advantage. What are supposedly disastrous negative parts of this plan that make an alternative plan (ie: increasing the block size) so necessary and obvious. I think the advocates of the size increase are failing to explain the disadvantages of maintaining the current size. It feels like the explanation are missing because it should be somehow obvious how the sky will burn if we don't increase the block size soon. But, well, it is not obvious to me, so please elaborate on why having a fee market (instead of just an price estimator for a market that doesn't even really exist) would be a disaster.
Some suspected Gavin/Mike were trying to rush the hard fork for personal reasons.
Mike Hearn's response was to demand a "leader" who could unilaterally steer the Bitcoin project and make decisions unchecked:
No. What I meant is that someone (theoretically Wladimir) needs to make a clear decision. If that decision is "Bitcoin Core will wait and watch the fireworks when blocks get full", that would be showing leadership
I will write more on the topic of what will happen if we hit the block size limit... I don't believe we will get any useful data out of such an event. I've seen distributed systems run out of capacity before. What will happen instead is technological failure followed by rapid user abandonment...
we need to hear something like that from Wladimir, or whoever has the final say around here.
Jorge Timón responded:
it is true that "universally uncontroversial" (which is what I think the requirement should be for hard forks) is a vague qualifier that's not formally defined anywhere. I guess we should only consider rational arguments. You cannot just nack something without further explanation. If his explanation was "I will change my mind after we increase block size", I guess the community should say "then we will just ignore your nack because it makes no sense". In the same way, when people use fallacies (purposely or not) we must expose that and say "this fallacy doesn't count as an argument". But yeah, it would probably be good to define better what constitutes a "sensible objection" or something. That doesn't seem simple though.
it seems that some people would like to see that happening before the subsidies are low (not necessarily null), while other people are fine waiting for that but don't want to ever be close to the scale limits anytime soon. I would also like to know for how long we need to prioritize short term adoption in this way. As others have said, if the answer is "forever, adoption is always the most important thing" then we will end up with an improved version of Visa. But yeah, this is progress, I'll wait for your more detailed description of the tragedies that will follow hitting the block limits, assuming for now that it will happen in 12 months. My previous answer to the nervous "we will hit the block limits in 12 months if we don't do anything" was "not sure about 12 months, but whatever, great, I'm waiting for that to observe how fees get affected". But it should have been a question "what's wrong with hitting the block limits in 12 months?"
Mike Hearn again asserted the need for a leader:
There must be a single decision maker for any given codebase.
Bryan Bishop attempted to explain why this did not make sense with git architecture.
Finally, Gavin announced his intent to merge the patch into Bitcoin XT to bypass the peer review he had received on the bitcoin-dev mailing list.
submitted by sound8bits to sound8bits [link] [comments]

Working of Cryptocurrency Mining pool

Working of Cryptocurrency Mining pool
Source - https://coinscapture.com/blog/working-of-cryptocurrency-mining-pool

Working of Cryptocurrency Mining pool
Cryptocurrency is the most discussed and trending topic on various internet forums, communities, and social media. Many individuals are keen to enter the cryptoworld and unfold all the profits within it. Cryptocurrency can be bought from an exchange or mined through the mining pools. In this guide, we’ll understand the working of the cryptocurrency mining pool.
What is Mining Pool?
Cryptocurrency mining is the same as mining the metals from the earth. The individual or company that digs out the metal from the earth becomes the owner similarly the individual who discovers first the valid hash using the computational power becomes the owner and earns a block reward. The crypto mining can either be done solo using his/her own mining devices or through a mining pool.
As more and more enthusiasts participated in mining to earn a block reward became equally difficult and it would take centuries for a miner to generate a block because the probability of finding the hash value first and generating a block is directly proportional to the computing power in the network. The smaller the computational power the smaller is the chance of generating the next block. Hence a solution, to this problem mining pools were formed.
A mining pool is a group of miners pooling/combining their computational power together in order to mine a cryptocurrency quickly and earn a block reward consistently. Each contributing miner earns reward according to their investment in processing power. The working of mining pools depends on certain algorithms that are designed to check the authenticity and validity of the transactions. Miners are required to solve a complex math problem that requires millions of calculations with the help of High computational power. When the miners combined their computational power the block generation process happens at a much faster rate as compared to a single mining rig. For more understanding of mining please refer our previous blog (What is Bitcoin mining?)
Types of Mining Pools
  • Single mining pools: This type of mining pool mine only single cryptocurrency
  • Multi-currency pools: This type of mining pool mine different cryptocurrencies and gives the miner a chance to choose the cryptocurrency for mining timely depending rewards points offered.
  • Cloud mining pools: Cloud-based mining can be combined with mining pools by making an online contract. This type of mining pool allows individuals to participate in mining activity without even buying specialized equipment.
How rewards are shared on mining pools?
The rewards shared after successfully adding the new block to the blockchain vary from currency to currency. The reward sharings also depend on the factors like mining difficulty, the exchange rate between different coins, the hash rate and the block generation time. Some of the followed reward structures are as follows:
  1. Pay-per-share (PPS): This method offers instant payout depending on the miner’s contribution to finding the block. The payment is done using the pool's existing balance and can be withdrawn immediately.
  2. Shared Maximum Pay Per Share (SMPPS): It is the same as Pay-per-share (PPS) but limits the payout to the maximum that the pool has earned.
  3. Equalized Shared Maximum Pay Per Share (ESMPPS): This method is similar to (SMPPS) but the rewards are distributed equally among all miners in the pool.
  4. Proportional (PROP): The miner is rewarded the share that is proportional to the number of shares he has in the pool with respect to the pool’s total shares
Advantages of mining pools
  • Mining pools offer a more stable income
  • Mining pools lower costs of mining
  • Mining pools helps in generating a higher income
Disadvantages of Mining pools
  • There may be some interruptions in the Mining pools
  • There is a sharing of block rewards
  • There may be sometimes unfavorable pool reward structure
Widely-Used Mining Pools
  • Antpool: The largest pool available on the web offering mining of cryptocurrencies like BTC, BCH, LTC, ETH, ETC, ZEC, DASH, SCC, XMC, BTM
  • Minergate.com: A public mining pool mining of cryptocurrencies like ETH, ETC, ZEC, BTG, BCN, XMR, XMO, FCN, XDN, AEON
  • Btc.com: The most popular mining pool among miners offering cryptocurrencies BTC, BCH, ETH, ETC, LTC, UBTC, DCR to mine
  • BTCC: The largest Chinese pool in the world mining 7% of all existing blocks.
  • Slush: The most trusted mining pools on internet mining 7% of all available blocks.
Mining pools can definitely be a change to the entire mining process offering the highest and the real income without spending years depending on the computational powers. Hence, investing in a mining pool can be beneficial but always choose the mining pool that fits your personal needs and facilities.
submitted by coinscapturecom to u/coinscapturecom [link] [comments]

Easy probability calculation of bip 91 activation this period.

http://stattrek.com/online-calculatobinomial.aspx
Enter the following from top to bottom:
Then look at the bottom most probability.
Depending on what you insert as the hashrate percentage right now there seems to be about 30% change of activating BIP91 this period.
If slushpool would join right now this would increase to about 50%.
If F2pool would also join right now, this would increase to about 99% probability of activation.
EDIT: Putting in the value 82.1% from this post https://www.reddit.com/Bitcoin/comments/6ofjcq/821_gb_miners_just_started_signalling/ gives a probability of 83.2% (currently 84 blocks left) that BIP91 will activate this period. If slush or f2pool will also join and we will not hit a bad streak (which is always possible) this percentage could still increase. Looking good :)
submitted by Tyanuh to Bitcoin [link] [comments]

Plz Help. Have I found a Discrepancy in Slush Pool?

I may have found a bad discrepancy in Slushpool's reporting... Can you guys cross-check it for me? I'm not happy to say this, and rather than accuse anyone, I'd just like to get some second opinions. If I'm wrong, I ask redditers to politely explain why this discrepancy appears to be happening. After all, maybe it's my math, or logic, or facts missing, etc... But if there is a discrepancy, it could affect major things like payouts, theoretically... and I mean in a major way... retroactive for years.
My concern starts with the average speed per worker of the bitcoin mining pool, on Slushpool.
As I write (12/26/17 Pacific time, around 11pm), Slushpool currently says it is running at 1.587 Eh/s. https://slushpool.com/dashboard/?c=btc
The website also says there are 62810 workers in the pool. I want to calculate the speed per worker. Speed per worker should be expressed in Th/s, so to reduce it to common terms, we need to convert the pool's global Eh/s to Th/s... which means to multiply the Eh/s by 10002... one thousand, squared.
The speed of Slushpool was 1.587 Eh/s, so we set it up like this: 1.587 * 1000 * 1000 = 1587000 Th/s. †
Now to get from Slush Pool's total Th/s to Slush Pool's average Th/s per worker, divide total by number of workers...
(1587000 th/s) / (62810 workers) = 25.26 Th/s per worker.
So I got the number I was looking for... excellent. You might say "Okay, interesting, so the average worker is mining at 25.26 Th/s. NP. Cool."... But what you SHOULD be doing here is asking HOW ON EARTH ANY WORKER IS MINING AT 25.26 TH/S, and even moreso how THE AVERAGE worker mining on Slush Pool is mining at that speed. The fastest miner on the market is the s9, and it mines at 14 Th/s. So how is the average miner on Slush Pool more so much faster than the very best miner on the market, today? The S9, The BEST MINER on the MARKET, today, is only 56% the speed of the AVERAGE miner on Slush pool.
Now, maybe somebody built a specialized frankenminer in a laboratory... maybe someone uncovreed a secret cache of Spondoolies SP50 miners... which was designed to mine at a whopping 110th/s, for example... but Spondoolies went bankrupt in 2016, and production was halted. Even before then, they didn't make too many sp50's, and they were restricted to special clients.
So... assuming it isn't legacy Spondoolies sp50's doing this mystery hashing, how else can we explain the high h/s on Slush Pool? Maybe someone got really good at overclocking... maybe they cooled the hell out of their miners, so they can run at super fast speeds. Would that really be enough to yield 25.26 Th/s? Is that credible? Is it possible or plausible? ... Even if some miners are achieving that incredibly blazing speed, would the AVERAGE miner be achieving it?
Don't forget about how the AVERAGE includes all these micro miners, as well... misfits like the u3, gridseed orb, blade miner, s1-s5, running in a dorm rooms, etc. There are hobby miners who would pull the average h/s (per miner) on Slush Pool down alot.
So, how is it possible that the pool is running at this speed? Better asked... IS it possible, and if so, how? And if it's not possible, then what are we looking at?
If the pool operator is overstating the total hashing power of the mining pool, then are payouts being reduced according to a false ratio, where the divisor in the ratio is artificially large? The payouts are based on that... they depend on it. So are the payouts on Slush Pool being artificially shrunken? If the total Eh/s of the pool is really much lower than what they say, then I'd have to suspect that it is. But I am absolutely NOT saying for certain that this is what's happening. It's what my suspicious anxiety closet suggests could be happening... but I really don't know. That's why I'm asking you guys to help sort this all out, and explain to me whether these concerns are misguided or not. I'm asking a question, here... not throwing accusations. Frankly I think it is more likely that I've made an error of some kind, either miscalculating or possibly unaware of some vital detail, than that the net's oldest and most respected mining pool is doing something like this. It is very likely there's a good explanation for the apparent discrepancy, but I do not know what it is... so again, I'm asking you, reddit, if you can evaluate this reasoning and comb it for flaws, math errors, weak factual assumptions, and/or whatever else might explain what I'm seeing, or if you can confirm the math and logic framed in the questions I've asked. Thanks everyone, and have a happy new year.
† (Here is a site which tells the relation) https://bitcoin.stackexchange.com/questions/9219/what-is-the-difference-between-kh-s-mh-s-and-gh-s/21498 (here is a site with a calculator which goes from E~ to T~. Although it does not have Eh/s and Th/s, you can use Ehenry to get the same mathematical result. https://www.translatorscafe.com/unit-converteen/inductance/5-4/gigahenry-terahenry/
submitted by mercucio007 to MiningPoolHub [link] [comments]

Analysis of Bitcoin Pooled Mining Reward Systems

arXiv:1112.4980
Date: 2011-12-21
Author(s): Meni Rosenfeld

Link to Paper


Abstract
In this paper we describe the various scoring systems used to calculate rewards of participants in Bitcoin pooled mining, explain the problems each were designed to solve and analyze their respective advantages and disadvantages.

Bibliography
[1] c00w. bithopper: Python pool hopper proxy. http://bitcointalk.org/?topic=26866.
[2] forrestv. p2pool. https://bitcointalk.org/?topic=18313.0.
[3] Satoshi Nakamoto. Bitcoin p2p virtual currency. http://www.bitcoin.org/.
[4] Raulo. Optimal pool abuse strategy, 2011. http://bitcoin.atspace.com/poolcheating.pdf.
[5] slush. Bitcoin pooled mining. http://mining.bitcoin.cz/.
submitted by dj-gutz to myrXiv [link] [comments]

A bribe attack is ongoing

First of all, I should note it's not a big deal and there are no reasons to panic or anything, but it's just remarkable that the thing we knew is theoretically possible is happening now.
To provide background on this kind of attack I need to start from fundamentals. Here's the security assumption from the Bitcoin paper:
The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.
Originally mining was done by users themselves, it was a part of node/wallet software. However, later it became more specialized.
Hashing, running nodes and using Bitcoin are completely separate things nowadays when pooled mining is commonplace. That is, somebody can "mine" bitcoins using his hashing hardware without running a node. (And, perhaps, without even being a Bitcoin user, as a "miner" can auto-convert his revenue to dollars.)
Calling this "mining" isn't quite accurate. More precisely it can be described as renting (that is, mining pools rent hashing hardware of so-called "miners") or paying for a service (mining pools pays a "miner" for the efforts he's performed).
Some "miners" believe that they receive bitcoins they created, but it's not true in a general case. One thing is that more often then not, individual miners fail to solve the block, but are still compensated for their efforts (not for results). Also pools generally have reserves which they use to smooth out reward payments, thus rewards miners receive do not necessarily come from freshly mined bitcoins.
Now let's recall that hashpower is intimately linked to the security of the network. Attacker who controls a significant portion of total hashpower might be able to perform double-spend attacks (e.g. see Meni Rosenfeld's Analysis of Hashrate-Based Double Spending) or denial-of-service attacks (he might mine empty blocks).
It is usually understood that these attacks are practically unfeasible, as overpowering the honest network would require enormous amounts of hardware, energy, etc. However, there are several different attack model.
The most primitive one was relevant back when mining was done on CPUs: an attacker could rent CPU power from a cloud provider such as Amazon and try to do a double-spend reorganization or a 51% attack. It's fairly easy to do calculations within this model as the cost of an attack is known (for a certain difficulty) and one just needs to compare it to potential profits attacker might get.
But CPU mining is irrelevant now, attacker would need specialized hardware to have a chance. This makes attack much more complex, as attacker needs to buy hardware, deploy it, start mining... And once attack is complete, he needs to do something with that hardware. It's generally understood that parties who own hashing hardware will be reluctant to perform attack because a successful attack can drastically decrease the value of the hardware they own. Thus it can be said that ASICs made Bitcoin much more secure due to this stickiness.
But wait... what if an attacker rents hardware instead of buying it? It's much simpler than buying hardware: no complex logistics, little overhead, no concerns about how an attack would affect hardware price. Attacker would need to pay slightly above the market price to make sure he gets more than a half of total hashpower to make sure that it's statistically certain his attack can succeed.
This can be describe as a sort of a bribe. Normally miners get block rewards (subsidy + fees). Attacker adds a bribe to it, making it subsidy + fees + bribe. This is attractive to miners as it pays more. Once attack is successful, attacker receives subsidy + fees + attack profit. Thus his cost is
(subsidy + fees + attack profit) - (subsidy + fees + bribe) = attack profit - bribe 
Note that bribe can be arbitrarily small, it should be just enough to get miners interested. It can be 1% of a subsidy, for example. E.g. suppose attacker wants to earn 1000 BTC by double-spending, he gives a 10 BTC bribe to miners to orphan some of the recent blocks and pockets 990 BTC.
The cost of this attack can be arbitrarily small, but it requires a lot of a capital and is also quite risky. And also it's not possible right now because miners do not just rent their hashpower to the highest bidder, they use mining pools they trust. Thus there's no way for the attacker go get more than 50% of total hashpower to be successful with this attack.
There are, however, pools which allow people to rent hashpower. For example, NiceHash. It currently has 16 PH/s of SHA256 hashpower (according to the stats they publish), thus controlling around 1% of total hashpower. NiceHash allocates hashpower to highest bidder, and thus it can be potentially used for attacks I described above. But currently it's too small to have any effect.
So this is just something to keep in mind. Pools like NiceHash are evil, they can potentially destabilize Bitcoin if more than a half of total Bitcoin's hashpower will be rented out on pools like this. It is important for miners to choose legitimate pools.
So until now I thought that a bribe attack is just a curiosity in context of Bitcoin (it might be more relevant for alt-coins with much weaker hashpower), but today I was surprised with the fact that somebody tries to pull it off right now.
There's a post on /btc: Someone just donated 16 BTC towards Classic Hashpower. We are now at 2 Petahash/sec on Slush pool. Thank you, donator. The fund is at 30 BTC and recycling the mining rewards over and over..
This is exactly the bribe attack, but they aren't using for double-spending or DoS, but on an attempt to hard-fork Bitcoin. Basically it's an attempt to artificially prop up Classic hashpower a little, and is good only for PR. But still it's something we should be aware of, I think.
NodeCounter site the link points to is absolutely hilarious, BTW, totally recommend:
Bitcoin development has been bought out by a private company called "Blockstream". Blockstream has directed the crippling of Bitcoin in order to provide the solution, for their own future, financial gain.
(I hope moderators won't remove my post. /btc is currently being advertised in the sidebar of this subreddit, so every visitor is already one click away from learning information about "Classic Hashpower". I see absolutely no point in censoring this information.)
On topic of brigading: when I posted it initially the post was 100% upvoted, that is regular /bitcoin subscribers found it good and relevant. However a bit later upvote rate dropped to 65% and at the same time several comments defending Classic and /btc appeared. Brigading much? I don't really care what you do with hashpower (attack is just a technical term FYI, it's not necessarily morally wrong), but brigading is despicable.
submitted by killerstorm to Bitcoin [link] [comments]

Is mining really this simple?

Hello, forgive me for asking a stupid question. I come from a very poor family, I am used to working hard to make any money, and am skeptical of anything that sounds like easy money, this whole Bitcoin Mining thing seems too good to be true. I want to air my assumptions.
So; I get a Bitcoin wallet, buy an AntMiner S5/7 and power supply, hook it up to internet and configure it, join Slush's mining pool, and just leave the miner running in my basement. Each month I will earn ~0.186 BTC which I can convert into fiat money (~$79)?
Did I miss anything? My electricity is $0.07/kWh, so I am looking to pocket ~$48 a month? Really? Someone tell me I am wrong, cause this sounds insane...
Thank you,
TheGlutton
Source: https://www.bitcoinmining.com/getting-started/
http://www.coinwarz.com/calculators/bitcoin-mining-calculato?h=1155.00&p=590.00&pc=0.07&pf=2.00&d=93448670796.32380000&r=25.00000000&er=427.47210000&hc=500.00
submitted by TheGlutton to BitcoinMining [link] [comments]

With full blocks and average fees above 150sat/byte Slush Pool and ViaBTC payout more than Bitcoin.com mining pool

Roger claimed his pool Bitcoin.com was the "world's highest paying mining pool".
To his credit, this claim is true in certain circumstances, however it is misleading and it's currently NOT true. It's only true if the block transaction fees are under 1.53061224 bitcoins. (~150sat/byte for full blocks)
Slush Pool and ViaBTC (on PPLNS) both pay 98% of the block reward plus the block transaction fees.
Bitcoin.com pays 110% of the block reward and keeps the block transaction fees.
Over the last 24hours the average block transaction fees were 1.78648863 so directing your hashpower to Bitcoin.com would not have paid the most.
I realise Roger has to promote his pool but the gimmick "world's highest paying mining pool" is currently false.
Here's the maths (x is the fees):
Bitcoin.com = Block Reward * 110% = 12.5*1.1
Slush = (Block Reward + Fees) * 98% = (12.5+x)*.98
Bitcoin.com = Slush (calculate value of x (fees) for equal payout)
12.51.1 = (12.5+x).98
13.75 = (12.5+x)*.98
13.75/.98 = 12.5+x
14.03061224 = 12.5 + x
1.53061224 = x
submitted by m4king to btc [link] [comments]

A brief macroeconomic analysis of TRX and Crypto

Theoretical adoption/implementation of Tron (TRX) and the overall Cryptocurrency market: a brief macroeconomic analysis
If you're reading this I'm assuming you already have a bullish investment thesis on cryptocurrency; chances are you wouldn't be on this sub-reddit if you didn't. So I'll skip the value proposition and tech analysis. This isn't a price-hype post, but there will be some financial statistics and market cap quotes so bear with me.
1) In 2014 the worldwide GDP was estimated at approximately $78.3 Trillion
2) As of writing the worldwide physical Gold market is valued at approximately $8 Trillion
3) In July of 2017, the worldwide stock market was valued at approximately $76.3 Trillion (not to be confused with the world GDP figure above, they're separate)
4) Worldwide debt is valued at approximately $215 Trillion
5) The combined value of the all the world's real estate is estimated at around $217 Trillion
So some basic addition gives us a combined total value of approximately $594 Trillion. The nominal USD value of Earth, depending on how you calculate things.
As of writing this the total cryptocurrency market capitalization is just under $780 Billion. With a B instead of a T this time.
So let's just assume cryptocurrency achieves solid adoption and achieves a 1% overall share of the that massive that $594 Trillion value figure:
$594 Trillion x 1% = $5.94 Trillion
That's an growth rate of 761.5% from current market cap.
So now let's get a little crazier and assume cryptocurrency achieves a 5% overall share of the $594 Trillion value figure:
$594 Trillion x 5% = $29.7 Trillion .........
That's an growth rate of 3,807% from current market cap. We're not talking about hype growth here, that's overall market cap growth.
So I think you've gotten the point by now. But like a goddamn Steve Job's keynote presentation, we saved the best for last. The Worldwide Derivatives Market, valued at estimated $1.2 Quadrillion dollars. For those who don't know, derivatives are essentially investment securities based on the value of a underlying asset. Think Futures and Options. This is a good introduction article if you want to know more: https://www.investopedia.com/terms/d/derivative.asp
Anyways, $1.2 Quadrillion dollars.
Here's a written out side by side comparison with the current crypto market cap:
$1,200,000,000,000,000 $780,000,000,000
Currently the cryptocurrency market is a mere 0.065% of the worldwide derivatives market cap.
So if we added $1.4 Quadrillion to our previously calculated $594 Trillion, we get a grand total of $1.994 Quadrillion.
Obtaining 1% of that overall market would give cryptocurrency a market cap of $19,940,000,000,000 or $19.94 Trillion.
So my point is, realistically things are just getting started here in the mystical land of cryptocurrency. But this brings me to my next point; as everyone is aware people In my opinion there will be a market correction in the near future, followed by a rapid continued increase in overall market value. Somewhat reminiscent of the 90s Dotcom bubble, but fundamentally different in a few ways. Like the dotcom bubble, a collapse is required to end this uneducated cycle of careless hype-driven "investing". Just because a cryptocurrency has it's own blockchain or ERC20 token or a "A+" ICO ranking from a affiliate marketing blogger doesn't mean anything. For about $10,000 I could have one too. There's over 1,300 cryptocurrencies; the vast majority of them aren't worth anything. Some are outright scams. When this mass sell-off occurs, money will move from pseudo-crypto to the legitimate cryptocurrency projects. Only the creme-de-le-creme will be left standing. Like we've already seen in cryptocurrency, this will occur over a very short time span. The ease of accessibility has allowed a lot of naive hype-based folks to invest money. When the market experiences this large correction, panic sellers will send money in 2 ways: to fiat and to the creme-de-le-creme coins/tokens. I think many of these hype investors will actually keep the money in crypto to attempt to recoup lost profits. Essentially the market will consolidate into a smaller number of legitimate cryptocurrencies, and much of the currently invested capital will simply be transferred to legitimate projects. This will cause the prices of legitimate cryptocurrencies to pullback slightly, and then explode upward.
So to weed out the worthless projects from the promising projects you must heavily vet. Vet and then vet again. For starters consider these 4 aspects:
1) technological value and feasibility: you must deconstruct white papers and all available technical material! Learn a programming language, read CS forums, phone a friend.
2) Project team, management, advisors: look for teams with relevant background experience obviously; age isn't exactly a factor but maturity is. Buterin is 23 years old. Justin Sun is on Forbes 30 under 30. But be wary, these are shining examples and not the norm. Advisors are very important as well, as they can help hone in the raw talent and provide invaluable networking.
3) Current Partnerships/Applications: massive factor in my mind. We can talk theoretically all day, but when it comes down to it having actual clients/users will be what expands the crypto ecosystem. Partnering with services and business carves out a cryptocurrency's niche, giving it a basis for value.
4) target market conditions: who else is working on the same concept? What differentiates this project from one's similar like it? Do legal restrictions and government regulations hurt or help the project? Ex. Tron is rumored to be working to be regulated through the Chinese government, which could lead to faster mass adoption of TRX in China.
Vetting is what leads to good investments. Pick solid projects and stick with them. Allocate a small monthly investment slush fund if you really need to try exceedingly risky trades. Create your own strategy and opinion, and fact check everyone.
So with all this being said:
In my opinion, this is only the beginning for Tron and cryptocurrency as a whole. With upcoming updates and further partnerships, TRX will be a shining star in the cryptocurrency world (epitomizing it's founder's last name). I do believe ETH, XLM, XRP, VEN, and TRX are best positioned currently due to current partnerships and implemented usage. I would recommend also looking at WTC, REQ, ADA, QTUM, IOTA, NEO, and the privacy coin trio: XVG, XMR, ZEC. I'm not here to shill coins, so I'm done.
Like any investment, please only invest what you can afford to lose. A lot of cryptos will fail in the near future, so diversification is the key to success. Pick a handful of vetted projects you like and believe will be valuable and allocate funds responsibly. Just because you love a particular cryptocurrency doesn't mean you should allocate 50% of your holdings to it. In stock trading, many abide by 5% rule to mitigate risk: never invest more than 5% of your overall trading capital per security. Stay on top of the cryptos you invest in, keep up with news, and constantly reanalyze. Learn some technical analysis and day trade if you feel so inclined. But the goal is to accumulate more, not withdrawal shorter profits to fiat. I firmly believe that the bulk of the market cap growth in the cryptocurrency ecosystem will go towards Alt-coins, not Bitcoin. The overall market cap will easily be over $10 Trillion by 2025. With this much capital influx there will undoubtedly be efforts by the traditional financial sector to manipulate the market. Whales, dark web coalitions, pump/dump telegram groups, etc already make a killing running such scams. A wall street office of 20 quantitative economists could mastermind a manipulation scheme so sophisticatedly it would be largely unnoticed. Hedge funds, banks, and investment firms manipulate the market constantly; what makes anyone think they're going to pass up on crypto? That's the largest risk in my mind. And sure many things could happen that could negatively impact the whole cryptocurrency market, like government regulations (or ether cats). The overall blockchain-ecosystem will grow; decentralization is the future.
Closing words of unsolicited advice: Don't be the person who owned 10,000 shares of NVDA at $22, but sold at $44. If you believe in an investment thesis and there's an analytical basis to your belief, stick with it. The goal of cryptocurrency trading should be to increase the amount of crypto-capital you have, not fiat capital. The global economy could very well divert to operating exclusively in cryptocurrency, making fiat obsolete. But again that is simply speculation. If you don't feel comfortable trading or it just isn't your thing, just buy and hold. And while you're holding, learn how to trade.
TLDR: That's one small step for man....
submitted by alohacrypto to Tronix [link] [comments]

Quick calculation: Cost of bringing the Bitcoin network to a halt.

Facts:
So with this data, let's do some calculations:
Future internet money!
BONUS 1: Many miners will accept transactions with less fees or no fees at all, bringing the cost down.
BONUS 2: GHash.io (50% hashrate) and other pools like Slush are now limiting the blocksize to 340KBs, making the attack 3 times cheaper.
BONUS 3: The core devs are planning to reduce the fees to 10% of what they are now, therefore making the attack 10 times cheaper.
submitted by satoshibe_nakamoto to Buttcoin [link] [comments]

Back to the game!

This is a somewhat long story.
I started with BTC around 2012, first as a curious, then by joining Slush Pool with GPU mining. It was a good time to mine with CPU/GPU, and I could get around 1.0 BTC. It was that time when the block erupters arrived, and ASICS were still at design level. I crawled through faucets getting some satoshis, played a lot of Satoshidice, and finally discovered the first Exchange in Brazil (will not ad them here, even though I still trade with them).
Then, on July 2013 I had a little bit less than 3 BTC, when I saw at bitcointalk.org [https://bitcointalk.org/index.php?topic=252180.0;imode] what was to become my doom: a guy(?) called vdragon was selling a batch of BTC Erupters. Those provided more hash power than what I had, with less energy consumption. Lots of other guys were jumping the bandwagon, and I decided to do the same. I "bought" 3 pieces, with a total amount of 2.67 BTC which I calculated would be returned with the new mining power within a couple of months. vdragon was trading them at the market price, and trades like this were happening all the time at the forum.
Needless to say all of us who bought the erupters never received them. We opened a thread on the SCAM forum of bitcointalk.org, but it never went further than it. Some investigations pinned vdragon in either England or Germany, but police couldn't do anything else due to lack of evidence and BTC anonymity.
After this, I exchanged part of the BTC I had left, keeping only a few cents (0,027 BTC - I don't really know why). I shut down my fill node, and kept following on the news, but the mere fact of remembering I was stupid enough to blindly trust someone without previous research kept me away of the BTC scene.
Until last month, at least, when I checked the exchange rate between BTC and BRL. I remembered I had a wallet.dat file, and spent 3 weeks trying every password I have used in my life, until I finally found the correct password. Those 0.027 covered all my losses, and suddenly I saw myself HODLing again. I've watched as much Andreas' videos as possible, read "Mastering Bitcoin" on Github (paper version is on the way), bought a few more cents, installed Mycelium and transferred those 0.027 there. Also, my full node is back online and I'm setting a LN daemon as well.
With this amount, I'm trying my best to disseminate the technology to friends and colleagues, and I can proudly say that since last week there are at least 30 new adopters in the city I live, with much more to come. The most interesting part of the story for those who heard me is when I tell them I was fooled, but this fact didn't affected my belief in the technology and its potential.
I'm back to the game!
TL;DR: Lost 2.67 BTC in a scam, left the community for 4 years, and returned after overcoming the shame of being fooled, influencing people in my city.
submitted by andrelam to Bitcoin [link] [comments]

An objective score for Bitcoin mining decentralization (and other cryptos)

The Herfindahl index can be applied to objectively measure how decentralized a cryptocurrency's mining infrastructure is - and to directly compare cryptos in that regard. Perhaps more interesting, though more work, would be to graph how these change over time. Has bitcoin become more or less decentralized over the years? It's actually possible to answer, but I'll leave doing so up to others.
The more mining pools there are, and the more their hash rates are evenly distributed, the more decentralized a cryptocurrency's mining economy is. This is the basis of the Herfindahl index, and we can use the reciprocal to obtain a decentralization score.
Here is the procedure, followed by results and calculations for Bitcoin, Bitcoin Cash, and Ethereum.
  1. Pick a number of blocks (N) to give you a sufficiently good estimate.
  2. For all of those blocks, identify what pool/miner mined it.
  3. For each unique pool/miner, count how many blocks they mined (n) out of the total (N), and then calculate (n/N)2 (squared market share).
  4. Sum all of these squares up to give you the Herfindahl index (H).
  5. Optionally, calculate the reciprocal (1/H). This makes the index proportional to decentralization and is IMO easier to understand in "bigger is better" terms.
Since steps 1-3 are the already used by many web stats to calculate miner hash rate proportions, you can work directly from hash rate proportions. Square each miner's proportional hash rate and add these all up to get H, then take the reciprocal.
Higher values of the reciprocal Herfindahl index indicate greater decentralization. You can directly compare these between cryptos, but be aware that the index will fluctuate over time and will exhibit some variance.
In my opinion this value is an important metric of the security of a cryptocurrency's network along with the total hash rate.
Here are the current values for a few different cryptos. Higher is better.
Bitcoin: 7.9
Bitcoin Cash: 6.0
Ethereum: 7.0
So, what is an acceptable value? That is the subjective part. I would personally suggest the current state of bitcoin is not decentralized enough, so a value of 7.9 does not satisfy me. Your own opinion may differ.
How do we tell if the above values are different enough to warrant discussion? One method is through the use of significance tests. Or, it may be sufficient to simply plot such values on a graph an examine variability over time. I leave these as exercises for others...
Raw calculations for Bitcoin:
Miner Block Count share*share BitFury 12 0.00852071 ViaBTC 12 0.00852071 BTC.top 2 0.000236686 Bixin 8 0.003786982 BW Pool 3 0.000532544 BitClub 7 0.002899408 Slush Pool 26 0.04 BTCC 13 0.01 AntPool 28 0.046390533 GBMiners 5 0.00147929 ConnectBTC 1 5.91716E-05 BTC.com 8 0.003786982 Bitcoin.com 2 0.000236686 F2Pool 3 0.000532544 TOTAL 130 Excluded Blocks 14 H 0.126982249 Decentralization 7.875116496 
Note: 14 blocks excluded with "unknown" miners.
Raw calculations for Bitcoin Cash:
Miner Block Count share*share BTC.com 31 0.046344522 AntPool 19 0.017409336 Bitcoin.com 2 0.000192901 BTC.top 25 0.030140818 ViaBTC 29 0.040557485 F2Pool 17 0.013937114 Unknown 20 0.019290123 BitClub 1 4.82253E-05 TOTAL 144 Excluded Blocks 0 H 0.167920525 Decentralization 5.955198162 
Raw calculations for Ethereum:
Miner Block Count share*share f2pool 32 0.049382716 nanopool 23 0.025511188 miningpoolhub 19 0.017409336 ethermine 28 0.037808642 0x5a0b54d5... 11 0.005835262 dwarfpool 5 0.001205633 bitclubpool 6 0.001736111 bw 9 0.00390625 ethpool 2 0.000192901 0x625a083b... 1 4.82253E-05 0xb75d1e62... 2 0.000192901 0x180ba8f7... 1 4.82253E-05 0xeba863d1... 1 4.82253E-05 0x6b4afbc4... 1 4.82253E-05 waterhole 1 4.82253E-05 0xcc4b9f07... 1 4.82253E-05 0xb435ce7c... 1 4.82253E-05 TOTAL 144 Excluded Blocks 0 H 0.143518519 Decentralization 6.967741935 
submitted by CaptainOuzo to Bitcoin [link] [comments]

42 Antminer's S7 in a garage or Minining contract with genesis mining?

As the title says. I'm thinking about investing in 15000 USD this year and I did some research. I'm thinking of either running my own mining operation at slush pool and call it a self employment gig or just get a mining contract to get 61 Tera hashes per second and work with 2 grand a month with genesis mining. The fun part is maintaining the antminer's at home in the garage but paying electricity and such is something that I haven't calculated in yet. What's more profitable? Getting a contract or running a mining operation? All in all I will be trading the bitcoins at itbit in the end. If I get 42 antminer's and that will get me about 198.66 Th/s that sounds like a good way to go but I dunno about the electricity bill. Can anyone give some pointers of what should I do?
submitted by wayman2015 to Bitcoin [link] [comments]

Cost of voting for XT by renting mining time

Building off of the good idea that willsteel had here about how we can vote for XT by renting time on miners, I gave some thought to the cost of supporting XT through this method. Obviously if you have your own mining hardware and support XT you can do it directly, but for the rest of us, an effective way to vote is to rent hashing power that signs with the BIP101 flag. I wanted to figure out what the actual cost of voting this way is in the current market conditions, here's what I got.
Based on mining calculators, the current mining revenue from 1TH/sec averages to 0.00927BTC/day. NiceHash charges a 3% fee, and assuming you're pointed towards the slush pool, they charge a 2% fee, so you're left with 0.0088BTC. The cost of (1TH/sec) * 1day on NiceHash is currently 0.0096BTC, so for 1TH/sec*day you're losing 0.0008BTC/day, or at the current price of $226/BTC, $0.18/day. Getting to a nice round number, for a loss of $1/day, you can purchase 1/.18 = 5.56 TH/s hash rate
The total hashing power of the network is currently about 400PH/sec. So, for $1/day, the fraction of that you can purchase is 5.56 /400000= .000014 of bitcoin's hashing power, or 0.0014%.
tl;dr: using NiceHash and slush pool, you can pay 1 US dollar / day to convert 0.0014% of bitcoin's hash power to XT
submitted by medley_of_minds to bitcoinxt [link] [comments]

[Informational] [CC0] Maslow's Hierarchy of Coins

Hierarchical Deterministic Wallets

Bitcoin Wallets generate and store the private keys that control a user's funds. These keys are simply random numbers, chosen by the wallet from a range of numbers so vast that it is essentially impossible for there to be a collision with another wallet doing the same thing. Deterministic wallets, also known as HD wallets help to simplify backing up and restoring wallets by using a random seed number to deterministically generate all of a wallet's private keys.

Private Key Backups

Whenever a Bitcoin user receives funds, they need a new private key. This means that the set of numbers that are important to store and back up is increasing indefinitely. In the original Bitcoin wallet, this required refreshing a back-up with a new one every time a user received funds.
Over time, Bitcoin grew more valuable and this burden of security grew more tiresome and costly. To address the issue Satoshi Nakamoto in October of 2010 released Bitcoin version 0.3.14 which contained a key pool feature. This feature automatically pre-generated a set of keys, to remain in abeyance for the user's next receipt of funds. This made backing up a much less frequent necessity, only being necessary after key pool exhaustion.
Over the following years, many other methods of improving key backups were tried. A popular concept of a paper wallet arose: printing a private key onto paper to store in a secure location. However this concept fell out of favor as being too complicated, vulnerable to printer information leaks, and encouraging address re-use.

Type 1 Deterministic Wallets

In August of 2011 Mike Caldwell sought to simplify and streamline the process of managing a collection of private keys. He created a Windows application called Bitcoin Address Utility that used a single random pass-phrase to deterministically create private keys from a single seed: essentially choosing one random number and then feeding it into a formula that would always produce more random numbers from the starting one.
This created a much easier way to backup private keys: simply secure the original random seed and restoring becomes a simple exercise of running the seed through the algorithm again.

Type 2 Deterministic Wallets

Mike Caldwell's Type 1 deterministic wallet design was based on a simple scheme that had a significant limitation: to receive funds with a Type 1 wallet required also having access to the private keys that could spend them. In situations such as merchant scripts or exchange wallets, this represented a security issue.
Before Mike Caldwell published his Type 1 wallet, in June of 2011 Greg Maxwell had already outlined a theoretical improvement to the Type 1 scheme, in which the public and private key generation might be separated to improve the security of stored funds. In Greg's outlined Type 2 scheme, a script could use what is called a master public key to generate new addresses, without ever being able to spend those funds.
In February of 2012, Pieter Wuille came up with a formalization and standardized version of this concept, in BIP 32. A surge of wallet development activity followed the deterministic wallet concept. Since the master seed behind the wallet may be represented as a simple series of twelve words, it was widely considered to be the superior method for Bitcoin wallet private key generation.
Alan Reiner was the first to implement a Type 2 seed in Armory Wallet, and helped give feedback to the BIP 32 formalization. Since then, every major wallet has moved to support the feature.

BIP 44 Deterministic Wallets

After BIP 32, development of Type 2 deterministic wallets progressed to a state where additional features and standardization was sought to be defined. In April of 2014 Marek Palatinus, also known as Slush, and Pavol Rusnak, Slush's employee at his company SatoshiLabs, sought to advance the state of deterministic wallets by adapting advancements in their own Type 2 hardware wallet Trezor into a standard they authored in BIP 44.
Features promoted by the BIP 44 standard included a mechanism for internal pass-phrase protected accounts inside of a wallet seed, a standard for using the wallet seed across multiple chains, such as for Bitcoin Testnet, and an increased standardization of gap limits and change address separation.

Deterministic Wallet Caveats

Despite the huge improvement in the state of Bitcoin technology that HD wallets represent, there are some outstanding issues and drawbacks or gotchas that may present difficulties.
Deterministic wallets generally present users with a dictionary derived random pass-phrase that actually represents a master seed number in a form that is easier for humans to deal with. But this ease-of-use has sometimes tempted developers into allowing users to set their own pass-phrase, a very bad idea. Users are extremely bad at choosing a properly random pass-phrase, and this behavior can lead to loss of funds. For this reason, all well-maintained wallets have ceased the practice of encouraging users to invent their own pass-phrases.
Another issue that sometimes confronts users in unexpected ways is that the seeds created by deterministic wallets should not be shared between wallets from different software projects. The reason for this is that the standard for deterministic wallets is generally not actually adopted by all wallets, or there are still areas left unspecified. Due to these small differences, seeds may superficially appear to be share-able between wallets, but in actuality leave some coins difficult to access from the non-originating wallet. To switch between deterministic wallets, the best practice recommendation is to initiate fund transfers on the Blockchain.
From a security and privacy perspective, under normal circumstances a deterministic wallet is just as good as a wallet in which random keys are individually generated. However use of the public master key can prove the exception to that rule. Although it is called a public master key, for privacy reasons it should not be shared publicly, as it can link all wallet addresses together. Another important reason it should not be shared is that if a single private key derived from the private seed is leaked and the public master key is also known, all the other private keys may be derived as well. This type of theft is quite uncommon, but for these reasons it is strongly recommended that the master public key still be treated as guarded information.
One practice that must differ between using an individually generated wallet and a deterministic wallet is the practice of creating addresses that are never used. HD wallets have a key implementation detail in the way that they calculate wallet balances: they go through their deterministic algorithm sequentially to determine if each private key has been used, stopping when no further activity is detected. This is a critical optimization, an HD wallet cannot scan endlessly or know automatically all of its balance information without individual queries. To provide a safety margin, HD wallets use something called a gap limit, which represents the number of keys checked that have no activity before the balance query will cease its sequential checking. This gap limit can means that creating many addresses that are never used is a bad practice and can lead to users mistakenly believing their funds have been lost, if more unused addresses are created beyond the gap limit safety margin.
A powerful feature of BIP 44 HD wallets is the internal pass phrase account system. This feature addresses a common security concern amongst people who worry about keeping their seed backups secure from theft: it adds an internal password to the stored seed. The feature also powers another use-case, a scenario in which the owner is confronted with the seed and forced to give access to it. As a precautionary measure, the owner may create a red-herring pass phrase and a real pass-phrase, pretending that the red-herring phrase contains the entirety of the funds when forced to open the wallet under duress. But with this power also comes risk deriving from any situation where users choose pass phrases to remember. Human generated pass phrases should generally be considered weak: a brute-force attack can most often bypass them. And memorized pass phrases can be easily forgotten, leading to an annoying situation where funds are temporarily inaccessible, or if a truly strong pass-phrase has been chosen, permanently lost.
submitted by pb1x to writingforbitcoin [link] [comments]

Slush's or general pool application request: Andriod

Hello,
New miner here and looking for the best app (paid or free) to download to mah HTC One so I can monitor and calculate various things. The currently downloaded applications I have are:
Any advice?
submitted by Sl0anage to BitcoinMining [link] [comments]

BITCOIN Mining Tutorial how to mine bitcoins slush's pool - what is needed to mine bitcoin What Do YOU Need to MINE ONE BITCOIN In 2020?! - YouTube Is Bitcoin Dead Best Bitcoin Client

SlushPool.com Bitcoin Wallet with balance chart. 0.00016% of all coins: Received: count: 29614. first: 2014-09-27 11:19:33 UTC Bitcoin Mining Difficulty: It refers to the mining difficulty of bitcoin which is adjusted after every 2016 blocks in order to make bitcoin block generation time 10 minutes. It usually changes only when bitcoin network total hash power increase or decrease due to joining or leaving of the bitcoin network by miners. The current bitcoin difficulty is 15.78T (at the time of writing) where it ... Accurate Bitcoin mining calculator trusted by millions of cryptocurrency miners since May 2013 - developed by an OG Bitcoin miner looking to maximize on mining profits and calculate ROI for new ASIC miners. Updated in 2020, the newest version of the Bitcoin mining calculator makes it simple and easy to quickly calculate mining profitability for your Bitcoin mining hardware. Mining. For optimal performance keep mining 24/7. See following article to know how to set up mining in Slush's pool.. Expected reward. You can use online calculator to determine how much can be made with your mining hardware. Just insert hash rate of your miner and get your approximate reward. Durch Bitcoins Mining können Sie Einheiten der virtuellen Bitcoin-Währung erhalten. Mit entsprechendem finanziellen Aufwand kann so jeder Computer-Besitzer nebenbei Geld verdienen. Wie das geht und was Sie dabei beachten sollten, erklären wir Ihnen in unserem Ratgeber.

[index] [39864] [19845] [40842] [20107] [11145] [11165] [14769] [24832] [10928] [20696]

BITCOIN Mining Tutorial

For more info concerning bitcoin paper wallet, please visit site here: http://www.cryptocoinwalletcards.com/ Tags: asic bitcoin miner, asic bitcoin miner ava... For more info regarding bitcoin paper wallet, please visit web site below: http://www.cryptocoinwalletcards.com/ Tags: asic bitcoin miner, asic bitcoin miner... ANTMINER S7 with SLUSH POOL PAYOUT - Duration: 1:34. CALI CRYPTO 8,208 views. 1:34. ... BITCOIN MINING in Deutschland Profitabel?💰Rechnung und Erklärung - Duration: 15:15. Chris Rzepka 89,153 ... For more info concerning Bitcoin wallet card, litecoin wallet card, please visit site right here: http://www.cryptocoinwalletcards.com/ Tags: asic bitcoin mi... bitcoin mining calculator bitcoin farm bitcoins mining bitcoin machine scrypt miner bitmine bitcoin mining computer scrypt mining best bitcoin miner gpu mining bitcoin mining rig bitcoin mining ...

#