|
First it was Bitcoin XT by Mike Hearn that contained a hard fork, bigger blocks and blacklisting of ip's.
Then it was something short lived that was called Bitcoin unlimited which also failed.
And now Bitcoin Classic, also failed.
It should be clear that the attempts are political and not technical. They just use techno babble to make it sound like there is a problem. Those of us that actually spend Bitcoin and transact it, know very well it has all worked perfect for the past 7 years.
This is obviously not in line with how bankers want the world to perceive Bitcoin, so they start campaigns like this to make it sound like there is a problem. Reality is, Bitcoin has worked perfectly and still keeps working perfectly.
I would suggest people stop listening to all the FUD out there and keep in mind that all these attacks are in place to remove Bitcoin once and for all via a hard fork. People that want Bitcoin to go away will say anything, show any type of graph and go on a constant barrage of misinformation to try to make it happen.
Keep calm and carry on, and do not fall into the FUD of Hard Forks!
|
|
|
|
Since you don't oppose lifting 1mb (I made wrong assumption - my bad) then what's the problem with 'bitcoin classic'? Is it all about timing? You strongly oppose lifting it now, creating a topic about 'hostile attack' etc, but, if in couple of months blocks happen to be full - you will be all in favour of it? Am I getting this right?
I am not opposed to raising the block limit per se but what I am opposed to is the dumping of the Bitcoin Core development team in favour of another team when I don't see that the Bitcoin Core team deserve to be dumped (they have only done good things so far IMO). The agenda of both XT and now Classic is to take control away from the current Bitcoin Core developers (I don't there is any doubt about that) and that is what I have a problem with. If someone can convince me (without resorting to silly conspiracy theories or ridiculous needs for everyone to buy coffees with BTC) that the Bitcoin Core team is inferior to some new team then I would happily change my opinion (but so far I've seen nothing to persuade me that we are seeing anything more than politics hence why I created this topic). This is really the crux of the matter. "Core supporters" want development to be centralized in the hands of a few guys. Everyone else wants decentralized development and multiple implementations. You actaully dont get it, you really dont. The so-called few guys represent 99% of the developers that have EVER build code for Bitcoin. Gavin is the ONLY one that wants a fork and can call himself a developer of the code that Satoshi started. Not even Mike has ever build code for Bitcoin directly, but only for projects like bitcoinj. A fork is a very bad idea, and it is clearly an attempt by someone, to make stupid people (yes, stupidity is rampant in here as well) to make easy choices seem as the most obvious choices. You are clearly one of those "everyone else" that believe that increasing the blocksize does absolutely nothing bad (hard forks are VERY BAD). It is truly a shame that a wide range of developers, coders and crypto contributors have to waste so much time with people like you. By people like you I mean, not developers, not coders and not crypto contributors. |
|
|
|
...
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.  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. 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. 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. |
|
|
|
This is a simple animation to visualize how the network's block size limit could be increased through a completely decentralized process. When enough "forking pressure" builds, individual nodes defect 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. 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.  <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. |
|
|
|
...
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. 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. |
|
|
|
Is anyone playing around with the Thunder Network client/server? I would like to invite some people to do some testing together with me, on the Thunder Network. Find it all here https://matsjj.github.io/If anyone wants to actively work on this and help out with expanding and making the payment channel more simplified, let me know, and we can coordinate a roadmap and how we can also do some internal testing. |
|
|
|
Your limit is a function of the resources you want your node to consume. Above that limit, your node either rejects large blocks that are spam (not accepted by the longest chain), or drops off the network because it can't keep up.
So does BU follow the longest chain or not? If not, than it obviously can't work, as it was pointed out a million times already - everybody will fork off randomly according to their limit. If it follows the longest chain, then your limit doesn't matter, as eventually you will have to switch (otherwise, again, you will be forked off). Since BU can only work if it follows miners, your personal limit becomes irrelevant: if you insist on setting it, you will just hurt yourself and will still have to eventually switch if you plan to continue using Bitcoin. This limit cannot be used as a signal to miners because of Sybil attacks, so it's pointless. Yet BU proponents push it as the main feature of BU  It follows the longest chain as long as it can (based on your resources), and if it can no longer follow, it drops out. The personal limit can be of value as a signal, since there is no automatism between your "vote" and increased block size. There is little basis for the assumption that miners will be foolish enough to fall for a simple Sybil attack through this channel. And BU proponents do not think this signal information is the main feature, that's a silly assumption to make. 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. |
|
|
|
Actually, my Sybil attack can go something like this:
1) Vote for 1.5 MB blocks
2) Check how many nodes I have killed with the increase
3) Vote for 2MB blocks
4) Check how many nodes I have killed with the increase
X) Keep doing until I am the network of nodes. Fill up the blocks and start pushing out the Chinese miners as well.
Incremental Sybil attack, cheap and easy to pull off.
You can do the same with Core by modding it. Unless you're making assumptions about how people would configure their settings. Sure, if you think people will do unprofitable things without Core supervision, then yeah that could happen. I tend to think people with skin in the game will not do anything silly. A few may try, lose money, end of story - in fact this happened at the halving in November 2012 when a few miners modded their Core clients to keep getting 50 BTC per block. They lost $500 per pop, then "we never did that again." If I modify core it is no longer core consensus rules. No I cannot do the SAME sybil attack on core. |
|
|
|
|
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.
|
|
|
|
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#msg13430261Yup, I noticed that one. The attack is a lot more complex than that. I think you're on the BU forum? Taek had a nice explanation of the centralization pressure enabled by BU. Someone could leverage a sybil attack to effectively do just what he proposed: slowly but surely prune nodes out of the network until it gets consolidated into a few more controllable hands.
Exactly! Too easy to pull off. So we are back to square one. Why choose BU when it cannot resist a simple Sybil attack. |
|
|
|
Current situation: blocksize cap for the network is set by miners/nodes converging on either Core, XT or something else by downloading and running Core, XT, etc. ... and making the decision not to modify this code. Yeah, and it's worth noting the reasons people don't usually mod the blocksize in Core: because there are overwhelming economic incentives for a miner not to mine or build on a block that will likely be orphaned, and overwhelming economic incentives for node operators doing business not to accept such blocks. The same incentives apply to BU. There are [repeating the above verbatim] "overwhelming economic incentives for a miner not to mine or build on a block that will likely be orphaned, and overwhelming economic incentives for node operators doing business not to accept such blocks." As far as I understand it, BU merely removes the artificial authoritative "oomph" of the blocksize cap setting being hardwired in Core (and XT). It can be made to default to Core's blocksize cap settings (it doesn't now, but it would be trivial to make a fork that does), and there can be scary warnings about changing it away from Core's settings. It just takes away the inconvenience barrier, with the hope that people would follow a different Schelling point than the one set by Core. Failure of BU probably means just "everyone sets their settings to mimic Core." That's about the worst it could go, provided there are no coding errors (community definitely should vet it carefully; better yet, Core could just make the blocksize cap user-selectable). User selectable cap means sybil attack. Again, nobody is answering my questions here. What will BU do to stop my 2000 nodes acting to create the illusion of that the network wishes for very large blocks. Actually, my Sybil attack can go something like this: 1) Vote for 1.5 MB blocks 2) Check how many nodes I have killed with the increase 3) Vote for 2MB blocks 4) Check how many nodes I have killed with the increase X) Keep doing until I am the network of nodes. Fill up the blocks and start pushing out the Chinese miners as well. Incremental Sybil attack, cheap and easy to pull off. |
|
|
|
1) So I fire up 2000 nodes, all selecting 200MB as cap.
2) I make the miners belive this is the prefered block size.
Why do you believe that miners are really that stupid? My point is that it opens up to sybil attack. My suggestion is obviously a quick and dirty model. Okay, I agree with that. EDIT: How would miners actually know what the "real" consensus is? Ask around on the forum? What if I set the blocksize to 14MB. That would still knock off plenty of nodes.
See my post above. I think I read somewhere a Peter R post where he suggested the case of miners with BU sticking with 1 MB for a while. Then (especially when there is fee pressure) one brave miner might deem it worth the risk and try 1.1 MB to see what happens. If "nothing bad" happens, other miners would likely follow. Extrapolate from there. Yuck, this is really not a good model. If "nothing happens", and "what if this works" or "maybe we should try to" are really not solid models for something that relies on thousands of unknown factors. The moment there is the slightest room for attack you be sure alot of people will exploit it. They will because cashing out on Bitcoin's security gaps is the biggest prize on the internet right now. There are NO good actors. |
|
|
|
1) So I fire up 2000 nodes, all selecting 200MB as cap.
2) I make the miners belive this is the prefered block size.
Why do you believe that miners are really that stupid? My point is that it opens up to sybil attack. My suggestion is obviously a quick and dirty model. EDIT: How would miners actually know what the "real" consensus is? Ask around on the forum? What if I set the blocksize to 14MB. That would still knock off plenty of nodes. |
|
|
|
I still am curious as to what the difference is besides the nodes being able to signal to the ecosystem in a slightly easier way through a GUI that they wish larger blocks. Is this it?
I think there are a lot of misunderstandings about BU. The main idea is dirt simple: - Current situation: blocksize cap for the network is set by miners/nodes converging on either Core, XT or something else by downloading and running Core, XT, etc.
- With user-selectable blocksize cap: blocksize cap for the network is set by miners/nodes converging on either Core settings, XT settings (BIP101), or some other Schelling point by adjusting their settings to do so (BU can be made to default to Core settings, if you want)
There's another "oversized block acceptance depth" feature LovelyDay mentioned that is envisioned may come in handy, but it can be turned off anyway so I'll focus on just the "user-selectable blocksize cap" aspect. This is all it is. "user-selectable blocksize cap" aspect - 1) So I fire up 2000 nodes, all selecting 200MB as cap. 2) I make the miners belive this is the prefered block size. 3) They all start producing 200MB block. 4) I fill up the blocks for the next 10 days 5) Bye bye 75% of all network nodes 6) I pretty much run the network |
|
|
|
Nodes will then have to follow the rules ascribed by miners, and their vote is pointless as consensus is formed by those who mine. Which means, Adam will still get kicked off the network, when the winning miners decide on 2MB blocks, and Adam only accepts 1.1MB.
You go wrong in thinking that miners are all-important. I clearly stated "the majority of nodes decide the consensus", not only miners. As other have stated multiple times in this thread, miners have to be sensitive to where the real money comes from, ultimately. As such, the "vote" expressed by BU nodes through the settings they choose to run, is an important piece of information to miners. It is certainly not pointless. It would be pointless to ignore it, as a miner. If the miners set the limits then nodes will be kicked off, and we end up with more and more centralization, as everything moves to bigger data centers. If nodes set the limits, it opens up for sybil attacks as I described in an above post of mine. You dont answer my questions. Either the mayority of nodes set the consensus rules or the miners do, which one is it? |
|
|
|
And longest chain is a rule set by nodes, correct? Meaning, that consensus is formed by the highest voting number of nodes, in this scenario, my 2000 nodes.
If we go by the standard 6 confirmations, 6 depths, then we can safely assume it will be the longest chain. So after my 2000 nodes vote for a 200MB block, I wait 1h for the longest chain to become 200MB. Or for the real paranoid, we wait 2 hours, and I am certain that the 200MB rule is enforced and that there is probably not another chain.
I then spam it with 200MB data, and thus we get 200MB blocks until someone can form a better consensus (launch more nodes with a different blocksize consensus).
All this, I can do in less than one day, and cripple the network for less than $5000.
The majority of nodes decide the consensus, and the miners produce the actual blocks. If the mining majority does not produce 200MB blocks, then eventually they will outproduce your chain, even if your 2000 nodes (not the majority of nodes currently, btw.) accepted it. The only situation in which your scenario holds is if you control the mining majority and the majority of nodes. Then you can maintain a longest chain with 200MB blocks (provided you generate the transactions to fill it). If you can do that for $5000 then you can do it today already, nothing would be stopping you. I don't consider it fruitful to continue this line of thought since it does not add any new attack that could not have been done in the past. Ok so consensus is formed by miners and not the nodes. The miners set the absolute parameter for the size of the block, as they are the ones creating the block. This leads us back to what Adam said then. Nodes will then have to follow the rules ascribed by miners, and their vote is pointless as consensus is formed by those who mine. Which means, Adam will still get kicked off the network, when the winning miners decide on 2MB blocks, and Adam only accepts 1.1MB. |
|
|
|
Longest chain is mine, as I run the most nodes.
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? 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. |
|
|
|
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.htmlFurther 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. 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. |
|
|
|
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?
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. |
|
|
|
|
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?
|
|
|
|
|
Show Posts
