Gold collapsing. Bitcoin UP.

[rocks]

@solex
True, but people going to reddit or bitcoin.org to get their client information are probably not running full nodes anyway, but SPV wallets.

Also, Thermos' moral authority for starting to censor goes away (not that there was any). His excuse was always that core is the only legitimate client and people can't promote other clients.

Well, now core would be frozen and the blockstream client would be on equal footing as every other client. Stating that people can only promote branch X would be beyond absurd. I think he would have a hard time keeping that clamped down and would have to let people promote various clients, otherwise it's just too obvious even for those not paying attention.

If this is done though, I doubt it would be done and just left to having people going to reddt for info. It would be done with statements from major merchants and other main figures on their path. It would be done with a very strong PR campaign.

And it should be done with Gavin (if it is him) as a neutral party not producing any other client. Gavin is neutral in shutting down core, but Coinbase/Bitpay/KnC/etc are vocal in a scaling client that does not involve Gavin. Gavin only gets asked to join a winning path after the market has decided (unless Maxwell wins in which case I sell every coin).

 

[solex]

I hear you @rocks but Thermos said when BIP101 was committed to XT that he will point bitcoin.org etc to a new repo to support BS/Core if necessary. I just feel that the different clients won't start with an equal footing, but Gavin and Jeff will lose remaining influence on the majority client. It won't be much of a successful strategy, unfortunately.

 

[rocks]

@solex Yes, there is that and it definitely would be a risk. But which do you think is more powerful? a) Thermos pointing bitcoin.org to blockstream client, or b) Coinbase, Bitpay and Bitstamp all saying they are using client X which follows a BIP101-only path and that people that want to use their services need to use a compatible client? And that is followed by emails to their user base on upgrade requirements.

Bitcoin has grown a lot and is much larger than /r/bitcoin and bitcointalk.org, much much larger. I bet more than 90% of people who use Bitcoin have never been on either of those forums. They will get their information on the fork through the merchants and SPV wallets they use.

It's ugly all around, but that is democracy. The advantage of this democracy is we can exit if we don't like the direction.

Another thing to consider is one of the best things we have going is Maxwell as the PR agent for the blockstream path. I still think his communication in that scaling conference wrap up that was posted here last week was horrible. He does not seem to know how to make a convincing argument, he relies more on authority and manipulative arguments IMHO. I think most see through that. And if not, well we will end up on different chains.

Lastly, if a majority of users and miners want the blockstream path, well then I want to know that NOW so that I can rebalance my portfolio out of Bitcoin. (NatGas MLPs have crashed and there are some amazing opportunities in that space).

 

[Windowly]

The problem with XT is that it premises on the fact that 75% of the miners are on board. I think we should put out a different version (or maybe BU) that doesn't depend on miner majority but on economic majority.

Perhaps set a certain date in the future when all exchanges, merchants and miners who want to join will accept big blocks and stick to that date regardless.

 

[rocks]

@Windowly That is what I meant by a "BIP101-only" client. A version of BIP101 that locks in the upgrade by block X, meaning only blocks that accept the upgrade are validated as valid blocks. Blocks without the BIP101 version upgrade would be rejected. This would fork the chain into a BIP101 only chain and an older 1MB only chain. Everyone could continue to use the chain they prefer, that is a peaceful democracy.

In this scenario the SPV wallet providers become very powerful. Which way Mycelium and others go could decide it. Does anyone know what the main wallet devs have stated on their thoughts regarding scaling?

 

[smooth]

Greetings thread. I was inspired to come back and say hello after reading Peter R's excellent subchains paper.

Nice work Peter R.

 

[freetrader]

@Windowly That is what I meant by a "BIP101-only" client. A version of BIP101 that locks in the upgrade by block X, meaning only blocks that accept the upgrade are validated as valid blocks. Blocks without the BIP101 version upgrade would be rejected.

The good old 'fork me harder' approach. If hardly anyone's producing BIP101 blocks by the cut-over date, what's the use?

I think the sensible way is to pick up on the wishes of the majority of miners (scaling conference statements are probably a good indicator) and ensure they are factored into such a hard fork version. Am I incorrect in believing Gavin had efforts underway ahead of the conference to consult miner opinion?

 

[Peter R]

Greetings thread. I was inspired to come back and say hello after reading Peter R's excellent subchains paper.

Nice work Peter R.

Thanks!

And welcome to the forum, smooth! You're one of the best around when it comes to logic and critical thinking; it would be great to see more of you.

 

[molecular]

@Zangelbert Bingledack

Yes, they would just switch to a new repo. But it would be a different repo and I think people would notice the change and wonder what happened. Then they'd see Gavin (and Jeff?) on a new repo too and people might wonder "what is the real bitcoin now"?

Just brainstorming ways to get people to make an active choice, rather than blindly follow Core due to its historical ties to Satoshi's code.

Bad idea?

Not a bad idea (if it works). If it doesn't work, it gives them even more weight to their argument. So It's kind of risky. Personally, I would probably go for it (but I like taking risks, even stupid ones, so I shouldn't be the judge)

The situation pisses me off to no end. That attitude! Todd saying: "see, the users and miners voted for our change xyz" while he knows full well the miners do it out of fear and the users out of reluctance (and fear).

They win by default, it's not a fair vote. It's as if the non-voters were counted in their favor.. and also the people that aren't aware of any vote taking place (a LOT of people).

If there was no 1 MB limit currently and they would have to introduce it in a fork of their own ("bitcoin_limited"), how many do you think would switch to the fork? Yep: 0

 

[sickpig]

Greetings thread. I was inspired to come back and say hello after reading Peter R's excellent subchains paper.

Nice work Peter R.

@smooth long time no see. Eventually you joined

I'm glad to have you here and I'm looking forward your contributions.

 

[Peter R]

Ok so it looks like small-block proponents got wind of the "lock-the-GitHub-repo" idea, both in the XT R3KT thread and on /r/bitcoin.

Although several people already appear to support this idea, the two common adverse reactions are:

1. This would be censorship.

2. This would be sabotage.

I think the censorship argument can be refuted by making it clear that the repo would be shut down permanently. It would kick everyone out--not just some people.

I think the sabotage argument can be countered with the argument that the governance model of Core is one of "full consensus" which has now broken down and resulted in gridlock [1]. It is fairly easy to show this because Gavin and Jeff (and Luke and Peter Todd) didn't agree to Greg's proposal. Gavin--as the controller of the repo--is thus retiring the project to allow for an amicable parting of ways.

The locking of the repo would be to precipitate a rebirth, as it were. A metaphorical burning of Core to allow the green shoots of new implementations to grow from its fertile ashes. In addition to making progress regarding the block size limit debate, this would have the added benefit of encouraging decentralization in development.

The question is would it work. I don't know. I think the best chances would be if this were done in coordination with significant players such as Coinbase, BitPay and other major businesses.

[1] See @Pecuniology's recent post for an idea of how to frame this from a decision-cost perspective.

 

[sickpig]

The alternative is to present better solutions and let Mr Market apply the pressure. BU and XT with subchains has got to be the way forward. If @Peter R is too busy then I volunteer to draft BUIP002 to get started.

FWIW I think this would be a big step in the right direction. I can't do much to help except for proof reading the BUIP002 drafts, though.

edit: grammar

 

[Peter R]

@sickpig, @solex, @theZerg

When is the right time to write a BUIP? Take subchains for instance. Wouldn't it make more sense to code up something rough, run some tests on testnet, and then write the BUIP after we have some results to examine? Or is the BUIP process designed to also organize projects at an earlier stage, to help focus the effort?

 

[sickpig]

@Peter R

you're right. An implementation is an integral part of a BIUP.

We should start writing the documentation *and* code a proof of concept implementation.

Unfortunately @theZerg is in the middle of BU release, maybe if he's interested he could start working on it after the release. Maybe @davecgh (or even @Gavin Andresen) could bite the bullet.

 

[awemany]

@Peter R.: Regarding a core freeze, I think it would be indeed more productive if Gavin, Jeff or someome with influence on the core team would instead lead an initiative to at least 'agree to disagree'.

I think a lot would be gained by coming to an agreement that Development is decentralized and that there are several independent implementations of Bitcoin, such as XT, BU,Core, btcd. If bitcoin.org would list them equally, like a Wiki, that would be great.

And Bitcoin Core opposing or derailing such an effort would also speak for itself.

 

[Peter R]

@awemany

That is a nice way of looking at it. Under those conditions, would you suggest retiring the present Core repo? If not, who would keep it?

 

[awemany]

@Peter R.: Good question. This goes back to how much symbolism we attribute to the word Core.

I tend to think: Let 'them' have it (To make the farce more apparent, I'd personally even say: In a big Internet ceremony with shared banners and all, give the name 'Bitcoin Core' to Greg himself ;-)

I think we ourselves should not be stuck in 'Core is the reference' either. Given that there's also a plethora of similarly good names, such as Bitcoin Original, Bitcoin Reference, Bitcoin One, Bitcoin Zero, Bitcoin Unlimited, ...

We should also make an agreement that no client calls itself the reference or in any way elevates itself above other implementations due to its heritage. This is software, dammit, features, stability and so forth count.

However the 'points of entry' depending on just the Bitcoin brand, such as the github.com/bitcoin,
reddit.com/r/bitcoin, bitcoin.org and bitcoin.com (bitco.in?) should, under such an agreement, list all available clients equally.

I see only slim chances of something like this gaining traction. However, the offer/initiative alone will expose more of the hypocrisy.

 

[Windowly]

@Windowly That is what I meant by a "BIP101-only" client. A version of BIP101 that locks in the upgrade by block X, meaning only blocks that accept the upgrade are validated as valid blocks. Blocks without the BIP101 version upgrade would be rejected. This would fork the chain into a BIP101 only chain and an older 1MB only chain. Everyone could continue to use the chain they prefer, that is a peaceful democracy.

In this scenario the SPV wallet providers become very powerful. Which way Mycelium and others go could decide it. Does anyone know what the main wallet devs have stated on their thoughts regarding scaling?

I like that. Wallet providers would be powerful. Exchanges and merchants would also have a powerful voice.

Even if we are a minority fork (miner wise) in the beginning if enough exchanges and merchants sign up to fork, the miners will come around eventually. Also we could give them a decent warning, something like you said, by block this-and-this number we the undersigned will start making and accepting bigger blocks.

This, imho, seems like the only way forward.

 

[Zangelbert Bingledack]

Under this view, /u/eragmus took the bate:

 

[theZerg]

@Peter R

you're right. An implementation is an integral part of a BIUP.

We should start writing the documentation *and* code a proof of concept implementation.

Unfortunately @theZerg is in the middle of BU release, maybe if he's interested he could start working on it after the release. Maybe @davecgh (or even @Gavin Andresen) could bite the bullet.

Guys I know that the articles are long but please skim them.

Code is absolutely unnecessary for a BUIP. One purpose of a passed BUIP is to set direction BEFORE the money (effort) is spent.

A BUIP proposal opens formal discussion on a topic... the results of which are binding in the sense that if a subsequent implementation appears it will basically be "fast-tracked" to commitment. What this means is that the Developer can slow things down if the patch is sh*t but not stop it.