- Dec 16, 2015
- 2,806
- 6,088
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
majamalu
Active Member
- Aug 28, 2015
- 144
- 775
"how are we not living in a free market already?"
A common mistake between Bitcoin Core supporters is to confuse the inertia of the status quo with massive and enthusiastic support from Bitcoin users. This can be reduced to the following argument: "The market reveals the preferences of the people. Core is now the most used client. Therefore, now the market prefers Core ".
Although syllogistically valid, the argument contains two errors: one in the initial premise and the other in the conclusion.
First, it should be noted that in the absence of mechanisms for the market to efficiently express user preferences, it is not possible to know "what the market prefers" now. Under current circumstances (absence of a futures market for Bitcoin forks, among other catalysts), inferring that "the market prefers Core" is like inferring that a gagged woman is tacitly consenting the acts of her rapist, or that the inhabitants of East Berlin that did not risk their lives to cross the wall were in favor of Soviet policies.
Second, although personification of concepts in order to explain certain phenomena can be pedagogically useful, it should be recalled that the market is not a person who makes decisions. "Market" is a highly abstract concept that is useful to bring to an understandable level the extremely complex interaction between supply and demand for goods and services. If the demands from users (savers, investors, consumers, merchants, payment processors, etc.) are not taken into account (because they are irrelevant according to the central planners), the market, by definition, is not being taken into account.
A common mistake between Bitcoin Core supporters is to confuse the inertia of the status quo with massive and enthusiastic support from Bitcoin users. This can be reduced to the following argument: "The market reveals the preferences of the people. Core is now the most used client. Therefore, now the market prefers Core ".
Although syllogistically valid, the argument contains two errors: one in the initial premise and the other in the conclusion.
First, it should be noted that in the absence of mechanisms for the market to efficiently express user preferences, it is not possible to know "what the market prefers" now. Under current circumstances (absence of a futures market for Bitcoin forks, among other catalysts), inferring that "the market prefers Core" is like inferring that a gagged woman is tacitly consenting the acts of her rapist, or that the inhabitants of East Berlin that did not risk their lives to cross the wall were in favor of Soviet policies.
Second, although personification of concepts in order to explain certain phenomena can be pedagogically useful, it should be recalled that the market is not a person who makes decisions. "Market" is a highly abstract concept that is useful to bring to an understandable level the extremely complex interaction between supply and demand for goods and services. If the demands from users (savers, investors, consumers, merchants, payment processors, etc.) are not taken into account (because they are irrelevant according to the central planners), the market, by definition, is not being taken into account.
Last edited:
@freetrader There already is a clean-slate Bitcoin reimplementation with a good architecture (node separated from wallet) which you could extend:
https://github.com/btcsuite/
https://github.com/btcsuite/
- Dec 16, 2015
- 2,806
- 6,088
@Justus Ranvier : Thank you for that link, I really do need to take a close look at some stage (and teach myself a little Go) 
I would love to see a process of ironing out wrinkles in the core protocol, and then having a bunch of implementations in various languages emerge. I think it's practically inevitable that will happen, if Bitcoin can achieve wider success. Just like we have a proliferation of web frameworks today.
Perhaps that roadmap should be re-adjusted then, to mention existing clean-room implementations, and propose *more* of those, or rather start by proposing an architectural review and issue a revised architectural design for reference implementations to orient themselves along. Bitcoin could become something like the Rosetta Stone for computer languages in the future
But I suppose we might need to start at the beginning:
Translate the whitepaper into user requirements, and then into high-level system requirements, etc.
Unless this is all my ignorance again and someone else has done this already but their efforts just went unnoticed.
I would love to see a process of ironing out wrinkles in the core protocol, and then having a bunch of implementations in various languages emerge. I think it's practically inevitable that will happen, if Bitcoin can achieve wider success. Just like we have a proliferation of web frameworks today.
Perhaps that roadmap should be re-adjusted then, to mention existing clean-room implementations, and propose *more* of those, or rather start by proposing an architectural review and issue a revised architectural design for reference implementations to orient themselves along. Bitcoin could become something like the Rosetta Stone for computer languages in the future
But I suppose we might need to start at the beginning:
Translate the whitepaper into user requirements, and then into high-level system requirements, etc.
Unless this is all my ignorance again and someone else has done this already but their efforts just went unnoticed.
Last edited:
It's a shame, that it is written in Go (nothing against the language, I don't know anything about it to have an opinion). Just not too many Go developers around.
A new, clean client, written in C++ would be great imho. And more in different languages,
Before that, there should be a comprehensive (technical) protocol definition and something like the (non-technical) proposed "Bitcoin constitution", imho.
edit: Something like the temporary spam limit would have gone into the technical protocol part, not into the "constitution".
Wow, I didn't know I could get so excited by a roadmap!
Until I saw it on the roadmap, I hadn't heard of stigmergy. It is an interesting concept: our individual activities on the large collective scale are akin to termites building their nests and depend on communication driven 'social negotiation' and the resultant creative output.
Seen through the prism of stigmery, Core's disruption of free and proper communication has been critical: it ended the social negotiation opportunities of a large section of the community and thereby prevented their contribution to the creative output.
In the context of stigmery the btcfork allows all us disinherited termites to resume our social negotiation productively in the creation of a new nest.
Much kudos to you @freetrader and your fellow queen termites.
@satoshis_sockpuppet I don't have any real experience coding with Go, but I've been told it's easy for C programmers to pick up.
The reason to look at btcd IMHO is that it's the best-vetted clean room reimplementation of the consensus rules, and that it was designed from the beginning with a modular architecture.
The reason to look at btcd IMHO is that it's the best-vetted clean room reimplementation of the consensus rules, and that it was designed from the beginning with a modular architecture.
- Dec 16, 2015
- 2,806
- 6,088
Neither had I - kudos are entirely due to @singularity and others who researched the concepts. As far as I know Singularity came up with the relationship to stigmergy and phylogenetic trees.
I only contributed a tiny part of this document, and I'm looking forward to how it evolves.
@bluemoon, thank you, fellow termite.
Last edited:
pekatete
Active Member
THIS! This and this again.
Cue there are more core nodes on test-net running with the enum for compacts so BU on main-net for the last 6+ months should change the enum for xthins.
albin
Active Member
- Nov 8, 2015
- 931
- 4,008
This situation is abused politically by the Core devs in a manner that is truly shameless. The most recent example I can think of is the propaganda about how you can't hard fork b/c if you cap sigops to mitigate the O(n^2) hashing issue, then somebody out there might have a monstrously large (non-standard tx) nlocktime out there that the network has never seen which will be rendered invalid, and oh by the way what if they destroyed the private keys after producing that raw tx.
If we can't form a consensus and document what system behaviors are considered supported in the first place, then how the hell can we ever accomplish anything at all? How can you even begin to evaluate any claims about security if you have no idea what the intended behavior of the system is?
Even worse, with this whole "the code is the spec" business, aren't we just walking into a DAO-style nightmare should God forbid some catastrophic bug currently in Bitcoin requires some hardforking change? If there is no formal spec, how would you ever be able to justify what constitutes a bug? This whole thing is madness.
_mr_e
Active Member
- Aug 28, 2015
- 159
- 266
Something like that has been in active deployment for some time
https://bitco.in/forum/forums/iguana.23/Apparently it can sync the whole chain in 1 hour and can run as a chrome extension. Really looking forward to its release.
cliff
Active Member
- Dec 15, 2015
- 345
- 854
@freetrader
I haven't gotten through all of the fork roadmap yet (it is long and there's a lot buried in there), but I do have a quick comment or two.
First, It seems like the roadmap isn't necessarily about a fork per se - its more about creating a market conducive to a successful fork. Am I reading that correctly?
Second, the proposal here likely comes with some risks if it gets enough momentum (i.e., things that could go wrong). I think those risks could/should be identified and discussed up front (if not here, somewhere). Dont' get me wrong - not-forking also comes with risks and those risks are also topics within the scope of this document (or some other). Since part of the schtick here is transparency and choice, it would seem that a genuine assessment of the various risks and rewards could be laid for folks and that might help w/ the proposal's credibility.
Let me give you an example: if you're litigating a case and end up in a mediation session (which is more often than not in my locale), you're often asked by the mediator (often an expert/accomplished attorney in the topic area of the case) to prepare a mediation statement/brief for the mediator's eyes only. If you want to be taken seriously from the start by the mediator, its really helpful if your brief is really honest about both the strengths and weaknesses of the various positions in the case (i.e., you gotta reveal what you think your client's weaknesses are). A person that thinks they win all arguments all the time is just not very credible. Likewise, here, you might be able to distinguish this approach from the status quo by honestly assessing the risks and rewards of what is being proposed. Dunno if that makes sense.
Anywho - I'll continue reading.
I haven't gotten through all of the fork roadmap yet (it is long and there's a lot buried in there), but I do have a quick comment or two.
First, It seems like the roadmap isn't necessarily about a fork per se - its more about creating a market conducive to a successful fork. Am I reading that correctly?
Second, the proposal here likely comes with some risks if it gets enough momentum (i.e., things that could go wrong). I think those risks could/should be identified and discussed up front (if not here, somewhere). Dont' get me wrong - not-forking also comes with risks and those risks are also topics within the scope of this document (or some other). Since part of the schtick here is transparency and choice, it would seem that a genuine assessment of the various risks and rewards could be laid for folks and that might help w/ the proposal's credibility.
Let me give you an example: if you're litigating a case and end up in a mediation session (which is more often than not in my locale), you're often asked by the mediator (often an expert/accomplished attorney in the topic area of the case) to prepare a mediation statement/brief for the mediator's eyes only. If you want to be taken seriously from the start by the mediator, its really helpful if your brief is really honest about both the strengths and weaknesses of the various positions in the case (i.e., you gotta reveal what you think your client's weaknesses are). A person that thinks they win all arguments all the time is just not very credible. Likewise, here, you might be able to distinguish this approach from the status quo by honestly assessing the risks and rewards of what is being proposed. Dunno if that makes sense.
Anywho - I'll continue reading.
singularity
Member
- Aug 17, 2016
- 50
- 132
@cliff.
"Am I reading that correctly?"
Yes. While the goal of making the first fork is extremely important, it is more important that this situation never occurs again. To do this, a safe, simple and clean method of doing forks needs to be developed, as well as a better structure for development. Currently the power structure of the bitcoin economy is completely out of balance which is why we have developers colluding with miners in backroom meetings.
As to your other points; being upfront about the realities that we face is probably a good idea. Maybe you could make a pull request about the kind of things that should go into a section like this?
"Am I reading that correctly?"
Yes. While the goal of making the first fork is extremely important, it is more important that this situation never occurs again. To do this, a safe, simple and clean method of doing forks needs to be developed, as well as a better structure for development. Currently the power structure of the bitcoin economy is completely out of balance which is why we have developers colluding with miners in backroom meetings.
As to your other points; being upfront about the realities that we face is probably a good idea. Maybe you could make a pull request about the kind of things that should go into a section like this?
- Aug 29, 2015
- 536
- 2,597
@singularity "To do this, a safe, simple and clean method of doing forks needs to be developed, as well as a better structure for development."
I agree with this.
The BTCForks roadmap has many interesting ideas, but the focus should be on building the tools and knowledge to facilitate the creation of Bitcoin forks. This is the most important goal right now.
You don't need to decide right away the best way of how to deal with transaction replay, difficulty adjustment, and whether to change proof of work. Just make it easy to make forks, and try out different approaches. Think of it as a set of experiments. As the project accumulates experience, the knowledge gained can be used to improve the chances of success for more serious fork attempts in the future.
Think of it as a long-term approach, methodically building knowledge and capability.
I agree with this.
The BTCForks roadmap has many interesting ideas, but the focus should be on building the tools and knowledge to facilitate the creation of Bitcoin forks. This is the most important goal right now.
You don't need to decide right away the best way of how to deal with transaction replay, difficulty adjustment, and whether to change proof of work. Just make it easy to make forks, and try out different approaches. Think of it as a set of experiments. As the project accumulates experience, the knowledge gained can be used to improve the chances of success for more serious fork attempts in the future.
Think of it as a long-term approach, methodically building knowledge and capability.
The effect you're describing has a name:
http://www.huffingtonpost.com/david-shasha/what-is-pilpul-and-why-on_b_507522.html
singularity
Member
- Aug 17, 2016
- 50
- 132
@remile.
It is an excellent word to describe the current situation. An interesting question is; is pilpul occurring because of an ideology or because of an external incentive?
It is an excellent word to describe the current situation. An interesting question is; is pilpul occurring because of an ideology or because of an external incentive?
@singularity It comes naturally to some people. Others have to learn it.
Maybe to good:
...made a startling discovery: he was able to determine that the 525 bitcoin payment had come directly from Ulbricht himself by manually cross-referencing Force's and Ulbricht's bitcoin transactions. He was able to confirm this with a new website called Wallet Explorer.
From "http://arstechnica.com/tech-policy/2016/08/stealing-bitcoins-with-badges-how-silk-roads-dirty-cops-got-caught/2/"
[doublepost=1471479967,1471479015][/doublepost]
I read about it on reddit/r/btc. Sounded good, and it´s from jl777 but unlike Bitcoin Unlimited i hear/read seldom of IGUANA.Something like that has been in active deployment for some time
Apparently it can sync the whole chain in 1 hour and can run as a chrome extension.
Get it released as Bitcoin Dark? jl777 made much for Bitcoin Dark, but than Bitcoin Dark got "dark". But i read that it get "released" in the next time.
IGUANA is prominent hear at bitco.in but i don´t read through it because it´s not about bitcoin but SuperNET and all the code that is under the umbrella of IGUANA. Maybe we should ask in the IGUANA-subforum if they want to contribute to BTCfork?
- Dec 16, 2015
- 2,806
- 6,088
Scary shit (or not?)
I think Bitcoin needs to come up with a better way to run trustworthy, decentralized websites.
Perhaps this is all just an exercise in self-improvement.
I think Bitcoin needs to come up with a better way to run trustworthy, decentralized websites.
Perhaps this is all just an exercise in self-improvement.
Last edited:
