Gold collapsing. Bitcoin UP.

[solex]

We are good to add important improvements which will significantly reinforce BU as the best implementation available:

BUIP002 17/0 passed
BUIP004 17/0 passed with A1=15 & C=2, so A1 is passed
BUIP005 15/2 passed
BUIP010 17/0 passed
BUIP013 13/2 passed with A=10 & B=3, so neither have the minimum so the Developer may proceed with what is common between A & B

Note: 43 members, 25% turnout is 11 where >=75% for/against is also required.

 

[cypherdoc]

awesome

 

[Justus Ranvier]

More history:

The last time Core developers had a productive discussion about competing implementations:

https://bitcointalk.org/index.php?topic=122013.msg1389749l#msg1389749
[doublepost=1454269750,1454268933][/doublepost]More history:

2012-07-21: "Gavin has been finding ways to make hard-forking changes much smoother and easier in future, which will be important when we reach the 1MB limit."

https://bitcointalk.org/index.php?topic=94453.msg1044721#msg1044721

Note the completely absence of supplemental explanation of that statement.

Not one person in that thread found it the slightest bit controversial to talk about a hard fork when the 1 MB limit was reached as if it was obviously going to happen.

 

[Justus Ranvier]

2013-05-17, Gregory Maxwell:

https://bitcointalk.org/index.php?topic=208200.msg2182597#msg2182597

All that said, I do cringe just a little at the over-simplification of the video... and worry a bit that in a couple years it will be clear that 2mb or 10mb or whatever is totally safe relative to all concerns— perhaps even mobile devices with tor could be full nodes with 10mb blocks on the internet of 2023, and by then there may be plenty of transaction volume to keep fees high enough to support security— and maybe some people will be dogmatically promoting a 1MB limit because they walked away from the video thinking that 1MB is a magic number rather than today's conservative trade-off. 200,000 - 500,000 transactions per day is a good start, indeed, but I'd certainly like to see Bitcoin doing more in the future. ... But I suppose the community can work on educating people about that them with concrete demonstrations. Thing like bg002h's suggestion of a maxed out testnet would be interesting in establishing exactly what the scaling limits of current technology are.

In that thread the and the related video, notice the claim of some kind of security tradeoff regarding block size and decentralization which has been repeatedly asserted, yet never demonstrated via a coherent threat model, to this day.

 

[mother_of_another]

Hi guys!

An abundance of free spirits flowing around in here

 

[cypherdoc]

2013-05-17, Gregory Maxwell:

https://bitcointalk.org/index.php?topic=208200.msg2182597#msg2182597



In that thread the and the related video, notice the claim of some kind of security tradeoff regarding block size and decentralization which has been repeatedly asserted, yet never demonstrated via a coherent threat model, to this day.

i love these walks back in time.

 

[Justus Ranvier]

So regarding "controversial" hard forks:

On July 21, 2012, an eventual hard fork to raise the 1 MB limit was completely uncontroversial.
On May 17, 2013, Peter Todd is promoting a youtube video designed to create controversy where none previously existed.

He succeeded.

 

[cypherdoc]

 

[Justus Ranvier]

In the Bits of Proof thread from late (November/December) 2012, who were the Core developers who participated in the code review of BoP, with the intention of making it safe for miners to use:

• Mike Hearn
• Gregory Maxwell
• Jeff Garzik
• Sergio Demian Lerner
• Gavin Andresen
• Luke-Jr

Who showed up to talk them out of it? Peter Todd:

https://bitcointalk.org/index.php?topic=122013.msg1393234#msg1393234

Who, by the way, was only a few months out of newbie jail: https://bitcointalk.org/index.php?topic=15911.msg869632#msg869632

 

[cypherdoc]

Straussianism. Nice:

https://np.reddit.com/r/btc/comments/3y8o9c/is_the_real_power_behind_blockstream_straussian/

 

[Justus Ranvier]

Straussianism.

This part is completely plausible, yet also easy to fake:

Note that, as a by-product, this actually lets the devs off the hook: in this scenario, they are simply part of the deceived "masses" themselves, they really do believe they are acting in "good faith", and they do not know they are being lied to by the Straussians who set up the organization and lured them into believing in it (and gave them free rein to pursue various pet projects such as LN and RBF which such ego-driven and short-sighted devs might think are "cool" to work on, but which are actually damaging to Bitcoin).

This is why I said we have to look at outcomes, and not try to guess motivations. They could be acting in good faith and be mislead themselves. They could be acting maliciously, and willing to fall back on a Straussian excuse when caught. We'll never be able to prove which one is true.

They and their supporters are taking actions that result in them having monopoly control over the protocol, via a variety of underhanded methods.

That monopoly control has always been dangerous, especially because it's within the realm of possibility that good-intentioned people could be manipulated into misusing it.

That monopoly has to be broken. If they are acting in good faith, then breaking their monopoly is beneficial to them, because then any hypothetical behind-the-scenes manipulator has no reason to continue playing puppet master with them.

 

[cypherdoc]

https://www.reddit.com/message/messages/4vexd4

 

[albin]

That jdillon stuff is very troubling because assuming the whole thing isn't completely fabricated by the rich fantasy life of some internet rando or Peter Todd himself, it indicates that Peter Todd could be an extremely vulnerable useful idiot possibly being handled by intelligence without his knowledge. Tell-alls like Perkins' Confessions of an Economic Hitman give some insight into how people can be controlled by their personal vulnerabilities, and in the case of Todd, his new Twitter photo tells you everything you have to know to manipulate him.

 

[Justus Ranvier]

We don't even know if the supposed compromise of jdillon is actually real.

Maybe it was real. Maybe he "hacked" himself. We'll never know.

The way out of this is sound, logical methodologies. Develop procedures that work even in the presence of dishonest players, because we'll never really know who they are.

How to improve Bitcoin Security

1. Define the expected behavior of the system
   • List the actions which a users should be capable of taking
   • List the actions which the system should prohibit
2. List the ways in which the expected behavior could be violated (attacks)
   • How could an attacker successfully take a prohibited action?
   • How could an attacker successfully prevent a user from taking a legitimate action?
3. Define a set of attackers for each identified attack, and estimate their capabilities.
4. Estimate the cost for the specified attacker to perform each attack
5. Rank the attacks in order from least expensive (most severe) to most expensive (least severe)
6. For every attack identify all available countermeasures
7. Rank countermeasures available for each attack by cost.
8. Starting with the most severe attacks, implement the least expensive countermeasure.
9. Repeat as necessary, updating the list of attacks and countermeasures as new ones are identified.

 

[sickpig]

I wonder: Did anyone ever submit a thin blocks change to Bitcoin Core?
@Peter Tschipper : Did you try to open a PR with Core on your propagation scheme?

@Peter Tschipper already answered, but I just want to add that he already try to submit a scheme to reduce full node bandwidth requirment by compressing block data before sending (and decompressing upon receiving).

To make a long story short, Peter made an amazing job. He simulated his code on a variety of test cases both in terms of block size and latency.

If memory serves his solution produce something like 20% reduction in bandwidth usage without any significance loss in terms of CPU load.

And you know what: core devs danced the moving-the-goalposts dance, and as a matter of fact dissed such an important gain.

Take into account that SegWit gives 1.7 gain only at storage level: i.e.the witness data can be discarded only after they had been verified. This scheme gave you 20% gain in bandwidth terms, nevertheless it was not included. sad.

p.s. Peter feel free to correct me if my recollection of facts contains errors.

 

[Peter Tschipper]

@sickpig You're pretty much right, the datastream compression showed a 20-30% improvement in bandwidth but also the same for response times over the internet for both blocks and transactions.

 

[awemany]

@Peter Tschipper, @sickpig:

Thanks, well gmax is now outright saying that anything like thin blocks that isn't the relay network is crap. I think I even remember him saying before that the relay network is not a proper decentralized solution, and therefore AFAIR he's contradicting himself. I didn't look for that yet, though, so I might be mistaken.

I was in the mindset of Core not having rejected yet a reasonable proposal to reduce bandwidth and help with scaling Bitcoin. However, his latest posts in my above submission on reddit show that he's completely dismissing even the idea. So I agree it doesn't make sense now to submit a PR. Greg already rejected it before it got a PR.

@Peter R:

Regarding devs: I do think that e.g. gmax is intelligent and wouldn't Bitcoin and Blockstream be about money, would probably be an asset, albeit probably still someone with an abrasive personality. If he's not anywhere near a project leader position.

I think what would be great would be some kind of bounty system where one is able to say 'I'll work on it' and lock the bounty for a while. I'd also like to personally get more involved with Bitcoin low-level development.

 

[Peter R]

@awemany

Yes, Gmax has certainly made important contributions to Bitcoin. I think the tension with him now is the conflict of interest with respect to Blockstream, coupled with his view on Nakamoto consensus. His camp thinks that there are two different forms of consensus, while I believe most in the big-block camp think that ultimately only Nakamoto consensus matters.

"I think what would be great would be some kind of bounty system where one is able to say 'I'll work on it' and lock the bounty for a while. I'd also like to personally get more involved with Bitcoin low-level development."

Yes!! Imagine if we could setup perhaps three "Funding Councils" that would act similarly to Canada's National Research Council (NRC) or the USA's National Science Foundation (NSF) [I'm sure similar councils exists all over the world]. Development teams or researchers could submit project proposals to the Bitcoin funding councils; some competitive process would be used to allocate the funds. Individuals and teams that made progress that the community was pleased with would be more likely to receive continued support.

 

[Justus Ranvier]

2013-02-04: Remember when a hard fork was so uncontroversial that even Mircea Popescu agreed?

https://bitcointalk.org/index.php?topic=140233.msg1503470#msg1503470

 

[cypherdoc]

@Justus Ranvier

i haven't heard much anti-bigblock rhetoric from him recently. is he coming around given the rising level of dissatisfaction with core dev?