Gold collapsing. Bitcoin UP.

[cypherdoc]

if you doubt that everyone in the world will ever get an internet connection, here you go:

http://www.technologyreview.com/news/537956/emtech-digital-project-loon-head-details-how-the-balloons-interact/

[1713278026]

1713278026

[rocks]

i read about this here one time but i don't fully understand it nor the implications, not being a coder.

a spec is a written, detailed, normal language description of how the protocol works, is that correct?  wouldn't the current developer's guide qualify as something similar?

where as the code is what actually executes within the operating system and carries out the protocol rules?

and why NL, do you believe it would've prevented what we have going on now?

The Bitcoin Core is in such bad shape that fully specifying its behaviour is indistinguishable from impossible.

You could say this is Satoshi's fault. What we now call Bitcoin Core started out life as a prototype and evolved into its present condition - it is not an engineered piece of software.

Yes the Bitcoin core evolved in a convoluted and non-ideal manner, but I think the reason we have a situation where "the code" = "the specification" is more basic. Even if the Bitcoin core code was well designed, we would still be in the same situation where the code is the specification.

The reason is in a distributed system such as Bitcoin, there is no rule enforcer. i.e. a centralized entity with the power to tell the distributed system when it is not functioning according to spec.

The result is if the majority of nodes run a common set of code, that code becomes the specification even if the code deviates from the spec. The majority will follow that deviation, because it is the code they are running. If you think about it, that is exactly what a hard fork is. A hard fork is a majority of nodes agreeing to deviate from the existing specification. This holds true whether the hard fork was intentional or if the hard fork was unintentional (due to a bug).

Since the majority of nodes in the beginning ran the bitcoin core, that core became the spec, and any other implementation that deviated from the core would be kicked out of the system.

I think the best course of action would be to acknowledge that the prototype has served its purpose and retire it in favour of treating a non-prototype codebase as the reference implementation for which a specification can be written.

Even if we did this, and put a large amount of open effort into creating the a new perfect core, we would still have the above issue. That core would be the specification if the majority ran it, including all of it's unknown bugs.

The problem is that there are two very different things in play here:

• How humans think the Bitcoin protocol behaves
• What Bitcoin Core actually does

There is no case where a divergence between these two things is good. It means that despite years of effort Bitcoin Core is in some ways still a black box capable of surprising behaviour instead of predictable behaviour.

We have no guarantee that Bitcoin Core is self-consistent (like it wasn't in March 2013). Due to the way that code was written, it's likely that we never will have such a guarantee.

The only way out of this mess is to deprecate Bitcoin Core in favour of more-specifiable implementations as rapidly as possible.

If Bitcoin Core (and derivatives) were a minority of the nodes in the network, then the next time one of Bitcoin Core's surprises manifested it would be a problem that a minority of the network would need to fix instead of newly-discovered behaviour that the entire network would need to implement.

And that there is the solution IMHO, we need two things.

• A clear specification, and
• A situation where there are many separate individually developed cores run on the network, where no one core represents a majority of nodes

If you have those two things, then if any core has a bug, it is up to that core to fix itself to adhere to the spec. Without both, then we are back to the situation where a bug becomes the spec, no matter how well engineered the core is.  

[cypherdoc]

i read about this here one time but i don't fully understand it nor the implications, not being a coder.

a spec is a written, detailed, normal language description of how the protocol works, is that correct?  wouldn't the current developer's guide qualify as something similar?

where as the code is what actually executes within the operating system and carries out the protocol rules?

and why NL, do you believe it would've prevented what we have going on now?

The Bitcoin Core is in such bad shape that fully specifying its behaviour is indistinguishable from impossible.

You could say this is Satoshi's fault. What we now call Bitcoin Core started out life as a prototype and evolved into its present condition - it is not an engineered piece of software.

Yes the Bitcoin core evolved in a convoluted and non-ideal manner, but I think the reason we have a situation where "the code" = "the specification" is more basic. Even if the Bitcoin core code was well designed, we would still be in the same situation where the code is the specification.

The reason is in a distributed system such as Bitcoin, there is no rule enforcer. i.e. a centralized entity with the power to tell the distributed system when it is not functioning according to spec.

The result is if the majority of nodes run a common set of code, that code becomes the specification even if the code deviates from the spec. The majority will follow that deviation, because it is the code they are running. If you think about it, that is exactly what a hard fork is. A hard fork is a majority of nodes agreeing to deviate from the existing specification. This holds true whether the hard fork was intentional or if the hard fork was unintentional (due to a bug).

Since the majority of nodes in the beginning ran the bitcoin core, that core became the spec, and any other implementation that deviated from the core would be kicked out of the system.

I think the best course of action would be to acknowledge that the prototype has served its purpose and retire it in favour of treating a non-prototype codebase as the reference implementation for which a specification can be written.

Even if we did this, and put a large amount of open effort into creating the a new perfect core, we would still have the above issue. That core would be the specification if the majority ran it, including all of it's unknown bugs.

The problem is that there are two very different things in play here:

• How humans think the Bitcoin protocol behaves
• What Bitcoin Core actually does

There is no case where a divergence between these two things is good. It means that despite years of effort Bitcoin Core is in some ways still a black box capable of surprising behaviour instead of predictable behaviour.

We have no guarantee that Bitcoin Core is self-consistent (like it wasn't in March 2013). Due to the way that code was written, it's likely that we never will have such a guarantee.

The only way out of this mess is to deprecate Bitcoin Core in favour of more-specifiable implementations as rapidly as possible.

If Bitcoin Core (and derivatives) were a minority of the nodes in the network, then the next time one of Bitcoin Core's surprises manifested it would be a problem that a minority of the network would need to fix instead of newly-discovered behaviour that the entire network would need to implement.

And that there is the solution IMHO, we need two things.

• A clear specification, and
• A situation where there are many separate individually developed cores run on the network, where no one core represents a majority of nodes

If you have those two things, then if any core has a bug, it is up to that core to fix itself to adhere to the spec. Without both, then we are back to the situation where a bug becomes the spec, no matter how well engineered the core is.  

that's helpful tho i'm alittle confused about a couple things.

when you say different "cores", you mean like Bitcoin Core & btcd?  i thought everyone was referring to them as different "implementations" of the bitcoin protocol?

so is a spec a generalized description written in plain language that is supposed describe what the protocol does from a practical standpoint and thus acts like a broad ruleset to which different cores or implementations are to adhere?

[justusranvier]

Since the majority of nodes in the beginning ran the bitcoin core, that core became the spec, and any other implementation that deviated from the core would be kicked out of the system.

I think the best course of action would be to acknowledge that the prototype has served its purpose and retire it in favour of treating a non-prototype codebase as the reference implementation for which a specification can be written.

Even if we did this, and put a large amount of open effort into creating the a new perfect core, we would still have the above issue. That core would be the specification if the majority ran it, including all of it's unknown bugs.

What we should aim for is at least three full node implementations in the wild, with no single implementation having majority usage.

Also, a clear spec with extensive testing of each implementation's correctness.

As soon as we make a transition away from a monoculture (one implementation has a majority), we'll have an upper bound on the severity of likely chain forks. If 1 of n implementations disagrees with the other (n-1), then it's clearly a bug in that particular implementation that should be fixed.

The worst case scenario is a bug that causes more than one implementation to diverge at the same time, but that's no worse than what we've already been through in the past and the odds of that happening can be continually reduced with a good QA program.

[Adrian-x]

i read about this here one time but i don't fully understand it nor the implications, not being a coder.

a spec is a written, detailed, normal language description of how the protocol works, is that correct?  wouldn't the current developer's guide qualify as something similar?

where as the code is what actually executes within the operating system and carries out the protocol rules?

and why NL, do you believe it would've prevented what we have going on now?

The Bitcoin Core is in such bad shape that fully specifying its behaviour is indistinguishable from impossible.

You could say this is Satoshi's fault. What we now call Bitcoin Core started out life as a prototype and evolved into its present condition - it is not an engineered piece of software.

Yes the Bitcoin core evolved in a convoluted and non-ideal manner, but I think the reason we have a situation where "the code" = "the specification" is more basic. Even if the Bitcoin core code was well designed, we would still be in the same situation where the code is the specification.

The reason is in a distributed system such as Bitcoin, there is no rule enforcer. i.e. a centralized entity with the power to tell the distributed system when it is not functioning according to spec.

The result is if the majority of nodes run a common set of code, that code becomes the specification even if the code deviates from the spec. The majority will follow that deviation, because it is the code they are running. If you think about it, that is exactly what a hard fork is. A hard fork is a majority of nodes agreeing to deviate from the existing specification. This holds true whether the hard fork was intentional or if the hard fork was unintentional (due to a bug).

Since the majority of nodes in the beginning ran the bitcoin core, that core became the spec, and any other implementation that deviated from the core would be kicked out of the system.

I think the best course of action would be to acknowledge that the prototype has served its purpose and retire it in favour of treating a non-prototype codebase as the reference implementation for which a specification can be written.

Even if we did this, and put a large amount of open effort into creating the a new perfect core, we would still have the above issue. That core would be the specification if the majority ran it, including all of it's unknown bugs.

The problem is that there are two very different things in play here:

• How humans think the Bitcoin protocol behaves
• What Bitcoin Core actually does

There is no case where a divergence between these two things is good. It means that despite years of effort Bitcoin Core is in some ways still a black box capable of surprising behaviour instead of predictable behaviour.

We have no guarantee that Bitcoin Core is self-consistent (like it wasn't in March 2013). Due to the way that code was written, it's likely that we never will have such a guarantee.

The only way out of this mess is to deprecate Bitcoin Core in favour of more-specifiable implementations as rapidly as possible.

If Bitcoin Core (and derivatives) were a minority of the nodes in the network, then the next time one of Bitcoin Core's surprises manifested it would be a problem that a minority of the network would need to fix instead of newly-discovered behaviour that the entire network would need to implement.

And that there is the solution IMHO, we need two things.

• A clear specification, and
• A situation where there are many separate individually developed cores run on the network, where no one core represents a majority of nodes

If you have those two things, then if any core has a bug, it is up to that core to fix itself to adhere to the spec. Without both, then we are back to the situation where a bug becomes the spec, no matter how well engineered the core is.  

thanks nicely put, this also addresses the concerns and lack of trust many have of Gavin and Mike having proposed unpopular or inappropriate ideas in the past, ultimately it preserves the protocol and doesn't empower developers to change it but does encourage cooperation in addressing problems, this gives me confidence again.  

marcus_of_augustus poison pill is only a concern if we are switching Core for XT, but that's not what is happening, in fact I see Core under influence by Blockstream as the poison pill, but we are in fact distributing development, and moving the spec from Core to the majority, be there only 3 competitors at this time.

The irony, is we are seeing political positioning to maintain centralization, and the politicians are arguing that their version of centralized power is needed for decentralization.

I'm with Gavin on this one lets decentralize the gate keepers and preserve the network of users.  

[Fabrizio89]

It's all about that Greece

[rocks]

that's helpful tho i'm alittle confused about a couple things.

when you say different "cores", you mean like Bitcoin Core & btcd?  i thought everyone was referring to them as different "implementations" of the bitcoin protocol?

Yes, different implementations. That is better wording.

so is a spec a generalized description written in plain language that is supposed describe what the protocol does from a practical standpoint and thus acts like a broad ruleset to which different cores or implementations are to adhere?

Yes, a spec should be a plain language description on what is and is not valid. Even this can become complicated, but it serves a design point for any implementation. But as I said above, the spec alone is not enough. Even if you have a written spec, but there is a single implementation that is used by the majority, the implementation would trump the spec if a non compliant bug came up.

[rocks]

Since the majority of nodes in the beginning ran the bitcoin core, that core became the spec, and any other implementation that deviated from the core would be kicked out of the system.

I think the best course of action would be to acknowledge that the prototype has served its purpose and retire it in favour of treating a non-prototype codebase as the reference implementation for which a specification can be written.

Even if we did this, and put a large amount of open effort into creating the a new perfect core, we would still have the above issue. That core would be the specification if the majority ran it, including all of it's unknown bugs.

What we should aim for is at least three full node implementations in the wild, with no single implementation having majority usage.

Also, a clear spec with extensive testing of each implementation's correctness.

As soon as we make a transition away from a monoculture (one implementation has a majority), we'll have an upper bound on the severity of likely chain forks. If 1 of n implementations disagrees with the other (n-1), then it's clearly a bug in that particular implementation that should be fixed.

The worst case scenario is a bug that causes more than one implementation to diverge at the same time, but that's no worse than what we've already been through in the past and the odds of that happening can be continually reduced with a good QA program.

That sounds like an ideal plan. Not sure how to put it into action though. The current blocksize debate if anything shows how the current devs have conflict of interests in even considering this as a direction.

One option is to start with a move towards adoption of multiple implementations before making the "spec". If Bitcoin XT and btcd both gained enough adoption vs. the Satoshi client that all three were below 50% of the network, then we would now have a situation where a bug in the Satoshi client was no longer the spec, and the Satoshi client would have to quickly bug fix itself to adhear to the XT and btcd majority (and same for XT and btcd).

This situation would then force the drafting of a real specification. With one dominate implementation the need for a spec is diminished. But with several implementations the need for them to draft what is agreed becomes quite strong.

[rocks]

The irony, is we are seeing political positioning to maintain centralization, and the politicians are arguing that there version of centralized power is needed for decentralization.

It is highly ironic isn't it....

Humans as a species seem to love leaders and centralized decision making, we must be wired for it. Every example of a decentralize economic & political system that humans have organized (early US, early Rome are two examples) have been short lived and degenerated into the inevitable command and control organization model. But that's a different topic.

[smooth]

The result is if the majority of nodes run a common set of code, that code becomes the specification even if the code deviates from the spec. The majority will follow that deviation, because it is the code they are running. If you think about it, that is exactly what a hard fork is. A hard fork is a majority of nodes agreeing to deviate from the existing specification. This holds true whether the hard fork was intentional or if the hard fork was unintentional (due to a bug).

if the code is the specification then the code can't deviate from the specification. What happens if the code fails to converge to consensus is that the specification/code is proven to be broken, in which case the majority is forced to accept a change to the specification if they want to have a consensus system. In other hard-fork cases the majority may choose to accept a change, but it isn't forced.

Agree with Justus about multiple implementations.

[justusranvier]

One option is to start with a move towards adoption of multiple implementations before making the "spec". If Bitcoin XT and btcd both gained enough adoption vs. the Satoshi client that all three were below 50% of the network, then we would now have a situation where a bug in the Satoshi client was no longer the spec, and the Satoshi client would have to quickly bug fix itself to adhear to the XT and btcd majority (and same for XT and btcd).

This situation would then force the drafting of a real specification. With one dominate implementation the need for a spec is diminished. But with several implementations the need for them to draft what is agreed becomes quite strong.

Imagine if Bitcoin Core/XT, btcd, libbitcoin, BitcoinJ, Toshi, etc. all got together to make sure there was a common test suite that was a strict superset of all the relevant unit tests in each codebase.

The next step would be for each implementation to make sure to add any missing consensus-related tests to their own repositories. Repeat the process as necessary.

After all that was done, you could use the test suites as the basis of a spec.

Organizing that is something useful that Bitcoin Foundation could have done, instead of... whatever it was they did.

[Odalv]

One option is to start with a move towards adoption of multiple implementations before making the "spec". If Bitcoin XT and btcd both gained enough adoption vs. the Satoshi client that all three were below 50% of the network, then we would now have a situation where a bug in the Satoshi client was no longer the spec, and the Satoshi client would have to quickly bug fix itself to adhear to the XT and btcd majority (and same for XT and btcd).

This situation would then force the drafting of a real specification. With one dominate implementation the need for a spec is diminished. But with several implementations the need for them to draft what is agreed becomes quite strong.

Imagine if Bitcoin Core/XT, btcd, libbitcoin, BitcoinJ, Toshi, etc. all got together to make sure there was a common test suite that was a strict superset of all the relevant unit tests in each codebase.

The next step would be for each implementation to make sure to add any missing consensus-related tests to their own repositories. Repeat the process as necessary.

After all that was done, you could use the test suites as the basis of a spec.

Organizing that is something useful that Bitcoin Foundation could have done, instead of... whatever it was they did.

Bitcoin is protocol. -> valid chain of blocks filled with transactions

[Carlton Banks]

Agreed on all this formalise the spec talk, but this could only be another big (and possibly another fractious) debate at this stage of bitcoin's development. If you can get every interested party in the bitcoin development arena to agree, at this stage in the project, I'd be impressed. It would be best overall though, genuine marketplace for implementations. And a marketplace for forking too, but that's clearly coming anyway at some point or other, better to embrace it and keep the barriers to entry low.

[rocks]

Agreed on all this formalise the spec talk, but this could only be another big (and possibly another fractious) debate at this stage of bitcoin's development. If you can get every interested party in the bitcoin development arena to agree, at this stage in the project, I'd be impressed. It would be best overall though, genuine marketplace for implementations. And a marketplace for forking too, but that's clearly coming anyway at some point or other, better to embrace it and keep the barriers to entry low.

Let's not forget that the fact it is near impossible to get agreement on changes, is a very strong feature of Bitcoin.

[iCEBREAKER]

I'm working for Nick Szabo.

Szatoshi will back Back and Maxwell.

enough with the hints, spill the beans please.

The beans were spilled a long time ago, but most people (including StarbucksDoc apparently) weren't paying attention:

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  -David Chaum 1996

[cypherdoc]

I'm working for Nick Szabo.

Szatoshi will back Back and Maxwell.

enough with the hints, spill the beans please.

The beans were spilled a long time ago, but most people (including StarbucksDoc apparently) weren't paying attention:

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  -David Chaum 1996

i also like iCELatte.  has a nice ring to it.

[cypherdoc]

https://bitcointalk.org/index.php?topic=287.msg8810#msg8810

[kazuki49]

Gavin's strength is his maturity and calm demeanor, imo.  he'll win if it comes down to a battle.

Nope.  Szatoshi will back Back and Maxwell.  The cypherpunks will stick together (or hang separately).

You should change your handle to 'FrappuccinoDoc.'  

Bitcoin XT is a poison pill for all the newbs and unwary, certain bug fix commits that went into Core have already been omitted. Both Hearn and Andresen have been covertly anti-privacy from day zero, paying it only lip service when pressed. Don't trust it or them. Not to mention it is poorly maintained and totally untested. I can't believe I'm reading such a mad approach being championed on these pages ... it's like a twilight zone episode wtf are you people thinking !!! following Pied Pipers now?

Not only that friend, what else are they planing to change down the line? Like I said many moons ago, they will try change the emission and they will start making Bitcoin permanently inflationary, not that I'm against the model, I like Monero exactly because the disinflation but it is a severe rupture of Bitcoin's trust and social contract and all started with the project being hijacked into this obscure XT fork.

Neither me nor Gavin believe a fee market will work as a substitute for the inflation subsidy. It just doesn’t seem to work, economically.

https://medium.com/@octskyward/crash-landing-f5cc19908e32

Who said that? You guessed right, Gavin's vice-fuhrer.

[Adrian-x]

Gavin's strength is his maturity and calm demeanor, imo.  he'll win if it comes down to a battle.

Nope.  Szatoshi will back Back and Maxwell.  The cypherpunks will stick together (or hang separately).

You should change your handle to 'FrappuccinoDoc.'  

Bitcoin XT is a poison pill for all the newbs and unwary, certain bug fix commits that went into Core have already been omitted. Both Hearn and Andresen have been covertly anti-privacy from day zero, paying it only lip service when pressed. Don't trust it or them. Not to mention it is poorly maintained and totally untested. I can't believe I'm reading such a mad approach being championed on these pages ... it's like a twilight zone episode wtf are you people thinking !!! following Pied Pipers now?

Not only that friend, what else are they planing to change down the line? Like I said many moons ago, they will try change the emission and they will start making Bitcoin permanently inflationary, not that I'm against the model, I like Monero exactly because the disinflation but it is a severe rupture of Bitcoin's trust and social contract and all started with the project being hijacked into this obscure XT fork.

Neither me nor Gavin believe a fee market will work as a substitute for the inflation subsidy. It just doesn’t seem to work, economically.

https://medium.com/@octskyward/crash-landing-f5cc19908e32

Who said that? You guessed right, Gavin's vice-fuhrer.

if they get there way, they wont have any power to change things it will be a democracy of users who decide, luckily Monero doesn't have a nullc yet. 

[justusranvier]

Not only that friend, what else are they planing to change down the line? Like I said many moons ago, they will try change the emission and they will start making Bitcoin permanently inflationary, not that I'm against the model, I like Monero exactly because the disinflation but it is a severe rupture of Bitcoin's trust and social contract and all started with the project being hijacked into this obscure XT fork.

If they try to make a change like that, users will migrate away from their fork just as easy as they migrated to it.

In the end, the developers don't actually have any power - they can only product the software which users want or refrain from doing so.