Gold collapsing. Bitcoin UP.

[lunar]

the same seeds are now being planted to attack BU, we are now our own enemy,

I've noticed lots of posts recently using belittling attacks, such as ChinaBU or Did you know BU has a President? 'This is not decentralised'.

@theZerg was very wise to get the articles of federation in place, but make no mistake, this will be used as an attack vector, preparations and rebuttals need to be made.

@Christoph Bergmann I like it. u/FormerlyEarlyAdopter Has distilled something similar, down to a nice decision tree.

 

[theZerg]

I won't blame Greg for the @Peter Tschipper 's recent bug as I think that would be unfair.

However there are things to consider when you look at this calmly:

- If the preliminary analysis from yesterday is correct, ptschip basically made the same mistake twice. He assumed a certain behavior of assert(..) (a well-known C/C++ function with a standard behavior) to not matter in RELEASE builds (when you make the software and release it to the whole world) but only to be active in DEBUG builds (when you are testing the code). This is the STANDARD behavior.

- Greg Maxwell in 2013 changed Bitcoin so that all asserts happen as if they would in DEBUG builds. There are (somewhat) valid reasons to do this, but it is more a 'hot fix' and if he would have done it the right way, he would have deprecated and removed assert(..) altogether from the code and replaced it with an explicit function, like "fail_if_not(..)". It is basically a psychological issue here, like so much is in programming: People blackbox certain behavior, assume standard behavior, and then it is super-easy to fall into the trap that non-standard behavior can cause.

This is also a fine example on the kind of 'special Bitcoin knowledge' and barrier to entry Core amasses by introducing non-standard quirks into the Bitcoin code or build process.

As it was done by Greg back in 2013, I do not want to assume malice here.

But again, I do think it is a fine example of the kind of uphill battle that results from these kinds of changes.

And I do want to state that, although BU owns the actual bug, Core owns the culture and the idiotic assert policy that made this bug possible in the first place.

- I said after the last bug to have a closer look at all assert()s, especially those in BU. I am sure others said and thought the same. I am also sure that our devs started to look into exactly that. However, this takes time. Our enemy (and I think it is unfortunately 100% correct to call them that at this stage) likely prepared a whole string of exploits along the above assert(..) The only good thing is that they'll eventually run out of those. Bugs in stable code are a finite 'resource'.

Last but not least, I am thankful for our devs and I can see the immense pressure that they are under now.

I said that BU started with somewhat of a Cowboy mentality ('move fast') when it came into being - also somewhat out of necessity. From my casual glances at the current code, I have to say, however, that indeed quite a lot of work was done to clean up the code by our team (both on BU and Core parts) and I think everyone is taking the right approach now.

Thanks for these supporting words! We have done lots of cleanup in the code, and actually I think that the competition with Core has caused them to up their game. It would be interesting to compare activity in the Core repo before and after BU but I don't have the time for it.

I support minimal clients like an EC patch over Core, but we would not be where we are today with just that. Last year the biggest criticism with BU and its simple EC patch over 12.1 was that there weren't enough devs who knew the code well. "What if all the Core devs quit?" was the narrative. We could not show competence and a working development model by constantly rebasing a small patch set.

Nobody gains competence by just reading the code. This is the real truth of development, and basically everything in life. You might be a professional baseball player, but you cannot expect play soccer after you've just read about it.

So major features like Xthin and Expedited went in and did a huge amount for good for the large block cause. But we were doing this after working with the code part time for a few months, and we were tricked by expectations that a standard API call would behave in the standard way. We have of course started reviews of asserts and other aspects and the 1.0.1.2 patch set has a lot more in it than is needed to fix the block received vs xthin request race condition.

We are bearding the lion in his den here, and are winning! But the lion still has a few tricks up his sleeve across all aspects of the struggle -- for example, that modified letter from the exchanges.

 

[AdrianX]

This tree needs a black hat version. Discrediting BU, but add developers resolve controversial issue. If you follow the line that concluded that miners should not have control of the software rules it leads back to go read the white paper again.

 

[Inca]

As someone busy with other projects but always keeping an extremely keen eye on this battle for bitcoin's future I can say i think we, the sound money / on-chain scaling crowd are winning. Core and /r/bitcoin are running very scared. They have lost miners and now despite the ferocious attacks on BU they are losing nodes.

The ground has shifted. Use case after use case has moved to ethereum. Bitcoin is no longer fast or cheap (UK banks are more highly performant!). Everything we predicted and screamed about has come to pass but it still leads.

I moved most of my crypto funds to ethereum last year and that decision recently was confirmed as the right speculative move. But going forward I am not so sure. I think a revolution is still possible within bitcoin and if it happens it will coincide with the ejection from the development ecosystem of the entire Core cabal led by Gregory Maxwell and the beginning of a new exciting era of plasticity in the development and governance of the bitcoin network.

If bitcoin survives this very well planned and funded attack then it and cryptocurrency in general has an extremely bright future!

Keep going chaps!

 

[AdrianX]

@Peter R when I saw this raw data I got very excited, it needs to be sliced and diced in many ways ;-)

I grabbed screenshots and overplayed the data for existing images.

This is what I've wanted to see for a long time and it's confirmed my suspicion.

Could readers here please give feedback or suggestions I'd like to evolve this and see this through other people eyes.

Some observations:

1) the correlation between BTC Value and TX/s breaks when we start to run into transaction capacity. (block limit) - who could have predicted that ;-)

2) BTC value increasing - correlates with new emergent consensus block limits.

3) Network Block Limits go up and they can come down with engagement consensus.

4) the Miners enforcing the 1000,000 byte rule is a statistical anomaly, looking at historic block limits.

5) Block size and TX/s are strongly correlated. (the exposure of the background could be off maybe if I do this again I'll screenshot a different exposure from Peters video.)


The outliers in the raw data are interesting anyone know why so many empty blocks in late 15 and early 16?

• I added difficulty adjustments as this is also a very important metric for growth. When difficulty increases we have mining competition for market share. - subsidizing security,
  
  
• With full blocks we have miners competing to drop low fee transactions.
  
  
• 1MB block limit prohibits the free market strategy of maximizing profit with scales of economy.
  Users pay high fees as a result, the only strategy for mining growth is market share - (centralized mining pressure) High fees - creates demand for layer 2 networks. Reducing mining income to invest in growing or maintain market share. (less bitcoin security)
  
  
• with no block limit miners compete to optimism transaction costs and grow market share.
  Users benefit from market competition low fees as a result, Mining growth comes from efficient miners investing in growing market share - by maximizing profit on transactions - (decentralizing mining pressure with competing strategies for fee income) security is enhanced creating demand for bitcoin, reduced costs to use bitcoin increased distribution and demand.

 

[Zangelbert Bingledack]

@AdrianX @Peter R That pic (and variations of it highlighting different aspects) needs to be spread far and wide. So incredibly telling. Evocative, even:

That final bright line is the powerful Schelling point set by the hard blocksize limit baked into Core's code. You can almost see the weight of Core's finger pressing down on the scale as Honey Badger struggles valiantly to rally against the burden.

Little typo: UDS instead of USD

What would happen if you overlay BU hashrate, too? It looks like it correlates with the last bit of rally, representing the prospect that the 1MB dam will be breached.
[doublepost=1490306837][/doublepost]Here's my latest salvo as well.

https://www.reddit.com/r/btc/comments/614su9/adjustableblocksizecap_abc_clients_give_miners/

Spot the difference between how stakeholders can coordinate to fork to 2MB in a Core world vs. in an adjustable-blocksize-cap (ABC) client world:

- Core: miners and nodes coordinate to mod their Core code to increase the cap to 2MB

- ABC clients: miners and nodes coordinate to adjust their client settings to increase the cap to 2MB

Where is any extra power handed to miners? Where is any power taken away from nodes? How is the situation with ABC clients any different than under Core? We can point only to the difference in convenience, and even that was bound to be erased sooner or later by an enterprising developer making a patch.

What does it tell you that Core and its supporters are up in arms about a change that *merely makes something more convenient for users* and couldn't be prevented from happening anyway? Attacking the adjustable blocksize feature in BU and Classic as "dangerous" is a kind of trap, as it is an implicit admission that Bitcoin was being protected only by a small barrier of inconvenience, and a completely temporary one at that. If this was such a "danger" or such a vector for an "attack," how come we never heard about it before?

And even if we accept the remarkable premise that somehow this small inconvenience was the chewing gum and bailing wire holding the network together, it already would imply that letting stakeholders make their own choices is dangerous and that the only way to keep Bitcoin working is to spoonfed stances on controversial consensus settings to all users.

Even granting the improbable premise that inconvenience is the great bastion holding Bitcoin together *and* the paternalistic premise that stakeholders need to be fed consensus using a spoon of inconvenience, we still must ask, who shall do the spoonfeeding?

Core accepts these two amazing premises and further declares that Core alone shall be allowed to do the spoonfeeding. Or rather, if you really want to you can be spoonfed by other implementation clients like libbitcoin and btcd as long as they are all feeding you the same stances on controversial consensus settings as Core does.

Core and many of its supporters consider anyone trying to feed you anything else an outright attack on Bitcoin itself (examples: XT feeding you BIP101, the old Classic feeding you 2MB). More remarkable still, these people also consider anyone *refusing to spoonfed you anything* as an attack (examples: BU, new Classic, and other ABC clients).

This all of course implies the only non-attack is to vest all control and authority in the Core developers, specifically a few committers and the maintainer of a single repository. This mindset that considers everything else an "attack" is implicitly a centralized governance model, not specifically because *Core* is centralized but because all dev teams are.

The kind of adversarial thinking bitcoiners are familiar with easily demonstrates that any single dev team is ripe for co-option. The only protection against one team holding the community over a barrel on controversial matters is to have many mature competing teams, and better still would be if none of these teams try to bake their own coders' stances on controversies into the code offerings by hiding the control panel for those settings away from the user.

Such practices manage to be both childish and paternalistic, while lacking any material and sustainable effect of saving supposedly hapless stakeholders from making the wrong decision on controversial matters.

It is high time the community see central planning and abuse of power for what it is, and reject both:

- Throw off central planning by removing petty "inconvenience walls" (such as baked-in, dev-recommended blocksize caps) that interfere with stakeholders coordinating choices amongst themselves on controversial matters, without forcing those who disagree with the dev teams recommendations to switch dev teams

- Make such abuse of power impossible by encouraging many competing implementations to grow and blossom

 

[Mengerian]

The Future of Bitcoin Conference 2017 - Call for Proposals

I'd encourage anyone interested to submit proposals for presentations for The Future of Bitcoin Conference 2017! To be held in Arnhem, The Netherlands, 30 June - 01 July 2017.

The Future of Bitcoin Conference 2017

Bitcoin developers and the ecosystem coming together to discuss the future of Bitcoin

Arnhem, The Netherlands
June 30 - July 1

Call for Proposals

Members of the Bitcoin community are invited to submit proposals for presentations at the upcoming Future of Bitcoin Conference being held 30 June - 01 July 2017 in Arnhem, The Netherlands.

Submissions should include a 1-page abstract describing the topic to be presented. Presenters should aim for 20-30 minute presentations, to be followed by questions from the audience.

Topics may include (but are not limited to): Bitcoin scaling, privacy, fungibility, protocol upgrades, governance, economics, and social aspects. Submissions may be based on an academic-style paper, analytical studies, or more practitioner-oriented material such as implemented or proposed software and other developments in the ecosystem.

Please email proposals to: presentations@thefutureofbitcoin.com

Presentations will be chosen by a selection committee made up of individuals representing a wide range of interests.

The Future of Bitcoin Conference 2017 aims to be open and inclusive of all Bitcoin stakeholders. Submissions are welcome from individuals representing all projects and implementations.

Proposals should be in by April 30, 2017

Proposals and information: presentations@thefutureofbitcoin.com

 

[lunar]

The outliers in the raw data are interesting anyone know why so many empty blocks in late 15 and early 16?

Speculation only here, but i'm guessing that was around the time some hashers realised headers first mining was profitable? i.e they could start working on a new solution while they validated the incoming block. If solution found prior to full validation they broadcast an empty block to avoid conflicts?

You could check this theory, by plotting those points w.r.t time from previous block solution. If true, they'd all be very short ~< 30 seconds later?

And yes, this is what we all here, instinctively knew; although It's great to see a graph, along with Metcalf's law.

@Zangelbert Bingledack That bright light at 1MB shall hereforth be know as the trials of Honey badgers Blockstream burden.

Mr Bitcoin, he no likey

Future generations can point fingers and go, OMG how could they be so stupid?

 

[AdrianX]

thanks @Zangelbert Bingledack I added BU as a % of total hash and difficulty, and updated the original post.

Interesting how BU as an emergent idea started soon after blocks started filling up but is only catching on now.

 

[adamstgbit]

https://medium.com/@peter_r/on-the-emerging-consensus-regarding-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8#.jm7j1vgqg

what a plan.

synthetic fork is killer

 

[go1111111]

@Richy_T: Any indication that this isn't meant as some sort of "hipster irony"?

I think it's pretty clear that it's supposed to be a joke. Tadge strikes me as smart and self aware enough to not sincerely call himself a thought leader.

 

[freetrader]

I am unable to make this up.

Thread archive: http://archive.is/i7Lh8

 

[satoshis_sockpuppet]

New all time low market cap:
< 70 %

Come on miners.

 

[KoKansei]

All of these people bitching and moaning about Peter R pointing out a core element of bitcoin's economic game theory and somehow trying to frame it as a kind of moral outrage are starting to really get under my skin!

What happened to all the cypherpunks who actually have a firm understanding of what is and is not coercion? Is bitcoin really going to drown in a sea of idiocy, smothered by people who are clearly lesser thinkers than the founding members?

I have always thought that Satoshi staying out of this debate was a wise move. Bitcoin must prove that it does not need a leader. And yet, here we are, with what seems to be a sizable number of ecosystem participants behaving exactly like lemmings as they look for someone to lead them off a cliff, a role that a few sad opportunists are all too happy to fill.

If you were Satoshi and you still had control over at least some of your original keys so you could still establish your identity to the community, how bad would you let this political shitshow get before saying enough is enough?

I think I need another drink...

Edit: Rosenfeld replied to me:


I can't even... I think I need another 10 drinks...

 

[satoshis_sockpuppet]

@KoKansei
It's like everywhere: People try to stay or get in control by citing some "morality".

They act as if Peter wanted to sacrifice children for the mighty blockchain or something...

I'd like to go back to proof of work and longest chain please. All this noise is so unnecessary.
[doublepost=1490363119][/doublepost]Well and I'm pretty pissed by having to look up what fee to use for a fucking transaction.
My first satoshis, worth ~10 $, came around half the globe in ten minutes for free and Bitcoin was actually better than banking for a lot of stuff.
Now it's just circuitous.

 

[adamstgbit]

i use to sell "general purpose bitcoin businesses cards" for 1$ worth of bitcoin (+1 - 2.5$ Shipping).

it cost less for me to ship a letter full of paper across the globe then it does to send a <1kb tx

but i guess i could accept LTC or somthing lol...

 

[Windowly]

Wow people are really freaking out at the idea of miners orphaning blocks. Myself, I just can't wait till they start. I don't want to have to sell off my bitcoin horde and buy I don't know what coin to replace it.

 

[Mengerian]

New all time low market cap:
< 70 %

People are spooked. They have been fed fear and skewed information for the last several years. They have been told to fear hard forks. Guys like Vinny Lingham, trusted by many non-technical investor types, are running around telling everyone to sell their coins.

It's funny because the closer things get to a possible hard fork, the more optimistic I get. But I also expect fear to drive prices down leading up to a possible hard fork. If the ideas in this thread are correct, then this could represent a great asymmetric investment opportunity.

 

[Justus Ranvier]

What happened to all the cypherpunks who actually have a firm understanding of what is and is not coercion? Is bitcoin really going to drown in a sea of idiocy, smothered by people who are clearly lesser thinkers than the founding members?

The cypherpunks failed to invent P2P digital cash.

When an outsider stepped up and succeeded where they had not, most of them dismissed Bitcoin. They especially tended to attack the concept of a limited supply currency.

If Bitcoin is successful it proves they were fundamentally wrong about market action and monetary theory.

If Bitcoin fails they can say they were right all along.

 

[bluemoon]

People are spooked.

These people who are spooked spook me.

It must be clear as day to Bitfury where their future lies and it's not with BSCore.

Their business is as dependent on Bitcoin (original model) as Antpool, with whom they are now great buddies (yeah?). Yet still they signal Segwit.

What are they on?
[doublepost=1490378139][/doublepost]

If the ideas in this thread are correct, then this could represent a great asymmetric investment opportunity.

Haha, Bitcoin has been the mother of asymmetric investment opportunities for several years already.

It is also the mother of endurance tests.