che se riuscite a tradurre dall'inglese
e poi dal "bitcoinese"
e poi dallo "zucchese"
troverete tanto tanto valore aggiunto (come sempre .... visto che Giacomo è uno dei TOP del settore)
Dunque (in 3 su 1000) potrete distillare utili elementi
per (forse) anticipare le prossime evoluzioni del BITCOIN (anche se sotto sotto non lo sa nessuno = solo clues e troppe variabili in gioco)
ed i suoi possibili "bitcoin-casini estivi" (vedi anche la correzione bella tosta in corso)
Ma solo in 3 su 1000 ....perchè stavolta IO non vi traduco più nulla
non ve la metto giù in modo condivisibile per tutti.
Ho condiviso fin troppo in questi 9 anni di blogging 4000 post 20ml di pagine viste e decine di iniziative reali.
Sono in viaggio per Sant'Elena e ci rimarrò per un po'
stacco per un po' e mi taccio...
che del tutto fesso non sono....
«Un bel tacer non fu mai scritto».....------------------------------------------------------------------
SPLIT: Thoughts on BIP148, UASF, SegWit, Bitcoin, Life, the Universe and Everything.
Posted by Giacomo Zucco | Jun 15, 2017
SPLIT, Or: How What Apparently Looks Like a Multiple Personality Disorder, Actually Turns Out to Be a Completely Rational Opinion about BIP148, UASF, SegWit, Bitcoin, Life, the Universe and Everything.
Change is GoodInnovation means change. Continuous, fast, and often times dramatic changes are the tools that complex systems utilize to evolve and ultimately create antifragility for themselves (which is better than mere robustness in the long run).
“Creative Destruction”, as Joseph Schumpeter called it, is the engine truly responsible for maintaining operation and improvement, especially in the context of economic innovation and business cycles. Competition, disruption, and even failure, are all necessary for serious progress. Systems that are currently characterized by the worst situations of stagnation, inefficience, obsolescence, corruption, long term fragility, and moral hazard, are usually the ones in which competition and disruption are forbidden or slowed down by legal/violent monopolies, or where failures are prevented by bailouts, monetary manipulation and other kinds of distortion. Unsurprisingly, these situations mostly occur in sectors that are heavily contaminated by regulation, politics, government spending, taxation, etc.
There is no doubt that the financial sector (including the most important industry: the money industry) is a primary example of this kind of disease. Bitcoin was born to be the cure. Bitcoin will bring many changes, disruptions and failures as well as much creativity. Bitcoin is creative destruction. Its impact on finance, commerce, and society will “move fast and break things”. It’s already doing it.
In order to do so, Bitcoin itself will have to change over time, at various levels, in order to become stronger and evolve after each attack it will suffer from. Usually, in the material world, only dead things don’t change. Third party solutions will rise and fall, and use cases that now we cannot even imagine will become important. There will be a huge turnover in applications, products, services, miners, economic gateways and even developers. And that’s a good thing, because, in general, change is good.
But Change in Bitcoin-L1 is Bad
Complex systems behave non-linearly, and this is sometimes counter-intuitive and even paradoxical. In order to find global maxima, a system often has to explore the space away from local maxima. In general, the global anti-fragility of the system requires some kind of fragility in its local parts; however, sometimes in order to maximize evolution on a global level, some fundamental parts of the system need to reach a level of static, almost immutable, adamantine robustness..........................
.
This is especially true for open infrastructure-level protocols and standards. This staticity of underlying standards is not enforced by politics or violence, but instead by particular kinds of market forces. Market dynamics operate in very different ways for open infrastructural protocols and for commercial products. Products can be easily replaced, surpassed, modified and forgotten, while successful technical open infrastructure-level standards are extremely difficult to change or replace.
A simple example of this is the (in)famous Facebook-based game, Candy Crush Saga. It was a success, but how difficult would it be to eventually replace it with other superior Facebook-based games? Not much, actually. But it would be much more difficult to replace the Facebook platform itself, on top of which the game is based, even with a better alternative (although not impossible, as seen with MySpace which was replaced by Facebook). It would be much harder to replace the World Wide Web platform, on top of which Facebook is based, and even harder to replace the HTTP protocol, on top of which the WWW was based. The probability of modifying the TCP/IP protocol, underpinning HTTP, is close to zero in the foreseeable time-frame (actually, even trying to “replace” its current version, IPv4, with a new improved version, IPv6, is taking decades and it turned out to be quite difficult).
The Internet is indeed a wonderful example of something that brought much disruption and change (just think of Napster, Bittorrent, Uber, AirBnB, Amazon, Wikipedia, WikiLeaks and Bitcoin Itself), but this has been possible just because of a sound, robust, and mostly immutable infrastructure, that made experimentation and change on top of it possible, easy and “socially scalable”. Disruption often faces powerful enemies, and the only reason why is difficult for political incumbent to stop some of the new Internet-based challengers is because they cannot easily change, influence, distort or corrupt the underlying infrastructure.
With Bitcoin, the Internet of Money, that’s even more true. Bitcoin’s natural enemies are many, strong, powerful, influential, rich, with widespread intellectual, cultural and popular support. In order to maximize the probabilities of its success in disrupting finance and economy in general, with fast and continuous evolution among on-top layers, it has to rely on a robust and adamantine base layer (L1), static, independent, resilient to political attacks, basically immutable. If Bitcoin’s core consensus was easy to mess with, it would be easily done: changes in the inflation schedule could be politically promoted and enforced (Keynesians: they are everywhere), privacy and fungibility could be attacked even more effectively than today (Orwell’s Big Brother is stronger than ever, with huge popular support), bailouts and distortions could appear to generate huge moral hazard and a caste of “more equal” animals (for a telling example, see Ethereum’s bailout hard fork to change transactional history and favour some investors of TheDao contract). In order to change things, Bitcoin has to be as immune to change as possible, at least at its fundamental level. The wise man builds his house on the rock.
But SegWit on Bitcoin-L1 is Good
Stability is a property that an object approaches and eventually reaches, and that’s hardly a starting point but a destination, especially regarding technology.
Many technological infrastructures and protocols, even the ones that seem impossible to change right now, did have to change a lot during the first stages of their development. Internet was no exception: the fact that the version of IP protocol we use now is 4, and not 1, tells a lot.
Is Bitcoin’s L1 ready to become robust and static, in order to allow for change and evolution around it and on top of it? In the mind of all the main developers working on this protocol, the answer is “not quite yet”.
It’s probably possible, for Bitcoin as is, to become the cornerstone for a global, huge, permissionless, open, censorship-resistant and free financial system, but that could be a lot easier with few last changes. There are many fixes that some developers would like to perform on Bitcoin’s L1: a proof of work change to reduce mining centralization, a dynamic block size, a dynamic block time (with adjusted reward), sidechains and/or treechains readiness, native merge-mining and deterministic pegging support, generic non-bitcoin assets issuing, native replay protection, smoother difficulty and/or reward adjustments, and so on. Some of these changes could have a huge impact over the nature of Bitcoin, some could even damage it, while some other changes would clearly be safe improvements without serious drawbacks.
Segregated Witness, or “SegWit” is a perfect example of the latter: it fixes a lot of stuff, it makes Bitcoin stronger, faster, safer, more elastic and more efficient, without breaking anything. SegWit has many “pros” and just one single “con”.
SegWit is a specific single patch, but it happens to have a lot of helpful side effects that span in different areas: from the fix of third party transaction malleability (a design flaw in Bitcoin that prevented, until now, many interesting “smart contract” applications), to the introduction of a script versioning (enabling future important upgrades to the script, like Schnorr signatures or new powerful op_codes), to the solution of the “quadratic sighash” problem, to the signature of input values (extremely useful for hardware wallets), to disincentive mechanisms against UTXO data grow, to an increase of capacity for blocks (up to four times the current one).
The only “con” of SegWit is that it is a change, and also a deep and important one. But if we had to choose some last changes to Bitcoin’s L1, before its crystallization into something reliable, stable and almost impossible to manipulate, it’s clear that SegWit would be on top of this list.
But SegWit as a Fork is Bad
Even in case of a clear and unambiguous win like SegWit, changing the validity rules in Bitcoin is something dangerous, that should be done with extreme caution and only if absolutely necessary.
As stated before, Bitcoin is designed and implemented to be difficult to change, even by important parts of the ecosystem (developers, miners, holders, economic gateways), if there is not the agreement of all the other parts.
While “software forks” are a typical and healthy feature of open source project in general, if they impact the rules upon which Bitcoin is relaying, they bring to way more dangerous “consensus forks”, where nodes end up to follow different rules. This could have strong economic implications, as well as heavy consequences for decentralization, security and censorship-resistance. If not implemented correctly, or if not adopted by the super-majority of “economically relevant” nodes, a “consensus fork” could cause a split in the Bitcoin network and in its native asset. This kind of spit would negatively affect the value and the security of the resulting “twin” coins, reducing network effects (value and security of the sum of the two sides of the split would be way lower than the ones of the original, unique chain).
Assuming economic players behaving rationally, if a change in the protocol is contentious, that change will just not happen. This is the most important feature of Bitcoin: without it, censorship and manipulation would be trivial to perform by a state-level adversary. Any consensus fork should be consensual, always.
Also, any consensus fork, especially if it bring consequences at the economical level, should be studied, reviewed, discussed and simulated for years, and tested intensively and for long before being delivered to production.
Last but not least, any consensus fork should be, whenever possible, of the type that is usually called “soft”: a backward compatible one, in which the existent rules of Bitcoin are not violated anyhow, but instead new rules are added to them, tightening the rule-set instead of broadening it.
There are many more dangers with backward incompatible “hard forks”: harmful network splits would be almost guaranteed, unless there is a real unanimity among economically relevant nodes (while with soft forks splits only happen if the new rules don’t get a majority of the economical weight and, as consequence, of the total hashing power); the changes that can be performed violating existing rules are unbounded and potentially unpredictable in scope, typology and effects (while, with soft forks, the degrees of freedom coming from the addition of new rules on top are fewer, and the possible attack surface is smaller); the time window to upgrade becomes critical and can lead to the ouster of slower to comply users and services.
It’s worth noting that Bitcoin never suffered a permanent hard fork in its entire history, while many new features and patch have been implemented via soft fork so far. Every single previous attempt to hard-fork Bitcoin under rush and without wide consensus failed: from Bitcoin XT in August 2015 (a fork led by R3CEV’s Mike Hearn, with an eight-fold increase in the maximum block size, automatically doubling every two years, a lower than usual activation threshold and a controversial penalty for Tor connections), to Bitcoin Unlimited and Bitcoin Classic in January/February 2016.
When it was first designed in April 2015, by Bitcoin Core Developer Pieter “Sipa” Wuille, SegWit suffered of almost all these problems: it was still a controversial change, it was a new and untested idea (with a lot of pressure from people trying to rush it), and it was thought to be possible to implement only as an hard fork.
But a Consensual/Tested/Soft Fork is Good
Contentious, rushed and hard forks are bad, but the current SegWit proposal is just the opposite.
Eventually, in the last year, the proposal started to get interest, traction, support and at the end almost unanimous consensus: technical criticisms of the idea itself were always very few, all coming from non technical and mostly politically motivated observers, and are now almost impossible to find in the debate. There is still some opposition coming from some Chinese miners (which could be explained by the fact that they are strongly opposed to Bitcoin’s privacy and fungibility, that SegWit would vastly improve, directly and indirectly), but it’s getting weaker and less popular every day. Even the business constituency led by investor Barry Silbert (including many Chinese miners as well), that after the failure of all the previous attempts is trying to promote yet another contentious hard fork, is committed to include SegWit in their alternative client: this shows that the change in itself is not very contentious anymore.
SegWit fork would not be “rushed” either: the general concept and the proposed implementation have both been studied, discussed and reviewed openly for almost two years, the actual code is running flawlessly on a specific ad-hoc testnet since December 2015, on the regular Bitcoin testnet since May 2016, on the Litecoin network (one could say: “another, more realistic, Bitcoin testnet”) since May 2017.
And, last but not least, SegWit would now be just a soft fork: in late October 2015, Core developer Luke Dashjr first proposed a method that would allow this upgrade to be implemented in Bitcoin as fully backwards compatible with all existing Bitcoin software (although software has to be upgraded to fully understand and use the new design). This implementation of SegWit is now pending activation, waiting for a very safe and conservative threshold of 95% of blocks mined to be locked in.
Actually, some controversy emerged precisely about this very choice to turn SegWit into a less dangerous soft fork, but the reasons are more political than technical.
First of all, some of the proponent of the previous, failed, controversial hard forks, had gone a long way to try to convince everybody that “a hard fork is actually safer than a soft one”: that kind of public exposure remains now a strong incentive, for them, to adverse the idea of SegWit as a soft fork (a vague “technical debt” argument is often used as an excuse in these cases, but it easily breaks against a simple comparison of the code of the two alternative implementations).
Secondly, it was discovered that, incidentally, the soft fork version of SegWit, unlike the hard fork one, would interfere with a secret optimization strategy developed and possibly used by some miners (the correspondent overt optimization strategy wouldn’t be affected, but it’s covered by a patent, so those miners allegedly had to use the covert version in order to bypass patent laws and to leverage this advantage in secret).
But Political Sabotage of Consensual/Tested/Soft is BadIt comes as no surprise that the same miners and ASIC producers that have been accused to run the secret optimization strategy, and that have been politically exposed as harsh critics of the current Bitcoin Core’s scalability roadmap (which consist of SegWit lock-in as the next natural step), are also modifying signalling in order to block the activation of the upgrade, so far.
Since the signaling standard for the activation was intentionally set very high, this political opposition has proved to be sufficient to stall the upgrade proposal for the foreseeable future.
On one hand, it could be possible to just wait, defending Bitcoin’s status quo until this political operation against the upgrade eventually runs out of resources, or until scalability-related pain (high fees and long confirmation times for on-chain transactions, slow and difficult implementation of more advanced off-chain solutions) is so strong that the pressure on the “vetoing” miners is high enough to overcome their incentive to block the adoption. Even if the current SegWit deployment expired before that happened, it would be possible to develop a re-deployment, and then another, and so on.
On the other hand, though, the same pressure that could be used to push those miners to signal for SegWit, could be leveraged by yet other, more dangerous, contentious, untested and rushed hard fork attempts (possibly politically motivated as well).
There is an alternative, which is in general still considered safe and fair: try to activate upgrades based on actual consensus among the users, somehow bypassing political sabotages of the signaling process.
While thresholds in mined block represent a strong and objective metric, which is difficult to replicate in more vague and ambiguous “real consensus” measurements, there’s actually a precedent for a solution to this kind of problem: the “rough consensus” concept as developed inside the Internet Engineering Task Force, or “IETF” (again, the Internet itself is a good metaphor to understand the dynamics of its latter and most promising child, Bitcoin). Inside IETF, changes to the protocol were adopted based on a consensus process, taking into account the different views among participants, coming to “at least rough consensus” on technical matters, excluding political and personal considerations, always avoiding to rely on a “majority rule” philosophy, using “humming instead of voting” and especially letting actual products of engineering (running code) trump theoretical designs. Full consensus, or unanimity, was always the primary goal, but strictly requiring it would have allowed single interested parties to stall the process in order to use their consent as prize for a bargain, a ransom or a political compromise.
In Bitcoin too there are precedents of methods for bypassing vetoes by specific interested parties: something like that was used a while ago to successfully activate the P2SH soft fork (BIP16), even amidst some opposition (in that case, though, opposition was not just political, but also strictly technical).
Almost the same method is today re-proposed for the SegWit soft fork, under the name of “User Activated Soft Fork”, or “UASF”. The basic idea of UASF is to release a client that at a specific date, in case the safe threshold 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. Self interest of many individual, rational miners should be able to overcome political strategies of the category, and soon this dynamic should generate a chain reaction, giving more profitability to miners of the SegWit fork and attracting more miners in return. Eventually the majority of the hashing power should move to the SegWit fork, and then something very strange would happen: the non-SegWit chain would be “deleted” with a giant “reorganization” of the blocks and with huge financial losses for non-SegWit miners (that’s because the blocks of any soft fork would be considered valid for legacy nodes, while the opposite isn’t true, and Bitcoin clients are programmed to always follow the valid chain with the most proof of work on it). For this reason, one could even expect that a majority of hashing power would move on the SegWit fork from the beginning, avoiding the temporary split and the reorganization at all.
It’s an interesting game theory strategy, that of course couldn’t be used to push for any kind of soft fork (including maybe new rules that make Bitcoin less valuable or useful), but just for that kind of soft forks that everybody knows to be fundamentally beneficial for the protocol, regardless of the political strategies applied in the signaling process for other reasons.
But Caution in Overcoming Political Sabotage is GoodEven if UASF was proven to be the right solution for the present political impasse, still there are many different ways to implement it.
There are currently two different UASF proposals, contending support of the users: BIP148 and BIP149. BIP149 could appear as more cautious: it proposes 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 signaling 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.
BIP148 is different: nodes running this version would start to reject non-signaling blocks (as well as signaling blocks built on non-signaling 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 going to merge this proposal (even if many developers of he group support it). The safest way forward, theoretically speaking, would appear to be BIP149, and Bitcoin should always follow the safest way forward. Isn’t that right?
But Causing Splits in the Name of Caution is Bad
Here is where the game-theoretical implications get very interesting. Of course, in a situation in which developers and experts still got to propose, discuss and chose their preferred solution, the safest choice for a UASF would be to support BIP149.
But, what if the current situation is such that economically relevant nodes (and some miners) will actually run BIP148 before August? Well, in that case we might have a network split, and the only fork risking from reorganization dangers would be the legacy one, especially for miners. So we can expect many miners and node switching away from that (also considering that the value proposition of a SegWit chain would be inherently higher than the one of a legacy chain).
At this point, other than be incentivized to stay on the BIP148 chain for individual advantage, every node and miner would find yet more advantageous to avoid the split at all, if possible, signaling BIP148 before August. Basically, the theoretically “safest” choice, in this scenario, would be actually very risky and irresponsible, while the theoretically “aggressive” choice would help to preserve both personal wealth for participants and the overall unity (and thus the overall value) of the network.
Even better: in order to avoid a similar, scary scenario at all, miners should be incentivised to signal and activate “normal” SegWit (BIP141) way before August 1st!
Of course there would be some political embarrassment in doing so, for miners that always vocally opposed the current normal Bitcoin Core scalability roadmap, but this could be addressed in many ways: politics is not about facts, just about perception and narratives, and many “rebel” miners could just create the narrative that they are not “surrendering” to the UASF menace, but maybe “conceding” SegWit activation in exchange of something in the future, even if they know they will probably not get this something anyway (for this political purpose, Barry Silbert’s contentious hard fork proposal could actually result useful, if miners “interpret” it as consisting in an activation of SegWit as is now, in exchange for a promise of future useless hard forks, that will never be kept).
If the point was to choose, promote and suggest how to perform a UASF, BIP148 could be considered maybe reckless, rash, even inconsiderate. But the point now could become how to behave in a scenario where BIP148 gets some support anyway. In such a scenario, paradoxically, the answer would be that supporting BIP148 would represent the safest and more conservative choice.
There are many possibilities ahead of us, right now. The threat of BIP148 could convince the the 95% of hashing power to support BIP141 as is, in order to avoid UASF entirely. If this happens, we will have SegWit locked in on Bitcoin mainnet before August, without any network split, and the act of running, supporting and promoting BIP148 couldn’t do anything now but help this outcome.
Otherwise, there is the possibility that the same threat could convince little more than a mere half of the hashing power, and this would be sufficient to grant the same outcome than before: no split, SegWit active soon, maximum utility in running BIP148 now.
A third possibility would be a (non zero) minority of hashing power initially supporting BIP148. In this case the chain would split, and the final outcome would depend mainly on where the economical majority is, because the market value of the mining reward would strictly depend on that. Still, the situation would not be symmetrical: risks of reorganization would affect only the legacy chain, and potential severity of this reorganization would grow with time, even if its probability would decrease. Also, one branch would have SegWit and all its benefits, while the other would not. This scenario could trigger many other sub-scenarios: the most likely would be a quick flip of nodes and miners to the BIP148 chain, but other outcomes would be possible, like a permanent split, either caused by an hard fork finally getting majority on the legacy side, or by quick adoption of checkpoints or “no148” counter-soft-forks.
Then there is the eventuality of no miner supporting BIP148 at all, but it seems extremely unlikely, and anyway it would probably not result in a “failure” of the proposal, but instead in the creation of a new altcoin from the BIP148 chain, following a Proof of Work change.
All thing considered, running, signaling and supporting BIP148 represents now the safest choice.
There are other considerations to add to this. It is possible, for example, that this situation doesn’t represent just a normal step in the organic evolution of the protocol, but instead something that Asimov fans would recognise as a “Seldon Crisis” of Bitcoin: a turning point where even social and individual dynamic can determine an increase of anti-fragility of the system or its failure. There’s the fact that centralization in ASIC production is now more serious a problem than Satoshi Nakamoto could have imagined in his darkest dreams. BIP148 could be, other than just a way to get SegWit and its many benefits soon, a decisive way to tell mining equipment monopolists that they don’t actually control Bitcoin, and that they never will.
This could be one of the last important changes, that will help to avoid other changes in the future, making Bitcoin’s L1 more immutable, and doing so, making the entire financial and economical world incredibly, excitingly mutable. This is why I will support and run BIP148, and I will do what I can in order to push all the firms, services and products I interact with to do the same. And this is why you should do the same.
