Bitcoin Forum

The proposers of bitcoin unlimited said they would like to get some review which seems reasonable, if others would like to help.

The proposal seems at first skim to be a copy of a few existing technologies from Bitcoin's roadmap and were first proposed by Greg Maxwell and others*: weak-blocks & network-compression/IBLT to reduce orphan risk, and flexcap (or a variant of it perhaps).

Perhaps they could start by explaining what it is & how it works.  This might include unimplemented ideas, and a summary of what the code currently for download on the manifesto page does.

To review it will be clearer if you state your assumptions, and claimed benefits, and why you think those benefits hold.  (Bear in mind if input assumptions are theoretical and known to not hold in practice, while that can be fine for theoretical results, it will be difficult to use the resulting conclusions in a real system).  Particularly claimed compatibilities with Bitcoin and how the dynamic block-size game-theory is expected to work and remain secure with SPV mining, selfish-mining, block-withholding and fair (progress-free) mining could also use explaining.

I suggest the sensible thing is if there is something new or insightful, that Bitcoin consider adopting the technology and the BU proponents get behind that.

Maintaining a new coin is a rather complex undertaking and screwing up, as something like 40% of projects that have tried it have done, is very expensive of other peoples money.

To make progress on review it would be helpful to separate technical from political opinions.

Adam

* some citations seem to be notably missing, I trust this is unintentional.

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

i feel a little bit sarcasm  :P ?

i hope this thread will not waste too much dev-time for nothing in the end. PR is necessary but time is limited too.

We shouldn't assume the Core developers or anyone else is immune from review and I believe there is always something to learn my looking over other implementations. I think it is both extremely healthy for there to be multiple implementations in our ecosystem with different project maintainers and for them to both collaborate and review each others work. We should support Core, BU , libbitcoin , and others with testing.


To add to the discussion Gavin represents a qualified outside developer that conducted a very brief review of the code and this was his response-

https://bitco.in/forum/threads/i-really-want-to-like-bitcoin-unlimited.684/


More review of both core and BU is recommended and encouraged.

Agree I was kind of hoping Aquentys would be able to explain what it is and how they think it works.  It saves time reviewing when people take the time to explain their assumptions.

Adam

Here are some links from kanzure on IRC (Aquentys started a discussion but wanted to continue on a forum for persistence):


Adam

If you can stay on topic as I suggested: "To make progress on review it would be helpful to separate technical from political opinions." I dont see a problem. People have been discussing bitcoin NG ideas on here for years.

Are you able to explain what BU is and how you think it works?  I gave some reviewer questions in the OP.

Adam

From what I understand, BU moves the block size limit from consensus rules to a node policy rule. Instead of having the limit hard coded in, the user chooses their own block size limit. Also if a BU node detects a blockchain that has a higher block size (up to a certain user configurable threshold), after that chain is a number of blocks deep (user configurable), then it will switch to use that blockchain and set its block size limit higher.

So what happens if I left my node at 1MB +10% user threshold and a 1.2MB block comes - does my node reject it?

How will the network not split into a myriad little shards which diverge following accidental and/or intentional double-spends without manual human coordination?

Adam

That is something else, perhaps from one of the research papers on future areas of interest.

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.

The idea is that users would converge on a consensus Schelling point through various communication channels because of the overwhelming economic incentive to do so. The situation in a BU world would be no different than now except that there would be no reliance on Core (or XT) to determine from on high what the options are. BU rejects the idea that it is the job of Core (or XT, or BU) developers to govern policy on consensus or restrict the conveniently available policy options on blocksize.

BU supporters believe that to have it otherwise is the tail wagging the dog: the finding of market-favored consensus is not aided, but rather hindered, by attempts to spoonfeed consensus parameters to the users. (This is putting it gently. Having a controversial parameter set at a specific number by default would be spoonfeeding, not even having the option to change it is more like force-feeding.)

Widespread adoption of BU, or adoption of BU-like configurability of settings within Core/XT, would relegate developer-led BIPs on controversial changes to the status of mere recommendations. Proposals like 2-4-8 would be taken into consideration, but would have to compete in the market on their own without the artificial advantage of the current barrier of inconvenience and technical ability (users having to mod their code to deviate from Core settings).

BU does not support bigger blocks, nor smaller blocks; it is rather a tool for consensus on blocksize to emerge in a more natural, market-driven way - free of market intervention as it were.

Adam, if you are confident that, for instance, 2-4-8 scaling is the best option and would be supported by the market, I think you should either support BU or support a Core BIP to make the blocksize settings configurable within the Core client.

Right now the leaders of the dominant Bitcoin implementation are for a low blocksize cap, but imagine if the situation reverses and big blockists are in control, to the consternation of many in the community. I think you would not want them locking down the settings. You might say, "You folks are doing fine otherwise, but you are off on the blocksize cap. Why try to play central planner? Please leave it up to the market if you are so sure the market will like your huge blocks. People will follow your recommendations if they like them anyway, so what are you worried about?"

If I were Core maintainer, I would do the same. Perhaps I would set a higher default, but I would not take the option away from the user. To do so risks sudden consensus shocks due to friction effects, risks my position being undermined silently, and most of all assumes I know better than everyone else. I might set it at 10MB. But I may be wrong; I'd rather trust in the market, because none of us knows better than a million people all with skin in the game.

As for how communication to settle on a Schelling consensus happens, besides the usual out-of-band communication that happens now in the debate, there is also interest in adding a tool within BU to efficiently communicate information about blocksize settings across the network, thereby facilitating an emergent consensus.


The game theory is the same as that arising in the choice of Core vs. XT vs. whatever (or among the BIPs by the miners and other stakeholders; if we look at the game theoretic considerations applying to the Core dev consensus process I'm sure you realize that problem is intractable). Miners and nodes have all the same choices now, except there is some additional friction introduced by Core's locking down of the blocksize settings, forcing miners and nodes to mod the Core code if they want to change them.

The question ought to be turned around: what are the game-theoretic considerations involved in having a monolithic reference client causing complicated issues of inertia, authority, and potential power grabs on top of the cleaner game theory? If tractability of a game theory analysis is the goal, surely BU is at least no more complicated than the situation under Core in the event of a hard fork.


Ah. This is good. What I believe you are not noticing is that "manual human coordination" need not be top-down. Coordination can emerge, and it can be just as solid as any. Are you familiar with situations (https://www.youtube.com/watch?v=IYO3tOqDISE) where it does? That would save a lot of ink.

From a pure tech point of view, what is stopping the sybil attack on BU?

Without having dug much into it, can you answer what there is in place to stop me from setting up 2000+ nodes and adjusting the blocksize to 200MB per block, and thus subverting the entire network to form consensus on a smaller size?

Nodes decide how they play the game. If they feel that 2000 nodes suddenly appearing on the horizon demanding 200MB blocks is the way forward, then thats what they do. If, on the other hand, they are rational, then they wont.

I thought we were discussing how it works, you are discussing how to attack it.   ;)

There's nothing stopping an attacker from modding the Core client themselves and setting up 2000 nodes with 200MB blocks. Or at least, it's not the little bit of C++ coding that's likely going to be what stops them.

Bitcoin Unlimited is NOT a big blocks client, let alone an "unlimited blocksize" client. The "unlimited" only refers to unlimited options. At this time, BU is simply Core + a few options. They can all be turned off to mimic Core exactly.

Discussing its strengths and weaknesses is one of the best ways to understand how it works. Isn't it rational for many to attack the network? Don't we have to prepare for sybil attacks in a hostile environment? Shouldn't we design a network that isn't dependent upon rational actors with goodwill intent and is protected against both irrational actors, actors with malicious intent, and mistakes due to incompetance, shortcuts, or ignorance?


Isn't the difference being that BU will allow maxBlockSize to be determined by nodes and core/xt/ect... insures that miners make that decision, or am I missing something?

IIRC the node will keep the block and watch the chain it is on. If the chain it is on becomes n blocks deep (where n is user configurable) then your client will switch to use that chain as the active one. Otherwise it stays with the one it is currently using.

I don't know. You'll have to ask someone else about that.

Well, that is already the case. BU just makes it more convenient. And granular: you don't just have a choice between Core@1MB and XT@8MB+, but rather anything - but the increased number of options doesn't mean users can't converge on a Schelling point; more options doesn't mean more viable options.

I imagine a series of jumps from one Schelling-point consensus to the next. For example, first everyone warily converges on Pieter's very conservative BIP (+17%/year), then as capacity increases faster than expected people jump to Adam's 2-4-8, then an unforeseen adoption surge induces a jump to BIP101, and finally people see where this is going and nodes/miners - as the foremost experts on the network - move independently of the devs to create their own Schelling points.

A specialization and division of labor would occur as it should in any mature industry, with consensus-parameter-setting unbundled from the software offerings of Core/etc. People would "hire" the Core/etc. devs for their secure code, not for their determining of consensus parameters. Those would be set by the larger market, reacting dynamically to market conditions. To do otherwise is arguably a security risk as it concentrates power in one team of devs.

True, I suppose nodes can already break off from the main chain with little to no hashing security and create their own chain. You are suggesting that in BU a sybil attack is made easier though as the incentive structures under core and xt is to stay on the chain with the majority hashing security? It is far easier and less expensive to spin up a bunch of nodes than replicate replicate the hashing power. Would you agree or disagree?

I would say a Sybil attacker with the resources to cook up 1000 nodes will have no trouble modding a bit of C++ code or hiring a coder to do that. That's the least of the barriers, and even if it were to be relied on, that would be a losing battle. If inconvenience were all that is keeping Bitcoin secure, we would have a problem. Also see my edit to the post immediately above yours.

I feel that it will just derail what is supposed to be a general discussion on the pros and cons of moving away from hard coded limits. We either find that the concept is valid, in which case a discussion on attack vectors is called for, or its found to be unworkable, in which case the attack discussion in irrelevant.

Also, its very hard to find attack vectors that are specific to this implementation and that cannot be applied to bitcoin as a whole.

They don't even have to break off and form their own chain.  They can just recompile with a parameter changed to accept larger blocks.  And then in theory that larger block would be orphaned and it would go back to the main chain eventually. (There are other considerations for say allowing 200MB blocks with regard to just changing that parameter, but safe to ignore them in this reply I think).

Is there any coded algorithm for determining blocksize consensus in BU available to post here?

Not sure what you mean. I'm just saying if someone wanted to create a fork of Core with a 200MB blocksize cap now, it's not difficult. Then if they had the resources to deploy 1000 nodes, we'd be at your scenario.

Point is, this has nothing to do with BU.

I'm not sure if you're intentionally avoiding the gaping hole in your analysis or if you just don't see it.

Yes, someone could spin up 1000 nodes tomorrow that advertise a larger block size but the context is quite different in that the network has agreed by consensus that these would be invalid. For that reason miners will not mine such blocks or they will get forked off the network for not respecting the consenus rules (and lose money).

From what I understand BU proposes that all of these nodes be aggregated into a signal that miners should consider when creating the blocks. That is the nature of a sybil attack.

With current Core consensus rules it is very easy for miners to tell nodes apart from eachother, there are two kinds: 1MB nodes and the rest.

The difference being that those 1k nodes would be producing orphaned blocks on the original chain with 99% of the hashing security(thus committing economic suicide) and with the BU proposal one is assuming the miners have accepted the proposal and allow the nodes to dynamically adjust blocksize. This is a significant difference, is it not? Don't we want to assume the future hypothetical that BU has the majority of mining security behind it to evaluate it true potential?

Sorry for stepping in.

If someone tries to sybill the networks and sets up 2,000 nodes with a blocklimit of 200 MB, no responsible miner would take this as a reason to set his own limit to 200 MB.

When one of the miners was corrupted too, he could release a 200 MB block and 2,000 Nodes would propagate it. All the other nodes with lower limits would reject the block untill it reaches some depth. For that to happen the majority of miners has to be corrupted.

To be honest, I don't think that this attack is worth to be discussed - while Adam Back raised some question I'd love to see addressed.

Edit, cause "brand new" looks ugly: I'm C. Bergmann (https://bitcointalk.org/index.php?action=profile;u=149679) but unfortunately lost my password and my bitcoin-signed pledge for recovery was not answered. I'm not affiliated with BU but I like the idea and think it is worth to be discussed open-minded.

BitUsher, so you're saying an attacker spinning up all those nodes would encourage a bunch of other people to raise their limits to 200MB? Similar to what I said above, any miner wishing to take advantage of the situation and mine 200MB blocks is not going to be deterred by having to mod the code a bit. Miners already do that, in fact. Again, BU is only a change in convenience; if convenience is the different between Bitcoin being secure and insecure, we have bigger problems already (soon enough someone's just gonna make a patch, then it will be dirt simple to mod any consensus setting). It won't likely be fruitful to critique BU along those lines.

I'm pretty sure continued discussion on this point would clutter the thread quite a bit and not really be related to what Adam is asking about. Maybe make a new thread?

Yes, of course those 200MB blocks will be orphaned now with BU. We are discussing how BU would hypothetically work if a majority of the mining power supported the implementation and relegated the blocksize to nodes instead of themselves. BU isn't assuming switching to PoS in the future, right? The security model right now assumes a coordinated attack of miners and nodes. BU would allow the nodes to perform this attack immediately as the miners will be relegating their maxblocksize to the nodes, right?


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 ?


P.S... I am not posing these questions to denigrate your efforts and am genuinely interested in learning about BU and helping other implementations. Please don't be offended by these questions.

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.

You wanted to be able to post on this forum and not be censored, yet you are not prepared to answer the hard questions posed to BU?

Lets try again. 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.

Adam's questions are somehow of a similar fashion as he is asking how we prevent multiple shards of the block to happen, where each node follows an arbitrary size and starts rejecting the larger blocks. Meaning, I can kick Adam out of the network quite quickly as my 2000 nodes in consensus for 200MB blocks will ignore his 1MB + 10% blocks consensus with itself.

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.

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?

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.

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.

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?

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.

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.

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.

Thanks for clearing that up.

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.

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.

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.  

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.

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

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.

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?

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.

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

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.

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.

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.

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?

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.

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.

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

"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

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.

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.

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.

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.

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

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.

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

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?

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.

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.

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.

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.

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.

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.

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

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

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.

Keep up with the thread please.

Two words: sybil attack

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

What annoys me and confuses a lot of people is this "emergent consensus".

Some people, Peter R in particular, make it sound as if setting individual limit on nodes somehow magically makes consensus to emerge.

When in reality it's the good old "everybody agrees first, then sets their limit to the exact same value" consensus.

The only difference is that setting the limit is now even less reliable than the soft fork.

This clarifies a lot. This indicates that BU is more of a political difference than technical one. Re-flexibly I am drawn to this idea as it represents empowering the users with more of a voice where they have more of a stake in the decision process and this could be a method of incentivizing full nodes. On the flip side this does take away some of the power from developers and this can have some negative consequences as technical decisions based upon meritocracy now become political decisions based upon node vote for BIPs. Another concern is that many of these very talented developers are donating their time on a volunteer basis and one of the primary things that incentivizes their contributions is them having a say in the direction of this open source project.

 I am not so naive to believe there are no personal motivations behind some of the developers steering code to favor their side business as one of their motivations, but have more of a nuanced view and believe developers have multiple motivations from securing the code and peoples investments (including their own) , to philosophical motivations for what bitcoin represents and its impact upon society, to enjoying the challenge of the project and fun of learning.

BU brings up many complex issues about governance which I will have to reflect upon more.

Here are two posts from testing1567 on reddit (says he doesnt have a bitcointalk account):


and another one:


_{Mod note: fixed quote links}

Yep, you got. EDIT: At least that's how I see it. There are many ideas about how it might go. I prefer to focus on the user-selectable blocksize limit only, because that is a simpler issue. Besides, the other features can be turned off easily until they have more theoretical and experimental vetting. Or a forked client can be offered without those other options if people think that's too dangerous an option to give to the user. So I don't see it as material to the main question of whether it's a good idea to allow users to set the blocksize themselves.


I mentioned this above, but things like BIP101, BIP102, etc. will be selectable as options. Consider a scenario where XT/BIP101 were adopted. The difference between the current situation and a scenario where BU is dominant:

• Current situation: People notice the majority is moving to XT, flagging support for BIP101, so even the Core users switch to XT. On the flag day some stragglers might remain and cause a fork.
• If BU is the dominant implementation: People notice the majority is moving to BIP101, flagging support for BIP101, so even people that prefer 1MB or 2MB or whatever switch to BIP101. On the flag day some stragglers might remain and cause a fork.

Doesn't seem that different, right? The only real difference is that options aren't just Core's chosen blocksize cap and BIP101. There would be BIP102, etc. to choose from, as well as other options not given by Core or XT. It'd be very much like there weren't just Core and XT, but Core, XT, and a bunch more to choose from, and we see who wins - just like now except with BU the consensus-parameter-setting is unbundled from the secure-code-providing service of the Core/XT/etc. devs.

Rather than being spoonfed consensus options from an ivory tower (or two ivory towers), there are many options. Convergence on one options happens the same way, for the same reasons - just smoother.

Very nice to see Dr. Backamoto drolly trolling the F*CK out of the Gavinistas, albeit in his studiously academic Sword of Logic idiom!   :)

Weak blocks, etc. are great ideas....for an altcoin.  Because Bitcoin's social contract is at this point, for better or worse, ossified and absent a crisis basically carved in stone.

Here's all the info you need to know about Unlimiturd: you may have any block size you want, so long as it's <16MB.   ::)

Never mind the hilarity of "Bitcoin" "Unlimited" selecting a max_block_size LIMITED to 20% less than GavinCoin's original ill-conceived 20MB proposal.

Ignore the obvious problem of Sybil attacks, especially those exploiting BTC's current crummy P2P code and superlinear vulnerability to maliciously construed (ie very slow to verify) blocks.

The important thing is to distill our hatred of Thermos/Core/Blockstream/MPEX into a singular frame, such as the currently popular "North Korea" canard.

Only when Hearn's Redditard Army is unified around a common theme can the next stage of his puppet masters' Manufacturing Dissent strategem be enacted....

Too bad for them sunlight is the best disinfectant, and this thread is the functional equivalent of a coronal mass ejection right onto the Coinbase Pointy-headed CEO, Bitcoin Judas, Frap.doc, and Peter R's stupid faces!   :D

Those posts reflect a very different version of BU than has been described by its proponents in this thread . Either they have't fully reviewed the code or testing1567 is incorrect but there is a discrepency. I suppose I will have to read the code myself one day to get to the bottom of this.

This.

Right now the only difference is a nice front end to change a parameter (ignoring again other issues to keep the network secure).  Even a non programmer can edit it easily.

In case anyone was wondering if letting users select their own blocksize cap is a total wacko idea that some Bitcoin newbs came up with, note that Gavin supported that idea in 2013:

https://i.imgur.com/EO4zVXJ.png

Doesn't mean it's not a wacko idea! It could well be. But it should give an idea that it's not totally out of left field. I encourage everyone to read the thread from back then:

https://bitcointalk.org/index.php?topic=140233.msg1503099#msg1503099

Many points likely to be raised here were addressed back then as well.

The comments by testing1567 are showing up for me.

BitUsher, please note that I've been focusing on one part of BU - the aspect I consider to be the major one - because I know this discussion will quickly become impossible if we talk about two many things at once (already 6 pages), but there is another aspect of BU called the "oversized block acceptance depth" or "excessive block acceptance depth" that was originally thought to be either necessary or useful to make the concept work. I personally now don't think it is necessary at all, but it may turn out to be useful. It certainly looks like it would be useful, but I'm very much aware of the difficulties in proving that to be case, so for now I consider it an experimental thing for everyone to consider.

Meanwhile, I would like to argue that - even in the absence of that setting - the BU concept of simply letting users set the blocksize cap themselves will not result in chaos, but simply a smoother version of what we have now, with the will of the market expressed more completely and granularly, without jiggering by the wall of inconvenience of having controversial consensus parameters locked down. See here (https://bitcointalk.org/index.php?topic=1312371.msg13429654#msg13429654) for elaboration.

Peter R is using shopworn 1990s chaos theory rhetoric to sell Unlimiturd.   ::) ::) ::)

Specifically, he's invoking the 'spontaneous/emergent order' frame to bedazzle and persuade the drooling masses.

But his hand-waving about chaotic dynamic systems does not apply to Bitcoin, because although Bitcoin is certainly chaotic (and thus gratifyingly dramatic  :D) it is *NOT* dynamic, as the social contract (SHA256 PoW, 10 minute solution target, 21e6 emission, 1MB max block, pay-for-priority) cannot change one iota without alienating a dominant plurality of the socioeconomic majority's critical mass.

Here's a comment from my reddit relevant to BU. [/u/ForkiusMaximus in reply to /u/kanzure.]


Not sure whether I'm allowed to link to reddit, but it was in the thread titled "I just submitted a BIP that would allow users to decide which features to enable. Btcdrak rejected it (he's also controlling the dev mailing list). So I'm posting it here." by /u/anarchystar.

I spoke too soon. testing1567 was just hidden within a downvoted thread. I see it now.

Ok, thanks for clarifying and I understand why you wanted to ignore those "differences" but they should have been revealed up front when I kept asking for clarification as this is a technical subforum where we are meant to discuss the details .

testing1567 had 2 very interesting posts.... do you disagree with any of the information therein before I start pondering them in detail?

I've messaged the mods of /r/btc to enquire, and they confirm he's not banned there.

I didn't realize you were asking about those other features, as you didn't mention them explicitly that I noticed. I just thought you were misunderstanding something about my explanation. That might explain the confusion.

I don't have a lot of thoughts on the acceptance depth aspect. It seems it would work, but it is experimental. It can be turned off, and I have recommended that it be turned off by default and marked as an experimental feature. I don't consider it necessary for the BU concept of letting users determine the blocksize limit, which I consider the main attraction of BU, so for me it's kind of <shrug>.

Yeah, you're wrong. You're referring to src/unlimited.h:


It's a default value of a setting that can be changed in Unlimited. As in: not a permanent feature.

The actual hard limit is in src/consensus/consensus.h:


Note: this means it is 32MB - currently, subject to future removal.
Not 16 as you've now confidently twice claimed.

That's all.

Actually, I did mention this to you on page 3 (https://bitcointalk.org/index.php?topic=1312371.msg13430682#msg13430682). It's been a fast discussion and we forget things, so no worries.

Note to small block adherents: Despite the name, Bitcoin Unlimited is not a "big blocks" implementation. It's simply an implementation that doesn't include a locked-down blocksize as part of the package. It lets the user set it. It could be 500kB if you like.

It's an accident of history that BU is being developed by big block supporters. It could have been developed by small block supporters for the exact same reason: to avoid the dominant Bitcoin implementation from doing something you consider foolish.

As I said in my first post (https://bitcointalk.org/index.php?topic=1312371.msg13429654#msg13429654), right now the leaders of the dominant Bitcoin implementation are for a low blocksize cap, but imagine if the situation reverses and big blockists are in control, to the consternation of many in the community. I think you would not want them locking down the settings. You might say, "You folks are doing fine otherwise, but you are off on the blocksize cap. Why try to play central planner? Please leave it up to the market if you are so sure the market will like your huge blocks. People will follow your recommendations if they like them anyway, so what are you worried about?"

If I were Core maintainer, I would do the same. Perhaps I would set a higher default, but I would not take the option away from the user. To do so risks sudden consensus shocks due to friction effects, risks my position being undermined silently, and most of all assumes I know better than everyone else. I might set it at 10MB. But I may be wrong; I'd rather trust in the market, because none of us knows better than a million people all with skin in the game.

Bitcoin Unlimited is just as much a small blocks implementation, guarding against the possibility of, say, Mike Hearn taking over Core, as against, say, LukeJr. Bitcoin Unlimited is simply against central planning of the blocksize. Instead, blocksize consensus would emerge from each user making their own decisions, signaling, coordination, debate, flag days, expert recommendations, etc. It prevents against centralization of developers in one implementation; again, today it's small block adherents in Core, but what if it became big block adherents? It might start to sound like a pretty good idea to let the market decide.

https://i.imgur.com/aboZ2k3.png

Under BU, all our arguments about blocksize become merely academic. We would be trying to predict what the market would decide, rather than vying over control of the One Ring of Power - the official/reference implementation of Bitcoin. Much rancor could be dispensed with. The market would do its thing and probably maximize value, and Bitcoin would continue, unable to be controlled by anyone. Just the way we like it.

"We would be trying to predict what the market would decide, rather than vying over control of the One Ring of Power - the official/reference implementation of Bitcoin. Much rancor could be dispensed with."

@Zangelbert Bingledack, I'm somewhat sympathetic to your cause but I don't really see how the market mechanism operates here, outside of a very broad definition of "market" which encompasses politics. Node voting doesn't work at all. Without that you are still reduced to politics and whoever shouts the loudest in trying to convince miners what block size they should use.

Correct... thanks. This is interesting stuff.

Does BU have any sig-ops limits for CVE-2013-2292 like what Gavin proposed here - https://github.com/bitcoinxt/bitcoinxt/commit/cc1a7b53629b265e1be6e212d64524f709d27022 of is BU stuck to standard 20k ?
 I see a brief mention of it here - https://bitco.in/forum/threads/bitcoin-unlimited-code-review.359/  nothing confirmed.


Most of my interest is with the experimental stuff discussed by testing1567 as well as some interesting new attack vectors opened up politcially by empowering the nodes with developmental decisions. There are some topics that need further analysis.

This does get me interested in a potential oracle or DAO potentially having the role to determine maxBlockSize by analyzing technical merits/limitations at a higher weight than user demand which could be used to influence a more dynamic block adjustment.


There are indeed many misunderstandings. As a point of clarification 1) Very few of the core developers are "small block adherents", besides 1-2 developers , all suggest raising maxBlockSize. 2) testing1567 indicated " My other issue with BU is it lacks a way to move the blocksize down, only up." is this true for nodes with BU(I am aware that miners can set the limit to anything.)

Really? How? So far what I have seen is that a new block size limit in BU takes effect immediately. There is no mechanism that does the supermajority fork process.

If there is a specific option to for the supermajority fork process for a single BIP, then there should be that for every BIP. Will BU have options to allow the user to support whatever BIP or not? How will new BIPs be added? Through a software upgrade?

A new client download and install takes about 2 minutes, it's not that big of a problem. Even so, the miners would have to either switch to use bigger block sizes after the fork happens or somehow indicate that they are supporting the bigger blocks before the fork (e.g. the supermajority fork process). This means that that larger block size should not take effect immediately. 

Sure you can't blindly trust whatever Core puts out, same with XT, BU and every other software implementation.

Well that's how it is anyway, and even now the market does decide. My point is that there's market friction in the inconvenience barrier of users not being able to set the blocksize cap themselves. That gives artificial solidity to the Schelling point set by Core (as well as the one set by XT). If Core is doing the correct thing, it shouldn't mind putting it to the market test more fully, by taking its finger off the scale.

How much is Core's finger really on the scale here? Well, for example, how many reasons are there to mistrust Mike Hearn? Some would say a lot. That means, as things stand now, even if you want BIP101, you can't really have it if you have a problem with Mike, because XT isn't an option for you. And because other people feel that way, you're further limited. The way Core (and XT) does it now makes it a power struggle, a popularity contest, and a package deal. Maybe Core could stall for a long time before people would finally give up and go with Mike. That's a lot of friction in the market.

And small block adherents, imagine the reverse, if it were Mike and Gavin were running Core and Pieter, Wlad, and Maxwell had broken off and started their own implementation, with maybe Jeff going between. And people were sticking with Core and its giant block plan, heading for catastrophe. You might notice the market friction then.

BU eliminates the power struggle by unbundling the setting of consensus parameters from the rest of the Code. It also of course makes for a lot more choices. If 1MB is too small and 8MB too big, what recourse is there? Roll your own and try to popularize it? Very hard. But propose 4MB and try to get people to agree? More doable. Or what if, like some Chinese miners were saying, 8MB is fine but the scaling to 8GB is ridiculous. What do you do? You have two options, and they are bundled up tightly with all the other aspects of the code and why you choose Core or XT. That's again a lot of market friction.

I think you overlooked Zangelbert's mention that the BIPs are work in progress through BUIP002 - a BU Improvement Proposal.

You are correct that there is no full emulation of the BIP101 threshold etc. for now, and I believe the matter of to which degree BIPs need to be emulated faithfully is still being discussed.

This is indeed an issue as it could divide the network and create a lot of havoc . I personally believe XT's (and as suggested here BU) 75% threshold to be dangerously low as well. A 95% supermajority with a minimum 2 week grace period and alerts sent should be the default for hardforks. Developers have a responsibility to insure that code changes don't effect users investments. The loss of trust by the code itself losing assets would be extremely negative PR for bitcoin.


One doesn't have to pick sides. I respect all of the developers above and can have nuanced opinions and disagreements with individual aspects of their code contributions.

Thanks for the correction in response to my request for exactly such a clarification.

So 16MB is Unlimiturd's max, except when 32MB is the limit.   ::)

Unlimiturd: you may have any block size you want, so long as it's <32MB.

#rekt   ;D

Why should this be removed from the code and made user configurable? It is consensus critical since it can create hard forks, so why should it be removed?

It gives choices you say, so does that mean that we should make everything else that is consensus critical and make that user configurable? Should we remove the block reward schedule? Should we change the difficulty retargeting schedule?

I'm probably not the right person to ask. Other people on that forum should know.


Note that nodes already are empowered with decisions on the consensus parameters, it's just that there is a lot of friction in them doing so because of the inconvenience barrier and the strong Schelling point that artificially sets up. (See my post above in reply to Smooth. I would say the current approach makes it far more political, and BU attempts to eliminate such aspects.)


Interesting idea. Bitcoin has a lot up its sleeve for the future, and DAO+oracles could do amazing things to market efficiency. I think a prediction market would be ideal. Once a decentralized prediction market is up and running and gets liquidity, this will probably be the way the blocksize cap is decided in the future.  

This whole debate has made be extremely optimistic about Bitcoin's future, as I see the ferocity with which people will defend and debate until the right answer has been reached even on a fairly esoteric point to most lay people. This is the power of an economic system powered people with skin in the game. How much have all of us learned, no matter what side of the debate you are on, in this past year? Bitcoin drives us to be better, smarter, wiser, less biased, less emotional, less narrowly focused on our own domains of expertise.


Yeah. By "small" I just mean like single-digit MB sizes for the next few years. I don't mean just permanent 1MB supporters.


No, any limit can be set. I assume testing1567 was referring to something about how someone said the acceptance depth thing was supposed to work.

If indeed it is true that 1MB4EVA is part of Bitcoin's social contract, and indeed anything changed in the social contract will alienate the dominant plurality of the socioeconomic majority's critical mass, then you can go back to sleep, as BU presents no risk to you.

But your being here, expending effort in arguing against BU, is an indication that you are afraid that your assertions are incorrect.

If the economic majority does not agree to some new limit, then any fork based upon that limit will die. It requires an economic majority to sustain any fork.

I can only speak for myself, but I do agree with you that there are certain attributes that I feel are sacrosanct -- without which I would divest.

However, I do not agree that 1MB4EVA is even remotely part of these fundamental principles. Further, it seems you've lost that battle even amongst the majority of those that oppose a simple maxblocksize increase at this point in time.

Must suck. Sorry.

Yeah, software upgrade as far as I know. These are planned. Dev just started recently. Don't know how long it will take. Probably the supermajority requirements will be as in the original BIPs, with option for the user to customize them as well. Depends on what the devs do, or what people who fork BU do.*

*Note that, unlike Core or XT, it doesn't really matter (as far as consensus parameters) whether you run BU or a fork of it. This is an implication of the unbundling of consensus-parameter-setting from the rest of the code. So any questions you might be asking about the specific BU project with Andrew Stone as lead dev should probably be reconceived a bit:

Instead of asking BU what it will do, ask what anyone that does something similar could do. The genie is kind of out of the bottle. With the unbundling concept, anyone could offer blocksize-related BIP-mimicry of any kind in any configuration. It's just a matter of dev time and inclination. Dave Collins of the btcd implementation mentioned adding BU-style blocksize cap configurability, for example (on the other forum).

Of course, everything is configurable and to a developer their is little difference between recompiling from source a few changes in the code and making the changes with a GUI. To a non-technical person, this makes a world of difference and has a profound political impact however.


Interesting. Do you have a general sense of what block sizes are most BU supporters comfortable with? How about yourself?
Will BU be rolling in the long list of other scaling changes core is going to be rolling out, including SegWit/SepSig?  (Seems to be some confusion on the issue here-- https://bitco.in/forum/threads/what-is-bus-stance-on-segwit.665/) , perhaps this is all premature as you still need to vote in officers and finish updated your github as I see multiple issues there with a quick glance(many old notes and links from pre-fork).


1 MB couldn't possibly be a core principle in the inherent initial social contract as it was imposed at a later date and Satoshi. He later indicated how it could be raised as well. Its a good thing that almost no core devs want to keep it at 1MB...even Peter Todd has signed up to increase it recently by accepting SepSig.

 

Sorry but if you really think bitcoins success lies in the fact that a simple change can only be made by a developer then the system is completely doomed. Good thing emergent consensus does not work like this, anywhere in nature.

I think 60% is fine. Just kidding. Or am I? I say it doesn't matter what I think. The market will make the choice anyway. The only thing devs can do by locking the consensus parameters down in each implementation is force the market to make a less granular choice.

For example, if the market wants a 90% supermajority, and the options are Core at 98% and XT at 75%, maybe the market will be forced to go with 75%, which the market deems dangerously low but better than an impossible 98%, or it will be forced to go with 98%, causing a lot of unreasonable delay. 

Or maybe it's Core with 95% and a three-day grace period, and XT with 75% and a three-week grace period. Gotta choose the lesser of two evils, not a happy place to be.

When choices are not granular, consensus cannot find its optimum level. This is the kind of friction that can be removed by unbundling the consensus-parameter-setting service from the rest of the roles the devs play. The choices can even be among BIPs the devs offer, so it's not even anti-dev. If the market thinks devs know best, the market will go with a dev recommendation. If not, it will go with something else.


So do I. They all have great talents to contribute, and it pains me to see them have to be involved in a kind of power struggle because of the fact that they are being relied upon not just to recommend consensus parameters from among controversial choices, but to attempt to force them on users or at least spoonfeed them to users because they believe that they need to do so in order to generate consensus. I think some of them are unaware, or have not considered the fact that consensus can be emergent. I don't even think Gavin has fully internalized this, even though he did agree to the idea three years ago.

I'm not disagreeing with you necessarily about a users setting the parameters on their own nodes, but I don't see how this market mechanism works, nor do I see how you have "eliminated" a power struggle.

People will still struggle to influence the miners and users over what block size is being used. Developers will be under influence (internal and external) over what defaults to set (or are you going to remove defaults altogether and require end users to choose every possible parameter?).

Whatever the merits of the idea, I don't see how you have made these decisions into significantly more of a market process. As we have agreed, users could always modify the code or choose what code to use, so the market already existed. The politics will certainly still exist, and perhaps become even more intense (and potentially, expensive, which brings its own issues) with respect to trying to convince users and miners (and possibly developers, as to defaults).

Remove the hard code size limit? Okay, sure, maybe a good idea, maybe not. But beyond that you seem to be overselling the idea by a wide margin.

Everything controversial, yes, unless we want to vest inordinate power in whichever devs control the dominant implementation. That power concentration opens a major attack vector. I believe this hasn't been noticed before because there was never such a big controversy before. Who knows what the next big debate will be. Whatever it might be, realize that making the choices blockier (less granular) by trying to shoehorn people into one, two, or three possible implementations with bundled consensus parameters doesn't make the situation any better. The market will always choose the least bad option, but if there are only two options, say that offered by Core and that offered by XT, that's quite suboptimal and will lead to less satisfying results no matter what parameter we're talking about.

I agree that having too few options is bad, but at the same time too many options is not optimal either. BU gives too many options for this, and there currently aren't just two options for the block size limit. There are several other BIPs out there with many different alternatives to this.

Part of the problem I have with BU is that I see it as a not-production-ready software. It doesn't having the proper testing (I couldn't find any), and it doesn't consider the all of the consequences. I think it should have been released when deployment options were available and some more options were there instead of just block size limit. There is much more than just the block size limit when it comes to deploying such a fork and not completely screwing up the network.

This is indeed a fundamental difference in viewpoints. I normally like this principle - https://en.wikipedia.org/wiki/Wisdom_of_the_crowd
but when determining complex code improvements I believe the WOTC tends to breakdown as it tends to work best when there is a definitive correct answer to a particular question (not within scaling decisions as there are complex tradeoffs and no single correct option) and social influence can make the WOTC extremely inaccurate.

I do think there are valid concerns being raised about governance, but I would warn you that direct democracy and groupthink can be very dangerous. Emergent consensus can decide upon a larger block because enough users demand it , but that doesn't mean it technically can work or scale efficiently. O(n2) is a real problem that so far only lightning network with larger blocksizes or treechains seem to adequately address.

I can't wait to see BU (fail to) deal with 16/32MB blocks trollishly construed so as to take hours or days to verify.   ;)

BU doesn't need little old *me* to argue against it.  It's already been properly #R3KT by the socioeconomic majority, as expressed by the 99.9% of miners that support small blocks.

What you ridicule and denigrate as "1MB4EVA" is actually a beneficial outcome of Bitcoin's conservative/reactionary approach to preserving (at all costs) its fundamentally diffuse/diverse/defensible/resilient network.

1MB may change, should it prove to be an insurmountable impediment to growth or stubbornly problematic for maintaining status quo.

But "Z0MG I REALLY REALLY REALLY REALLY WANT TO!1!11!" isn't a good enough reason to pick some other magic number/algorithm, no matter how much you wish that constant to be changed Right Fucking Now.  Sorry, not tonight dear!

Must suck to be deep in the red on those BTC for which you paid $800.  :P

I used to be an unqualified big blocker until I realized that big blocksize caps aren't necessarily any more "free market" than small blocksize caps. I was caught up with the "cap" thing, thinking low caps are market interventions. Well they are, but so are high caps. So the free market position must be elsewhere. The free market position to let the market decide the cap. See the image (https://bitcointalk.org/index.php?topic=1312371.msg13431806#msg13431806) I posted above.

Now my position is that much bigger blocks are probably fine and the system will probably self-limit via mechanisms like orphaning, and that generally most of the small block arguments spring from a mistrust of markets... BUT that I shouldn't be the one to decide. I'd like to place my bet in a prediction market that, say, 50 MB would actually be fine right now, but if I were Core maintainer I definitely wouldn't want to put 50MB or even 10MB in the next release - for fear that I, a fallible human, could be wrong.

I wouldn't want anyone to have that power. I want the market to decide, and to do so unburdened by the interference of the hardcoded cap inserted by developers who - while absolutely excellent at what they do - have no track record as incentive designers, economic parameter setters, etc. And even if they did it wouldn't matter, the power would be too concentrated.

I'm for having Core be closer to a wallet, with any controversial consensus parameters left to the user. Users would not screw themselves over, just like a car driver doesn't turn on the emergency brake while cruising on the freeway. I know some people think they would, but as I keep saying, the inconvenience barrier isn't that high. It's plenty high enough to set a very strong Schelling point, though, which serves as a big market intervention. With multiple competing implementations to choose from, like XT, this intervention becomes weaker, but it is still highly suboptimal and in my opinion a security risk or at least a millstone slowing progress.


I think there is some interest in doing that. Generally I'm not that particular about what happens in any one implementation. If Core and XT would abdicate some power and give users leeway on consensus parameters that are controversial, that would be great. If BU is adopted, that would be fine, too. If someone forks BU and does something else with it, that would be cool as well. If btcd implements adjustable blocksize caps, I might use that.

From an adoption perspective, I think it likely that BU will try to incorporate whatever it can. I have even argued that opt-in RBF would be good to include, despite my disagreeing with it. My motto is,

"I find your settings despicable, sir, but I will defend to the death your right to set them."

Both of these statements cannot be simultaneously true. Which one do you consider dominant?

They do in fact have a track record. Various economic- and incentive-related decisions have been made in Bitcoin development over the past 6 years and it hasn't completely blown up yet. That includes both changes and decisions about what not to change.

I guess this conclusion depends in part on how big a failure you think the "blocksize debate" represents. From where I sit, the blockchain is still working, transactions are being processed, etc. I don't see a major failure even in that.

It is entirely obvious the MO of Unlimited.

1)  Create chaos.  By having all kinds of forks and "emergent" consensus, no one will know what to trust, and the network becomes useless and untrustworthy.

2)  Distract development on Bitcoin.  Any time spent having to refute this nonsense is time that could be spent on other tasks that are actually useful.

3)  Find new suckers.  The "Trump" effect.  Appeal to the lowest common denominator for those without critical thinking skills, develop a following, then use it as a fundraising attempt.  Just wait - they will be begging for money from their "government" as taxes and use it to fund themselves.

It's fairly obvious that this is an unworkable idea that will result in very bad things for anyone who uses it.  Give a warning for such users, and anyone stupid enough to follow these fools off a cliff without a parachute can suffer the consequences.

I think the blocksize is the biggest controversial economic aspect they have touched (kind of easy to change something when it's not controversial), but - see my edit - I don't think it would be good to vest power even in someone who did have a good track record on that.

I do think we will be fine whatever happens with blocksize, and are fine now, but that adoption could be set back quite a ways if too much friction is introduced and circuitous paths are taken, so I think it's worth pointing out some existing burdens on weighing on the market discovery process.

The statements are not equivalent; the former (obviously) does not consider the exigency analyzed in the latter.

Sorry to have confused you, I should have been more clear for the sake of easily disoriented Trump-voters.   ;)

Note to all since I've been answering a lot of questions: I'm not a spokesman for BU. I'm just someone with a keen interest in the project, and more than that, the overall concept and approach. My views are mine alone. For more details on what others involved in the project think, you'll probably have to go to other forums because many who are close to the project feel - with some justification but wrongly in this case I think - that they will be censored here.

I notice Adam posted on the other subreddit, so if you're not averse to asking questions there you may get some answers that I myself cannot provide. Really the developers should be answering a lot of the specific questions (on reddit: /u/thezerg1 /u/awemany and sickpig (not sure of sickpig's reddit name)). My responses here are mostly about the general idea of user-adjustable blocksize settings, which I see as the major idea of the project - note that many others probably do not agree.

Just wonder, if every week there are 100 new solutions, who has the time to review? Shouldn't the new solution based on current major user feedback instead of wishful thinking? Need a spam filter for new solutions  ;D

How Bitcoin Unlimited works

Please review these examples of emergence first:
http://www.pbs.org/wgbh/nova/sciencenow/3410/03-ever-nf.html

Assume a BU majority network.
Consensus occurs on the max block size over the whole Bitcoin network from low-level rules used by thousands of individual nodes. There is no voting.

With Core and XT everyone needs the same maximum for block size. BU is different in that only the whole network possesses the attribute of a dynamic block limit, while each individual node has an approximation, or even a limit which is a lot smaller or larger. It doesn't matter, except that nodes with a too-small limit will frequently have the latest blocks "on probation" waiting for them to reach an acceptance depth. A node which sees a block which is excessive (over its limit) will not relay or process it until it is buried under enough confirmations. BU nodes always track the chain tip with the most PoW.

A miner producing a block larger than emergent network consensus gets its block orphaned. As individual node owners update their settings after upgrading or getting new hardware, bandwidth etc, then the network consensus slowly changes, usually upwards although the exact value at any one time is an irrational number and unknowable.

Individual node settings:

• Excessive block limit (default 16MB)
• Acceptance depth, i.e. confirmations (default 4)

I mean... for how long are you going to dodge the very simple fact that BU is NOT a market driven solution but one that leaves EVERYTHING up to the miners?

It's painfully obvious to anyone paying attention yet you (and others to which I've raised the point) continue to swerve around the issue.

So it sounds like you are using non-relaying by end user nodes as a form of soft pressure to discourage miners from creating blocks larger than node limits.

How do you deal with the fact that miners will often want to have direct connections with other miners (due to the natural incentive to reduce "orphans"), making relay through end user nodes irrelevant?

Setting aside the previous, have you done simulations or mathematical models to characterize how relaying will behave in practice given some distribution of nodes putting a block "on probation" while other nodes process and relay it?

Can you characterize the cost of creating nodes that deliberately relay larger blocks than most of the end user nodes in an attempt to influence the orphan pressure on miners?

Without doing any simulations or models, it intuitively seems to me that even a small number of such permissive nodes (either malicious or otherwise) can quickly relay blocks to nearly the entire portion of the network willing to process them, though operators of such nodes will incur bandwidth costs.


Only if the block does not reach other miners.

As long as you can't understand a swarm and autopoiesis, you will never understand. You will always believe in authority.

Very nice to see what kind of 'Bitcoiners' with what kind of language on what kind of 'communication' channels are trying to back Mr. Back.
Very nice to see that such Monero-Trolls indeed believe they help to keep Bitcoin on core's track to cripple Bitcoin.

Here are two posts from the BU lead developer.

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-226#post-8419
https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-226#post-8444

Aquent has posted his reply to Adam's thread-opening post:

https://bitco.in/forum/threads/re-bitcoin-unlimited-seeks-review.718/

His closing statement is worth re-iterating in this forum:

I just wanted to come back on the superlinear problem that iCEBREAKER mentioned here, because it deserves response since it's just as much a problem for other BIPs and SW.

So this is not a new problem introduced by BU, and there have been some proposals made in the context of BU to mitigate this (by moving verification into separate threads etc.)

Most of the discussion around this in BU has happened in the thread below as far as I have seen:

https://bitco.in/forum/threads/i-really-want-to-like-bitcoin-unlimited.684/page-2#post-8087

BU does not always follow the longest chain.  In general BU operates in the same way as in Core,  BU nodes follow the longest valid chain.  There is a slight difference with respect to the blocksize issue.  It is possible BU nodes will follow the longest chain, where the blocksizes are arbitrarily large, but only under certain limited unusual conditions.  There is an “N depth” idea in BU, where nodes switch from regarding one chain as valid to another chain, if the chain with larger blocks has a lead of N blocks.  The default value of N is 4 and N could be manually set to any number, including infinity, when BU nodes will never switch to the longest chain.  Only if N is manually changed to 1, does BU follow the longest chain with respect to any blocksize.  Therefore the claim that BU always follows the longest chain is false.

There is no mechanism to reach consensus about the blocksize limit, with BU all nodes just set there own limits.  This does not reduce the potential for debate, arguments or central planning.  The community would still need to reach consensus about the blocksize limit in the same way it is trying to now.  The core development team could still try to keep the 1MB limit and miners would still need to make a decision to change to accept larger blocks, the only difference would be the debate may be about values to set in the client, rather than which client to use, which is effectively no significant change from the current status quo.  If we want nodes to dynamically set a blocksize limit, in a way determined by the market, we should use a proposal like BIP100.  BIP100 actually allows miners to dynamically set a blocksize limit and agree with each other on a new limit, BU has no system to enable nodes to agree on the limit.

This is an important point - and the one I've thought it safe to ignore here, but if you have people picking a larger sized block, without BU building in safeguards, it will be dangerous to the network if people are not aware of the consequences.  Even 2 MB blocks can have transactions that can take 5-10 minutes to verify.  

I just wanted to point out that the one comment I left in this thread has now been deleted. The idea that this place is "neutral" is silly.

All the good people are leaving.

The idea of enabling nodes & miners to set a market block-size is quite reasonable so there is no criticism of the idea.  Dont take review of the mechanism as a critique of the idea: for ideas to be deployed we need game-theory reviewed protocols and rigorously tested implementations.  Dynamic block-size is actually on the core roadmap and the best proposal I've seen for it is flexcap by GMaxwell & Maaku, with some ideas from Jeff.  You can watch a video about flexcap presented at scaling bitcoin HK.  Maaku has code for the core parts of it, I believe he was going to publish it, probably online by now.


The precursor idea was BIP "100" which Jeff retracted.  The BIP "100" proposal is similar but only miners vote.  In flexcap both users and miners vote.

I would suggest people interested in the idea of dynamic blocks, learn about BIP "100" and flex-cap and see if they can improve them.  There are design considerations that have been refined between 100 and the improvement on it flex-cap.

The bitcoin unlimited project has presented some ideas which do try to automate things.  Unfortunately all of the ones so far seem to be defective suffering sybil attack, constant centralisation pressure, dont take account of SPV mining, shared pools, relay network existing practice nor selfish-mining, attacks.

I have not really analysed the idea of validating two chains, but it seems likely to have problems based on intuition, particularly in the area of race-conditions, chain sharding and divergence risk, and in an adversarial environment.

Bear in mind that the consensus mechanism is extremely fragile, it only just works in that there are many design close things that completely fail.  Most variants I tried I self-broke fairly immediately.  But some of these things take a long time to realise, or require review from GMaxwell or others to disprove.  For example selfish mining was not noticed for years.  I did spend about 3 - 4 months cooking up analysing mining variants to improve bitcoin mining centralisation (eg I invented ghost, but rejected it as over complex for what it achieved, before the academic paper proposed it and a bunch of other variants), before getting into side-chains.

The idea for users to vote by delaying block relay wont work because most miners are already using the relay network or SPV mining.  Over 50% of the network was SPV mining during the 4th july fork.  A large portion of miners use the relay network.

Users voting by advertisement wont work because of sybil as others have explained.

You can read flex-cap to see how they combine miner and user voting in a secure, game-theory stable way that defends against all these attacks.

In summary:

1. The use case: dynamic market set block-sizes are interesting.

2. bitcoin unlimited proposals so far seems broken as discussed by multiple people for a whole range of reasons.  We didnt have a crisp definition and it seems that some things maybe undecided.  That's ok - just keep working on it and make a concrete proposal later and people can analyse it from that.

3. BIP "100" seemed plausible, but was only miner meta-incentive secure. Meaning we would be trusting miners to do the right thing, limited only by their commitment to not do anything too selfish for fear of hurting bitcoin's long term value.

4. flex-cap adds user voting (in transactions) and an economic quadratic feed-back mechanism to create an incentive to right-size blocks (to deter miner zero sum attacks against other miners and curtail the continuous centralisation pressure). Flex-cap also ensures miner fee profit in conditions where otherwise mining fees can be driven to zero by excess capacity in a non-dynamic block-size growth proposals like BIP-103.

[EDIT: I suppose the other thing is it might be better to run experiments on testnet rather than bitcoin or putting clear warnings for users if you have not.  People could lose bitcoin running partial implementations of incomplete ideas.  Encouraging users arent understanding it is a research project to run experimental code with real Bitcoin under it's control or even on the same machine, would be inadvisable.]

Adam

 if so, aren't fraud proofs for SW an illusion?

This ...1000x

Case in point - https://www.darkwallet.is/

Even with many warnings such as ---



People were still using real coins and losing them all the time on experimental software. Are any of the core devs open to us having a fundraiser to finish cleaning up the code and testing the dark wallet implementation or is this a matter of all the focus on bitcoin core at the moment?

A very simple attack can be done on the network.

There are really 3 parameters that can be set at each node:

1) Maximum generation size (only used by miners)

2) Maximum relay size (used to propagate to peers)

3) Maximum acceptance size and # of blocks ahead to force an automatic change of parameters (This mechanism is one I am less sure of how it works).


I'll ignore the first parameter since it's set by miners.  Suppose I want big blocks in my unlimited node.  I set a max relay size of 32MB and max acceptance size of 32MB (the maximum allowed?).  I will accept anything I see that is the longest chain and pass everything along.

Now suppose I connect to a bunch of nodes, and they have much lower limits - the max relay they have is 2MB, and max acceptance is 2MB.  I will never see any blocks bigger than 2MB!  Even if the majority of nodes were accepting large blocks, and I just got connected to a few small block nodes, I'm screwed.  I'm out of sync with everyone else, and there's nothing I can do to sync up.

The attack is simple - launch a bunch of nodes, try to connect to as many nodes as possible, and stop relaying anything big.

In a large enough network, this doesn't even need to be accidental.  Some poor sap gets unlucky and connects to all small block users, and can't ever get an update.  The end result is many chains and chaos.

Of course this is solved in an interesting mechanism - a bunch of people get together and talk and coordinate limits and upgrade together... hmmm.... sounds familiar.

Zero opposition from Adam against the deletions.

There seems to be multiple different explanations of BU which is leading to some confusion.



Is this a hypothetical "unanimous agreement for a 2mb limit" of the miners or just BU nodes? So BU takes queue from a miner "BIP100 like" vote and combines that with a supermajority BU node vote to determine a new maxBlockSize limit?

  
Thus a simple majority of miners is the "BIP-100" like vote that would permit an increase if the corresponding nodes agreed?

  
My thoughts are bitcoin simply made the game theory incentive to merely discourage dishonesty by incentivizing miners at a greater degree to secure the blockchain than attack it. Why are we assuming honesty? I hold the opinion we should prepare for dishonest and malicious miners as a possible attack vector. This is why we need to focus on decentralizing mining much more.


  
Is this true? As far as I know only Luke-jr wants to keep the blocklimit or lower it. Peter Todd signed up to make an effective increase and the rest of the scaling signers want to raise maxBlockSize after all the other improvements are completed to accommodate the LN. Is this simply a misunderstanding because I repeatedly see this being repeated on that forum and on r/btc or do you acknowledge cores statements and are assuming dishonest intent?

FYI... regarding post deletions, the only posts being deleted should be offtopic or non technical related ones, which we welcome because after all this is the " Development & Technical Discussion " section. Please take a screenshot of any "technical" post if you believe there is censorship here.

That seems a reasonable result. Just need to iron out the details....


I wouldn't say they are 'broken' - there is a lot of misunderstanding about it, and due to the level of censure taking place on bitcointalk its difficult to get a clear picture of what it is about on this forum.

So may I respectfully point interested parties to the BU 'white paper' ( without having this post moderated/deleted as a result) here (http://www.bitcoinunlimited.info/1txn) where you can digest the finer details. Additionally, the FAQ (http://www.bitcoinunlimited.info/faq.html) provides a higher level description of key topics. This should remove some of the guesswork which has characterised  this thread. Then present your thoughts or arguments on the unmoderated  /r/btc reddit or directly to bitco.in where they can be discussed.

It is not false with respect to any setting other than infinity (but your point is valid since infinity is a apparently a valid setting). There is never a guarantee that any Bitcoin node will converge to the longest chain in finite time, only eventually. The exact same guarantee applies to BU, though it may take longer to agree on a chain than other implementations.

We might need to think about moving forum because some of the people proposing the ideas apparently being "moderator incompatible". Technically I dont think it is accurate to say the clarity has been hurt by deletions directly, as far as I saw & remember contents of now deleted post no technical comments were deleted.  What has hurt clarity possibly is the refusal of people to participate because of the potential of moderation or clash of egos and moderators.

I do sympathize and dislike moderation myself, though there is a little irony in Peter R's deleted comment containing a proud link to his own heavy trolling of /r/bitcoin which is not exactly the way to encourage people to divert their time to review your proposal (moderator or not!)

I started a thread on /r/btc

https://www.reddit.com/r/btc/comments/3zc6qg/review_of_shelling_point_protocol_selection_ideas/

and typed up a summary of ideas explained so far (including the below one that I already read before starting this thread we're in).


I had read that one before starting the thread. It seems to be a different idea again not mentioned on this thread.  Maybe we should be analysing a set of features that BU proposes to combine.

Immediate observation with empty block ratios is that this appears not to work in the face of 4 existing network behaviours SPV mining, relay network, big pools and selfish-mining.


Dont recall if I read that one yet.


Ha after thought I figured /r/btc is the next best option given the egos and the moderators clashing, yes, see above.

Adam

I am very enthusiastic about Bitcoin Unlimited and think it is a great idea. (Disclaimer: I am a big blocker, and see BU as the mechanism that will end up bringing higher maximum block sizes that can let Bitcoin scale with on-chain transactions. Anyway, my stance on big blocks is, I think, independent of my argument below.)

As Zangelbert Bingledack has argued before, BU lets users do something that they can already do, albeit currently in a more complicated way. Let's suppose a group of miners decide that a blockchain with 2 MB blocks is acceptable to them, and want to gamble that other miners and economic actors (like exchanges) will think likewise and accept such big blocks too. They can already upgrade to a blockchain that supports larger blocks by recompiling their own custom version of Bitoin Core where they substitute a higher value for the integer constant MAX_BLOCK_SIZE. If these miners command a minority of the total hashing power, they will find that whenever they try to relay a 1.9-MB block, it gets stalled among nodes that refuse to relay it and the block gets orphaned and rejected by the longest chain. Now they could keep on trying to propagate their blocks and use human-communication channels like this forum to try to attract other miners and users to the 2-MB camp, but there is something that will probably put them off and that makes it hard for this approach to succeed: the moral aspect. Right now, the more common view is that a block that exceeds the 1-MB cap is an "invalid" block that violates the consensus rules, just as would be a block that contains, say, invalid transactions or incorrect hash values. This leads to a situation where the miners sending 1.9-MB blocks out to the open will get rejected as "malicious" or "attacking" nodes. Any reputable mining company won't want to be associated with such antics, and will understandably keep their blocks under the limit to be seen as well-behaved legit nodes.

Now the great idea behind BU is that it completely eliminates this moral aspect by taking the maximum block size out of the consensus rules. Under BU, the blockchain becomes a parameterised family of N-capped blockchains. If BU becomes the main Bitcoin implementation, miners may freely choose to decide that they can support a 2-MB-capped blockchain or a 32-MB-capped blockchain without anyone shouting at them "malicious!", "attacker!", "you filthy rascal, impostor of a node, boo, boo, boo!!!". The moral aspect vanishes as it is now just as legit to adhere to any cap. Those who only support the 1-MB-capped blockchain will reject any blocks bigger than 1 MB, while the 2-MB-capped blockchain nodes may keep on trying to build a longer chain. It's important to note that the blockchain only splits when a subset of the miners advocating for an N-capped blockchain command more hashing power than those miners that advocate for M-capped blockchains such that M < N. At that point, two things could happen: a node supporting the M-capped blockchains may accept that a longer chain now has larger blocks and raise their M parameter to match at least N, the new proof-of-work consensus, or insist that they won't support such large blocks and keep on mining a shorter chain of blocks that respect their M limit. This might lead to several alternative chains coexisting for some time, but the ensuing chaos should be very brief as the free market will rapidly settle for one of them. My feeling is that this would be the chain with the higher block sizes and the larger proof-of-work behind it.

How will the growth of the block size cap happen under this mechanism? I think the pressure on miners to increase the limit will grow as the cap starts to be hit. As more users try to send (on-chain) Bitcoin payments, the 1 MB limit will be hit more and more often and a backlog of transactions will start to grow. This will lead to users complaining about their transactions being stuck in limbo and some negative media reporting about it ("Bitcoin network collapsing" and the like). Under such strained conditions, which we may start to see pretty soon, the Bitcoin price will take a battering in the exchanges with miners starting to worry about their income and realising that they're jeopardising the Bitcoin network and their earnings by not raising the cap. I could be wrong about all this, of course, but then it would be the free market which would prove me wrong by settling on a tightly capped blockchain. In any case, thanks to the mechanism that BU provides, raising the block size limit can be a market-driven smooth transition rather than an incessant and unseemly fracas among the core developers in the mailing lists and IRC channels.

https://i.imgflip.com/wscjq.jpg (https://imgflip.com/i/wscjq)via Imgflip Meme Maker (https://imgflip.com/memegenerator)

Legitimate kudos to adam for moving the discussion here:

https://www.reddit.com/r/btc/comments/3zc6qg/review_of_shelling_point_protocol_selection_ideas/

Your arguments via oprah meme and appended "tard" might get downvoted, but they won't be deleted.

Hi PR.  I too had a mostly on-topic, albeit slightly aggro, post deleted by a mod apparently set on keeping the thread's decorum conducive to productive discourse.

So quit yer bitchin!   ;)


EDIT: How close is BU to JR's block-market proposal?

I've always thought https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-1-scarcity/ is full of great ideas....for altcoins to test.

It seems BU is just an abstraction onto which people like Frap.doc project their unrequited ideals, at evidence by the inability to get the story straight (https://bitcointalk.org/index.php?topic=1312371.msg13440089#msg13440089) w/r/t whether or not BU follows the longest ("valid") chain.

I countered the criticism of Taek and so did many other people on the bitco.in forum, here is a link to my response:

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-203#post-7395
https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-208#post-7550

Your responses to him addressed none of his arguments and mischaracterized the rest of them, as usual.

Nothing to see here.

brg - the English language was on and left you a message:

"Please stop torturing me!!"

Wrong. I read it some seconds ago. You can combat his responses, you can try to destroy them, but if you try to make people think they are no responses and don't adress the problem, you obviously aren't trying to communicate the issue well and objective but to spread things that are not true. Play fair.

Here are the quotes:

--> he says that there is nothing like mining centralization, but only pool centralization. Criticize this argument, but don't pretend it is none.  Bitcoins natural game theory is that there are more honest miners than dishonest miners.


--> he says that an increase in the blocksize doesn't centralize mining. I made a similar objection in this discussion on page 3, but you didn't respond it.

Other than you taek followed the discussion and took the response serious. He claimed that the pool owner can force the miners to accept things they don't like, since they are a centralized source of power.

The response was:


--> If there are 10-20 pools cumulating the hash power of hundreds, it is distributed. We experienced what happened to ghash when they nearly reached 51 percent for some time. If miners don' like what a pool does, they leave. In the case of ghash they even left when ghash just had the chance to do something evil but claimed they won't do.

The limit I see with BU's market driven block size is that it supposes that every market participant is so poor that they have to be a rational economist. In fact the richer you are, the less you care about efficiency and profit, and you start to care about those higher level concerns

For example, the BU suggests that miners are willing to take a larger block when the fee is enough high to compensate for the orphaning risk. As a result, we would have many orphaned large blocks chasing for 50+ btc fee in each block. And transactions will often take longer time to confirm even if you paid lots of fee. This is the result of trying to squeeze every juice from the blockspace resource, an environmental hazzard

In comparison, if we have super fast block propagation and extremely low orphan rate, the network is much more healthy, and the value for this can not be measured by market, it is an environmental bonus on every user of the entire ecosystem

I do think this is true, and if it was it would render rule by the economic majority non viable. The more invested a person is the more incentivized they will become in order to do what is best for the network and inform themselves, overall.

If there where fifty plus BTC of fees with high volume I would consider this a great success, large blocks are a consequence and a necessary condition for Bitcoins success, that is if we define success as greater mass adoption of the Bitcoin blockchain. It seems like you are more interested in running an extremely efficient network like a good engineer should, however there is more at stake then that.

The value of this can be measured by the market, and if you do not think so then you are disconnected with the reality. The market capitalization of Bitcoin directly influences the security of the protocol, when the price goes up the protocol pays the miners more for security, bringing more people in further distributing the hashpower.

I suppose according to your definition of a well running network there should not be many people using it and cloging up the blockspace. Since lots of people wanting to use the Bitcoin blockchain is an "enviromental hazzard"? This is why we need to limit blockspace and price most use cases and bussiness out of the ecostystem? I see it completly differently, when more people join Bitcoin it strenghtens the network, adds value, and brings about profound change in our civilization. I think we should allow that to continue to happen, keep the fees low and transactions reliable with an increased blocksize.

It seems to me like you are missing the point. The advantages that BU brings are primarily political, empowering the participants of the Bitcoin network. From a purely technical perspective BU is not that different from Core or from the protocol today as a whole. Considering that you are not interested in discussing the political implications only further proves to me that you are completely missing the point.

That you think that a flexcap is similar to BU in regards to the blocksize only further highlights this misunderstanding. Flexcap if introduced by Core is a form of centralized economic planning, which history has shown us is ill advised. Flexcap will be charging miners for creating bigger blocks, this can be seen as a type of "taxation" or "fine", which would then be payed out to the next miner if they create a smaller block, forever adding a new incentive structure to Bitcoin mining in order to keep the blocks small fundamentally changing the economic policy of Bitcoin.

Almost all of the blocksize proposals so far have been forms of centralized economic planning. Since we are free to choose alternative implementations, these alternative have their own proposals and policies. We are limited in our choice however by the options that are giving to us by developers. This is like a form a representative democracy, with some of the accompanying problems that this creates. Singular implementations must decide on the vision and path for Bitcoin into the future, this is where some implementations have now diverged. Bitcoin Unlimited in many ways is different since it has transcended this debate, both small blockists and big blockists can arguably use BU, instead of dividing up into political camps and fighting over what the vision of Bitcoin should be, which would most likely lead to a split. Many of us can choose instead to allow the free market to decide what the blocksize should be in a more distributed and emergent fashion. Bitcoin Unlimited helps to further remove any barriers to this free market. Bitcoin Unlimited is also about disempowering developers from having a disproportionate influence over the economic policy of Bitcoin.

I can see why you might think that developers having more control over the protocol is a good thing. I can bite the bullet and say that this would most likely also slow down development, as I did in my conversation with Greg Maxwell. This can be percieved as being a positive thing however, making development in Bitcoin more conservative. It can also be argued that many developers are not well equipped to decide on the future of Bitcoin, considering that many of them have engineering and computer science backgrounds, these questions have a very large scope where the humanities also become important. I would argue that it is better that the market decides, I think that the wisdom of the crowd will always be better compared to any other form of centralized authority deciding for us. We can only lose our freedom by allowing others to decide for us.

Even if miners got so rich that they started to revel in luxurious
irrationality, the "ordinary" users will have to count their pennies.
If the price discovery is allowed to happen unhindered, the fees will
not be exorbitant, but reflect the actual demand & supply.

Also there will be in all probability advanced tools to calculate the right fee,
similar to the current fee estimation functionality.
 

Advances in propagation will translate to increased supply of
block space, and that will be measured by the market.

This bitcoin-dev post from 2012 by Stefan Thomas explains the philosophy behind BU exceptionally well:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001551.html


It seems the idea was not really explored further until now.

The counter-argument given by GMaxwell in that thread? (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001550.html)


Funny that would be at the top of his mind.

Quite the foresight by good ol gmax.

The real question is where did Blockstream find a time machine to go back and bribe him then?

I tried really hard to have a healthy and technical discussion at the reddit forum that Adam directed us to continue the conversation but was met with a lot of groupthink , trolls , and some dishonesty. I suppose that exists a bit in the other reddits too so have given up wasting time in all those social platforms or that other forum as they are a bit toxic IMHO.

Bitcoin Unlimited seems somewhat interesting so I will still follow up looking into it some more independently .

Technically, the best things I like about Bitcoin Unlimited is the incentivization it places upon node operators. Recently BTCC decided to spin up 102 AWS nodes which they assumed would help the ecosystem but made the mistake of forgetting that you need an active human on the other side verifying txs and check for bugs... meaning you can't just spin up node instances and not use them as their action, albeit well intended, is slightly harmful to the ecosystem. BU incentivizes "economic full nodes" run by individuals on different /16 ranges which is exactly what we need . The incentive isn't enough to have much of an impact but it has got me thinking .... What other gamification techniques can be used to encourage economic node use?

Please be more specific about how it does that.

I am claiming that one should assume a slight psychological incentive to run a full node as the maxBlockSize GUI within the BU full node wallet empowers the end user and encourages them to use an economic full node. The consequence of this is that it very slightly dis-empowers any developers as the decision with maxBlockSize(and in the future some BU supporters claim other BIP's) now is made principally between the nodes and miners instead of the developers(which is a slight negative consequence IMHO). I don't know if the incentives are strong enough to have a profound impact but at least it has started me thinking of ways we can encourage more economic full nodes besides the normal methods-

More features, better privacy, better UI, more secure, more reliable, ect...

All these represent obvious things we can improve to encourage more economic full nodes which is a large cost which will continue to grow as blocks size increases.

Some other methods to incentivize full nodes would be to cut them in on some of the LN, fraud proof server,  or payment channel fees by acting as a hub for these.

Than there is the other more complex incentives like gamification techniques that psychologically rewards the user in multiple ways or makes running a full node fun that can be explored.

Good.  Let's hope Dr. Back has learned a valuable lesson about flittering between forums just because (heaven forfend) a mod does their job when Peturd Rizun insists on shitposting in a Serious Thread.

The idea that the grass is greener and free of Sensor Ships on /r/btc (of all places) is asinine.

For one (exorbitantly obvious) thing, posts here cannot be hidden by brigading Gavinistas or (charitably pretending there's a functional difference) Buttcoiners.

You'd think Dr. Back would know better after Bitcoin Judas's pet sub threw Drak under the bus.

Perhaps this is simply an extension of his admirably subtle strategy to counter-troll Unlimiturd's Redditard Army....   :P

Thank you. I understand your perspective now. It is interesting.

[ I really like the concept of BU - mainly because it is the most decentralised approach ]

I am curious as to what people think will happen, IF people started running BU, and the CORE said ' USE THESE SETTINGS ' , would the majority of people use them ?

I think they would.

In fact I think the CORE boys are doing themselves a disservice, by not realising that 'almost' everyone would still follow their lead. Easily the majority.

AND - importantly - even though we would still be using the settings CORE feels is right, because we were given a choice and not forced, there would be no animosity. win win.

People are funny like that.

And you would be surprised by how easy it would be to manipulate a small number of people to change a few settings to cause chaos for them, then have them have a really bad experience, then get press about how bad it is and how they lost their money.  This is a clear intent to break everything and make it too chaotic to be usable.

Actually because of the defaults set in BU it is more likely to follow the longest chain regardless of what the blocksize will be. Therefore it can be argued that BU is better for end users since if they where using Core instead they would be forked off the network when the blocksize is increased. BU allows for continued compatibility with the Bitcoin blockchain regardless of what blocksize proposal is adopted, unlike both XT and Core which will need to be upgraded and or patched in order to maintain consensus with the economic majority depending on the blocksize proposal that is chosen. Bitcoin Unlimited on the other hand maintains compatibility with other proposals out of the box from day one using the default settings.

Indeed.  For people who want to track consensus regardless of the who/what/where/when/why of the eventual block size limit increase, Bitcoin Unlimited is the best choice.  

https://i.imgur.com/KDPD7yu.png

Why are you posting that picture? Is the RED supposed to induce a negative emotion? Is RED supposed to be wrong?

BU is full of flaws and allows for Sybil attacks.

The crowd here are capable of thinking for themselves, this is not some political campaign where you just utter the same words over and over and show us 4 colored boxes. It means absolutely nothing that you draw those boxes. Its insulting how you present your option.

Could have fooled me with the flagrantly biased, misleading and just plain wrong quote in your signature.  You're hardly the posterboy for neutrality, are you.  Troll harder next time.

Nobody cares about XTurd or Unlimiturd.  They had their chance, but failed to get more than 0.001% of the network to support them.

Bitcoin Ultra is the new hawtness.   :D

And BTW, what happened to the "Watch out Core, XT is going to take over in January" threats?

Did you forget about that?  Too bad; I have not.

[a] Then what's the point of your post?

If you imagine that the block size issue would turn quickly towards something like bitpay nodes, wouldn't it be "safer" to run BU? I'm not saying that this is the saving grace of BU, just that this point might be more relevant now than it has been.



U R [expletive deleted]

Okay I give up. What the hell is Bitcoin Ultra?

It's a softfork of XT which makes it compatible with Bitcoin, and also removes all of its other ill-advised changes. ;)

I gotta admit XT failed miserably.

Hearn ran away...and support for XT is literally dead at this point.

PseudoNode (https://github.com/basil00/PseudoNode) is better because it also covers any future non-blocksize related hardfork:

https://i.imgur.com/uGvZtFG.png

The only rational thing to do is to replace the entire Bitcoin network with PseudoNodes :P

Green stands for yes and red stands for no, there is nothing manipulative about this, unless you think that traffic lights and price graphs for example are also propaganda. These associations with colors are well established, and it is a fact that Core does not support an increased blocksize whereas BU does regardless of the blocksize limit and which blocksize increase proposal is chosen by the economic majority, so the way that Peter R depicts potential support and compatibility for these different implementations under different network conditions is accurate.

BU does not allow for Sybil attacks like you claim, since proof of work can not be Sybil attack, and it is proof of work which under BU would allow for a change to the blocksize limit, this is actually not any different to how the network already functions today, BU just further empowers participants by reducing the barriers to entry to effect such change.

Bitcoin Unlimited will just follow the longest chain regardless of the blocksize limit under the default settings, and proof of work can not be Sybil attacked, which is the primary reason why POW is even used in Bitcoin in the first place. It is supposed to be a reliable way to measure consensus since miners would not act against their own self interests by turning against the economic majority.

This is a simple animation to visualize how the network's block size limit could be increased through a completely decentralized process (https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-233#post-8692).  

When enough "forking pressure" (https://i.imgur.com/IbrVfLq.gif) builds, individual nodes defect (http://xtnodes.com) from the historical 1 MB consensus, setting their personal block size limits higher.  A new consensus forms at a higher block size limit with the help of signalling (https://bitco.in/forum/threads/buip005-settings-information-via-coinbase-txn-user-agent.696/).  When miners are confident that the economic majority will accept larger blocks, they begin to relieve the pressure by increasing their generation limits and producing larger blocks.  


https://i.imgur.com/j5ux8Ah.gif

<sarcasm>Wow thank you for opening our eyes Peter R! This is amazing, how did we all miss this? The animated pressure valve you are showing us makes all the difference! </sarcasm>

How about you write some code for core instead of fixating on one single issue day in and out. Its boring to listen to same broken record player, over and over and over again. Core has rejected your idea, its time to move on, and leave the issue mate.

It is obvious you have failed at understanding the basic principles behind Bitcoin. A Sybil attack has NOTHING to do with Proof of Work.

The Sybill attack comes from nodes! Please do yourself a favor and read up on all the posts in this thread, where multiple examples are given for a Sybil attack against BU, without anyone explaining how to prevent it. No matter how many fancy animations Peter R creates, it still does not solve the technical challenges.

I don't github.  I prefer to gif. 

https://i.imgur.com/Mpd1dWq.gif

https://i.imgur.com/yq9f64Z.jpg

Thanks to The Mighty Banhammer, Reddit's signal-to-noise ratio just crept up ever so slightly.   :D

Ledger needs to follow suit.  Toxic assclowns like Peter R have no place in legitimate academic publications.

BRB, need to milk the lolcows over at /r/bitcoinXT, /r/btc, and bitco.in.   ;D ;D ;D

_{note to self: get a bigger bucket}

Exactly my point proof of work can not be Sybil attacked, and under Bitcoin Unlimited the blocksize limit is determined by the economic majority through proof of work. Not the nodes like you claim, therefore BU is not vulnerable to such an attack vector. Of course node count can be manipulated through Sybil type attacks. This is why it is not a reliable measure of consensus unlike proof of work. Bitcoin Unlimited does not change this, it is no different to how the network operates today.

I do not need to explain how to prevent such an attack since nobody has successfully explained how such an attack would even occur, once you have done that I can counter your critique, though I would presently consider this attack vector completely ineffectual under BU. Therefore the burden of proof is on your end. Since previous posts on this subject have already been discussed, to me it seems clear that BU can not effectively be Sybil attacked, not anymore so then Core can, presently at least.

Here's an interesting thought experiment to drive your point home, VeritasSapere:

How could we ever know for sure if the economic majority had upgraded to a client that would support larger blocks?

The answer is we can't.  Instead, we could talk to people, read comments on forums like this, attend conferences, listen to statements from influential people, and check sites like xtnodes.com to see how many nodes have upgraded.  

These could all be "spoofed": people could lie, forum comments could be from sock puppets, conferences could be frauds, influential people might be confused, and xtnodes might be Sybil attacked.  

In other words, there is no way to be 100% sure--instead we must make our best judgements.  Fortunately, this is fairly easy because most people don't lie, sock puppets are outnumbered, conferences are usually legitimate, influential people have accurate information, and Sybil attacks are often obvious.  

Who are you?

Now, that peter was banned from reddit, you feel strong enough to offend him?

And who are you, to speak for the crowd?

Like Peter or like him not, but listen to him, when he's right: As a result of unsuccesfull discussions, unlucky decision-finding and bad behavior we face a future, where hardforks without consensus become more likely to emerge. Like it or not. You can blame, whoever you need to blame, but it's better to be prepared.

Like Peter said: Bitcoin Unlimited could help you to manage forks.

If you had read anything in this thread, you should know.

Ah, btw


There is no sense in debatting, when you don't read. Scroll back to  page 2 (https://bitcointalk.org/index.php?topic=1312371.20) to see that this kind of attack we are talking about has ABSOLUTELY EVERYTHING to do with Proof of Work.


Small-Block stalward brg444 helped. Even he knows that this simple sybill doesn't work.


The attack is that a majority of MINERS that controll a mass of nodes pushes the network step by step into centralization by pruning the weaker parts of the network out. Several people did answer this attack in this discussion. Also it was answered in another forum, where you have been linked to. None of it was answered by you. Instead you are still insisting on the sybill-attack that was denies even by your own teammate.

You don't need to have to be willing to learn. But please, stop disrupting people, who want to learn and discuss, with your insults.

Says the Gavinista who just wrote an entire post insulting the mods (IE our gracious, tolerant, and generous hosts) and "small block militia."

Your already unseemly self-pity is becoming nauseating.  The sooner you Gavinistas are herded into /v/bitcoinxt to circlejerk yourselves the better.

BU nodes do not accept the longest chain if it disagrees with their idea of validity (e.g. block size), until that longest chain is a sufficient number of blocks ahead. This creates forks that will persist for up to an hour or even longer, and can be used for attacks. Many merchant systems currently use 1-3 confirms on Bitcoin and will either have to change that to a higher number or be easily attacked.

Yes, that's a good point

There are situations where you should wait longer with bu to be sure a tx is really confirmed. But this only happens when the First block your tx is in raises the size.

If You receive tx you should set your limit very conservativ to ne sure you are not on The wrong chain.

Every miner doing this risks to loose his block, so the theory is that this kind of active consens seeking will rarely emerge.

Sorry, typos, Smartphone ...

When the time comes that a block >1MB is mined, and built upon... it's a safe bet that you've had plenty of warning.

Last year, the XTurds said that was going to happen sometime this month (Jan 2016).

That didn't happen.  LOL.   ;D

Come at us bro.  But don't complain when you get rekt like Stannis on the Blackwater.

https://i.imgur.com/o0mty0J.jpg

Thanks Joffrey, but you may find that it's not only Stannis that challenges your rule.

FTFY  8)

This would be problematic if a merchant kept her excessive block size limit
constantly below the actual block size that is being accepted by the majority on
the network.

However in real life we can expect the consensual block size limit to update
itself infrequently, thus allowing ample time for the users to adjust.

I think many (well-intentioned) BU critics have hard time of letting go
from concentrating exclusively on how a particular implementation
works, to include the social-economical activity of the players involved:
users, merchants, full node operators, miners, devs.

That's exactly my point. You can't rely on the non-Sybil properties of a proof-of-work longest chain. You have to make other complex arguments about socio-econmical activity and once you do that it is easy for Sybil attacks and various other forms of social engineering attacks to sneak back in.

BU may be a perfectly good approach for cryptocurrency, taken broadly, but it doesn't work the same way as Bitcoin and can't legitimately claim to, nor rely on Bitcoin's established security model or properties.

I agree insofar that the original model attempts to
fix security and consensus issues entirely on code level.

But things have changed, and "one cpu, one vote" does
not apply anymore. Neither the Core approach or BU approach
to dealing with the blocksize issue can be said to exist
inherently as a property of Bitcoin. Although I personally
feel that the latter approach is more in line with the
"philosophy" or "vision".

But I'm all for bridging the gap between the technology
and socio-economics with programmatic solutions that
can assist users in deciding the block size settings and
distinguish between honest players and sybil attackers.
For instance, statistical analysis of advertised block settings
on the network, and an option of registering settings on the blockchain.

Bitcoin's longest chain rule is still Sybil-proof unconditionally and by fairly simple reasoning, regardless of the wider context of Core's approach to development. BU's is not.

That doesn't mean that Bitcoin is the best approach. It also doesn't mean that BU is unsound. It just means you can't correctly claim that BU obviously has the same longest chain proof-of-work security properties as Bitcoin. Because it does not.

You have to reason about its properties independently, and justify their soundness. And mostly not to me but to the rest of the world. I think you will fail, but my opinion means little.

* Le One Year Later *

Despite all the huffing and puffing, no block >1MB has been mined by Bitcoin_Unlimited.

And having been rekt like Stannis on the Blackwater exactly as predicted, Cconvert2G36 no longer posts here.

Poor thing.  I did warn him Maester Satoshi's wildfire burns something fierce.  But he was too fucking arrogant to listen to his superiors.

Frap.doc, by far the most prolific poster there, rage-quit BU's rump forum months ago and will never return.


LMAO

At this point, Bitcoin_Unlimited has more lapsed than active members.

:D :D :D