Best Bitcoin Cloud Mining Contract Reviews and Comparisons

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.
submitted by Tricky_Troll to ethfinance [link] [comments]

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.
Oof, this blows the whole case out of the water huh? That seems pretty bullish about the effectiveness of Lynn Wright's claim to be a member of W&K, a claim Judge Bloom has just thrown out.
Deadbeat threatens to ban someone for not agreeing with him about Lynn Wright's baseless claim to be a member of W&K, this is so certain and obvious in his mind that disagreement is a ban-worthy offence:
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.
This post:
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.
submitted by Zectro to bsv [link] [comments]

Gridcoin 5.0.0.0-Mandatory "Fern" Release

https://github.com/gridcoin-community/Gridcoin-Research/releases/tag/5.0.0.0
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.

Highlights

Protocol

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.

GUI

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.

Blockchain

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!

Summary Changelog

Accrual

Changed

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.

Removed

Beacons

Added

Changed

Removed

Unaltered

As a reminder:

Superblocks

Added

Changed

Removed

Voting

Added

Changed

Removed

Detailed Changelog

[5.0.0.0] 2020-09-03, mandatory, "Fern"

Added

Changed

Removed

Fixed

submitted by jamescowens to gridcoin [link] [comments]

Dragonchain Great Reddit Scaling Bake-Off Public Proposal

Dragonchain Great Reddit Scaling Bake-Off Public Proposal

Dragonchain Public Proposal TL;DR:

Dragonchain has demonstrated twice Reddit’s entire total daily volume (votes, comments, and posts per Reddit 2019 Year in Review) in a 24-hour demo on an operational network. Every single transaction on Dragonchain is decentralized immediately through 5 levels of Dragon Net, and then secured with combined proof on Bitcoin, Ethereum, Ethereum Classic, and Binance Chain, via Interchain. At the time, in January 2020, the entire cost of the demo was approximately $25K on a single system (transaction fees locked at $0.0001/txn). With current fees (lowest fee $0.0000025/txn), this would cost as little as $625.
Watch Joe walk through the entire proposal and answer questions on YouTube.
This proposal is also available on the Dragonchain blog.

Hello Reddit and Ethereum community!

I’m Joe Roets, Founder & CEO of Dragonchain. When the team and I first heard about The Great Reddit Scaling Bake-Off we were intrigued. We believe we have the solutions Reddit seeks for its community points system and we have them at scale.
For your consideration, we have submitted our proposal below. The team at Dragonchain and I welcome and look forward to your technical questions, philosophical feedback, and fair criticism, to build a scaling solution for Reddit that will empower its users. Because our architecture is unlike other blockchain platforms out there today, we expect to receive many questions while people try to grasp our project. I will answer all questions here in this thread on Reddit, and I've answered some questions in the stream on YouTube.
We have seen good discussions so far in the competition. We hope that Reddit’s scaling solution will emerge from The Great Reddit Scaling Bake-Off and that Reddit will have great success with the implementation.

Executive summary

Dragonchain is a robust open source hybrid blockchain platform that has proven to withstand the passing of time since our inception in 2014. We have continued to evolve to harness the scalability of private nodes, yet take full advantage of the security of public decentralized networks, like Ethereum. We have a live, operational, and fully functional Interchain network integrating Bitcoin, Ethereum, Ethereum Classic, and ~700 independent Dragonchain nodes. Every transaction is secured to Ethereum, Bitcoin, and Ethereum Classic. Transactions are immediately usable on chain, and the first decentralization is seen within 20 seconds on Dragon Net. Security increases further to public networks ETH, BTC, and ETC within 10 minutes to 2 hours. Smart contracts can be written in any executable language, offering full freedom to existing developers. We invite any developer to watch the demo, play with our SDK’s, review open source code, and to help us move forward. Dragonchain specializes in scalable loyalty & rewards solutions and has built a decentralized social network on chain, with very affordable transaction costs. This experience can be combined with the insights Reddit and the Ethereum community have gained in the past couple of months to roll out the solution at a rapid pace.

Response and PoC

In The Great Reddit Scaling Bake-Off post, Reddit has asked for a series of demonstrations, requirements, and other considerations. In this section, we will attempt to answer all of these requests.

Live Demo

A live proof of concept showing hundreds of thousands of transactions
On Jan 7, 2020, Dragonchain hosted a 24-hour live demonstration during which a quarter of a billion (250 million+) transactions executed fully on an operational network. Every single transaction on Dragonchain is decentralized immediately through 5 levels of Dragon Net, and then secured with combined proof on Bitcoin, Ethereum, Ethereum Classic, and Binance Chain, via Interchain. This means that every single transaction is secured by, and traceable to these networks. An attack on this system would require a simultaneous attack on all of the Interchained networks.
24 hours in 4 minutes (YouTube):
24 hours in 4 minutes
The demonstration was of a single business system, and any user is able to scale this further, by running multiple systems simultaneously. Our goals for the event were to demonstrate a consistent capacity greater than that of Visa over an extended time period.
Tooling to reproduce our demo is available here:
https://github.com/dragonchain/spirit-bomb

Source Code

Source code (for on & off-chain components as well tooling used for the PoC). The source code does not have to be shared publicly, but if Reddit decides to use a particular solution it will need to be shared with Reddit at some point.

Scaling

How it works & scales

Architectural Scaling

Dragonchain’s architecture attacks the scalability issue from multiple angles. Dragonchain is a hybrid blockchain platform, wherein every transaction is protected on a business node to the requirements of that business or purpose. A business node may be held completely private or may be exposed or replicated to any level of exposure desired.
Every node has its own blockchain and is independently scalable. Dragonchain established Context Based Verification as its consensus model. Every transaction is immediately usable on a trust basis, and in time is provable to an increasing level of decentralized consensus. A transaction will have a level of decentralization to independently owned and deployed Dragonchain nodes (~700 nodes) within seconds, and full decentralization to BTC and ETH within minutes or hours. Level 5 nodes (Interchain nodes) function to secure all transactions to public or otherwise external chains such as Bitcoin and Ethereum. These nodes scale the system by aggregating multiple blocks into a single Interchain transaction on a cadence. This timing is configurable based upon average fees for each respective chain. For detailed information about Dragonchain’s architecture, and Context Based Verification, please refer to the Dragonchain Architecture Document.

Economic Scaling

An interesting feature of Dragonchain’s network consensus is its economics and scarcity model. Since Dragon Net nodes (L2-L4) are independent staking nodes, deployment to cloud platforms would allow any of these nodes to scale to take on a large percentage of the verification work. This is great for scalability, but not good for the economy, because there is no scarcity, and pricing would develop a downward spiral and result in fewer verification nodes. For this reason, Dragonchain uses TIME as scarcity.
TIME is calculated as the number of Dragons held, multiplied by the number of days held. TIME influences the user’s access to features within the Dragonchain ecosystem. It takes into account both the Dragon balance and length of time each Dragon is held. TIME is staked by users against every verification node and dictates how much of the transaction fees are awarded to each participating node for every block.
TIME also dictates the transaction fee itself for the business node. TIME is staked against a business node to set a deterministic transaction fee level (see transaction fee table below in Cost section). This is very interesting in a discussion about scaling because it guarantees independence for business implementation. No matter how much traffic appears on the entire network, a business is guaranteed to not see an increased transaction fee rate.

Scaled Deployment

Dragonchain uses Docker and Kubernetes to allow the use of best practices traditional system scaling. Dragonchain offers managed nodes with an easy to use web based console interface. The user may also deploy a Dragonchain node within their own datacenter or favorite cloud platform. Users have deployed Dragonchain nodes on-prem on Amazon AWS, Google Cloud, MS Azure, and other hosting platforms around the world. Any executable code, anything you can write, can be written into a smart contract. This flexibility is what allows us to say that developers with no blockchain experience can use any code language to access the benefits of blockchain. Customers have used NodeJS, Python, Java, and even BASH shell script to write smart contracts on Dragonchain.
With Docker containers, we achieve better separation of concerns, faster deployment, higher reliability, and lower response times.
We chose Kubernetes for its self-healing features, ability to run multiple services on one server, and its large and thriving development community. It is resilient, scalable, and automated. OpenFaaS allows us to package smart contracts as Docker images for easy deployment.
Contract deployment time is now bounded only by the size of the Docker image being deployed but remains fast even for reasonably large images. We also take advantage of Docker’s flexibility and its ability to support any language that can run on x86 architecture. Any image, public or private, can be run as a smart contract using Dragonchain.

Flexibility in Scaling

Dragonchain’s architecture considers interoperability and integration as key features. From inception, we had a goal to increase adoption via integration with real business use cases and traditional systems.
We envision the ability for Reddit, in the future, to be able to integrate alternate content storage platforms or other financial services along with the token.
  • LBRY - To allow users to deploy content natively to LBRY
  • MakerDAO to allow users to lend small amounts backed by their Reddit community points.
  • STORJ/SIA to allow decentralized on chain storage of portions of content. These integrations or any other are relatively easy to integrate on Dragonchain with an Interchain implementation.

Cost

Cost estimates (on-chain and off-chain) For the purpose of this proposal, we assume that all transactions are on chain (posts, replies, and votes).
On the Dragonchain network, transaction costs are deterministic/predictable. By staking TIME on the business node (as described above) Reddit can reduce transaction costs to as low as $0.0000025 per transaction.
Dragonchain Fees Table

Getting Started

How to run it
Building on Dragonchain is simple and requires no blockchain experience. Spin up a business node (L1) in our managed environment (AWS), run it in your own cloud environment, or on-prem in your own datacenter. Clear documentation will walk you through the steps of spinning up your first Dragonchain Level 1 Business node.
Getting started is easy...
  1. Download Dragonchain’s dctl
  2. Input three commands into a terminal
  3. Build an image
  4. Run it
More information can be found in our Get started documents.

Architecture
Dragonchain is an open source hybrid platform. Through Dragon Net, each chain combines the power of a public blockchain (like Ethereum) with the privacy of a private blockchain.
Dragonchain organizes its network into five separate levels. A Level 1, or business node, is a totally private blockchain only accessible through the use of public/private keypairs. All business logic, including smart contracts, can be executed on this node directly and added to the chain.
After creating a block, the Level 1 business node broadcasts a version stripped of sensitive private data to Dragon Net. Three Level 2 Validating nodes validate the transaction based on guidelines determined from the business. A Level 3 Diversity node checks that the level 2 nodes are from a diverse array of locations. A Level 4 Notary node, hosted by a KYC partner, then signs the validation record received from the Level 3 node. The transaction hash is ledgered to the Level 5 public chain to take advantage of the hash power of massive public networks.
Dragon Net can be thought of as a “blockchain of blockchains”, where every level is a complete private blockchain. Because an L1 can send to multiple nodes on a single level, proof of existence is distributed among many places in the network. Eventually, proof of existence reaches level 5 and is published on a public network.

API Documentation

APIs (on chain & off)

SDK Source

Nobody’s Perfect

Known issues or tradeoffs
  • Dragonchain is open source and even though the platform is easy enough for developers to code in any language they are comfortable with, we do not have so large a developer community as Ethereum. We would like to see the Ethereum developer community (and any other communities) become familiar with our SDK’s, our solutions, and our platform, to unlock the full potential of our Ethereum Interchain. Long ago we decided to prioritize both Bitcoin and Ethereum Interchains. We envision an ecosystem that encompasses different projects to give developers the ability to take full advantage of all the opportunities blockchain offers to create decentralized solutions not only for Reddit but for all of our current platforms and systems. We believe that together we will take the adoption of blockchain further. We currently have additional Interchain with Ethereum Classic. We look forward to Interchain with other blockchains in the future. We invite all blockchains projects who believe in decentralization and security to Interchain with Dragonchain.
  • While we only have 700 nodes compared to 8,000 Ethereum and 10,000 Bitcoin nodes. We harness those 18,000 nodes to scale to extremely high levels of security. See Dragonchain metrics.
  • Some may consider the centralization of Dragonchain’s business nodes as an issue at first glance, however, the model is by design to protect business data. We do not consider this a drawback as these nodes can make any, none, or all data public. Depending upon the implementation, every subreddit could have control of its own business node, for potential business and enterprise offerings, bringing new alternative revenue streams to Reddit.

Costs and resources

Summary of cost & resource information for both on-chain & off-chain components used in the PoC, as well as cost & resource estimates for further scaling. If your PoC is not on mainnet, make note of any mainnet caveats (such as congestion issues).
Every transaction on the PoC system had a transaction fee of $0.0001 (one-hundredth of a cent USD). At 256MM transactions, the demo cost $25,600. With current operational fees, the same demonstration would cost $640 USD.
For the demonstration, to achieve throughput to mimic a worldwide payments network, we modeled several clients in AWS and 4-5 business nodes to handle the traffic. The business nodes were tuned to handle higher throughput by adjusting memory and machine footprint on AWS. This flexibility is valuable to implementing a system such as envisioned by Reddit. Given that Reddit’s daily traffic (posts, replies, and votes) is less than half that of our demo, we would expect that the entire Reddit system could be handled on 2-5 business nodes using right-sized containers on AWS or similar environments.
Verification was accomplished on the operational Dragon Net network with over 700 independently owned verification nodes running around the world at no cost to the business other than paid transaction fees.

Requirements

Scaling

This PoC should scale to the numbers below with minimal costs (both on & off-chain). There should also be a clear path to supporting hundreds of millions of users.
Over a 5 day period, your scaling PoC should be able to handle:
*100,000 point claims (minting & distributing points) *25,000 subscriptions *75,000 one-off points burning *100,000 transfers
During Dragonchain’s 24 hour demo, the above required numbers were reached within the first few minutes.
Reddit’s total activity is 9000% more than Ethereum’s total transaction level. Even if you do not include votes, it is still 700% more than Ethereum’s current volume. Dragonchain has demonstrated that it can handle 250 million transactions a day, and it’s architecture allows for multiple systems to work at that level simultaneously. In our PoC, we demonstrate double the full capacity of Reddit, and every transaction was proven all the way to Bitcoin and Ethereum.
Reddit Scaling on Ethereum

Decentralization

Solutions should not depend on any single third-party provider. We prefer solutions that do not depend on specific entities such as Reddit or another provider, and solutions with no single point of control or failure in off-chain components but recognize there are numerous trade-offs to consider
Dragonchain’s architecture calls for a hybrid approach. Private business nodes hold the sensitive data while the validation and verification of transactions for the business are decentralized within seconds and secured to public blockchains within 10 minutes to 2 hours. Nodes could potentially be controlled by owners of individual subreddits for more organic decentralization.
  • Billing is currently centralized - there is a path to federation and decentralization of a scaled billing solution.
  • Operational multi-cloud
  • Operational on-premises capabilities
  • Operational deployment to any datacenter
  • Over 700 independent Community Verification Nodes with proof of ownership
  • Operational Interchain (Interoperable to Bitcoin, Ethereum, and Ethereum Classic, open to more)

Usability Scaling solutions should have a simple end user experience.

Users shouldn't have to maintain any extra state/proofs, regularly monitor activity, keep track of extra keys, or sign anything other than their normal transactions
Dragonchain and its customers have demonstrated extraordinary usability as a feature in many applications, where users do not need to know that the system is backed by a live blockchain. Lyceum is one of these examples, where the progress of academy courses is being tracked, and successful completion of courses is rewarded with certificates on chain. Our @Save_The_Tweet bot is popular on Twitter. When used with one of the following hashtags - #please, #blockchain, #ThankYou, or #eternalize the tweet is saved through Eternal to multiple blockchains. A proof report is available for future reference. Other examples in use are DEN, our decentralized social media platform, and our console, where users can track their node rewards, view their TIME, and operate a business node.
Examples:

Transactions complete in a reasonable amount of time (seconds or minutes, not hours or days)
All transactions are immediately usable on chain by the system. A transaction begins the path to decentralization at the conclusion of a 5-second block when it gets distributed across 5 separate community run nodes. Full decentralization occurs within 10 minutes to 2 hours depending on which interchain (Bitcoin, Ethereum, or Ethereum Classic) the transaction hits first. Within approximately 2 hours, the combined hash power of all interchained blockchains secures the transaction.

Free to use for end users (no gas fees, or fixed/minimal fees that Reddit can pay on their behalf)
With transaction pricing as low as $0.0000025 per transaction, it may be considered reasonable for Reddit to cover transaction fees for users.
All of Reddit's Transactions on Blockchain (month)
Community points can be earned by users and distributed directly to their Reddit account in batch (as per Reddit minting plan), and allow users to withdraw rewards to their Ethereum wallet whenever they wish. Withdrawal fees can be paid by either user or Reddit. This model has been operating inside the Dragonchain system since 2018, and many security and financial compliance features can be optionally added. We feel that this capability greatly enhances user experience because it is seamless to a regular user without cryptocurrency experience, yet flexible to a tech savvy user. With regard to currency or token transactions, these would occur on the Reddit network, verified to BTC and ETH. These transactions would incur the $0.0000025 transaction fee. To estimate this fee we use the monthly active Reddit users statista with a 60% adoption rate and an estimated 10 transactions per month average resulting in an approximate $720 cost across the system. Reddit could feasibly incur all associated internal network charges (mining/minting, transfer, burn) as these are very low and controllable fees.
Reddit Internal Token Transaction Fees

Reddit Ethereum Token Transaction Fees
When we consider further the Ethereum fees that might be incurred, we have a few choices for a solution.
  1. Offload all Ethereum transaction fees (user withdrawals) to interested users as they wish to withdraw tokens for external use or sale.
  2. Cover Ethereum transaction fees by aggregating them on a timed schedule. Users would request withdrawal (from Reddit or individual subreddits), and they would be transacted on the Ethereum network every hour (or some other schedule).
  3. In a combination of the above, customers could cover aggregated fees.
  4. Integrate with alternate Ethereum roll up solutions or other proposals to aggregate minting and distribution transactions onto Ethereum.

Bonus Points

Users should be able to view their balances & transactions via a blockchain explorer-style interface
From interfaces for users who have no knowledge of blockchain technology to users who are well versed in blockchain terms such as those present in a typical block explorer, a system powered by Dragonchain has flexibility on how to provide balances and transaction data to users. Transactions can be made viewable in an Eternal Proof Report, which displays raw data along with TIME staking information and traceability all the way to Bitcoin, Ethereum, and every other Interchained network. The report shows fields such as transaction ID, timestamp, block ID, multiple verifications, and Interchain proof. See example here.
Node payouts within the Dragonchain console are listed in chronological order and can be further seen in either Dragons or USD. See example here.
In our social media platform, Dragon Den, users can see, in real-time, their NRG and MTR balances. See example here.
A new influencer app powered by Dragonchain, Raiinmaker, breaks down data into a user friendly interface that shows coin portfolio, redeemed rewards, and social scores per campaign. See example here.

Exiting is fast & simple
Withdrawing funds on Dragonchain’s console requires three clicks, however, withdrawal scenarios with more enhanced security features per Reddit’s discretion are obtainable.

Interoperability Compatibility with third party apps (wallets/contracts/etc) is necessary.
Proven interoperability at scale that surpasses the required specifications. Our entire platform consists of interoperable blockchains connected to each other and traditional systems. APIs are well documented. Third party permissions are possible with a simple smart contract without the end user being aware. No need to learn any specialized proprietary language. Any code base (not subsets) is usable within a Docker container. Interoperable with any blockchain or traditional APIs. We’ve witnessed relatively complex systems built by engineers with no blockchain or cryptocurrency experience. We’ve also demonstrated the creation of smart contracts within minutes built with BASH shell and Node.js. Please see our source code and API documentation.

Scaling solutions should be extensible and allow third parties to build on top of it Open source and extensible
APIs should be well documented and stable

Documentation should be clear and complete
For full documentation, explore our docs, SDK’s, Github repo’s, architecture documents, original Disney documentation, and other links or resources provided in this proposal.

Third-party permissionless integrations should be possible & straightforward Smart contracts are Docker based, can be written in any language, use full language (not subsets), and can therefore be integrated with any system including traditional system APIs. Simple is better. Learning an uncommon or proprietary language should not be necessary.
Advanced knowledge of mathematics, cryptography, or L2 scaling should not be required. Compatibility with common utilities & toolchains is expected.
Dragonchain business nodes and smart contracts leverage Docker to allow the use of literally any language or executable code. No proprietary language is necessary. We’ve witnessed relatively complex systems built by engineers with no blockchain or cryptocurrency experience. We’ve also demonstrated the creation of smart contracts within minutes built with BASH shell and Node.js.

Bonus

Bonus Points: Show us how it works. Do you have an idea for a cool new use case for Community Points? Build it!

TIME

Community points could be awarded to Reddit users based upon TIME too, whereas the longer someone is part of a subreddit, the more community points someone naturally gained, even if not actively commenting or sharing new posts. A daily login could be required for these community points to be credited. This grants awards to readers too and incentivizes readers to create an account on Reddit if they browse the website often. This concept could also be leveraged to provide some level of reputation based upon duration and consistency of contribution to a community subreddit.

Dragon Den

Dragonchain has already built a social media platform that harnesses community involvement. Dragon Den is a decentralized community built on the Dragonchain blockchain platform. Dragon Den is Dragonchain’s answer to fake news, trolling, and censorship. It incentivizes the creation and evaluation of quality content within communities. It could be described as being a shareholder of a subreddit or Reddit in its entirety. The more your subreddit is thriving, the more rewarding it will be. Den is currently in a public beta and in active development, though the real token economy is not live yet. There are different tokens for various purposes. Two tokens are Lair Ownership Rights (LOR) and Lair Ownership Tokens (LOT). LOT is a non-fungible token for ownership of a specific Lair. LOT will only be created and converted from LOR.
Energy (NRG) and Matter (MTR) work jointly. Your MTR determines how much NRG you receive in a 24-hour period. Providing quality content, or evaluating content will earn MTR.

Security. Users have full ownership & control of their points.
All community points awarded based upon any type of activity or gift, are secured and provable to all Interchain networks (currently BTC, ETH, ETC). Users are free to spend and withdraw their points as they please, depending on the features Reddit wants to bring into production.

Balances and transactions cannot be forged, manipulated, or blocked by Reddit or anyone else
Users can withdraw their balance to their ERC20 wallet, directly through Reddit. Reddit can cover the fees on their behalf, or the user covers this with a portion of their balance.

Users should own their points and be able to get on-chain ERC20 tokens without permission from anyone else
Through our console users can withdraw their ERC20 rewards. This can be achieved on Reddit too. Here is a walkthrough of our console, though this does not show the quick withdrawal functionality, a user can withdraw at any time. https://www.youtube.com/watch?v=aNlTMxnfVHw

Points should be recoverable to on-chain ERC20 tokens even if all third-parties involved go offline
If necessary, signed transactions from the Reddit system (e.g. Reddit + Subreddit) can be sent to the Ethereum smart contract for minting.

A public, third-party review attesting to the soundness of the design should be available
To our knowledge, at least two large corporations, including a top 3 accounting firm, have conducted positive reviews. These reviews have never been made public, as Dragonchain did not pay or contract for these studies to be released.

Bonus points
Public, third-party implementation review available or in progress
See above

Compatibility with HSMs & hardware wallets
For the purpose of this proposal, all tokenization would be on the Ethereum network using standard token contracts and as such, would be able to leverage all hardware wallet and Ethereum ecosystem services.

Other Considerations

Minting/distributing tokens is not performed by Reddit directly
This operation can be automated by smart contract on Ethereum. Subreddits can if desired have a role to play.

One off point burning, as well as recurring, non-interactive point burning (for subreddit memberships) should be possible and scalable
This is possible and scalable with interaction between Dragonchain Reddit system and Ethereum token contract(s).

Fully open-source solutions are strongly preferred
Dragonchain is fully open source (see section on Disney release after conclusion).

Conclusion

Whether it is today, or in the future, we would like to work together to bring secure flexibility to the highest standards. It is our hope to be considered by Ethereum, Reddit, and other integrative solutions so we may further discuss the possibilities of implementation. In our public demonstration, 256 million transactions were handled in our operational network on chain in 24 hours, for the low cost of $25K, which if run today would cost $625. Dragonchain’s interoperable foundation provides the atmosphere necessary to implement a frictionless community points system. Thank you for your consideration of our proposal. We look forward to working with the community to make something great!

Disney Releases Blockchain Platform as Open Source

The team at Disney created the Disney Private Blockchain Platform. The system was a hybrid interoperable blockchain platform for ledgering and smart contract development geared toward solving problems with blockchain adoption and usability. All objective evaluation would consider the team’s output a success. We released a list of use cases that we explored in some capacity at Disney, and our input on blockchain standardization as part of our participation in the W3C Blockchain Community Group.
https://lists.w3.org/Archives/Public/public-blockchain/2016May/0052.html

Open Source

In 2016, Roets proposed to release the platform as open source to spread the technology outside of Disney, as others within the W3C group were interested in the solutions that had been created inside of Disney.
Following a long process, step by step, the team met requirements for release. Among the requirements, the team had to:
  • Obtain VP support and approval for the release
  • Verify ownership of the software to be released
  • Verify that no proprietary content would be released
  • Convince the organization that there was a value to the open source community
  • Convince the organization that there was a value to Disney
  • Offer the plan for ongoing maintenance of the project outside of Disney
  • Itemize competing projects
  • Verify no conflict of interest
  • Preferred license
  • Change the project name to not use the name Disney, any Disney character, or any other associated IP - proposed Dragonchain - approved
  • Obtain legal approval
  • Approval from corporate, parks, and other business units
  • Approval from multiple Disney patent groups Copyright holder defined by Disney (Disney Connected and Advanced Technologies)
  • Trademark searches conducted for the selected name Dragonchain
  • Obtain IT security approval
  • Manual review of OSS components conducted
  • OWASP Dependency and Vulnerability Check Conducted
  • Obtain technical (software) approval
  • Offer management, process, and financial plans for the maintenance of the project.
  • Meet list of items to be addressed before release
  • Remove all Disney project references and scripts
  • Create a public distribution list for email communications
  • Remove Roets’ direct and internal contact information
  • Create public Slack channel and move from Disney slack channels
  • Create proper labels for issue tracking
  • Rename internal private Github repository
  • Add informative description to Github page
  • Expand README.md with more specific information
  • Add information beyond current “Blockchains are Magic”
  • Add getting started sections and info on cloning/forking the project
  • Add installation details
  • Add uninstall process
  • Add unit, functional, and integration test information
  • Detail how to contribute and get involved
  • Describe the git workflow that the project will use
  • Move to public, non-Disney git repository (Github or Bitbucket)
  • Obtain Disney Open Source Committee approval for release
On top of meeting the above criteria, as part of the process, the maintainer of the project had to receive the codebase on their own personal email and create accounts for maintenance (e.g. Github) with non-Disney accounts. Given the fact that the project spanned multiple business units, Roets was individually responsible for its ongoing maintenance. Because of this, he proposed in the open source application to create a non-profit organization to hold the IP and maintain the project. This was approved by Disney.
The Disney Open Source Committee approved the application known as OSSRELEASE-10, and the code was released on October 2, 2016. Disney decided to not issue a press release.
Original OSSRELASE-10 document

Dragonchain Foundation

The Dragonchain Foundation was created on January 17, 2017. https://den.social/l/Dragonchain/24130078352e485d96d2125082151cf0/dragonchain-and-disney/
submitted by j0j0r0 to ethereum [link] [comments]

Eth 2.0 vs Polkadot and other musings by a fundamental investor

Spent about two hours on this post and I decided it would help the community if I made it more visible. Comment was made as a response to this
I’m trying to avoid falling into a maximalist mindset over time. This isn’t a 100% ETH question, but I’m trying to stay educated about emerging tech.
Can someone help me see the downsides of diversifying into DOTs?
I know Polkadot is more centralized, VC backed, and generally against our ethos here. On chain governance might introduce some unknown risks. What else am I missing?
I see a bunch of posts about how Ethereum and Polkadot can thrive together, but are they not both L1 competitors?
Response:
What else am I missing?
The upsides.
Most of the guys responding to you here are full Eth maxis who drank the Parity is bad koolaid. They are married to their investment and basically emotional / tribal in an area where you should have a cool head. Sure, you might get more upvotes on Reddit if you do and say what the crowd wants, but do you want upvotes and fleeting validation or do you want returns on your investment? Do you want to be these guys or do you want to be the shareholder making bank off of those guys?
Disclaimer: I'm both an Eth whale and a Dot whale, and have been in crypto for close to a decade now. I originally bought ether sub $10 after researching it for at least a thousand hours. Rode to $1500 and down to $60. Iron hands - my intent has always been to reconsider my Eth position after proof of stake is out. I invested in the 2017 Dot public sale with the plan of flipping profits back to Eth but keeping Dots looks like the right short and long term play now. I am not a trader, I just take a deep tech dive every couple of years and invest in fundamentals.
Now as for your concerns:
I know Polkadot is more centralized
The sad truth is that the market doesn't really care about this. At all. There is no real statistic to show at what point a coin is "decentralized" or "too centralized". For example, bitcoin has been completely taken over by Chinese mining farms for about five years now. Last I checked, they control above 85% of the hashing power, they just spread it among different mining pools to make it look decentralized. They have had the ability to fake or block transactions for all this time but it has never been in their best interest to do so: messing with bitcoin in that way would crash its price, therefore their bitcoin holdings, their mining equipment, and their company stock (some of them worth billions) would evaporate. So they won't do it due to economics, but not because they can't.
That is the major point I want to get across; originally Bitcoin couldn't be messed with because it was decentralized, but now Bitcoin is centralized but it's still not messed with due to economics. It is basically ChinaCoin at this point, but the market doesn't care, and it still enjoys over 50% of the total crypto market cap.
So how does this relate to Polkadot? Well fortunately most chains - Ethereum included - are working towards proof of stake. This is obviously better for the environment, but it also has a massive benefit for token holders. If a hostile party wanted to take over a proof of stake chain they'd have to buy up a massive share of the network. The moment they force through a malicious transaction a proof of stake blockchain has the option to fork them off. It would be messy for a few days, but by the end of the week the hostile party would have a large amount of now worthless tokens, and the proof of stake community would have moved on to a version of the blockchain where the hostile party's tokens have been slashed to zero. So not only does the market not care about centralization (Bitcoin example), but proof of stake makes token holders even safer.
That being said, Polkadot's "centralization" is not that far off to Ethereum. The Web3 foundation kept 30% of the Dots while the Ethereum Foundation kept 17%. There are whales in Polkadot but Ethereum has them too - 40% of all genesis Ether went to 100 wallets, and many suspect that the original Ethereum ICO was sybiled to make it look more popular and decentralized than it really was. But you don't really care about that do you? Neither do I. Whales are a fact of life.
VC backed
VCs are part of the crypto game now. There is no way to get rid of them, and there is no real reason why you should want to get rid of them. They put their capital at risk (same as you and me) and seek returns on their investment (same as you and me). They are both in Polkadot and Ethereum, and have been for years now. I have no issue with them as long as they don't play around with insider information, but that is another topic. To be honest, I would be worried if VCs did not endorse chains I'm researching, but maybe that's because my investing style isn't chasing hype and buying SUSHI style tokens from anonymous (at the time) developers. That's just playing hot potato. But hey, some people are good at that.
As to the amount of wallets that participated in the Polkadot ICO: a little known fact is that more individual wallets participated in Polkadot's ICO than Ethereum's, even though Polkadot never marketed their ICO rounds due to regulatory reasons.
generally against our ethos here
Kool aid.
Some guy that works(ed?) at Parity (who employs what, 200+ people?) correctly said that Ethereum is losing its tech lead and that offended the Ethereum hivemind. Oh no. So controversial. I'm so personally hurt by that.
Some guy that has been working for free on Ethereum basically forever correctly said that Polkadot is taking the blockchain tech crown. Do we A) Reflect on why he said that? or B) Rally the mob to chase him off?
"I did not quit social media, I quit Ethereum. I did not go dark, I just left the community. I am no longer coordinating hard forks, building testnets, or contributing otherwise. I did not work on Polkadot, I never did, I worked on Ethereum. I did not hate Ethereum, I loved it."
Also Parity locked their funds (and about 500+ other wallets not owned by them) and proposed a solution to recover them. When the community voted no they backed off and did not fork the chain, even if they had the influence to do so. For some reason this subreddit hates them for that, even if Parity did the 100% moral thing to do. Remember, 500+ other teams or people had their funds locked, so Parity was morally bound to try its best to recover them.
Its just lame drama to be honest. Nothing to do with ethos, everything to do with emotional tribalism.
Now for the missing upsides (I'll also respond to random fragments scattered in the thread):
This isn’t a 100% ETH question, but I’m trying to stay educated about emerging tech.
A good quick intro to Eth's tech vs Polkadot's tech can be found on this thread, especially this reply. That thread is basically mandatory reading if you care about your investment.
Eth 2.0's features will not really kick in for end users until about 2023. That means every dapp (except DeFI, where the fees make sense due to returns and is leading the fee market) who built on Eth's layer 1 are dead for three years. Remember the trading card games... Gods Unchained? How many players do you think are going to buy and sell cards when the transaction fee is worth more than the cards? All that development is now practically worthless until it can migrate to its own shard. This story repeats for hundreds of other dapp teams who's projects are now priced out for three years. So now they either have to migrate to a one of the many unpopulated L2 options (which have their own list of problems and risks, but that's another topic) or they look for another platform, preferably one interoperable with Ethereum. Hence Polkadot's massive growth in developer activity. If you check out https://polkaproject.com/ you'll see 205 projects listed at the time of this post. About a week ago they had 202 listed. That means about one team migrated from another tech stack to build on Polkadot every two days, and trust me, many more will come in when parachains are finally activated, and it will be a complete no brainer when Polkadot 2.0 is released.
Another huge upside for Polkadot is the Initial Parachain Offerings. Polkadot's version of ICOs. The biggest difference is that you can vote for parachains using your Dots to bind them to the relay chain, and you get some of the parachain's tokens in exchange. After a certain amount of time you get your Dots back. The tokenomics here are impressive: Dots are locked (reduced supply) instead of sold (sell pressure) and you still earn your staking rewards. There's no risk of scammers running away with your Ether and the governance mechanism allows for the community to defund incompetent devs who did not deliver what was promised.
Wouldn’t an ETH shard on Polkadot gain a bunch of scaling benefits that we won’t see natively for a couple years?
Yes. That is correct. Both Edgeware and Moonbeam are EVM compatible. And if the original dapp teams don't migrate their projects someone else will fork them, exactly like SUSHI did to Uniswap, and how Acala is doing to MakerDao.
Although realistically Ethereum has a 5 yr headstart and devs haven't slowed down at all
Ethereum had a five year head start but it turns out that Polkadot has a three year tech lead.
Just because it's "EVM Compatible" doesn't mean you can just plug Ethereum into Polkadot or vica versa, it just means they both understand Ethereum bytecode and you can potentially copy/paste contracts from Ethereum to Polkadot, but you'd still need to add a "bridge" between the 2 chains, so it adds additional complexity and extra steps compared to using any of the existing L2 scaling solutions
That only applies of you are thinking from an Eth maximalist perspective. But if you think from Polkadot's side, why would you need to use the bridge back to Ethereum at all? Everything will be seamless, cheaper, and quicker once the ecosystem starts to flourish.
I see a bunch of posts about how Ethereum and Polkadot can thrive together, but are they not both L1 competitors?
They are competitors. Both have their strategies, and both have their strengths (tech vs time on the market) but they are clearly competing in my eyes. Which is a good thing, Apple and Samsung competing in the cell phone market just leads to more innovation for consumers. You can still invest in both if you like.
Edit - link to post and the rest of the conversation: https://www.reddit.com/ethfinance/comments/iooew6/daily_general_discussion_september_8_2020/g4h5yyq/
Edit 2 - one day later PolkaProject count is 210. Devs are getting the hint :)
submitted by redditsucks_goruqqus to polkadot_market [link] [comments]

Technical: Taproot: Why Activate?

This is a follow-up on https://old.reddit.com/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/
Taproot! Everybody wants it!! But... you might ask yourself: sure, everybody else wants it, but why would I, sovereign Bitcoin HODLer, want it? Surely I can be better than everybody else because I swapped XXX fiat for Bitcoin unlike all those nocoiners?
And it is important for you to know the reasons why you, o sovereign Bitcoiner, would want Taproot activated. After all, your nodes (or the nodes your wallets use, which if you are SPV, you hopefully can pester to your wallet vendoimplementor about) need to be upgraded in order for Taproot activation to actually succeed instead of becoming a hot sticky mess.
First, let's consider some principles of Bitcoin.
I'm sure most of us here would agree that the above are very important principles of Bitcoin and that these are principles we would not be willing to remove. If anything, we would want those principles strengthened (especially the last one, financial privacy, which current Bitcoin is only sporadically strong with: you can get privacy, it just requires effort to do so).
So, how does Taproot affect those principles?

Taproot and Your /Coins

Most HODLers probably HODL their coins in singlesig addresses. Sadly, switching to Taproot would do very little for you (it gives a mild discount at spend time, at the cost of a mild increase in fee at receive time (paid by whoever sends to you, so if it's a self-send from a P2PKH or bech32 address, you pay for this); mostly a wash).
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash, so the Taproot output spends 12 bytes more; spending from a P2WPKH requires revealing a 32-byte public key later, which is not needed with Taproot, and Taproot signatures are about 9 bytes smaller than P2WPKH signatures, but the 32 bytes plus 9 bytes is divided by 4 because of the witness discount, so it saves about 11 bytes; mostly a wash, it increases blockweight by about 1 virtual byte, 4 weight for each Taproot-output-input, compared to P2WPKH-output-input).
However, as your HODLings grow in value, you might start wondering if multisignature k-of-n setups might be better for the security of your savings. And it is in multisignature that Taproot starts to give benefits!
Taproot switches to using Schnorr signing scheme. Schnorr makes key aggregation -- constructing a single public key from multiple public keys -- almost as trivial as adding numbers together. "Almost" because it involves some fairly advanced math instead of simple boring number adding, but hey when was the last time you added up your grocery list prices by hand huh?
With current P2SH and P2WSH multisignature schemes, if you have a 2-of-3 setup, then to spend, you need to provide two different signatures from two different public keys. With Taproot, you can create, using special moon math, a single public key that represents your 2-of-3 setup. Then you just put two of your devices together, have them communicate to each other (this can be done airgapped, in theory, by sending QR codes: the software to do this is not even being built yet, but that's because Taproot hasn't activated yet!), and they will make a single signature to authorize any spend from your 2-of-3 address. That's 73 witness bytes -- 18.25 virtual bytes -- of signatures you save!
And if you decide that your current setup with 1-of-1 P2PKH / P2WPKH addresses is just fine as-is: well, that's the whole point of a softfork: backwards-compatibility; you can receive from Taproot users just fine, and once your wallet is updated for Taproot-sending support, you can send to Taproot users just fine as well!
(P2WPKH and P2WSH -- SegWit v0 -- addresses start with bc1q; Taproot -- SegWit v1 --- addresses start with bc1p, in case you wanted to know the difference; in bech32 q is 0, p is 1)
Now how about HODLers who keep all, or some, of their coins on custodial services? Well, any custodial service worth its salt would be doing at least 2-of-3, or probably something even bigger, like 11-of-15. So your custodial service, if it switched to using Taproot internally, could save a lot more (imagine an 11-of-15 getting reduced from 11 signatures to just 1!), which --- we can only hope! --- should translate to lower fees and better customer service from your custodial service!
So I think we can say, very accurately, that the Bitcoin principle --- that YOU are in control of your money --- can only be helped by Taproot (if you are doing multisignature), and, because P2PKH and P2WPKH remain validly-usable addresses in a Taproot future, will not be harmed by Taproot. Its benefit to this principle might be small (it mostly only benefits multisignature users) but since it has no drawbacks with this (i.e. singlesig users can continue to use P2WPKH and P2PKH still) this is still a nice, tidy win!
(even singlesig users get a minor benefit, in that multisig users will now reduce their blockchain space footprint, so that fees can be kept low for everybody; so for example even if you have your single set of private keys engraved on titanium plates sealed in an airtight box stored in a safe buried in a desert protected by angry nomads riding giant sandworms because you're the frickin' Kwisatz Haderach, you still gain some benefit from Taproot)
And here's the important part: if P2PKH/P2WPKH is working perfectly fine with you and you decide to never use Taproot yourself, Taproot will not affect you detrimentally. First do no harm!

Taproot and Your Contracts

No one is an island, no one lives alone. Give and you shall receive. You know: by trading with other people, you can gain expertise in some obscure little necessity of the world (and greatly increase your productivity in that little field), and then trade the products of your expertise for necessities other people have created, all of you thereby gaining gains from trade.
So, contracts, which are basically enforceable agreements that facilitate trading with people who you do not personally know and therefore might not trust.
Let's start with a simple example. You want to buy some gewgaws from somebody. But you don't know them personally. The seller wants the money, you want their gewgaws, but because of the lack of trust (you don't know them!! what if they're scammers??) neither of you can benefit from gains from trade.
However, suppose both of you know of some entity that both of you trust. That entity can act as a trusted escrow. The entity provides you security: this enables the trade, allowing both of you to get gains from trade.
In Bitcoin-land, this can be implemented as a 2-of-3 multisignature. The three signatories in the multisgnature would be you, the gewgaw seller, and the escrow. You put the payment for the gewgaws into this 2-of-3 multisignature address.
Now, suppose it turns out neither of you are scammers (whaaaat!). You receive the gewgaws just fine and you're willing to pay up for them. Then you and the gewgaw seller just sign a transaction --- you and the gewgaw seller are 2, sufficient to trigger the 2-of-3 --- that spends from the 2-of-3 address to a singlesig the gewgaw seller wants (or whatever address the gewgaw seller wants).
But suppose some problem arises. The seller gave you gawgews instead of gewgaws. Or you decided to keep the gewgaws but not sign the transaction to release the funds to the seller. In either case, the escrow is notified, and if it can sign with you to refund the funds back to you (if the seller was a scammer) or it can sign with the seller to forward the funds to the seller (if you were a scammer).
Taproot helps with this: like mentioned above, it allows multisignature setups to produce only one signature, reducing blockchain space usage, and thus making contracts --- which require multiple people, by definition, you don't make contracts with yourself --- is made cheaper (which we hope enables more of these setups to happen for more gains from trade for everyone, also, moon and lambos).
(technology-wise, it's easier to make an n-of-n than a k-of-n, making a k-of-n would require a complex setup involving a long ritual with many communication rounds between the n participants, but an n-of-n can be done trivially with some moon math. You can, however, make what is effectively a 2-of-3 by using a three-branch SCRIPT: either 2-of-2 of you and seller, OR 2-of-2 of you and escrow, OR 2-of-2 of escrow and seller. Fortunately, Taproot adds a facility to embed a SCRIPT inside a public key, so you can have a 2-of-2 Taprooted address (between you and seller) with a SCRIPT branch that can instead be spent with 2-of-2 (you + escrow) OR 2-of-2 (seller + escrow), which implements the three-branched SCRIPT above. If neither of you are scammers (hopefully the common case) then you both sign using your keys and never have to contact the escrow, since you are just using the escrow public key without coordinating with them (because n-of-n is trivial but k-of-n requires setup with communication rounds), so in the "best case" where both of you are honest traders, you also get a privacy boost, in that the escrow never learns you have been trading on gewgaws, I mean ewww, gawgews are much better than gewgaws and therefore I now judge you for being a gewgaw enthusiast, you filthy gewgawer).

Taproot and Your Contracts, Part 2: Cryptographic Boogaloo

Now suppose you want to buy some data instead of things. For example, maybe you have some closed-source software in trial mode installed, and want to pay the developer for the full version. You want to pay for an activation code.
This can be done, today, by using an HTLC. The developer tells you the hash of the activation code. You pay to an HTLC, paying out to the developer if it reveals the preimage (the activation code), or refunding the money back to you after a pre-agreed timeout. If the developer claims the funds, it has to reveal the preimage, which is the activation code, and you can now activate your software. If the developer does not claim the funds by the timeout, you get refunded.
And you can do that, with HTLCs, today.
Of course, HTLCs do have problems:
Fortunately, with Schnorr (which is enabled by Taproot), we can now use the Scriptless Script constuction by Andrew Poelstra. This Scriptless Script allows a new construction, the PTLC or Pointlocked Timelocked Contract. Instead of hashes and preimages, just replace "hash" with "point" and "preimage" with "scalar".
Or as you might know them: "point" is really "public key" and "scalar" is really a "private key". What a PTLC does is that, given a particular public key, the pointlocked branch can be spent only if the spender reveals the private key of the given public key to you.
Another nice thing with PTLCs is that they are deniable. What appears onchain is just a single 2-of-2 signature between you and the developemanufacturer. It's like a magic trick. This signature has no special watermarks, it's a perfectly normal signature (the pledge). However, from this signature, plus some datta given to you by the developemanufacturer (known as the adaptor signature) you can derive the private key of a particular public key you both agree on (the turn). Anyone scraping the blockchain will just see signatures that look just like every other signature, and as long as nobody manages to hack you and get a copy of the adaptor signature or the private key, they cannot get the private key behind the public key (point) that the pointlocked branch needs (the prestige).
(Just to be clear, the public key you are getting the private key from, is distinct from the public key that the developemanufacturer will use for its funds. The activation key is different from the developer's onchain Bitcoin key, and it is the activation key whose private key you will be learning, not the developer's/manufacturer's onchain Bitcoin key).
So:
Taproot lets PTLCs exist onchain because they enable Schnorr, which is a requirement of PTLCs / Scriptless Script.
(technology-wise, take note that Scriptless Script works only for the "pointlocked" branch of the contract; you need normal Script, or a pre-signed nLockTimed transaction, for the "timelocked" branch. Since Taproot can embed a script, you can have the Taproot pubkey be a 2-of-2 to implement the Scriptless Script "pointlocked" branch, then have a hidden script that lets you recover the funds with an OP_CHECKLOCKTIMEVERIFY after the timeout if the seller does not claim the funds.)

Quantum Quibbles!

Now if you were really paying attention, you might have noticed this parenthetical:
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash...)
So wait, Taproot uses raw 32-byte public keys, and not public key hashes? Isn't that more quantum-vulnerable??
Well, in theory yes. In practice, they probably are not.
It's not that hashes can be broken by quantum computes --- they're still not. Instead, you have to look at how you spend from a P2WPKH/P2PKH pay-to-public-key-hash.
When you spend from a P2PKH / P2WPKH, you have to reveal the public key. Then Bitcoin hashes it and checks if this matches with the public-key-hash, and only then actually validates the signature for that public key.
So an unconfirmed transaction, floating in the mempools of nodes globally, will show, in plain sight for everyone to see, your public key.
(public keys should be public, that's why they're called public keys, LOL)
And if quantum computers are fast enough to be of concern, then they are probably fast enough that, in the several minutes to several hours from broadcast to confirmation, they have already cracked the public key that is openly broadcast with your transaction. The owner of the quantum computer can now replace your unconfirmed transaction with one that pays the funds to itself. Even if you did not opt-in RBF, miners are still incentivized to support RBF on RBF-disabled transactions.
So the extra hash is not as significant a protection against quantum computers as you might think. Instead, the extra hash-and-compare needed is just extra validation effort.
Further, if you have ever, in the past, spent from the address, then there exists already a transaction indelibly stored on the blockchain, openly displaying the public key from which quantum computers can derive the private key. So those are still vulnerable to quantum computers.
For the most part, the cryptographers behind Taproot (and Bitcoin Core) are of the opinion that quantum computers capable of cracking Bitcoin pubkeys are unlikely to appear within a decade or two.
So:
For now, the homomorphic and linear properties of elliptic curve cryptography provide a lot of benefits --- particularly the linearity property is what enables Scriptless Script and simple multisignature (i.e. multisignatures that are just 1 signature onchain). So it might be a good idea to take advantage of them now while we are still fairly safe against quantum computers. It seems likely that quantum-safe signature schemes are nonlinear (thus losing these advantages).

Summary

I Wanna Be The Taprooter!

So, do you want to help activate Taproot? Here's what you, mister sovereign Bitcoin HODLer, can do!

But I Hate Taproot!!

That's fine!

Discussions About Taproot Activation

submitted by almkglor to Bitcoin [link] [comments]

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.
submitted by Tricky_Troll to ethtrader [link] [comments]

Here's A to Z list of a *few* scams that happened since 2014 in India

Since today is my cake-day, I thought of posting something that got a lot of upvotes earlier on india.
Here's the full list of all the scams as listed on the site - corruptmodi.com from A-to-Z:
submitted by OMDB-PiLoT to india [link] [comments]

Technical: The Path to Taproot Activation

Taproot! Everybody wants to have it, somebody wants to make it, nobody knows how to get it!
(If you are asking why everybody wants it, see: Technical: Taproot: Why Activate?)
(Pedants: I mostly elide over lockin times)
Briefly, Taproot is that neat new thing that gets us:
So yes, let's activate taproot!

The SegWit Wars

The biggest problem with activating Taproot is PTSD from the previous softfork, SegWit. Pieter Wuille, one of the authors of the current Taproot proposal, has consistently held the position that he will not discuss activation, and will accept whatever activation process is imposed on Taproot. Other developers have expressed similar opinions.
So what happened with SegWit activation that was so traumatic? SegWit used the BIP9 activation method. Let's dive into BIP9!

BIP9 Miner-Activated Soft Fork

Basically, BIP9 has a bunch of parameters:
Now there are other parameters (name, starttime) but they are not anywhere near as important as the above two.
A number that is not a parameter, is 95%. Basically, activation of a BIP9 softfork is considered as actually succeeding if at least 95% of blocks in the last 2 weeks had the specified bit in the nVersion set. If less than 95% had this bit set before the timeout, then the upgrade fails and never goes into the network. This is not a parameter: it is a constant defined by BIP9, and developers using BIP9 activation cannot change this.
So, first some simple questions and their answers:

The Great Battles of the SegWit Wars

SegWit not only fixed transaction malleability, it also created a practical softforkable blocksize increase that also rebalanced weights so that the cost of spending a UTXO is about the same as the cost of creating UTXOs (and spending UTXOs is "better" since it limits the size of the UTXO set that every fullnode has to maintain).
So SegWit was written, the activation was decided to be BIP9, and then.... miner signalling stalled at below 75%.
Thus were the Great SegWit Wars started.

BIP9 Feature Hostage

If you are a miner with at least 5% global hashpower, you can hold a BIP9-activated softfork hostage.
You might even secretly want the softfork to actually push through. But you might want to extract concession from the users and the developers. Like removing the halvening. Or raising or even removing the block size caps (which helps larger miners more than smaller miners, making it easier to become a bigger fish that eats all the smaller fishes). Or whatever.
With BIP9, you can hold the softfork hostage. You just hold out and refuse to signal. You tell everyone you will signal, if and only if certain concessions are given to you.
This ability by miners to hold a feature hostage was enabled because of the miner-exit allowed by the timeout on BIP9. Prior to that, miners were considered little more than expendable security guards, paid for the risk they take to secure the network, but not special in the grand scheme of Bitcoin.

Covert ASICBoost

ASICBoost was a novel way of optimizing SHA256 mining, by taking advantage of the structure of the 80-byte header that is hashed in order to perform proof-of-work. The details of ASICBoost are out-of-scope here but you can read about it elsewhere
Here is a short summary of the two types of ASICBoost, relevant to the activation discussion.
Now, "overt" means "obvious", while "covert" means hidden. Overt ASICBoost is obvious because nVersion bits that are not currently in use for BIP9 activations are usually 0 by default, so setting those bits to 1 makes it obvious that you are doing something weird (namely, Overt ASICBoost). Covert ASICBoost is non-obvious because the order of transactions in a block are up to the miner anyway, so the miner rearranging the transactions in order to get lower power consumption is not going to be detected.
Unfortunately, while Overt ASICBoost was compatible with SegWit, Covert ASICBoost was not. This is because, pre-SegWit, only the block header Merkle tree committed to the transaction ordering. However, with SegWit, another Merkle tree exists, which commits to transaction ordering as well. Covert ASICBoost would require more computation to manipulate two Merkle trees, obviating the power benefits of Covert ASICBoost anyway.
Now, miners want to use ASICBoost (indeed, about 60->70% of current miners probably use the Overt ASICBoost nowadays; if you have a Bitcoin fullnode running you will see the logs with lots of "60 of last 100 blocks had unexpected versions" which is exactly what you would see with the nVersion manipulation that Overt ASICBoost does). But remember: ASICBoost was, at around the time, a novel improvement. Not all miners had ASICBoost hardware. Those who did, did not want it known that they had ASICBoost hardware, and wanted to do Covert ASICBoost!
But Covert ASICBoost is incompatible with SegWit, because SegWit actually has two Merkle trees of transaction data, and Covert ASICBoost works by fudging around with transaction ordering in a block, and recomputing two Merkle Trees is more expensive than recomputing just one (and loses the ASICBoost advantage).
Of course, those miners that wanted Covert ASICBoost did not want to openly admit that they had ASICBoost hardware, they wanted to keep their advantage secret because miners are strongly competitive in a very tight market. And doing ASICBoost Covertly was just the ticket, but they could not work post-SegWit.
Fortunately, due to the BIP9 activation process, they could hold SegWit hostage while covertly taking advantage of Covert ASICBoost!

UASF: BIP148 and BIP8

When the incompatibility between Covert ASICBoost and SegWit was realized, still, activation of SegWit stalled, and miners were still not openly claiming that ASICBoost was related to non-activation of SegWit.
Eventually, a new proposal was created: BIP148. With this rule, 3 months before the end of the SegWit timeout, nodes would reject blocks that did not signal SegWit. Thus, 3 months before SegWit timeout, BIP148 would force activation of SegWit.
This proposal was not accepted by Bitcoin Core, due to the shortening of the timeout (it effectively times out 3 months before the initial SegWit timeout). Instead, a fork of Bitcoin Core was created which added the patch to comply with BIP148. This was claimed as a User Activated Soft Fork, UASF, since users could freely download the alternate fork rather than sticking with the developers of Bitcoin Core.
Now, BIP148 effectively is just a BIP9 activation, except at its (earlier) timeout, the new rules would be activated anyway (instead of the BIP9-mandated behavior that the upgrade is cancelled at the end of the timeout).
BIP148 was actually inspired by the BIP8 proposal (the link here is a historical version; BIP8 has been updated recently, precisely in preparation for Taproot activation). BIP8 is basically BIP9, but at the end of timeout, the softfork is activated anyway rather than cancelled.
This removed the ability of miners to hold the softfork hostage. At best, they can delay the activation, but not stop it entirely by holding out as in BIP9.
Of course, this implies risk that not all miners have upgraded before activation, leading to possible losses for SPV users, as well as again re-pressuring miners to signal activation, possibly without the miners actually upgrading their software to properly impose the new softfork rules.

BIP91, SegWit2X, and The Aftermath

BIP148 inspired countermeasures, possibly from the Covert ASiCBoost miners, possibly from concerned users who wanted to offer concessions to miners. To this day, the common name for BIP148 - UASF - remains an emotionally-charged rallying cry for parts of the Bitcoin community.
One of these was SegWit2X. This was brokered in a deal between some Bitcoin personalities at a conference in New York, and thus part of the so-called "New York Agreement" or NYA, another emotionally-charged acronym.
The text of the NYA was basically:
  1. Set up a new activation threshold at 80% signalled at bit 4 (vs bit 1 for SegWit).
    • When this 80% signalling was reached, miners would require that bit 1 for SegWit be signalled to achive the 95% activation needed for SegWit.
  2. If the bit 4 signalling reached 80%, increase the block weight limit from the SegWit 4000000 to the SegWit2X 8000000, 6 months after bit 1 activation.
The first item above was coded in BIP91.
Unfortunately, if you read the BIP91, independently of NYA, you might come to the conclusion that BIP91 was only about lowering the threshold to 80%. In particular, BIP91 never mentions anything about the second point above, it never mentions that bit 4 80% threshold would also signal for a later hardfork increase in weight limit.
Because of this, even though there are claims that NYA (SegWit2X) reached 80% dominance, a close reading of BIP91 shows that the 80% dominance was only for SegWit activation, without necessarily a later 2x capacity hardfork (SegWit2X).
This ambiguity of bit 4 (NYA says it includes a 2x capacity hardfork, BIP91 says it does not) has continued to be a thorn in blocksize debates later. Economically speaking, Bitcoin futures between SegWit and SegWit2X showed strong economic dominance in favor of SegWit (SegWit2X futures were traded at a fraction in value of SegWit futures: I personally made a tidy but small amount of money betting against SegWit2X in the futures market), so suggesting that NYA achieved 80% dominance even in mining is laughable, but the NYA text that ties bit 4 to SegWit2X still exists.
Historically, BIP91 triggered which caused SegWit to activate before the BIP148 shorter timeout. BIP148 proponents continue to hold this day that it was the BIP148 shorter timeout and no-compromises-activate-on-August-1 that made miners flock to BIP91 as a face-saving tactic that actually removed the second clause of NYA. NYA supporters keep pointing to the bit 4 text in the NYA and the historical activation of BIP91 as a failed promise by Bitcoin developers.

Taproot Activation Proposals

There are two primary proposals I can see for Taproot activation:
  1. BIP8.
  2. Modern Softfork Activation.
We have discussed BIP8: roughly, it has bit and timeout, if 95% of miners signal bit it activates, at the end of timeout it activates. (EDIT: BIP8 has had recent updates: at the end of timeout it can now activate or fail. For the most part, in the below text "BIP8", means BIP8-and-activate-at-timeout, and "BIP9" means BIP8-and-fail-at-timeout)
So let's take a look at Modern Softfork Activation!

Modern Softfork Activation

This is a more complex activation method, composed of BIP9 and BIP8 as supcomponents.
  1. First have a 12-month BIP9 (fail at timeout).
  2. If the above fails to activate, have a 6-month discussion period during which users and developers and miners discuss whether to continue to step 3.
  3. Have a 24-month BIP8 (activate at timeout).
The total above is 42 months, if you are counting: 3.5 years worst-case activation.
The logic here is that if there are no problems, BIP9 will work just fine anyway. And if there are problems, the 6-month period should weed it out. Finally, miners cannot hold the feature hostage since the 24-month BIP8 period will exist anyway.

PSA: Being Resilient to Upgrades

Software is very birttle.
Anyone who has been using software for a long time has experienced something like this:
  1. You hear a new version of your favorite software has a nice new feature.
  2. Excited, you install the new version.
  3. You find that the new version has subtle incompatibilities with your current workflow.
  4. You are sad and downgrade to the older version.
  5. You find out that the new version has changed your files in incompatible ways that the old version cannot work with anymore.
  6. You tearfully reinstall the newer version and figure out how to get your lost productivity now that you have to adapt to a new workflow
If you are a technically-competent user, you might codify your workflow into a bunch of programs. And then you upgrade one of the external pieces of software you are using, and find that it has a subtle incompatibility with your current workflow which is based on a bunch of simple programs you wrote yourself. And if those simple programs are used as the basis of some important production system, you hve just screwed up because you upgraded software on an important production system.
And well, one of the issues with new softfork activation is that if not enough people (users and miners) upgrade to the newest Bitcoin software, the security of the new softfork rules are at risk.
Upgrading software of any kind is always a risk, and the more software you build on top of the software-being-upgraded, the greater you risk your tower of software collapsing while you change its foundations.
So if you have some complex Bitcoin-manipulating system with Bitcoin somewhere at the foundations, consider running two Bitcoin nodes:
  1. One is a "stable-version" Bitcoin node. Once it has synced, set it up to connect=x.x.x.x to the second node below (so that your ISP bandwidth is only spent on the second node). Use this node to run all your software: it's a stable version that you don't change for long periods of time. Enable txiindex, disable pruning, whatever your software needs.
  2. The other is an "always-up-to-date" Bitcoin Node. Keep its stoarge down with pruning (initially sync it off the "stable-version" node). You can't use blocksonly if your "stable-version" node needs to send transactions, but otherwise this "always-up-to-date" Bitcoin node can be kept as a low-resource node, so you can run both nodes in the same machine.
When a new Bitcoin version comes up, you just upgrade the "always-up-to-date" Bitcoin node. This protects you if a future softfork activates, you will only receive valid Bitcoin blocks and transactions. Since this node has nothing running on top of it, it is just a special peer of the "stable-version" node, any software incompatibilities with your system software do not exist.
Your "stable-version" Bitcoin node remains the same version until you are ready to actually upgrade this node and are prepared to rewrite most of the software you have running on top of it due to version compatibility problems.
When upgrading the "always-up-to-date", you can bring it down safely and then start it later. Your "stable-version" wil keep running, disconnected from the network, but otherwise still available for whatever queries. You do need some system to stop the "always-up-to-date" node if for any reason the "stable-version" goes down (otherwisee if the "always-up-to-date" advances its pruning window past what your "stable-version" has, the "stable-version" cannot sync afterwards), but if you are technically competent enough that you need to do this, you are technically competent enough to write such a trivial monitor program (EDIT: gmax notes you can adjust the pruning window by RPC commands to help with this as well).
This recommendation is from gmaxwell on IRC, by the way.
submitted by almkglor to Bitcoin [link] [comments]

Don't Get Ripped Off Buying Bitcoin or Mining Contracts on eBay Nuvoo Cloud Mining- Bitcoin Contracts Bitcoin Mining Contract Earnings In 6 Months On $500 Bitcoin Mining Contracts Are Finally Back at Genesis Mining! GENESIS MINING RELEASES NEW AND IMPROVED BITCOIN MINING CONTRACTS - Don't Be Fooled

Cloud mining means a host company owns Bitcoin mining hardware and runs it at a professional mining facility. You pay the company and rent out some of the hardware. Based on the amount of hash power you rent, you will earn a share of payments from the cloud mining company for any revenue generated by the hash power you purchased. This is a cloud mining contract by Bitcoin.com, a reference source for everything Bitcoin related. The contract is for 100 TH/s with 1-year duration. When buying a Bitcoin.com mining contract, you're contributing to the activation of Bitcoin Unlimited's Emergent Consensus. Cloud Mining is a way to mine bitcoin cryptocurrency without the need of owning a miner or mining hardware. Simply said, you buy yourself some shares of mining power – like a mining pool – and profit together with the pool. This means that you only need a contract with someone who offers Cloud Mining Services and a bitcoin wallet. Bitcoin Cloud Mining Contract is an agreement with a cloud mining company wherein you pay them some money, and they offer you some computing power for mining coins, which belong to you. Herein, you pay for the output of mining power from hardware that is placed in remote data centers. The right Bitcoin mining contract is the only thing missing to get started. In layman’s terms, BTC cloud mining is a process of making Bitcoin as a reward without the hassles of hardware upkeep, high electricity bills, and related issues. On the whole, it comes down to using the capabilities of remote data centers that Hashmart will provide ...

[index] [1363] [4091] [5087] [2300] [2202] [1701] [2340] [4428] [4301] [3884]

Don't Get Ripped Off Buying Bitcoin or Mining Contracts on eBay

What to look out for when buying Bitcoins or Bitcoin mining contracts on eBay. This also includes resources to use when buying Bitcoin or mining Bitcoins. The new Bitcoin mining contracts have increased in price due to both high demand for Bitcoin cloud mining, as well as the increased cost of the mining hardware. But despite the higher price of ... How to buy Mining Contracts with Bitcoin Subscribe to my newsletter to learn more about how you can earn bitcoin and create wealth and enjoy daily cashflow as well as early bird investment into in ... What is Bitcoin Mining? (In Plain English) - Duration: ... 99Bitcoins 183,509 views. 16:01. Genesis Mining Contracts Are DEAD! My Thoughts. - Duration: 8:13. Crypto Jedi 7,265 views. 8:13. HARD ... A short introduction video explaining Bitcoin Mining Hardware, Hosted Bitcoin Mining Hardware and Cloud Mining Contacts (including PACMiC's). We look into the pros and cons for all different types ...

#