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

As I understand it, miners would presumably communicate with each other, since other forms of ostracization of uncooperative fellows are entirely within their realm of possibility.

From the somewhat unified appearance of the Chinese miners at the last conference, a conservative approach seems to strongly match their behaviour.

And they would want node operators, businesses and end users supporting their move, so they would indicate a serious desire to raise the limit to the other stakeholders in advance and in plain language so that preparations could be made.

This is what I actually expect to happen, whether BU receives wider adoption or not - if there is no Economic Change Event beforehand. Or perhaps there has to be one for all to learn a lesson.

BU will let the user select a given Core or XT BIP (this is still be worked on (BUIP002, probably not supposed to link it here)), so for example if they turned on the BIP101 option, their node would mimic an XT node as far as following BIP101, including the 75% threshold and specific starting block.

Just like today, where if XT were winning Core miners might switch to XT, and if not they wouldn't, it's the same dynamic: if XT were winning, the BU miners would likely set their blocksize settings to BIP101. They can do this even faster than Core miners can switch to XT since it's just a GUI setting, not a new client to download. 


They can just follow Core. BU can be set up to default to Core behavior (it doesn't now, but it's an experimental release; anyone could fork it that way, trivially). I mean, you could say the same about XT: dumb users might try using XT. Could happen. This certainly isn't a security risk, or else Bitcoin is doomed because there's no way to stop people from releasing forks. Yeah I know XT has the 75% failsafe, so then imagine the reverse: everyone is using XT and someone dumb downloaded Core with its 1MB cap and tried to mine but kept not being able to build any blocks because their client rejected all the XT blocks.

Point is, the situation today is that miners and nodes need to pay attention to developments today. They can't just blindly trust whatever Core puts out - and if that's the expectation then we already have bigger problems.

A signal can be more or less reliable, miners will analyze their environment like every intelligent human beings are able to do so.

For example :
- transactions are slow because blocksize limit is often hit + nothing suspicous in the nodes activity + a majority of nodes signals their wish to increase the blocksize => miners will choose to increase the blocksize according to the nodes
- blocks are way below the limit + suspicious nodes activity + a majority of nodes signal their wish to increase the blocksize => miners will choose to no increase the blocksize

Basically it's likely that the blocksize will only be increased when it's needed.

I think you've just not understood the answers you've been given multiple times:

BU does not by itself open up a new Sybil attack vector - anything you've described can be used against Core just as easily.

This will be my last post on this "Sybil attack" hobby horse. Over and out.

P.S. So far since joining this thread, I've been kicked off by the forum software once, denied login for 45s, and now throttled for posting within a 360s cool-off period.
You may find these settings useful on your forum, but they do not contribute to my good experience as a new user trying to participate in this thread.
FWIW I've never run into such limits on the other forum proposed to hold this discussion.

To make it as clear as possible regarding Sybil attacks, any miner now running BU would be a fool to deviate from 1MB settings. Any node now running BU for business purposes would be a fool to deviate from 1MB settings. (Unless to make a point, experiment, etc.)

That is why a Sybil attack won't work and has nothing to do with BU. The reason people think it has something to do with BU is, people think consensus comes from everyone trusting the Core devs to set it. It doesn't. It comes from everyone having skin in the game and knowing if they deviate from the prevailing consensus in the network - no matter how it arose - they lose money. Yes, Core's approach does guard against the occasional careless miner who would accidentally or just foolishly mess with their settings, but that can be handled with warnings, etc. in the GUI. Careless users can lose money in a lot of ways already.

Changing the settings happens on market timing, probably with several months of debate and planning as consensus coalesces. Just like now except the options are not just Core vs. XT.

How exactly does setting the block size limit constitute as a vote for that block size? How would anyone else know that you set your node to accept a certain maximum block size? If there is no mechanism for this (and I couldn't find any in the code), then a lot of things said here are wrong.

If there is no mechanism that tells everyone else what they are accepting as the max block size, then there is no voting happening. A sybil attack wouldn't work since there is no voting.

Additionally, miners wouldn't know when to increase the block size as the safe method of deploying the block size limit as a hard fork is no longer there. It could result in either nothing happening as miners want to play it safe, or the blockchain forking in multiple ways as miners test out different block sizes. Either way could be catastrophic.

Lastly, why would it be a good idea for users (especially non-technical users) to decide what their block size limit is? Not everyone is smart enough to know all of the implications of why a certain block size limit should be accepted or not.

This is indeed a headspinning attack and should be considered carefully. While Satoshi was able to publish Bitcoin with many opportunities to attack, today such an option is no longer reasonable since the value of the network did explode.

I don't feel comfortable to argue with you on this as you obviously know more about bitcoin (technically) than me. But since the envirenment here seems a bit more hostile against BU than healthy-critical and the persons knowing most about BU are not willing to attempt this discussion in this forum for reasons I can understand, let me give a try to be the "angel's advocate": I think this attack is based on strange assumptions:

- you assume a correlation between miner's hashrate and miner's capability to deal with large blocks. I don't see this. In fact the great firewall indicates the opposite.
- you assume that a small increase of the blocklimit can prune miners out. I don't see this, since miners are free to not fill up blocks, download capacity is no issue and miners can easily set an upload-limit for their node. Or am I missing something?
- you assume that miners will blindly follow the pruning and unknowingly support the 85%-attack while the number of nodes and miners are dwarfing. This is assuming they act against their own financial incentive.
- you assume the honest miners will not detect the 2,000-nodes-sybill-attack, which can easily to detected by using some basic statistics like median, average and standard deviation. Miners can decrease the blocklimit if they feel something going on.

Sure, an blocksize increase will lead to the pruning of some nodes. For example, my excessive poor internet connection will force me to limit the upload of my node (which is easily possible with BU's gui) when blocks reach 2 MB, so that I will no longer be able to propagate blocks to 8 peers in 30 seconds. Maybe to 4 or 5. But I think this will be inevitable since blocks have to increase in size.

But after all I feel far from being comfortable with this attack possibility and regard it as a serious concern for Bitcoin Unlimited.

Correct me if I'm wrong, but it sounds like you're making the point that there are lot of dumb people out there, so some miners and nodes will likely be dumb and set BU in ways that are unprofitable. Could be, but those same people might run XT or mod their Core foolishly.

For example, any smart miner running BU right now would want to mimic Core settings - unless they didn't mind losing money to make a point. If dumb people are the worry, set the defaults to mimic Core behavior exactly and include a scary warning not to change the settings or lose money. If they're dumb enough to still do it, they're dumb enough to send their coins to the wrong address, etc. I don't see dumb people as a big issue - do you?

Gavin at least has already looked at the code, and while he found code smells in places, his comments were not immediately dismissive.

So I think anyone willing to further review the BU code is welcome to, given that it's openly published.

It might make sense to take such review to where the Bitcoin Unlimited developers are, just like Gavin did.

My personal limit can mimic 2000 limits. Thus I can spoof the network to behave as if it is ready for 1.5MB. If the miners believe that, its only a matter of time.

We have covered this 10 times in the thread now, yet we are given no answer to how you would prevent an incremental Sybil attack like brg444 posted.

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.

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.

Keep up with the thread please.

Two words: sybil attack

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.

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

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

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

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

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.

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.