Gold collapsing. Bitcoin UP.

[cypherdoc]

 

[Norway]

Impact Assessment of Too Big Blocks

I want to write a BUIP to create a BU backed impact assessment of blocks larger than a node can handle.

The reason for this, is that I get the impression that large parts of the technical community consider a node running out of memory as the ultimate failure that must be avoided at all cost, while other people see it as a trivial reboot (power off/on) and possibly closing the connection to the node that sent the block in the first place.

A too big block can come from an attacker who want to take the system down or a miner that have invested in a better node than you and just want the fees.

An assessment like this should certainly include dialogues with several miners/pools, cost estimates of a too big block event etc.

It should look at it from the attack scenario and if it's possible too keep a sustained attack effective.

And it should look at the situation where a minority of hashpower can't keep up with the blocks vs when a majority of hashpower can't keep up.

I believe a project like this should be positive for BCH-proponents, BSV-proponents and neutral big blockers.

I'm willing to do some work on this for free, but if I should lead the project or put in a lot of work, I'd have to be compensated.

But first I want some input from you guys. Is it a stupid idea? How should it be organized? What aspects are relevant? What do you think an assessment like this should include and why?

EDIT: The final report should be translated to chinese. Maybe japanese, russian and spanish too?

 

[cypherdoc]

thank you @MarkBLundeberg for your ABC and BSV compatible version of EC! TIL that the reason BSV wasn't compatible with the Fyookball version was because of the checkpoints. Okey dokey:

https://github.com/markblundeberg/coinsplitter/releases

 

[Norway]

Let's not forget to congratulate @Peter R becoming a dad for his first time:

 

[Norway]

@Mengerian, what do you think about an "Impact Assessment of Too Big Blocks"?

Is it a stupid idea? Or good? Why?

 

[Norway]

Jeez, I had to block the inventor of bitcoin for trolling on twitter today.

Bitcoin is difficult.

 

[freetrader]

the inventor of bitcoin

I thought that was David Rees. (/s in case it's not obvious)

Someone has to get their story straight.

 

[8up]

Jeez, I had to block the inventor of bitcoin for trolling on twitter today.

Bitcoin is difficult.

Greg Maxwell? /s

 

[awemany]

Hey guys, merry xmas and all that.

And @Peter R, congratulations to your baby news!

I am taking a bit of a break from daily Bitcoin involvement.

For us in the BCH crowd, here's something that I am right now pondering about with regards to finalization and Avalanche as a soft fork (AASF), and given that some folks seem to be fine proposing both.

With AASF, in the best case you tie it to the past POW (100 blocks or so). Not using POW but still having it as a soft fork is a whole other can of worms that folks have adressed on reddit.

So lets assume you want past-POW-AASF: You make the assumption that the last 100 blocks (or so) are an accurate representation of current honest hash power, and that this should be key to the current block building process.

With finalization, you make the assumption that the last 100 blocks (or so) are not an accurate representation of hash power and are a temporary overpowering attack, one that needs to be defended against (with finalization as a stop-gap measure and eventually even more hash power than the attacker).

How does this fit together? @Mengerian, if I understand correctly, you are supporting both ideas?

Now, I personally have warmed up a bit to the general idea finalization, but that also means I cannot really accept the premises of Avalanche. If check points make sense (and even Satoshi thought so), then short term hash or hidden hash might be antagonistic. But that means that Avalanche's foundational premises, in the case of Avalanche with a soft fork, seem to fall apart.

Thoughts?

I also must say that I feel "Cryptocached" on reddit made good commentary on this.

 

[Mengerian]

@Mengerian, what do you think about an "Impact Assessment of Too Big Blocks"?

Is it a stupid idea? Or good? Why?

I think it's an OK idea in concept. I think it would be important to focus on the impact to the users of the node software, whether that be miners, businesses, hobbyists, etc. What risk and potential costs are borne by them.

Also consider various scenarios of network makeup. Ie, if most of the rest of the network is running ABC with a 32MB limit, versus if the majority of the network is running with no-limit, how would each scenario affect the risk and potential cost to the user of a too-big-block event.

@awemany

How does this fit together? @Mengerian, if I understand correctly, you are supporting both ideas?

I'm not sure what "both" refers to. There's definitely many possibilities for the details of how Avalanche could be used. The way I see it, Avalanche could basically be a drop-in replacement for the networking portions of node function. So the transaction flooding and "first-seen" rule could be replaced by Avalanche. I see "first seen" as basically just a not very good consensus method, so it makes sense to replace it with a reliable consensus method. Then, later on, it could maybe be enforced via soft-fork as pre-consensus... But I think that would come after it has been live for a while without miner enforcement.

For the "post-consensus" portion, again as a first step it could just be used for the regular orphan race scenario where you have two blocks at equal height. The miners have an incentive to all want to mine on the same chain tip, so it makes sense to have a good method for them to agree on which block to mine on. As a side benefit, this could also mitigate selfish mining. Maybe the finalization aspect would come later, maybe based on something like Jonald's block time proposal which seems to be better than the current ABC finalization rule.

For the peer selection / Sybil resistance, I'm not sure what the best approach is. I don't think the 100-block idea is necessarily the best idea. I think Chris just came up with that as a random example. I've also heard the idea of basing it on older blocks only, ie remove the latest 1000 blocks (or whatever number), and only let older blocks participate. This seems to make more sense for post-consensus.

There's still tons of work to do, and many details to be figured out about Avalanche. My main goal right now is to try to document what's going on, and try to get people involved. It would be great if people could dig into reviewing the code that Amaury has been working on. He is looking for more review.

https://reviews.bitcoinabc.org/search/query/q44xtgMpVABD/

 

[Norway]

@Mengerian
Thanks for your reply.

I don't see how hobbyists are relevant, they can play with a mini toy version of bitcoin.

Regarding the scenario where an (ABC) majority of hash using a choked version, I think it's out of the scope of an assessment like this. If smallblockers have majority, they set the rules.

The assessment should look at what happens when a small group of developers does not have the power to prevent miners/pools from competing on how much tx capacity they can provide.

What's the consequence of not having blocksize nerd police?

Anyway, happy new year BU buddies!

 

[solex]

Happy New Year to all.

In 2016 BTC had its capacity max out and become an ICO for the Lighting Network.
In 2017 BCH was launched and gave the onchain-scaling community a lot of hope, unlocking value for all Bitcoin investors.
In 2018 BCH forked into two and destroyed value for all Bitcoin Cash investors.
2019? One thing for sure, it won't be a dull one in crypto-land.

 

[Norway]

@solex
I don't envy your current role.

I think BU can't afford to sit on the fence as an organization anymore.

If we had more time, I would support the wait and see aproach.

But miners are running out of income.

My wet dream is that developers related to BU are happy to just make the best client. BU has done this for a long time. We are the best.

The toxic and sexy idea to change the boring consensus rules are the way to hell. Drama, future splits etc.

Personally, I have no problem with @deadalnix bossy style and making decissions. In fact, I like it. This is what happens in a situation where leadership is unclear.

Deadalnix' powerbase has been perceived hashpower.

"Agree with me, because miners will follow my code".

The point is that we have to get rid of developer powerplay. The "protocol developers" are the single point of failiure. They have good intentions, are cool people. But they can't be protocol developers anymore. As an investor, I don't accept them as trustworthy technocrats.

Bitcoin doesn't need to be fixed.
[doublepost=1546313485,1546312636][/doublepost]@Peter R tried to make me agree that IBS was some sort of Weakblocks / Avalance pre consensus shit.

It's not.

Nobody agrees on anything with IBS. It's just miners telling other mners, by their choosing, what they plan to put in a block.

It's just a way to scale capacity without interfering with any rules.
Removing network spikes (blocks, Xthin filters, CB filters, Graphene filters).
Pre buildup of merkle trees for the miners/pools you are connected to (nobody have ever come up with this possibility before).

You throw away the trees that never became the solution after a block is found, together with the potential blocks (block candidates) that never materialize.

The cool part, data you have to keep for 10 minutes is not a problem. With terabyte blocks and 100 pools, it's trivial today.

Near instant block propagation. But still keeping orhans relevant. They have a purpose.

Just ramping up the general speed/capacity.
[doublepost=1546314681][/doublepost]So far, the two tech feebacks I have gotten from the BU community on IBS is these:

@awemany:
UDP is better. (I agree for public tx propagation, but that's it. Not block communication where it's important.)

@Peter R
IBS is similar to my weakblock idea. But it's not. The difference?
I don't try to change the rules in bitcoin.
[doublepost=1546314746][/doublepost]@cypherblock seem to have actually understood what we suggest.

 

[Norway]

.




And if there are any idiots still out there not paying attenton:

Read my lips. Slowly.

Zero-conf transactions are solved.

No, they are.


Shut up, or doublespend POP by HandCash after they improved their connections to miners.

Any POS system can use exactly the same tx-probing technique that the attacker used to understand which nodes are close to mining.

So it's solved. Deal with it, if you think bitcoin is broken and needs Avalanche sybil control.

Accept the fact.

Bitcoin works in a brick & mortar shop.

It just does.

Hack POP by HandCash' double spend alerts today. Or go home.

 

[cypherblock]

Well @Norway fast double spend may not be the biggest issue. It's the wait 3 minutes, leave store, then double spend that is a bigger issue.

This is why I like your IBS concept since miners would have higher orphan risk if they build a block different than what they've been communicating via IBS. Especially true when 1) blocks are large 2) miners communicating over IBS don't also use compact blocks (or xthin) as fall back.

So even though I agree IBS is not "pre-consensus" it is a type of loose 'pre-commitment". It is not set in stone, but a pretty good indicator of what is to come.

 

[Norway]

Well @Norway fast double spend may not be the biggest issue. It's the wait 3 minutes, leave store, then double spend that is a bigger issue.

Well, I feel goalposts are moving.

I'm not saying you do it. But they are moving.

Too bad @Peter R never made measurments of high bribes and long delays before people enjoyed Italy.

I'd like to see more test of these problems nobody are reporting.

Stats from the thousands of BTM's would be even more interesting on this issue created in the lab.

Sure, IBS could help if this was a problem. But it isn't, AFAIK.

Where are the angry BTM providers?
[doublepost=1546324076][/doublepost]And, oh. I forgot to mention that nChain people, the company that invested in a POS-soluttion none of you can trick without spending a lot of bribe money on potentential miners, where first invited to Italy.

Then they were kicked out of the conference.

@solex hold the responsibility to kick them out because ABC wanted it.
[doublepost=1546324724,1546323740][/doublepost]Yeah, I'm a little emotional now. But blocking people from a BU conference goes against every hair on my hot body, and Solex was the boss of that decision.

I am very curious what the path forward for BU is.

Are there any candidates for the next dev boss in BU? Is Andrew doing it again? Where do the candidates kiss my ass for getting the opportunity?
[doublepost=1546325771][/doublepost]I know @theZerg is very capable, and my favourite candidate for the job if he wants to do it.

But my question to you, @theZerg, is this:

Do you think BU should focus on changing the protocol or optimize the client for more capactity in the future?

 

[cypherblock]

Well, I feel goalposts are moving.

I'm not saying you do it. But they are moving.

Well there have been various other solutions to detect fast double spends in the past. Generally they work by having multiple nodes listening on the network and using those to detect double spends attempts. Such techniques are discussed for example here (a paper from 2012) specifically in section 5.2 "Inserting listeners into the network", which they cite as being an effective solution although noting it has costs. Also in section 5.3 they discuss making double spend alerting part of the regular protocol.

I don't know exactly what Handcash is doing (do you??), but I assume they are doing something similar to "inserting listeners into the network" but perhaps trying to more selectively connect directly to mining pool nodes or as close (fewest hops) as possible to them (perhaps even setting up paid relations with miners?). As a company providing a service they can support the cost of maintaining this network, and that is fine for them although personally I would wish for a more standardized approach for this so that bitcoin payments don't become dependent on such a single vendor like Handcash.

However the "slow" double spend attack has always been there. Entities like Handcash target fast double spend because it is in fact solvable (with various degrees of certainty depending on the exact implementation). It has never been the entire story however.

 

[Zarathustra]

I don't think blocking other people on twitter is bad, it often is more of a survival tactic.

Nassim Taleb considers to block Stefan Molyneux, but I think he shouldn't, because it's not difficult to compete with Molyneux.

 

[wrstuv31]

Well, I feel goalposts are moving.

I'm not saying you do it. But they are moving.

Let them reinvent the wheel.

 

[Golarz Filip]

Happy birthday block #0