Topic: bitcoin "unlimited" seeks review - page 9. (Read 16106 times)

Your limit is a function of the resources you want your node to consume. Above that limit, your node either rejects large blocks that are spam (not accepted by the longest chain), or drops off the network because it can't keep up.


How does this differ from any other block?


I don't remember seeing anything about BU promising faster (statistical) finality than regular Bitcoin.

I just meant, if you are spending a ton of money to set up 1000 nodes, the cost of hiring a C++ coder to mod your Core code is going to be negligible ("1%" of your dough might be spent on hiring the coder). That's why it has nothing to do with BU, as in that case the convenience barrier is irrelevant.

This is not unique to BU, which is why I say it seems to have little to do with the OP. Again, a simple modding of the code is not going to stop someone that motivated, nor a miner willing to risk 25 BTC a block to try this. I'd love to see a hard question for BU, but this sounds to me like a hard question for Core, at best (I think incentives would prevent this, but again that's just me defending Core, not on topic).

Quite right. The choice of settings effectively becomes a vote on what you support.
Just as it is now, the miners actually decide what size of blocks they want to create, based on their knowledge of the network and its participants.
As an end user, you could set your limits high enough not to worry about them for the foreseeable future.

And there are plans to make it easier for end users to track the limit growth curves of BIPs they agree with, which makes it easier for them to express their views on the policy.
To prevent them from isolating themselves from the emerging consensus, there will be a warning message issued by the BU client if the user's settings are too restrictive to continue following the longest chain.

Hey, we have to start somewhere. This thread isn't being censored and many of us are genuinely interested in learning.

--------------------

I still am curious as to what the difference is besides the nodes being able to signal to the ecosystem in a slightly easier way through a GUI that they wish larger blocks. Is this it?

Ok so consensus is formed by miners and not the nodes. The miners set the absolute parameter for the size of the block, as they are the ones creating the block.

This leads us back to what Adam said then.

Nodes will then have to follow the rules ascribed by miners, and their vote is pointless as consensus is formed by those who mine. Which means, Adam will still get kicked off the network, when the winning miners decide on 2MB blocks, and Adam only accepts 1.1MB.

There's no such thing as "majority of miners support BU," other than "majority of miners run BU." The majority of miners can run BU with Core settings, for example. So I'm really not sure what you're asking here, especially by saying "relegate blocksize to nodes."

The majority of nodes decide the consensus, and the miners produce the actual blocks.

If the mining majority does not produce 200MB blocks, then eventually they will outproduce your chain, even if your 2000 nodes (not the majority of nodes currently, btw.) accepted it.

The only situation in which your scenario holds is if you control the mining majority and the majority of nodes.
Then you can maintain a longest chain with 200MB blocks (provided you generate the transactions to fill it).

If you can do that for $5000 then you can do it today already, nothing would be stopping you.

I don't consider it fruitful to continue this line of thought since it does not add any new attack that could not have been done in the past.

You couldn't find it because Zangelbert Bingledack edited his post and in doing so my question is finally answered. Thanks.


My initial reaction is that I don't think its a good idea to empower non-technical people with the ability to control such an important variable with a click of a button. I suppose they would be held into account by the miners and this would essentially be a node vote which would allow individual nodes to confirm larger blocks easier. The difference may not be significant as an attacker isn't going to be limited by the code and this could be a signal to allow users to vote. This change appears to me to have more political implications than anything.  

But if BU will switch to the longest chain eventually anyway, then what exactly is the point of your limit?

You can't blindly accept a 2 Mb block just because it's below your limit, as it might be orphaned because no other miner agreed on it.

So you will still have to wait like 6 blocks.

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.

Thanks for clearing that up.

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.

No, no and no again. I can have 1 million nodes and I wont be making any type of 51% attack as the blocksize is hardcoded.

What will currently happen is that my nodes will be part of a network that never makes any block larger than 1MB, despite the fact that my nodes accept up to 200MB.

Bitcoin is not about nodes, or about miners. Its about nodes AND miners.

EDIT: A 200MB block are all valid transactions, send by ME to ME. Remember, I have 2000 nodes to send to and from. I will loose only the fee's that I pay miners, which is absolutely nothing.

This attack was performed on Bitcoin not long ago, with the aim of filling up the mempool. It did not work under the current consensus rules.

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.

I am not sure which "1%" difference you are citing. I have searched this thread and it came up first referenced in one of your posts. Can you provide a complete link / citation of the statement so that it can be looked at properly?

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.

And longest chain is a rule set by nodes, correct? Meaning, that consensus is formed by the highest voting number of nodes, in this scenario, my 2000 nodes.

If we go by the standard 6 confirmations, 6 depths, then we can safely assume it will be the longest chain. So after my 2000 nodes vote for a 200MB block, I wait 1h for the longest chain to become 200MB. Or for the real paranoid, we wait 2 hours, and I am certain that the 200MB rule is enforced and that there is probably not another chain.

I then spam it with 200MB data, and thus we get 200MB blocks until someone can form a better consensus (launch more nodes with a different blocksize consensus).

All this, I can do in less than one day, and cripple the network for less than $5000.

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?

In the interest of this "review", I will point out a point commonly not understood by those new to BU:

BU follows the longest chain.

If an excessive block is accepted after the chain it's on reaches a certain depth, then that chain becomes an eligible choice, but if there is a longer one with smaller blocks then it will still not be chosen.

So the claim that BU will "insta-fork" when there is a block > 1MB is simply not understanding how it works.

Those who have asked for the detailed algorithm can find a link to the Github repository containing the source code at the BU download page:

http://www.bitcoinunlimited.info/download.html

Further detailed information about BU can also be obtained from the Resources section of the BU site linked above.
That could serve as a good basis of discussion / review.

P.S. I have opened an account on BCT to join this discussion since I think it is important to clear up misconceptions about BU.