bitcoin "unlimited" seeks review

[LovelyDay]

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.

I take your point on the minimal value of this information - at the outset at least.

I think the conveyance of this information ("vote") is pretty much an add-on to the BU idea, and time has to show whether it has any meaningful value.

[1714567975]

1714567975

[1714567975]

1714567975

[1714567975]

1714567975

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

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.

Yuck, this is really not a good model. If "nothing happens", and "what if this works" or "maybe we should try to" are really not solid models for something that relies on thousands of unknown factors. The moment there is the slightest room for attack you be sure alot of people will exploit it.

They will because cashing out on Bitcoin's security gaps is the biggest prize on the internet right now. There are NO good actors.

[Zangelbert Bingledack]

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.

Yeah, and it's worth noting the reasons people don't usually mod the blocksize in Core: because there are overwhelming economic incentives for a miner not to mine or build on a block that will likely be orphaned, and overwhelming economic incentives for node operators doing business not to accept such blocks.

The same incentives apply to BU. There are [repeating the above verbatim] "overwhelming economic incentives for a miner not to mine or build on a block that will likely be orphaned, and overwhelming economic incentives for node operators doing business not to accept such blocks."

As far as I understand it, BU merely removes the artificial authoritative "oomph" of the blocksize cap setting being hardwired in Core (and XT). It can be made to default to Core's blocksize cap settings (it doesn't now, but it would be trivial to make a fork that does), and there can be scary warnings about changing it away from Core's settings. It just takes away the inconvenience barrier, with the hope that people would follow a different Schelling point than the one set by Core. Failure of BU probably means just "everyone sets their settings to mimic Core." That's about the worst it could go, provided there are no coding errors (community definitely should vet it carefully; better yet, Core could just make the blocksize cap user-selectable).

[brg444]

So still not one person on the BU side is willing to tackle the faulty assumption that user defined parameters is somehow a good way to signal the economic majority's preferred blocksize to miners, making its one distinctive aspect pretty much worthless.

[JackH]

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.

Yeah, and it's worth noting the reasons people don't usually mod the blocksize in Core: because there are overwhelming economic incentives for a miner not to mine or build on a block that will likely be orphaned, and overwhelming economic incentives for node operators doing business not to accept such blocks.

The same incentives apply to BU. There are [repeating the above verbatim] "overwhelming economic incentives for a miner not to mine or build on a block that will likely be orphaned, and overwhelming economic incentives for node operators doing business not to accept such blocks."

As far as I understand it, BU merely removes the artificial authoritative "oomph" of the blocksize cap setting being hardwired in Core (and XT). It can be made to default to Core's blocksize cap settings (it doesn't now, but it would be trivial to make a fork that does), and there can be scary warnings about changing it away from Core's settings. It just takes away the inconvenience barrier, with the hope that people would follow a different Schelling point than the one set by Core. Failure of BU probably means just "everyone sets their settings to mimic Core." That's about the worst it could go, provided there are no coding errors (community definitely should vet it carefully; better yet, Core could just make the blocksize cap user-selectable).

User selectable cap means sybil attack. Again, nobody is answering my questions here.

What will BU do to stop my 2000 nodes acting to create the illusion of that the network wishes for very large blocks.

Actually, my Sybil attack can go something like this:

1) Vote for 1.5 MB blocks
2) Check how many nodes I have killed with the increase
3) Vote for 2MB blocks
4) Check how many nodes I have killed with the increase
X) Keep doing until I am the network of nodes. Fill up the blocks and start pushing out the Chinese miners as well.

Incremental Sybil attack, cheap and easy to pull off.

[brg444]

User selectable cap means sybil attack. Again, nobody is answering my questions here.

What will BU do to stop my 2000 nodes acting to create the illusion of that the network wishes for very large blocks.

Actually, my Sybil attack can go something like this:

1) Vote for 1.5 MB blocks
2) Check how many nodes I have killed with the increase
3) Vote for 2MB blocks
4) Check how many nodes I have killed with the increase
X) Keep doing until I am the network of nodes. Fill up the blocks and start pushing out the Chinese miners as well.

Incremental Sybil attack, cheap and easy to pull off.

See my page 2 post for a detailed walk through of what you have in mind.

https://bitcointalk.org/index.php?topic=1312371.msg13430261#msg13430261

[LovelyDay]

So still not one person on the BU side is willing to tackle the faulty assumption that user defined parameters is somehow a good way to signal the economic majority's preferred blocksize to miners, making its one distinctive aspect pretty much worthless.

You're not commenting on the technical aspects here, you're making a value judgment. Fair enough, it's your opinion, but at least substantiate it.
Otherwise I am going to have to disagree and say that plenty of folks find the ability to set their own blocksize limits an idea worthy of consideration.

For one, it has the potential to defuse the current charged atmosphere surrounding this topic, and let the Bitcoin community move on to the many other technical improvements that deserve attention.

Also - in the interest of constructive participation, do you have a better way to signal the economic majority's preferences?

[JackH]

User selectable cap means sybil attack. Again, nobody is answering my questions here.

What will BU do to stop my 2000 nodes acting to create the illusion of that the network wishes for very large blocks.

Actually, my Sybil attack can go something like this:

1) Vote for 1.5 MB blocks
2) Check how many nodes I have killed with the increase
3) Vote for 2MB blocks
4) Check how many nodes I have killed with the increase
X) Keep doing until I am the network of nodes. Fill up the blocks and start pushing out the Chinese miners as well.

Incremental Sybil attack, cheap and easy to pull off.

See my page 2 post for a detailed walk through of what you have in mind.

https://bitcointalk.org/index.php?topic=1312371.msg13430261#msg13430261

Yup, I noticed that one.

The attack is a lot more complex than that. I think you're on the BU forum? Taek had a nice explanation of the centralization pressure enabled by BU. Someone could leverage a sybil attack to effectively do just what he proposed: slowly but surely prune nodes out of the network until it gets consolidated into a few more controllable hands.

Exactly! Too easy to pull off. So we are back to square one. Why choose BU when it cannot resist a simple Sybil attack.

[Zangelbert Bingledack]

"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

Here's the difference with Core:

1) So I fire up 2000 nodes, hire a coder to mod the Core code to set 200MB as cap.

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

3) They all go "yayyy tons of fees!" and hire a coder to mod the Core code so they can 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

Not that you could actually do (2) anyway, but that's just me defending Core again. As I mentioned, this is just a bit more convenient in BU. Someone with the resources to spin out 1/3 of the total number of nodes now on the network, and mining pools that are actually mining the blocks now, are going to find it trivial to do (1) and (3) right now, in Bitcoin with Core, if they wanted to. The convenience of BU is not going to be of any noticeable help, and even if you think it is, that horse has left the stable - the miners convinced can just download BU. Under that view, all that was necessary to kill Bitcoin was to release BU. That can't be right.

[Fatman3001]

If you want info about Bitcoin Unlimited you should check out their forum (https://bitco.in/forum/forums/bitcoin-unlimited.15/). Most of their discussions is there, including technical and not.

The idea was to have some technical focussed constructive discourse and this is a more neutral forum and also where more Bitcoin experts hang out.

Adam

Surely this is a joke?  The only reason the other forum was created was because Bitcointalk was becoming known in the Bitcoin community as North Korea.  

Think he meant more likely to find constructive criticism here, assuming thread stays open and is not censored. Big assumptions and poor choice of words, I know.

Hmmmm.... "constructive criticism"... thus far we've had four pages of Jack here ranting about a far-fetched sybil attack that isn't even unique to BU.

DIsclaimer: I'm not on the BU boat...yet, but if this is going to turn into a charade then it concerns all of us.

[LovelyDay]

User selectable cap means sybil attack. Again, nobody is answering my questions here.

What will BU do to stop my 2000 nodes acting to create the illusion of that the network wishes for very large blocks.

Actually, my Sybil attack can go something like this:

1) Vote for 1.5 MB blocks
2) Check how many nodes I have killed with the increase
3) Vote for 2MB blocks
4) Check how many nodes I have killed with the increase
X) Keep doing until I am the network of nodes. Fill up the blocks and start pushing out the Chinese miners as well.

Incremental Sybil attack, cheap and easy to pull off.

See my page 2 post for a detailed walk through of what you have in mind.

https://bitcointalk.org/index.php?topic=1312371.msg13430261#msg13430261

Yup, I noticed that one.

The attack is a lot more complex than that. I think you're on the BU forum? Taek had a nice explanation of the centralization pressure enabled by BU. Someone could leverage a sybil attack to effectively do just what he proposed: slowly but surely prune nodes out of the network until it gets consolidated into a few more controllable hands.

Exactly! Too easy to pull off. So we are back to square one. Why choose BU when it cannot resist a simple Sybil attack.

The plan comes to an end very soon (perhaps at 2MB now) when you run into the actual limit imposed by transaction demand and the capabilities of the network - things which affect the bottom line of miners and to which the mining majority has strong incentive to pay attention.

At that point, you (and others who voted for an increase and got it) have established a new, better consensus for the users of the network. Congratulations, this is the point of BU.

Any excessive votes past that limit carries very little real-world import.

[JackH]

Yes it IS unique to BU, because it apparently allows nodes to set blocksize limits/indications.

The best answer I have to what is a VERY well accepted Sybil attack, is that "people are not on this forum".

Really? I should switch to BU based on the answer that there is nobody here? And since all you XT/BU people screamed to post about your Altcoin projects here, well, here you go. POST the answer.

[Zangelbert Bingledack]

Actually, my Sybil attack can go something like this:

1) Vote for 1.5 MB blocks
2) Check how many nodes I have killed with the increase
3) Vote for 2MB blocks
4) Check how many nodes I have killed with the increase
X) Keep doing until I am the network of nodes. Fill up the blocks and start pushing out the Chinese miners as well.

Incremental Sybil attack, cheap and easy to pull off.

You can do the same with Core by modding it. Unless you're making assumptions about how people would configure their settings. Sure, if you think people will do unprofitable things without Core supervision, then yeah that could happen. I tend to think people with skin in the game will not do anything silly. A few may try, lose money, end of story - in fact this happened at the halving in November 2012 when a few miners modded their Core clients to keep getting 50 BTC per block. They lost $500 per pop, then "we never did that again."

[JackH]

Actually, my Sybil attack can go something like this:

1) Vote for 1.5 MB blocks
2) Check how many nodes I have killed with the increase
3) Vote for 2MB blocks
4) Check how many nodes I have killed with the increase
X) Keep doing until I am the network of nodes. Fill up the blocks and start pushing out the Chinese miners as well.

Incremental Sybil attack, cheap and easy to pull off.

You can do the same with Core by modding it. Unless you're making assumptions about how people would configure their settings. Sure, if you think people will do unprofitable things without Core supervision, then yeah that could happen. I tend to think people with skin in the game will not do anything silly. A few may try, lose money, end of story - in fact this happened at the halving in November 2012 when a few miners modded their Core clients to keep getting 50 BTC per block. They lost $500 per pop, then "we never did that again."

If I modify core it is no longer core consensus rules. No I cannot do the SAME sybil attack on core.

[NxtChg]

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.

So does BU follow the longest chain or not?

If not, than it obviously can't work, as it was pointed out a million times already - everybody will fork off randomly according to their limit.

If it follows the longest chain, then your limit doesn't matter, as eventually you will have to switch (otherwise, again, you will be forked off).

Since BU can only work if it follows miners, your personal limit becomes irrelevant: if you insist on setting it, you will just hurt yourself and will still have to eventually switch if you plan to continue using Bitcoin.

This limit cannot be used as a signal to miners because of Sybil attacks, so it's pointless.

Yet BU proponents push it as the main feature of BU

[BldSwtTrs]

So still not one person on the BU side is willing to tackle the faulty assumption that user defined parameters is somehow a good way to signal the economic majority's preferred blocksize to miners, making its one distinctive aspect pretty much worthless.

Maybe you should care to explain why it's a faulty assumption for starters.

[brg444]

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

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

Andddd it ends there because the economic majority currently has settled on enforcing a 1MB nodes and that any change to that rule require consensus upgrade from the whole network.

[brg444]

So still not one person on the BU side is willing to tackle the faulty assumption that user defined parameters is somehow a good way to signal the economic majority's preferred blocksize to miners, making its one distinctive aspect pretty much worthless.

Maybe you should care to explain why it's a faulty assumption for starters.

Keep up with the thread please.

Two words: sybil attack

[Zangelbert Bingledack]

This limit cannot be used as a signal to miners because of Sybil attacks, so it's pointless.

Yet BU proponents push it as the main feature of BU

Some BU proponents don't understand BU and have a lot of odd ideas about it. The main feature is that it lets the user select what the biggest block they will accept and the biggest block they will mine, instead of these being fixed at 1MB (or whatever). In practice, right now, any miner would be foolish to mine with settings besides 1MB.

The idea is simply that users can basically choose their BIP rather than having it bundled in with Core/XT. Perhaps that makes more sense? Of course users would converge on a BIP (something BIP-like proposed by someone else) - just like they converge on Core or XT based on what they see others are doing.

[LovelyDay]

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.

So does BU follow the longest chain or not?

If not, than it obviously can't work, as it was pointed out a million times already - everybody will fork off randomly according to their limit.

If it follows the longest chain, then your limit doesn't matter, as eventually you will have to switch (otherwise, again, you will be forked off).

Since BU can only work if it follows miners, your personal limit becomes irrelevant: if you insist on setting it, you will just hurt yourself and will still have to eventually switch if you plan to continue using Bitcoin.

This limit cannot be used as a signal to miners because of Sybil attacks, so it's pointless.

Yet BU proponents push it as the main feature of BU

It follows the longest chain as long as it can (based on your resources), and if it can no longer follow, it drops out.

The personal limit can be of value as a signal, since there is no automatism between your "vote" and increased block size.
There is little basis for the assumption that miners will be foolish enough to fall for a simple Sybil attack through this channel.
And BU proponents do not think this signal information is the main feature, that's a silly assumption to make.