The LTB Network Forum

Upcoming Bitcoin Hard Fork & /r/bitcoin censorship

Back to Bitcoin & Beyond

Comments

• MaxEntropy

  

  Offline
  Posts: 28

  Adam says:

  How has he shown this? Can you link to anything? - Why is development any less centralized with two voting developers compared to five? are they both really centralized by any standard? Why does "Andresen being a poster child for XT but control lies in London" matter?

  --

  Software developers who can not lead the development activity are quickly moved aside - in development projects. Competent developers are unlikely to follow the designated lead developer, if the lead can not demonstrate leadership skills both technically and design.

  So... if Andresen has thrown the towel in with Bitcoin Core team and hence any possibility of achieving the bump to Block Size, then he is not seen as the lead developer.

  --

  Code changes incrementally... design features are slipped into the code base without distribution channels; 3rd party developers and customers... knowing. New software releases are always required, else the software becomes stale. This requirement introduces the need to keeping evolving the code base at different levels. There will be 'features' added that do not affect the backwards compatibility that advance someone's interests.

  It is the features that are slipped in that are subject to regional interests. Example, if Microsoft funded Bitcoin Core you would see Addon's and extensions and eventionally multiple implementations of Bitcoin Core... unique to Microsoft's interests.

  I do not sense that Reddit follows the code changes in Github closely... so who would know?

  --

  California should not outsource Bitcoin software development to the UK, London group.

  Posted on August 16, 2015 at 9:06 AM
  Permalink
  0 likes
• Cryptonaut

  

  Offline
  Posts: 1944
  Location: Canada

  @maxentropy

  So while your question, Adam, is constructive, it remains bizarre to the observer that Bitcoin Core guys would drop their work and jump on board for another system - just to fix a narrow Block Size issue.

  Bumping the Block Size can not be that difficult.

  --

  Something much larger is at play.

  It's not that difficult, and it isn't even really a whole other system. BitcoinXT is literally a clone of Bitcoin Core but with some minor changes, and then also the block size code which itself isn't terribly complicated. It's sort of like how there is lots of different variants of Linux

  Posted on August 16, 2015 at 9:07 AM
  Permalink
  0 likes
• adam

  

  Offline
  Posts: 1980
  Location: California, USA

  @maxentropy Adam raises valid objective questions... Adam says:

  Is there any possibility Gavin is pushing for the correct solution and in reality the developers you define as no longer being under Gavins control are just wrong in their opposition for whatever reason?

  --

  A software development group, developers, and management would never throw their code base over for a competing system. They would seek an incremental solution to problem with a code base that introduces the LEAST amount of risk, to the solution to the problem - Block Size; and to the overall system.

  Developers always introduce bugs with code changes.

  --

  So while your question, Adam, is constructive, it remains bizarre to the observer that Bitcoin Core guys would drop their work and jump on board for another system - just to fix a narrow Block Size issue.

  Bumping the Block Size can not be that difficult.

  --

  Something much larger is at play.

  From my perspective everyone is acting in their self interest and since any one objection derails taking any action, and not taking any action is the course of action desired by one side in the dispute, it seems perfectly reasonable that the other three core developers simply have taken their stand and will not be moved. If that is the case then for XT not to be proposed in this way is to concede to the other side that nothing will be done because they can prevent it by not giving consensus

  The fact that this fork attempt is happening would seem to suggest that they HAVE exhausted their other less controversial options and this is what they perceive to be the lowest risk.

  So the question comes back around to the one I keep asking: **If both sides believe they have the right answer, and those answers are mutually exclusive from one another (going with one neccesarily means you did not go with the other) and because of their different perspectives all believe they are right and will not change, how does a decision get made? XT would suggest that a worst-case is where we are now "putting it to the community" because developers failed to come to a consensus.

  Posted on August 16, 2015 at 9:08 AM
  Permalink
  4 likes
• cmason

  

  Offline
  Posts: 119

  @cryptonaut

  Really good points, Thanks.

  Posted on August 16, 2015 at 9:09 AM
  Permalink
  0 likes
• MaxEntropy

  

  Offline
  Posts: 28

  Adam says:

  Do you also have this curiousity for who is funding developers supporitve of the no-block-increase school of thought? Seems like everybody is obviously operating in what they perceive to be their own best interest in both camps.

  --

  I would have thought that if Hearn wanted to affect positive change, then he would have made a 'single code change' to the Bitcoin Core software for the Block Size fix. Anyone could have done this.

  He did not do that, he forked the project and has introduced a great many code changes.

  Why?

  If as Hearn and Andresen argue, that the Block Size change is so urgent... simply advocate for changing the Bitcoin Core.

  They are not doing that.

  Why?

  Posted on August 16, 2015 at 9:11 AM
  Permalink
  0 likes
• MaxEntropy

  

  Offline
  Posts: 28

  Adam says:

  Do you also have this curiousity for who is funding developers supporitve of the no-block-increase school of thought?

  --

  No... I expect that the developers simply need a source of funding. MIT stepped up after the fiasco at the Foundation became apparent.

  I still advocate for California to take the project back.

  Posted on August 16, 2015 at 9:14 AM
  Permalink
  0 likes
• cmason

  

  Offline
  Posts: 119

  I think the fork needs to happen precisely because the existing "Core" is paralyzed. This just isn't going to work long term. Viva la futura!

  Posted on August 16, 2015 at 9:14 AM
  Permalink
  1 like
• MaxEntropy

  

  Offline
  Posts: 28

  Hi Cryptonaut,

  Again... no one in software development rolls back to another fork eights months back in a live operational system... hundreds of code changes.

  This is the definition of bizarre.

  Posted on August 16, 2015 at 9:19 AM
  Permalink
  0 likes
• cryptowanderer

  

  Offline
  Posts: 4
  Location: South Africa

  @adam - you know I am at once your biggest fan and that I love playing devil's advocate.

  So, seeing as most of the debate here seems in favour of XT - what about Bram Cohen's response: https://medium.com/@bramcohen/bitcoin-s-ironic-crisis-32226a85e39f ?

  From what I can glean, I am still in favour of a blocksize increase (and Cohen's could well be a Nirvana fallacy as Hearn claims) but 2 out of 5 developers worries me and I'm not a fan of going along with the people shouting the loudest.

  "High transaction fees would be the first clear evidence of Bitcoin providing real value instead of just being a vehicle for speculation. It would also lead to miners directly earning more money, which is another reason they’d be well advised to not view this as a problem worth solving. In the long term the mining rewards for bitcoin will go away completely (there’s a strict schedule for this) and all that’s left will be transaction fees. Attempting to ‘solve’ the problem of transaction fees would in the long run undermine the security of Bitcoin even if it were done perfectly

  [...]

  Not having real transaction fees already is a major impediment to the development and adoption of real solutions, because the incentive isn’t there.

  [...]

  For the limit to be raised in advance to avoid hitting it is paternalistic and totalitarian. It also continues the current situation of transactions being allowed at a ludicrously subsidized rate at the expense of those running full nodes." - interesting stuff, but I'm less technical than you, so that is all I will say about it ;)

  Posted on August 16, 2015 at 9:22 AM
  Permalink
  1 like
• Cryptonaut

  

  Offline
  Posts: 1944
  Location: Canada

  @MaxEntropy if you want to talk about potential conflicts of interest etc... are you forgetting Blockstream, which mysteriously raised $21 million (with no apparent business plan) in funding late last year and consists of several of the Bitcoin Core devs, including multiple with direct commit access? All of whom happen to be unanimously against increasing the block size or making any serious change to the protocol, while at the same time building their own off chain systems and pushing the idea of bitcoin as a purely high value settlement network.... how is that not a conflict of interest?

  If as Hearn and Andresen argue, that the Block Size change is so urgent... simply advocate for changing the Bitcoin Core.

  They are not doing that.

  They did this for years. You can find posts on bitcointalk about how the block size limit is a bad idea, way back when it was first introduced. Discussion on removing the cap has been going on for years, you can even see Gavin talking about raising the limit back in October last year in his scalability roadmap post: http://blog.bitcoinfoundation.org/a-scalability-roadmap/ . Since the issue has been put in the spot light the past several months, over and over again Greg Maxwell and other Core devs have stated that they would immediately reverse any patch which includes the changes. They refuse to make any sort of decision that requires a hard fork, so now we are just doing it for them.

  Posted on August 16, 2015 at 9:25 AM
  Permalink
  0 likes

Post Reply