Is there any coded algorithm for determining blocksize consensus in BU available to post here?

I'm not sure if you're intentionally avoiding the gaping hole in your analysis or if you just don't see it.

Yes, someone could spin up 1000 nodes tomorrow that advertise a larger block size but the context is quite different in that the network has agreed by consensus that these would be invalid. For that reason miners will not mine such blocks or they will get forked off the network for not respecting the consenus rules (and lose money).

From what I understand BU proposes that all of these nodes be aggregated into a signal that miners should consider when creating the blocks. That is the nature of a sybil attack.

With current Core consensus rules it is very easy for miners to tell nodes apart from eachother, there are two kinds: 1MB nodes and the rest.

Sorry for stepping in.

If someone tries to sybill the networks and sets up 2,000 nodes with a blocklimit of 200 MB, no responsible miner would take this as a reason to set his own limit to 200 MB.

When one of the miners was corrupted too, he could release a 200 MB block and 2,000 Nodes would propagate it. All the other nodes with lower limits would reject the block untill it reaches some depth. For that to happen the majority of miners has to be corrupted.

To be honest, I don't think that this attack is worth to be discussed - while Adam Back raised some question I'd love to see addressed.

Edit, cause "brand new" looks ugly: I'm C. Bergmann but unfortunately lost my password and my bitcoin-signed pledge for recovery was not answered. I'm not affiliated with BU but I like the idea and think it is worth to be discussed open-minded.

Yes, of course those 200MB blocks will be orphaned now with BU. We are discussing how BU would hypothetically work if a majority of the mining power supported the implementation and relegated the blocksize to nodes instead of themselves. BU isn't assuming switching to PoS in the future, right? The security model right now assumes a coordinated attack of miners and nodes. BU would allow the nodes to perform this attack immediately as the miners will be relegating their maxblocksize to the nodes, right?


Yes, I would rather move onto other topics, but can you explain to me the "1% easier" difference in 1 post assuming future possibility of a majority of miners support BU and relegate the blocksize to nodes instead of themselves ?


P.S... I am not posing these questions to denigrate your efforts and am genuinely interested in learning about BU and helping other implementations. Please don't be offended by these questions.

You wanted to be able to post on this forum and not be censored, yet you are not prepared to answer the hard questions posed to BU?

Lets try again. If I setup 2000 nodes, each voting for a 200MB block, thus overtaking consensus, what prevents a step 2 scenario from happening, where a miner that gets lucky starts mining 200MB blocks and propagating those. Longest chain is mine, as I run the most nodes.

Adam's questions are somehow of a similar fashion as he is asking how we prevent multiple shards of the block to happen, where each node follows an arbitrary size and starts rejecting the larger blocks. Meaning, I can kick Adam out of the network quite quickly as my 2000 nodes in consensus for 200MB blocks will ignore his 1MB + 10% blocks consensus with itself.

Thank You. So if it follows the longest chain than that is exactly how bitcoin core currently works , so I am amiss to what that "1%" cited  difference actually is. Any hints?

And what is to stop this from happening on bitcoin right now? If you have the most nodes, you have a 51%+ attack.

And what, exactly, is in the 200MB block? Are they all valid transactions in the mempool? And if they are not, how are they going to be validated by nodes?

Just because a limit is 200mb doesnt make it so - just like we dont have  too many 1mb blocks now, despite the present limit.

That is my limited understanding of BU. In fact I believe I was the one (as part of an interaction with Peter R) on the GcBU thread who pointed out that the satoshi whitepaper can be read as effectively miners making all the rules on what constitutes a valid block. End user nodes would also implement verification for protection against short term chain forks, but they would validate based on rules set entirely by miners. So as an end user, if miners change the rules, you would simply need to implement those changes in your node, or you would be unable to process the longest chain, and therefore no longer a participant.

This is certainly a different security model than what many in the Bitcoin community have come to understand over the past several years, where forks are accepted by an "economic majority" and "longest chain" is replaced with "longest valid chain". But it seems that (maybe) BU proponents want to adopt a stricter "longest chain" rule that vests all of the rule-making power with miners. I'm neither agreeing nor disagreeing here; I'm trying to state the position to see if I understand it.

Now in the case of BU specifically, I'm not sure I understand how this works when the user has configured a smaller block limit than is present on the longest chain? Does their node switch into an "offline" state based on block headers? The user then has a choice to adjust their setting (and network bandwidth, etc.) or stay off the network?


As I understand it, the rule is solely set by proof-of-work (i.e. large sum off difficulty). Any node that is off the chain with the most work is considered off the network. In that case it would be sybil proof, because proof-of-work can't be replicated. Let's see if I'm right.

And BU proponents are to blame, because they keep pushing it as "everybody sets their own limit and then magic happens (emergent consensus)".

If it follows the longest chain, then I believe the message of BU user can be summarized like this:

"I will accept any blocks the 51% of miners agreed on, at the expense of my business, which will now have to wait for something like an hour, before accepting any transactions".

This is how it should be promoted, then people would understand.

And this also begs the question: why the hell anybody needs to set their own limit at all?!

You still need a delay to see what size the miners picked, so your limit doesn't matter.

It matters because miners do not have a direct economic interest in forcing end users off the network. End users provide fees and demand for the currency which is how miners make money. There may be indirect interests though.