9 Profitable BitCoin Cloud Mining Contracts And Services
8 Best Bitcoin & Cryptocurrency Mining Contracts
Minimum Viable Issuance - Why Ethereum’s lack of a hard cap on ETH issuance is a good thing.
This post will explain how the argument used by the average Bitcoin maximalist, thinking that they have found Ethereum’s achilles heel when talking about issuance is actually highlighting one of Ethereum’s strong points and one of the main threats to the longevity of the Bitcoin network. So first let’s answer the question which I know many people have about Ethereum:
What is Ethereum’s ETH issuance schedule?
Ethereum has an issuance policy of Minimum Viable Issuance. So what does this mean exactly? It means that the issuance of ETH will be as low as possible while also maintaining a sufficient budget to pay miners (and soon to be stakers) to keep the network secure. For example, if ETH issuance was halved, miners would drop off the network and stop mining as it is no longer profitable for them to mine. As a result, the network would be less secure as it would cost less money for an attacker to control 51% of the hash power and attack the network. This means that the Ethereum community plans to change ETH issuance as time goes on to maintain a reasonable security budget which will keep the network secure but will also keep inflation in check. We have done this twice in the past with EIP-649 and EIP-1234 which reduced block rewards from 5 ETH per block to 3 ETH and from 3 ETH to 2 ETH respectively. I previously made a graph of ETH issuance over time here: https://redd.it/it8ce7 So while Ethereum doesn’t have a strictly defined issuance schedule, the community will reject any proposals which either put the security of the network at risk such as the recent EIP-2878, or we will reject proposals which will lead to excessive network security and therefore an unnecessarily high inflation rate (or we will accept proposals which reduce issuance after price rises and therefore the security budget rises). This means that when Bitcoiners accuse the Ethereum Foundation of being no better than a central bank because they can “print more Ether”, this is completely untrue. Any proposals made by the EF which would increase issuance unnecessarily would be rejected by the community in the same way that a proposal to increase the supply of Bitcoin from 21 million to 22 million would be rejected. There is a social contract around both Bitcoin’s and Ethereum’s issuance schedules. Any networks or proposals which break the social contracts of 21 million Bitcoins and minimal viable issuance of Ether would be a breach of these contracts and the new proposed network would be labeled by the community as illegitimate and the original network would live on.
So why is minimum viable issuance better than a hard cap?
Minimum viable issuance is better than a hard cap because it puts the most important part of the network first - the security. MVI ensures that the Ethereum network will always have a security budget which keeps the cost of a 51% attack impractically high. Bitcoin on the other hand, halves its security budget every 4 years until eventually only the transaction fees pay for network security. This means that every 4 years, the amount of money paying for network security halves until eventually, the value of attacking the network becomes greater than the security budget and someone performs a 51% attack (technically the security budget only halves if terms of BTC not in dollars. However, even if the price of Bitcoin more than doubles in the time that the security budget halves, the ratio of security budget to value secured on the network still halves, doubling the financial viability of performing a network attack). The strategy to pay for the security budget once Bitcoin issuance stops is for transaction fees to secure the network since transaction fees are paid to miners. Not only does this have its own security problems which I won’t detail here, but unless Bitcoin scales on layer 1 (layer 2 scaling solutions have their own security mechanisms separate from L1), then fees would have to cost well in the thousands of dollars to secure a trillion dollar market cap Bitcoin that is secured by nothing but fees. If Bitcoin maximalists want a 10 trillion or 100 trillion dollar market cap then expect fees to go up another 10 or 100 times from there. Ethereum on the other hand, will be able to keep its network secure with approximately 1-2% annual issuance being paid to stakers under ETH 2.0. This is because not all of the network will be staking, so if 33 million of the approximately 110 million Ether in existence stakes under ETH 2.0, then paying this 33 million Ether 6% a year (a very decent yield!) would cost just under 2 million ETH per year which would equate to less than 2% annual ETH inflation. This is also before considering EIP-1559 which will burn a portion of transaction fees which will counter the effect of this inflation and potentially even make ETH deflationary if the sum of all burned transaction fees are greater than the annual inflation. Also, under ETH 2.0, an attacker performing a 51% attack would get his funds slashed (they would lose their funds) if they attack the network, meaning that they can only perform a 51% attack once. However, in Bitcoin, anyone who controls 51% of the mining hash power could perform multiple 51% attacks without losing everything like they could in ETH 2.0. So in conclusion, while Ethereum doesn’t have the guaranteed anti-inflation security of a hard cap, it does have the guarantee of always paying it’s miners (or stakers under ETH 2.0) enough to keep the network secure. In contrast, while Bitcoin’s social contract may guarantee a hard cap of 21 million, it cannot simultaneously guarantee network security in the long run. Eventually, its users will have to decide if they want a secure network with more than 21 million coins or a tax to pay for security or an insecure network with super high fees and a hard cap of 21 million Bitcoin. Disclaimer:The details I covered around 51% attacks and network security are simplified. I am not an expert in this field and things are a lot more nuanced than I laid out in my simplifications above.
u/deadbeat1000 totally saw the denial of Craig's Motion for Summary Judgment coming
In this post I'm going to go through a selections of quotations from our dear friend u/deadbeat1000 on this score: First his most recent one where he echoes the rationalisation in the latest Coingeek article on this and says:
This really comes as no surprise.
So clearly he saw this coming, right? He didn't make a bunch of comments several months back where he seemed certain Craig was going to win this motion? Let's find out. This quote doesn't look good (my emphasis added):
W&K was formed by CSW's wife, Lynn Wright and Dave in order to enable them to bid on government contracts having nothing to do with mining Bitcoin. And W&K was formed not at a "partnership" but as a Limited Liability Corporation (LLC). Therefore, it really should be about shares in a corporation and a corporate structure not an assumed "50:50" partnership. In a corporation there are voting rights and thus before Ira could sue CSW on behalf of W&K, there would have to be a vote by the shareholders. In this case Lynn & Ira as CSW relinquished his stake in the company during his divorce. In other words, Lynn is alleging that Ira has violated W&K legal structure and corporate governance. She was never informed, consulted, and voted on Ira's suit on behalf of W&K as the majority shareholder of W&K. This blows Ira whole case as he is actually committing fraud by misrepresenting his authority on behalf of W&K to bring suit against CSW. Actually it also reflects on Velvel Freeman as yet another shyster lawyer who looks to use the courts as a shakedown proxy. This case should have never been brought and it also reflects badly on Reinhart who should have dismissed this case just from demanding the legal paperwork of the corporate structure of W&K.
I'm about ready to revoke your account on this board because you are acting like an ass. This is a legal matter and there is settled law about business legal structures. W&K is a corporation and as a corporation all revenue is owned by the corporation and not the individuals. Lynn Wright is the majority shareholder of W&K and she is the one who gets to decide the disposition of W&K via her controlling interest.
It looks like Ira has some explaining to do. Isn't ironic how the trolls scrutinize every utterance of CSW but never took the time to examine Ira's behavior. And worst yet is the court for not even demanding the business filings that are on file with the Secretary of State of the State of Florida. This whole case has been a travesty from the start designed as a shakedown and should have been thrown out immediately by the Magistrate. What they managed to do was to get CSW to fork over $135,000.00 USD for a process "error" that wasn't even of his own making but due to Reinhart & Freedman's ignorance of Bitcoin. The dilettantes and the mediocre are truly in charge.
Looks like Ira doesn't have any explaining to do as the claim was thrown out. Don't worry deadbeat, you're not alone in being blind-sided like this. Calvin was too, and he's footing the bill for his sugar-baby Craig because were he not these legal bills these overworked lawyers are charging as they try to save Craig from his own web of lies would be too onerous for poor Craig. You'd think these people who saw this coming might have given at least him a head's up given his financial involvement in the case.
https://github.com/gridcoin-community/Gridcoin-Research/releases/tag/18.104.22.168 Finally! After over ten months of development and testing, "Fern" has arrived! This is a whopper. 240 pull requests merged. Essentially a complete rewrite that was started with the scraper (the "neural net" rewrite) in "Denise" has now been completed. Practically the ENTIRE Gridcoin specific codebase resting on top of the vanilla Bitcoin/Peercoin/Blackcoin vanilla PoS code has been rewritten. This removes the team requirement at last (see below), although there are many other important improvements besides that. Fern was a monumental undertaking. We had to encode all of the old rules active for the v10 block protocol in new code and ensure that the new code was 100% compatible. This had to be done in such a way as to clear out all of the old spaghetti and ring-fence it with tightly controlled class implementations. We then wrote an entirely new, simplified ruleset for research rewards and reengineered contracts (which includes beacon management, polls, and voting) using properly classed code. The fundamentals of Gridcoin with this release are now on a very sound and maintainable footing, and the developers believe the codebase as updated here will serve as the fundamental basis for Gridcoin's future roadmap. We have been testing this for MONTHS on testnet in various stages. The v10 (legacy) compatibility code has been running on testnet continuously as it was developed to ensure compatibility with existing nodes. During the last few months, we have done two private testnet forks and then the full public testnet testing for v11 code (the new protocol which is what Fern implements). The developers have also been running non-staking "sentinel" nodes on mainnet with this code to verify that the consensus rules are problem-free for the legacy compatibility code on the broader mainnet. We believe this amount of testing is going to result in a smooth rollout. Given the amount of changes in Fern, I am presenting TWO changelogs below. One is high level, which summarizes the most significant changes in the protocol. The second changelog is the detailed one in the usual format, and gives you an inkling of the size of this release.
Note that the protocol changes will not become active until we cross the hard-fork transition height to v11, which has been set at 2053000. Given current average block spacing, this should happen around October 4, about one month from now. Note that to get all of the beacons in the network on the new protocol, we are requiring ALL beacons to be validated. A two week (14 day) grace period is provided by the code, starting at the time of the transition height, for people currently holding a beacon to validate the beacon and prevent it from expiring. That means that EVERY CRUNCHER must advertise and validate their beacon AFTER the v11 transition (around Oct 4th) and BEFORE October 18th (or more precisely, 14 days from the actual date of the v11 transition). If you do not advertise and validate your beacon by this time, your beacon will expire and you will stop earning research rewards until you advertise and validate a new beacon. This process has been made much easier by a brand new beacon "wizard" that helps manage beacon advertisements and renewals. Once a beacon has been validated and is a v11 protocol beacon, the normal 180 day expiration rules apply. Note, however, that the 180 day expiration on research rewards has been removed with the Fern update. This means that while your beacon might expire after 180 days, your earned research rewards will be retained and can be claimed by advertising a beacon with the same CPID and going through the validation process again. In other words, you do not lose any earned research rewards if you do not stake a block within 180 days and keep your beacon up-to-date. The transition height is also when the team requirement will be relaxed for the network.
Besides the beacon wizard, there are a number of improvements to the GUI, including new UI transaction types (and icons) for staking the superblock, sidestake sends, beacon advertisement, voting, poll creation, and transactions with a message. The main screen has been revamped with a better summary section, and better status icons. Several changes under the hood have improved GUI performance. And finally, the diagnostics have been revamped.
The wallet sync speed has been DRASTICALLY improved. A decent machine with a good network connection should be able to sync the entire mainnet blockchain in less than 4 hours. A fast machine with a really fast network connection and a good SSD can do it in about 2.5 hours. One of our goals was to reduce or eliminate the reliance on snapshots for mainnet, and I think we have accomplished that goal with the new sync speed. We have also streamlined the in-memory structures for the blockchain which shaves some memory use. There are so many goodies here it is hard to summarize them all. I would like to thank all of the contributors to this release, but especially thank @cyrossignol, whose incredible contributions formed the backbone of this release. I would also like to pay special thanks to @barton2526, @caraka, and @Quezacoatl1, who tirelessly helped during the testing and polishing phase on testnet with testing and repeated builds for all architectures. The developers are proud to present this release to the community and we believe this represents the starting point for a true renaissance for Gridcoin!
Most significantly, nodes calculate research rewards directly from the magnitudes in EACH superblock between stakes instead of using a two- or three- point average based on a CPID's current magnitude and the magnitude for the CPID when it last staked. For those long-timers in the community, this has been referred to as "Superblock Windows," and was first done in proof-of-concept form by @denravonska.
Network magnitude unit pinned to a static value of 0.25
Max research reward allowed per block raised to 16384 GRC (from 12750 GRC)
New CPIDs begin accruing research rewards from the first superblock that contains the CPID instead of from the time of the beacon advertisement
500 GRC research reward limit for a CPID's first stake
6-month expiration for unclaimed rewards
10-block spacing requirement between research reward claims
Rolling 5-day payment-per-day limit
Legacy tolerances for floating-point error and time drift
The need to include a valid copy of a CPID's magnitude in a claim
10-block emission adjustment interval for the magnitude unit
One-time beacon activation requires that participants temporarily change their usernames to a verification code at one whitelisted BOINC project
Verification codes of pending beacons expire after 3 days
Self-service beacon removal
Burn fee for beacon advertisement increased from 0.00001 GRC to 0.5 GRC
Rain addresses derived from beacon keys instead of a default wallet address
Beacon expiration determined as of the current block instead of the previous block
The ability for developers to remove beacons
The ability to sign research reward claims with non-current but unexpired beacons
As a reminder:
Beacons expire after 6 months pass (180 days)
Beacons can be renewed after 5 months pass (150 days)
Renewed beacons must be signed with the same key as the original beacon
Magnitudes less than 1 include two fractional places
Magnitudes greater than or equal to 1 but less than 10 include one fractional place
A valid superblock must match a scraper convergence
Superblock popularity election mechanics
Yes/no/abstain and single-choice response types (no user-facing support yet)
To create a poll, a maximum of 250 UTXOs for a single address must add up to 100000 GRC. These are selected from the largest downwards.
Burn fee for creating polls scaled by the number of UTXOs claimed
50 GRC for a poll contract
0.001 GRC per claimed UTXO
Burn fee for casting votes scaled by the number of UTXOs claimed
0.01 GRC for a vote contract
0.01 GRC to claim magnitude
0.01 GRC per claimed address
0.001 GRC per claimed UTXO
Maximum length of a poll title: 80 characters
Maximum length of a poll question: 100 characters
Maximum length of a poll discussion website URL: 100 characters
Maximum number of poll choices: 20
Maximum length of a poll choice label: 100 characters
Magnitude, CPID count, and participant count poll weight types
The ability for developers to remove polls and votes
[22.214.171.124] 2020-09-03, mandatory, "Fern"
Backport newer uint256 types from Bitcoin #1570 (@cyrossignol)
Implement project level rain for rainbymagnitude #1580 (@jamescowens)
Upgrade utilities (Update checker and snapshot downloadeapplication) #1576 (@iFoggz)
Provide fees collected in the block by the miner #1601 (@iFoggz)
Add support for generating legacy superblocks from scraper stats #1603 (@cyrossignol)
Port of the Bitcoin Logger to Gridcoin #1600 (@jamescowens)
Implement zapwallettxes #1605 (@jamescowens)
Implements a global event filter to suppress help question mark #1609 (@jamescowens)
Add next target difficulty to RPC output #1615 (@cyrossignol)
Add caching for block hashes to CBlock #1624 (@cyrossignol)
Make toolbars and tray icon red for testnet #1637 (@jamescowens)
Add an rpc call convergencereport #1643 (@jamescowens)
Implement newline filter on config file read in #1645 (@jamescowens)
Implement beacon status icon/button #1646 (@jamescowens)
Add gridcointestnet.png #1649 (@caraka)
Add precision to support magnitudes less than 1 #1651 (@cyrossignol)
Replace research accrual calculations with superblock snapshots #1657 (@cyrossignol)
Publish example gridcoinresearch.conf as a md document to the doc directory #1662 (@jamescowens)
Add options checkbox to disable transaction notifications #1666 (@jamescowens)
Add support for self-service beacon deletion #1695 (@cyrossignol)
Add support for type-specific contract fee amounts #1698 (@cyrossignol)
Add verifiedbeaconreport and pendingbeaconreport #1696 (@jamescowens)
Add preliminary testing option for block v11 height on testnet #1706 (@cyrossignol)
Add verified beacons manifest part to superblock validator #1711 (@cyrossignol)
Implement beacon, vote, and superblock display categories/icons in UI transaction model #1717 (@jamescowens)