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

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.

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.

Yup, I noticed that one.


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

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?

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

https://bitcointalksearch.org/topic/m.13430261

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.

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.

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

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.

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.

Okay, I agree with that.


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.

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.

Why do you believe that miners are really that stupid?

"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

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

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.

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.

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?

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.

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.