Gold collapsing. Bitcoin UP.

[Peter R]

@Zangelbert Bingledack

I see! In that case, what we need to do is show them that what requires broad consensus is changing Bitcoin's nature. From that point of view then, changing a historically-rarely-used line of code to preserve the economic paradigm that Bitcoin has always operated under might then appear as the right thing to do from the moral/image perspective.

I think so much of the debate has been biased by the historically dominant "software" viewpoint. The word "hard fork" suggests that something about Bitcoin's nature would change, when really the only thing "changing" is Satoshi's temporary patch. And the only reason we're changing it is to preserve Bitcoin's nature.

 

[rocks]

sounds like XT is in a holding pattern (after all its prime purpose BIP101 is finished) and that Hearn was expecting industry leaders to step up and support XT before now. He can only work with no salary for so long, unless OFC he bought lots of BTC early.

To some extent I think XT has been a distraction and source of FUD and confusion.

Mike originally implemented BIP101 in both core and XT. However since the patch was rejected from core, XT became the only client with BIP101 implemented. Since XT is an "unofficial" client, blockstream, thermos et. al were able to create FUD and attack XT and BIP101 as "not bitcoin".

I think the right way to circumvent this is to bypass Peter and Greg's check-in control and implement BIP101 directly in core. i.e. Create a new Bitcoin 0.11.2 branch on github and add BIP101 to that branch.

Now we would have the "core client with BIP101". I think this is easier to accept for most people and is very hard to attack as being "not bitcoin". With that we would have two competing clients.

- Bitcoin core 0.11.2
- Bitcoin core 0.11.2 with BIP101

Both are "Bitcoin", both are "official", both offer identical code bases with just BIP101 as the diff, etc., etc.

I think this would be easier for people to adopt and eliminate the potential for FUD. They are identical versions of Bitcoin just with and without BIP101. Organizations could also adopt BIP101 and still state that they are running the "official" client. I think there has been a fear of running "unofficial" clients and being attacked for that, this path offers organizations cover and a defense that they are still running the same and official Bitcoin.

This also goes after the only source of power Peter and Greg have, which is check-in control of the "official" client. This is open source, just branch and release the same "official" client with BIP101 added.

Going forward this could be repeated for each new version released. i.e. When core 0.11.3 is released, release a core 0.11.3 with BIP101; when core 0.12, release a core 0.12 with BIP101.

 

[Justus Ranvier]

I think the right way to circumvent this is to bypass Peter and Greg's check-in control and implement BIP101 directly in core. i.e. Create a new Bitcoin 0.11.2 branch on github and add BIP101 to that branch.

BitPay already did that a few days ago.

Their GitHub repository has a BItcoin Core fork + BIP101 branch in it.

 

[cypherdoc]

@Justus Ranvier

i didn't see that. you gotta link? did they provide any commentary as to why?

 

[Peter R]

@cypherdoc: yes, they said they were doing internal tests in preparation.

I wonder if they would consider hosting binaries on their site (should the stalling continue)?

 

[rocks]

@Justus Ranvier

That is awesome and hopefully indicates how ecosystem participants are going to proceed. Coinbase indicated they had backup plans if blockstream did not move. Maybe this is it.

This is also the 2nd idea I posted this month only to find out it was just recently started and/or implemented, not sure if that means I should stop posting or not

 

[Justus Ranvier]

Here's the GitHub link:

https://github.com/bitpay/bitcoin/tree/0.11.1-big-blocks

Pretty sure there's a Reddit post about it somewhere too.

 

[rocks]

@Justus Ranvier

Even the readme is identical. It is a straight up identical version of core that just has big blocks added.

I love it.

I am trying to guess how thermos and team will attack this as "not bitcoin". So far their definition seems to have been alternative clients. But if this IS the core client it is hard to attack it as an alternative client.

The only way I can see to attack this version as "not bitcoin" is to say bitcoin is defined to only be what the maintainers say it is. That seems to be a difficult approach though since the sentiment is counter to the ethos of bitcoin's decentralized nature. Peter and Greg do not own bitcoin.

They have also used the "we are the technical experts" attack as well. Again this seems hard since bitpay and other major firms obviously are technical experts as well.

Are there any other ways they can try to use to counter this version? It seems to address most of the main sources of FUD they've used so far.

 

[Peter R]

Are there any other ways they can try to use to counter this version? It seems to address most of the main sources of FUD they've used so far. -- @rocks

I think BitPay would need to make binaries and host it on a webpage--or endorse a third-party organization doing so. It needs to appear like it is a "finished product."

Regarding FUD, I would expect small-block proponents to claim that this represents a corporate takeover.

 

[rocks]

@Peter R
Good point, but isn't that a situation of the pot calling kettle black considering the maintainers against work for blockstream.

At least bit pay and others serve the community and have large numbers of users. Who is blockstream serving besides themselves?

 

[Peter R]

@rocks: I completely agree that it would be the pot calling the kettle back. But I think that FUD will resonant with some people, nonetheless.

To me it seems that "Bitcoin Core" still has this aura around it that it's maintained by the community, whereas other implementations could only ever be controlled by a small group (I remember the FUD about XT being MikeCoin although I couldn't see how its governance was practically different than Core's). Somehow we have to break that, I think. Perhaps by hitting harder on the Blockstream Conflict-of-Interest while softening up on Blockstream in general might be good. There is so much misinformation about Blockstream that the real issue of its conflict of interest with respect to Core gets diluted.

 

[Zangelbert Bingledack]

@Peter R

I've tried the "it's actually more preserving of the status quo / social contract to fork to keep the cap high above normal transaction load as it always has been, rather than keeping 1MB or keeping the cap below demand to raise fees" angle before but surprisingly people seemed unconvinced by it. At the time I thought it odd but it's cleared up by your (and maybe @cypherdoc's) point that people are perceiving the software as where the consensus happens, rather than in the intent of the user.

On that view, by using the Core software I am committing to all changes the software has scheduled to go into effect even years later, such as the 1MB cap. The view makes no allowance for my running the software for a time with the understanding that the cap is temporary and/or my intention to run a different implementation if Core doesn't offer a larger blocksize implementation. The argument that the social contract is for a fee-market-forcing low cap above 1MB is even more tenuous, as now we're down to interpreting my use of the very same software as consenting to one stance "implied" in that software when it is equally arguable that another contradictory stance is also so implied.

Bottom line: it is untenable to argue that running software implies agreement with any social contract. The users' intent matters. Nodes aren't just robots running software, they're people! People who 1) largely can't or won't go through the trouble to modify the Core code themselves to change parameters and 2) even if they could and wanted to they would wait to do something like raising the cap until they were sure it wouldn't result in dealing with blocks that would be later orphaned.

Wonder of wonders, Bitcoin Unlimited addresses 1 by enabling all users to select the cap and addresses 2 by enabling users to set a block depth at which they will ignore their set cap in order to track consensus.

 

[Zangelbert Bingledack]

@rocks

I thought there was already a "just big blocks" version of XT, which I assume means the same thing as Core+BIP101. Anyway over on reddit especially the argument has been based around not having consensus for BIP101 and such a fork therefore being an "altcoin," with the XT/MikeCoin FUD just used as icing. Having XT out of the picture would at least remove that distraction, but the "contentious hardforks are an attack on Bitcoin" FUD would remain.

@Justus Ranvier

Couldn't Core do something evil like release the next version of Core with changes that are incompatible with the code for BIP101? I assume that could be worked around, but it might be a hassle and take time. Especially if they got really vindictive and deliberately murkified parts of Core in a way that made it really thorny to go over their chosen blocksize limit. If so, it seems Core has an inherent advantage as long as people are forking off their repo and as long as they have the bulk of the coding expertise on their side. Thoughts?

 

[Justus Ranvier]

Especially if they got really vindictive and deliberately murkified parts of Core

That would be a great way of squandering any residual goodwill they might still enjoy.

 

[albin]

Couldn't Core do something evil like release the next version of Core with changes that are incompatible with the code for BIP101? I assume that could be worked around, but it might be a hassle and take time.

I'm not really 100% clear on the details, but is the version bits situation potentially exactly what you're describing?

 

[rocks]

Might be timely to re-mention this news, and this was from back in August well before all of the craziness, since then more companies have come out supporting BIP101

7 Leading Bitcoin Companies Pledge Support for BIP101 and Bigger Blocks
https://bitcoinmagazine.com/articles/7-leading-bitcoin-companies-pledge-support-bip101-bigger-blocks-1440450931

BTW, whatever happened to KnC, they were supposedly behind BIP101 but never mined any blocks. Just waiting until there is enough support before flipping the switch?

 

[awemany]

Might be timely to re-mention this news, and this was from back in August well before all of the craziness [...]

I follow Bitcoin since somewhere in 2010. I eventually made my reddit account specifically for the purpose of addressing or at least trying to address the grave danger of a stuck blocksize. That is pretty much exactly 2 years ago now (had reddit cake day a couple days, yay ). I saw back then that small blocks are going to be the wedge that people are trying to drive into Bitcoin to destroy it. Unfortunately, my foresight on this has been proven absolutely correct.

Ever since I read and understood the initial worry about this (by BCT user caveden AFAIR), I am on this topic.

If anyone doubts me - look on what topics I wrote on reddit regarding Bitcoin since I created my account. Basically just that: The blocksize issue.

This thing is crazy since a long time, and if anything it shows me how many people are naturally in the gullible to stupid corner.

Of course, I also understand that you specifically are coming from another angle - that of comparing the level of craziness now to that of a few months back

But I will never accept people saying that no one could see this shit coming.

 

[Zangelbert Bingledack]

Luke's new release offers opportunities for education.

 

[Zangelbert Bingledack]

@Justus Ranvier

Indeed. As a non-coder I've always wondered just how amazing at their jobs the Core dev team really is. If they are replaceable then the problem seems easier, but if they are truly world class it seems hard to overcome their hold.

 

[sickpig]

@Zangelbert Bingledack re: is Core dev world class at coding.

I'm a developer myself and I've a mixed feelings about the ability of Core devs.

They're doing and did amazing things. Just think about Pieter Wuille libsecp256k1, btc core 0.12.0 will ditch OpenSSL in favour of this new lib to perform ECDSA validation. In tests they made such change, along with cli option -dbcache=8000, will decrease IBD drammatically.

Just to give you an idea it took 3h22min to go from a fresh bitcoind install to a full functional instance with all the blockchain downloaded and validated.

2015-11-08 19:17:23 Bitcoin version v0.11.99.0-332a5b0 (2015-11-06 08:30:43 +0100)
2015-11-08 22:39:21 UpdateTip: new best=000000000000000009641f7a3734cfb9fe861c20a1aa77e8d1d6780913728bfe height=382556

The same level of crafting apply to BIP 62, even if not to improve performance, but to fix a form of malleability.

On the other hand it seems like they don't pay attention to more normal thing like the one preposed in this PR: "Compress Blocks before sending". Maybe they find more simple things boring. I don't see 15-20% efficiency increase storage wise as not worthy, though.

The same apply to DB stuff in general. Be it mempool or LevelDB block storage. Those are just anecdotal evidence and gut feeling, though.

That said I think they have a common view on the economic/political angle and that in general could hinder their work on the technical side.

EDIT: ofc they were able to get 3h22min just because they have almost not constraints in terms of download bandwidth.