bitcoin "unlimited" seeks review

[NxtChg]

It matters because miners do not have an economic interest in forcing end users off the network. End users provide fees and demand for the currency which is how miners make money.

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.

[1714541035]

1714541035

[1714541035]

1714541035

[1714541035]

1714541035

[BitUsher]

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

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?

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

Bitcoin Unlimited's main change at present is simply that, for better or worse, it makes it more convenient for miners and nodes to adjust the blocksize cap settings. This is done through a GUI menu, meaning users don't have to mod the Core code themselves like some do now. Planned improvements to BU include options that automatically mimic the blocksize settings of some Core BIPs, as well as blocksize proposals recommended by other luminaries.

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.  

[LovelyDay]

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.

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.

[Zangelbert Bingledack]

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 ?

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."

[JackH]

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.

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.

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.

[BitUsher]

.... but the people who work on BU are not/do not feel welcome here.

Unless you're starting a bashing thread I have real doubts about the fruitfulness of your effort.

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?

[LovelyDay]

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.  

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.

[Zangelbert Bingledack]

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.

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).

[Zangelbert Bingledack]

I am amiss to what that "1%" cited  difference actually is. Any hints?

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.

[smooth]

It matters because miners do not have an economic interest in forcing end users off the network. End users provide fees and demand for the currency which is how miners make money.

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

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.

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.

How does this differ from any other block?

So you will still have to wait like 6 blocks.

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

[LovelyDay]

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.

You go wrong in thinking that miners are all-important. I clearly stated "the majority of nodes decide the consensus", not only miners.

As other have stated multiple times in this thread, miners have to be sensitive to where the real money comes from, ultimately.
As such, the "vote" expressed by BU nodes through the settings they choose to run, is an important piece of information to miners.
It is certainly not pointless. It would be pointless to ignore it, as a miner.

[smooth]

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.

You go wrong in thinking that miners are all-important. I clearly stated "the majority of nodes decide the consensus", not only miners.

As other have stated multiple times in this thread, miners have to be sensitive to where the real money comes from, ultimately.
As such, the "vote" expressed by BU nodes through the settings they choose to run, is an important piece of information to miners.
It is certainly not pointless. It would be pointless to ignore it, as a miner.

If it is supposed to be a "vote" then I agree with the other comments here that it is trivially sybil attackable and pointless. If it is supposed to be an anti-spam protection that avoids having your node flooded by huge blocks that the longest chain does not accept, that is not necessarily pointless. In the latter case, the miners will have to come to their own conclusions as to the "best" block size to produce, almost entirely independently of this propertied "vote" (using market research, experimentation, etc.). I agree with you that a "vote" of nodes is information, but it is almost worthless information so it should be almost entirely ignored.

[JackH]

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.

You go wrong in thinking that miners are all-important. I clearly stated "the majority of nodes decide the consensus", not only miners.

As other have stated multiple times in this thread, miners have to be sensitive to where the real money comes from, ultimately.
As such, the "vote" expressed by BU nodes through the settings they choose to run, is an important piece of information to miners.
It is certainly not pointless. It would be pointless to ignore it, as a miner.

If the miners set the limits then nodes will be kicked off, and we end up with more and more centralization, as everything moves to bigger data centers.

If nodes set the limits, it opens up for sybil attacks as I described in an above post of mine.

You dont answer my questions. Either the mayority of nodes set the consensus rules or the miners do, which one is it?

[Zangelbert Bingledack]

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?

I think there are a lot of misunderstandings about BU. The main idea is dirt simple:

• Current situation: blocksize cap for the network is set by miners/nodes converging on either Core, XT or something else by downloading and running Core, XT, etc.
• With user-selectable blocksize cap: blocksize cap for the network is set by miners/nodes converging on either Core settings, XT settings (BIP101), or some other Schelling point by adjusting their settings to do so (BU can be made to default to Core settings, if you want)

There's another "oversized block acceptance depth" feature LovelyDay mentioned that is envisioned may come in handy, but it can be turned off anyway so I'll focus on just the "user-selectable blocksize cap" aspect. This is all it is.

[LovelyDay]

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?

The real difference is that nodes can easily set and adjust their limits to keep following the consensus as it emerges by way of the block emission.
And miners can use node settings information to coordinate their response to changes in demand.

I think that's a novel and beautiful contribution by BU.

[smooth]

Current situation: blocksize cap for the network is set by miners/nodes converging on either Core, XT or something else by downloading and running Core, XT, etc.

... and making the decision not to modify this code.

[JackH]

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?

I think there are a lot of misunderstandings about BU. The main idea is dirt simple:

• Current situation: blocksize cap for the network is set by miners/nodes converging on either Core, XT or something else by downloading and running Core, XT, etc.
• With user-selectable blocksize cap: blocksize cap for the network is set by miners/nodes converging on either Core settings, XT settings (BIP101), or some other Schelling point by adjusting their settings to do so (BU can be made to default to Core settings, if you want)

There's another "oversized block acceptance depth" feature LovelyDay mentioned that is envisioned may come in handy, but it can be turned off anyway so I'll focus on just the "user-selectable blocksize cap" aspect. This is all it is.

"user-selectable blocksize cap" aspect -

1) So I fire up 2000 nodes, all selecting 200MB as cap.

2) I make the miners belive this is the prefered block size.

3) They all start producing 200MB block.

4) I fill up the blocks for the next 10 days

5) Bye bye 75% of all network nodes

6) I pretty much run the network

[smooth]

1) So I fire up 2000 nodes, all selecting 200MB as cap.

2) I make the miners belive this is the prefered block size.

Why do you believe that miners are really that stupid?

[JackH]

1) So I fire up 2000 nodes, all selecting 200MB as cap.

2) I make the miners belive this is the prefered block size.

Why do you believe that miners are really that stupid?

My point is that it opens up to sybil attack. My suggestion is obviously a quick and dirty model.

EDIT: How would miners actually know what the "real" consensus is? Ask around on the forum? What if I set the blocksize to 14MB. That would still knock off plenty of nodes.

[smooth]

1) So I fire up 2000 nodes, all selecting 200MB as cap.

2) I make the miners belive this is the prefered block size.

Why do you believe that miners are really that stupid?

My point is that it opens up to sybil attack. My suggestion is obviously a quick and dirty model.

Okay, I agree with that.

EDIT: How would miners actually know what the "real" consensus is? Ask around on the forum? What if I set the blocksize to 14MB. That would still knock off plenty of nodes.

See my post above.

I think I read somewhere a Peter R post where he suggested the case of miners with BU sticking with 1 MB for a while. Then (especially when there is fee pressure) one brave miner might deem it worth the risk and try 1.1 MB to see what happens. If "nothing bad" happens, other miners would likely follow. Extrapolate from there.