Just doing some catchup on my reading, since a number of us here at Phil's thread use Nicehash... pls read
How will the possible Bitcoin UASF, BIP148, BIP149 and SegWit2x affect you2017-06-19
https://new.nicehash.com/news/174I read it and I smell rotten statement.
Or poorly worded.
This is a click and drag from citronick's link above.
What is the safe side of the fork?
and if coins are placed on both forks with coins worth say Btc left fork = 2200 usd and BTC right fork = 220 usd is nicehash keeping all those 220 usd coins? since they are on the weak side of the fork
major questions if you do a large rental near the fork. ie don't do a large rental near the fork.
At the time gets closer . I will alter my mining a bit maybe go to direct mining of a few coins with all my gpus'
and maybe mine with new address for my asic's
this is why I built a new wallet and rebuilt an old one I now can send coins to them.
i also sold more btc.
← BACK TO NEWS
How will the possible Bitcoin UASF, BIP148, BIP149 and SegWit2x affect you
2017-06-19
FacebookTwitterVkontakteRedditEmailGmail
Dear users,
As you probably noticed, there is a lot of discussion around Bitcoin UASF, BIP148, BIP149 and SegWit2x among the Bitcoin developers, investors, companies and other interested parties. Since we're receiving several questions regarding how will our service respond to these proposals and how will affect you as a NiceHash user we prepared some answers.
NiceHash stance
Fist of all please note that our NiceHash hashing power marketplace is open for mining on any third-party pools that hashing power buyers are using on their hashing power orders. That said - we're not running our own coin pools or coin wallets and therefore can not directly affect on any blockchain voting mechanism.
Secondly, we're using BitGo's Enterprise hot and cold wallets to store your Bitcoins on NiceHash account. That said - your Bitcoins will stay safe on the "strong" chain in an unlikely Bitcoin chain split. BitGo is supporting hundreds of top Bitcoin Blockchain companies (besides NiceHash) like Bitstamp, BitBay, Kraken, etc. Any decision that BitGo as our wallet provider will take it will therefore be carefully evaluated among several interested involved parties.Moreover, it is also important to say that we strongly support good solutions that will increase Bitcoin Block size, consequently increase Bitcoin transacting throughput and consequently lower the transactions fees. We believe that SegWit is a good option, therefore we support it and we also already enabled and signalized SegWit on our Solo pool. Hopefully SegWit will be soon enabled on Bitcoin - it will benefit us all.
We would also like to stress out that the Bitcoin ecosystem including developers, stake holders, investors, miners and others is built on sane common goals: to make usable and valuable crypto currency. It is therefore highly unlikely that any of the new proposals or changes will be enforced dramatically. It is also highly unlikely that the changes would be enforced in such a way that Bitcoin's value would be significantly impacted since this would benefit none.
Here are also some quick summaries of UASF, BIP148, BIP149 and SegWit2x
"User Activated Soft Fork", or "UASF".
The basic idea of UASF is to release a Bitcoin wallet client (like Bitcoin Core) that at a specific date, in case the safe threshold of the original SegWit is not activated yet by miners, starts to enforce the new rules of the soft fork, disregarding the signaling failure. The reasoning is something like this: if many users with economic relevance will start to use this client, but the majority of the hashing power will refuse to cooperate with them, the coin will temporarily split, taking most of the economical value on the SegWit fork. Many miners, at that point, will start to comply, in order to mine coins that are actually worth something, assuming that their contention was just a contingent political move and not a real, fundamental, economical or technical concern. In short - with UASF those who are Bitcoin users are deciding over SegWit instead of Bitcoin miners.
"Bitcoin Improvement Proposal 148", or "BIP148"
BIP148 is implementing UASF by proposing the following: nodes running this version would start to reject blocks that are not signalling SegWit (as well as signalling blocks built on non-signalling ones) already on August 1st 2017, way before the current deployment's expiration date (that’s by necessity, because the proposal actually leverages the current deployment), and they would outright reject any chain built on blocks that don’t signal readiness themselves. BIP148 could appear as a rushed and "aggressive" proposal, associated with a significant probability of reluctant miners splitting the network, at least temporarily. Even if the split eventually resolved, it would do so creating a huge and painful reorganization on the non-BIP148 chain. Bitcoin Core, traditionally used to follow established policies of slow, safe, smooth and minimal change, is not likely going to merge this proposal (even if many developers of the group support it).
"Bitcoin Improvement Proposal 149", or "BIP149"
BIP149 is implementing UASF by proposing to initiate a second activation process, in an orderly fashion, only once the current activation attempt will time out unsuccessfully, in November 2017. This second activation process would differ in that, after the signalling process, SegWit enforcement would be autonomously activated by nodes running this client, even without reaching particular thresholds. This enforcement, anyway, would not include rejection of any chain built on blocks that don’t signal readiness for SegWit after that flag date: the new rules would be enforced only on blocks that contain SegWit data, allowing “non-signaling” blocks to be mixed into the chain. Thus, miners that don’t change anything would build on the SegWit chain, without serious disruption. In order to cause the network to split, a majority of adversarial miners would need to deliberately and continuously reject every SegWit block, or to mine blocks with invalid SegWit transactions, valid for legacy nodes but not for updated nodes.
SegWit2x
SegWit2x is a kind of "accelerated" version of original SegWit, but in contrast to original SegWit it also implies a hard fork. It relies on 80% of miners saying they are ready and support it. Here another signalling bit is used (Bit 4) first before the actual SegWit BIP 9 bit. The SegWit2x code run by miners sets out that once 80% of blocks that they mine are signalling using bit 4 they (the 80+%) will then orphan any blocks that don't signal SegWit under the BIP 9 rule. The final result is that 100% of blocks they mine are then signalling SegWit and BIP 9's 95% activation threshold is triggered. Because this activates SegWit under BIP 9 all existing SegWit ready nodes then get SegWit. If Segwit is activated on the main chain then all existing SegWit ready nodes will see that SegWit has been enabled - not just the nodes running SegWit2x.
Final words
Hopefully these brief explanations gave you some more insights into the current development around Bitcoin soft and hard forks. Once again, please note that the Bitcoin ecosystem including developers, stake holders, investors, miners and others is built on sane common goals: to make usable and valuable crypto currency. It is therefore highly unlikely that any of the new proposals or changes will be enforced dramatically. It is also highly unlikely that the changes would be enforced in such a way that Bitcoin's value would be significantly impacted since this would benefit none.
Thank you for using our service and stay strong with Bitcoin!
Best regards,
NiceHash team.