Core and Bitcoins Security Triads Implicit Double Random Development Path Walk - jalToorey/IdealMoney GitHub Wiki

On The Generalization and Transformations of the Classical BGP

In our generalization of the Byzantine Generals Problem we considered some different ‘transformations’ and generalizations that we feel might be useful for different applications especially with regard to concepts represented by Bohmian hidden variables theory.

Here we want to explore and apply some of those concepts with regard to different parts of the phenomenon we can blanket call ‘bitcoin’ (hinting that we may or may not encapsulate the traditional definition of bitcoin or more or less etc).

Bitcoin’s Security Triad: Security Considerations of the Bitcoin System as a Whole

Here we are suggesting that the macro interplay of bitcoin and its security considerations should be considered with respect to the checks and balances of 3 parties: users, miners, and developers (we are purposefully framing the triad like this).

The users are implicit because they are who the system is primarily or directly meant to serve.

The miners are hired to secure the network through their computational labor, and the developers are hired for their specialty in maintaining the software which is necessary for the system.

When viewed like this it is expected that the users will pay miners to secure the system, and miners in exchange will secure the system.

It's expected that the developers will work within open source constraints and that the nature of the system is that their required efforts scale and we rely on their knowledge and expertise in this regard (there is implicit trust etc.).

It should be understood that there IS asort of trust here with the developers with regard to the general users not having the expertise to fully verify code.

On Bitcoin’s Security Triad Strategy: UASF

We can see then how we model the security allows us to show that a UASF is a consensus between the users and the developers to make changes to the code and thus the protocol without any necessary consent of the miners:

UASF is an acronym which stands for User Activated Soft Fork in the context of Bitcoin.

In this example the miners were advertised as adversarial and the UASF was championed for its game theoretical strategy that forced miners to conform:

A UASF is the coordinated activation of a Bitcoin soft fork on a specified date and enforced by a of full nodes rather than relying on miners alone. In order to succeed, participating nodes must represent the so-called “economic majority” – users, exchanges and businesses with significant influence over the Bitcoin economy. A UASF requires developer, industry and user coordination. In the past, a UASF was successfully carried out to activate the P2SH soft fork (aka BIP16). On Feb 25, 2017, a contributor named Shaolin Fry proposed that UASF be used to activate Segregated Witness and later published details in BIP148.

We can think of situations where this could be the intent of the users and devs but where the implicit negotiation or contract effectively demands security without recompense from the miners.

On Other Bitcoin Security Triad Strategies

We can consider a scenario where miners and devs team up to force changes onto the users that all of sudden don’t treat them as the primary user. This could be thought of or represented as if the devs and miners are colluding-or simply as if the miners are themselves the devs.

On Segwit Vs ASICBOOST and the Security Triad Considerations

Consider Greg Maxwell’s explanation of the relationship between Segwit upgrade and ASICBOOST. He explains there would have been pains to KEEP the protocol COMPATIBLE had it not have been a covert hardware exploit:

A month ago I was explaining the attack on Bitcoin's SHA2 hashcash which is exploited by ASICBOOST and the various steps which could be used to block it in the network if it became a problem.

While most discussion of ASICBOOST has focused on the overt method of implementing it, there also exists a covert method for using it. As I explained one of the approaches to inhibit covert ASICBOOST I realized that my words were pretty much also describing the SegWit commitment structure.

The authors of the SegWit proposal made a specific effort to not be incompatible with any mining system and, in particular, changed the design at one point to accommodate mining chips with forced payout addresses.

Had there been awareness of exploitation of this attack an effort would have been made to avoid incompatibility-- simply to separate concerns.

What he said however is that it didn’t really matter because any upgrade to the system would have made ASICBOOST incompatible anyways:

But the best methods of implementing the covert attack are significantly incompatible with virtually any method of extending Bitcoin's transaction capabilities; with the notable exception of extension blocks (which have their own problems).

On Consensus of Protocol Development In Regard to the Players Represented By The Bitcoin Security Triad

It’s implicit at least until it's decided otherwise that there is a need for consensus of protocol development between these three parties.

We COULD think of this need for consensus as if each party is in fact championing for the long term benefits of the system and that there is still a difficult goal of coming to consensus.

On The Tele-Communications Field As A Transformative Tool Derived From The Generalization Of The BGP

One of the useful concepts we get from generalizing the BGP is the concept of a tele-communications field that allows us to manipulate its properties to represent different communication mappable scenarios.

This allows us to model the effects of many different types of systems or scenarios that aren’t just traditional computer network scenarios.

Having a FIELD allows us consider even a scenario where ALL POSSIBLE communications are IMPLICITLY ‘bugged’ etc.

On Classical Byzantine Considerations of The Classical Bitcoin Security Triad

Here we consider again our base case of the BGP formalization:

If all of the players are honest careers of the ‘msg’ then there is no BGP related issues, HOWEVER even though are using the Bitcoin Security Triad with considerations of consensus between mutually cooperative players (ie on a macro or large picture scale) it's obvious that each of the groups has their own inner complexity (it is our duty to map these ‘sub-group’ to Bohm concept of the sub-quantum levels and fields etc but not necessarily in this writing).

These underlying sub-nodes are important because it can’t really be assumed that one of these groups always does act with intent to the system and in a state of three nodes there is in fact theoretically no BGP solution.

On Consensus to Develop Versus Consensus Within Core

Here we wish to highlight a FIRM nuance that we haven’t heard before which is the difference between the security triad deciding to change, develop, evolve, roll-back, etc. the implicit protocol of the system via changes to the code versus the decisions of the developers on how to IMPLEMENT such decisions translated to code.

That is to say, in our model it is first considered that the Bitcoin Security Triad comes to consensus to move forward (ie 0 for no change, 1 for change in regard to a certain content/proposal) and then the developers that are hired to make the change have to come to their OWN internal consensus as to how to implement the request of the Triad consensus.

Core Consensus Considerations

If core is a secure development team/process we could consider it has its own internal security triad that makes decisions on how its code should evolve based on its customers expectations etc. And of course it's not just audits of the code but also the security of their processes so they don’t merge insecure code etc.

It is interesting to note then that in our model, the security triad could come to consensus and core, as the generally accepted maintainer, could veto this consensus and if they are bold or sneaky they could create a nefarious implementation undiscovered by users etc.

On Modeling the Bitcoin Security Triad Consensus Field as a Classical BGP Problem

Let us consider the concept of us ‘arranging’ our observations and or the actual communication between Bitcoin’s Security Triad participants (and all of the millions of people involved etc as a field of concerned participants). We want to consider if it is at all possible to arrange the problem closer and closer to one that models very much like the BGP problem.

We could then ask “How could we find Byzantine consensus in such a complex and ‘treacherous’ field of secrecy and deceit etc.?’

Then as we arrange the problem as such we WOULD be approaching an ability to use solutions such as Optimal Probabilistic Byzantine Consensus.

On the OPB Oblivious Common Coin As a Bitcoin Security Triad Development Decision

If we consider the OPB solution as our consensus mechanism for the Bitcoin Security Triad we can consider the output of the agreement which is the oblivious common coin flip.

The coin that flips either 0 or 1 could be used to consider a yay or nay to a development decision. This decision would then be passed to the development team chosen to implement the decisions. (These flips as a consensus result are akin to ‘retreat’ or ‘advance’ in the classical BGP formalization).

On the OPB Oblivious Common Coin As a Core Development Decision

We can consider the same framework and solution from Core’s perspective (today’s implicit choice for Bitcoin development). Core could make decisions on how to implement certain changes and use the BGP framework and solution to come to consensus on them.

On Rounds of Negotiation In Regard to Different Security Triads Searching For BGP Consensus

It is quite a natural mapping to consider that there might be multiple rounds of negotiation in which there is no consensus (and perhaps if we have modeled well enough the successive rounds would imply increased probability of consensus).

On The Problem of The Implicit Randomness of BGP

For those that haven’t really traversed the BGP problem (especially the OPB solution) they might not know of, or understand, the oblivious common coin flip.

The common coin flip is a randomized OUTCOME of the process of probabilistic byzantine agreement. It's NECESSARY that it's RANDOM because otherwise it can be predicted by those that would mean to game the consensus process if they knew the consensus results beforehand.

This means that using the coinflip as a consensus result would imply the decision made by the consensus to be RANDOM.

What Just Happened?

We just showed that if the complexity of the security system is such that probabilistic byzantine agreement is desired or especially necessary, the consensus output can ONLY be RANDOM.

If this result and observation was accepted, then at BEST adding the developers consensus to the protocol development INCREASES the random walk of it.

This is of course ON TOP of the random walk the Bitcoin Security Triad is also thus implicitly taking.

On The (Shadow) Tele-communications Field As An Exogenous Third Player

Our model allows for the tele-communication field to act as if it is a third player thus bring about considerations of hidden strategies and effects of having either existing or exogenous players having various controls over the communications of related and mappable systems

On The Byzantium Uncertainty Principle

It seems there is a comparable uncertainty principle here in regard to the need for Byzantine Consensus and thus the approach of a probabilistic output.