Topic: I just switched to running a Bitcoin Unlimited node - page 3. (Read 4213 times)

Were you able to identify the Remote DoS bug there?

The point is that even with changes that aren't "earth-shattering" they lack any code review whatsoever. The BU devs also have demonstrated that they don't understand the code that they are modifying. In the post where they went over supposed issues in Core, they made several claims which were later debunked by Greg He also said that "AFAICT many of issues were actually caused by changes they made to code they didn't understand."

You're missing something.

Danny Hamilton stated



Danny Hamilton is a highly intelligent individual. This is obvious from his extensive technical explanations concerning Bitcoin, cryptography, game theory and the mathematics concerning all three. I read his posts regarding those with interest, he writes and explain those topics very well.


Square this circle. How can someone, otherwise demonstrably so intellectually adept, state and believe such basic and blatant falsehoods?

It's very simple. Danny Hamilton has spent several years on this forum building up social capital, and he's cashing in that social capital on support for the Bitcoin Unlimited campaign.



Or do you think that Danny Hamilton actually believes that Bitcoin Core started and perpetuated the blocksize debate? That's so entirely absurd, that I would question the judgement and/or motivation of anyone who knows Danny Hamilton and believed it.

I read through the PRs and none of it is really earth-shattering. PR36 is hardly a huge or even big code change and its common for bugs to make it though even with thorough code review. I worked for a Fortune 300 where all code had to get 3 approvals and there were still bugs - its just part of software development and not a reason to say the programmers aren't competent.

A good example of what you're saying would be the various hardware wallets (e.g.Satoshi Labs' Trezor). Without BIP32 and BIP44, implementing multiple cryptocoins for use with hardware wallets would be a far more laborious task than it is now. Key differences in coin features (such as the PoW algorithm used) can still add to the workload, but BIP32 and BIP 44 still remove huge obstacles to both development and user experience (e.g. 1 wallet seed can be used for many different cryptocoins)

Though I do not agree with Danny's overall argument that Consensus is failing now
because the Core team is not attempting to reconcile the two sides, (since I consider
a stalemate between two separate ideologies as being a part of the Consensus
mechanism) I just want to say I do not agree with the way you are talking to Danny here.

It is alright if we disagree with each other and at times it becomes heated, but I do not
agree with the way in which you talked down to him. IMO Danny is not a common troll/
shill and if he believes what he believes, it is important to listen and try to understand his
viewpoint, whether we agree or not.

If you said this to Jonald_Fyookball, I wouldn't care since that user has really become a
hardcore BU pumper lately and that account is shilling conspiracy, misrepresentations,
and accusing Core of "fill in the blank", but Danny is not Jonald, and does not conduct
himself in such a way, and rarely provides his opinion in this whole debate. So I believe
Danny is venting about some frustration because this issue has gone on longer than some
would have assumed.

Whatever the end result of this whole "blocksize debate", we should not lower ourselves
to attacks of people's character unless it is warranted and IMO, Danny's statements in this
thread do not warrant them. There are some people we should attack and shun and then
there are others we should listen to, but disagree with respectfully. We can distinguish those
two groups by their overall deeds. Jonald has become a shill, Danny is voicing a personal
concern whether we agree or not. There is a difference.

BU has recently had 3 publicized and exploited remote crashing bugs. Here's a thread on reddit discussing the first two. These bugs allowed people to send specially crafted messages over the P2P network to a BU node and cause it to crash thus taking it offline. These bugs are a result of large changes with little or poor code review. Two of the 3 bugs was first introduced in PR 36. As you can see from looking at the PR, there was very little commentary prior to it being merged, no one ACK'ed it, there is no indication that anyone had even reviewed the code. The third bug was added in PR 43, which, much like the previous PR, is a very large change which does not have a lot of review and very few comments about the changes even though the changeset is quite large. There is only one person who reviewed the code, and even in the end, he doesn't give an indication of approving the code before it is merged in. This lack of review makes BU more prone to severe bugs like the aforementioned Remote DoS bugs and potentially even changes to wallet code that can risk your Bitcoin.

There is more to the BIP system than just block size increases and scaling solutions. Proposed block size increases make up a very small fraction of BIPs. Furthermore, BIPs are not used only by Core, but rather nearly every other popular wallet software or service uses the BIPs in order to implement things in a standardized way to make all software compatible with each other. One such example of commonly used BIPs are BIP 32 and BIP 44 which specify the derivation process for Hierarchical Deterministic wallets and that standard is what allows people to import the BIP32 master private and public keys into multiple wallets.

Please provide evidence of these statements.

What bugs? All software has bugs. Core has many. A lot of commits are even labeled "bug fixes". I'm running an unlimited node and haven't had any problems. I currently will accept up to 4MB blocks.

The BIP system seems useless. Most(all?) of them have included block size increases and Core just refuses to do it.

On a side note, one thing that really irks me is when people speak on behalf of "the community". I know right away who I'm really hearing - a tool for the establishment. The kind of smart, independent, free-thinking minds that started Bitcoin are wise enough to speak for only themselves.

I agree with you that Core has better documentation for SegWit than BU has. Both are bloated clients, imho, but right now I'm choosing the lesser evil.

It's also a practical matter. Right now, either Bitcoin is going to fork, or the other miners are going to adopt BU, but BU isn't going to back down from an almost 40% hash rate. If the fork happens, Segwit miners are going to have a hell of a time mining blocks AND they'll be limited to 1MB. Fees will go through the roof and the chain will essentially quit working making BTC worthless.

There is nothing misleading about saying he is running a bitcoin unlimited node, if he is actually running a bitcoin unlimited node. He doesn't say anything about a fork at all in his subject.

Please change the subject of the topic. I thought the fork had already happened when in fact it didn't yet and I was worried. Until the fork is officially done please change the subject of the thread to something else as is misleading.

The bitcoin blockchain is actually a software update for unlimited. A few years ago, when I started to make a name for bitcoin bitcoin developers Put a restriction on the total data that can be processed in the ecosystem. This restriction, which makes the system very slow when the number of transactions increases, but at the same time security that stop potential attacks that can be loaded from system memory.

Han Wu ji " bitcoin is a major investor, and the system is regarded as the Creator, Roger Ver bitcoin is moving to important names such as unlimited insists that, although prominent in Peter Todd bitcoin encoding, data limit, combined with the removal of both the security problems that both governments and big banks will emerge that expresses sovereignty over blockchain.

i think; they trust the men themselves, both sides may be right. but they have to give a joint decision to continue this system. this system definitely will unite for the maintenance of a softer idea.

You don't understand what "evidence" means, Danny Hamilton


All that BU's existence proves is that some programmers out there have the time on their hands to produce it. That's it. What their genuine intentions are is unknowable, but friends of yours (like Peter Rizun and Gavin Andresen) have unequivocally stated that their intention is to prevent a Bitcoin Core blockchain from being able to operate, using more friends at Bitmain to perform the required hashrate attack.

All this seems a little coordinated, and the design of BU is perfect to perform a whole variety of attacks against any blockchain. But, "Free the Market" right?

BU cannot compete, painting yourself as a "concerned regular user" doesn't wash when you're clearly intelligent enough to understand that the BU software and it's cheerleading campaign (of which you are the most subtle part) are designed as a weapon, not as a network. That's aggression, brute force and fraud, all rolled into one. Not free market competition.



And from whence did this wedge originate? You're saying that Core devs started and perpetuated the argument, and it's a cheap and ignoble trick.

The party that both began this war, and will not let it go, is yours, and yours alone. You are a disgraceful liar, and a disgrace in general to try to state the opposite as the truth.

You are in essence committing a violent and provocative act, then claiming the other party is the instigator. You have no shame, not worthy of being called human. Only cowards and thieves lie to obtain their worldly goods, and you have proven that about yourself in spades. But by all means, keep digging. You are a real person, and one day you will be sold out, one cannot exist uncovered for long as a liar in the information age.


If you really believed your own words, shut your lying mouth and stop telling lies to try to commandeer this project away.


Why can BU not compete against Bitcoin freely? Why can BU not launch itself as a separate cryptocurrency? What is this pathological obsession with using a cacophony of falsehoods to wrest Bitcoin away from the Core team?

If your idea is so good, why must you use fraud and force to make it so? You are a liar and a bully, Danny Hamilton

Except no one from Core was refusing to work with them nor have they shut them out.  Many now are refusing to work with BU due to BU's active hostility and toxicity towards them. Would you want to work with someone who shit on you, talked trash about you, and insulted you all day? Because that is what the BU devs are doing to the Core devs yet they (and their supporters) somehow expect the Core devs to voluntarily contribute to their project should they become the reference implementation.

Regarding the BIP process, the BU devs most certainly were not shut out at all. In fact, they were explicitly invited by Luke-Jr (current BIP editor) to submit their BUIPs as BIPs as well who even offered to go and assign a BIP number to every single BUIP (even though I don't think those BUIPs meet the standard for BIPs, i.e. not enough specifics for implementation in the document) but they explicitly rejected the offer and refused to work with the process that every single other developer in the Bitcoin ecosystem has been using to standardize every protocol change.

Furthermore, the BU developers are explicitly alienating the Core developers with their childish and rather unprofessional behavior of posting about suspected bugs in Core in blog posts rather than responsibly reporting them to Core through the issue tracker. Instead of reporting bugs responsibly when they find them, they wait days, weeks, to report them, and do so using outside channels instead of the bug reporting channel. Conversely, people on Core have pointed out bugs in BU to them through their official bug reporting channel (github issue page) and when proposals with implementations have been posted to the mailing list (Matt Corallo reviewed Tom Zander's reference implementation for FlexTrans). Greg Maxwell has said that he found several sever vulnerabilities in BU which he reported to them but they never responded nor did they patch the bugs.

In what way is the BIP system broken? So far, what BU has come up with seems to be even worse than the BIP system. At the very least the BIP system has defined what it is supposed to do, what can be considered a BIP, and what needs to be included in a BIP before it will be accepted, given a number, and added to the repo. AFAICT, no such document exists in the BUIP repo.

BIPs are not affiliated with Core. Core is not involved in what is accepted as a BIP (they don't have to like it or agree with it for the BIP to be given a number and added to the repo, e.g. FlexTrans, BIP 134).

With every single change, there will always be people who do not agree with it. BU happens to be that group of people right now. Yet Core and segwit has been able to gain the support of the a significant number of wallet developers, exchanges, and services while BU has not.

Furthermore several hundred individuals, organizations, and companies have indicated that they support Core.

Documentation for Core has been around for a very long time already. The doxygen docs were added in 2011, for version 0.5.1. For BIPs to be considered for final status and deployment, they must be well documented. They have to have enough specifics about the change so that anyone can independently implement the BIP just by reading the BIP. Hell, the code is, IMO, very well commented and has comments that explain what everything does.

Now, I understand that it wasn't always like this (and granted, there are still some undocumented parts that are basically holdovers from the very early days, and those are not consensus critical), but with so much documentation already, if BU wants to become the reference implementation, they need to be able to match the same code quality and documentation quality of Core. They keep advocating for multiple implementations, but the only way to allow multiple implementations is to provide enough documentation that people can independently implement everything, which, as of now, is not the case with the BUIPs.

As are comments like the one you just made.


Only the ones that refuse to work with them.


If a system is broken and/or shuts you out, then using it doesn't make any sense.


The "Core" community took a while to work out a broken system.  Perhaps, give Unlimited a bit of time to work out one that isn't broken?


And the very existence of Unlimited is evidence that Core and their BIPs are failing to form consensus and bring a community together.

Remember, there is nothing "official" about Core.  The ONLY thing that makes their software the "reference client" is the fact that a significant majority run it.  If a significant majority run something else, then Core is an alt-client and any fork they trigger is an alt-coin.  That is how Bitcoin is designed to work, and that is the only way that Bitcoin CAN work.  Maintain consensus, or fall apart.  You can't maintain consensus by alienating half the miners and a huge population of users. Forcing a wedge between people with "us vs. them" mentality, accusations, insults, fear, uncertainty, doubt, and belittling is cutting off your nose to spite your face.  In a consensus system it is pretty much the best way to destroy the entire system.

If you actually want Bitcoin to be a success, you'll need to stop trying to rip it apart at the seams.

Governments and central banks don't need to destroy bitcoin.  They can just sit back and watch a bunch of children do it to themselves.


I listened for years while people complained about how little documentation there was for Core.  Know what EVERYONE got told?  "It's open source. If you want documentation, write it."

IMO:

Under the current development team, ideas are proposed and the community either accepts them or not.
This type of system ensures that the network is voluntarily and relieves potential liabilities, and only "upgrades" within
Community supported Consensus. Monopolies, centralization, and governmental regulations can not ever enter the
network or the protocol with this type of system. The current layout prevents such intrusion.

As a so called "crypto-anarchist" the Core implementation and it's Censuses standard is somewhat
consistent with such ideals.


Under the BU development team, ideas are forced on the users with hardforks and those who disagree are left behind.
This type of system ensures that the network becomes exclusive with each "upgrade" based on the sole direction of
the leader/decider. This creates responsible parties which opens themselves to personal liabilities (that do not exist now).  
Monopolies, centralization, and governmental regulations will need to be allowed into the protocol to protect this type of
centralized payment system. It will need to conform to AML and KYC on-chain eventually. A centralized payment system
can not survive without governmental assistance.

As a so called "crypto-anarchist" the BU implementation and it's new Censuses standard is contradictory to such ideals.

Bitcoin Unlimited has demonstrated a lack of understanding of the code that they are working on and have introduced multiple critical bugs. Their code review process is non-existent.

The BU developers are also extremely toxic. They refuse to work with every other developer in the Bitcoin community. They have refused to use the BIP system which is used by everyone else in the Bitcoin community (not just Core) in order to standardize proposals and make sure that different implementations of the consensus rules still follow the consensus rules. Furthermore, BU's BUIP system is extremely lacking in technical documentation that allows other developers to work on separate implementations of a BUIP.

The very nature of how BU is conducting themselves is that they are making it extremely difficult for multiple implementations of Bitcoin to exist; their documentation for stuff like Emergent Consensus, the specific system that they are using, XThin, etc. is so bad that no pretty much no other developer can actually independently implement any of them. Thus you will be stuck with just whatever the BU developers put out, and they have shown that what they do produce has many issues.

I personally don't like the people working on Core, and I don't trust them. I'm not sure I trust Roger Ver, but I KNOW I don't trust Core.

Can someone here explain in an honest, intelligent way why I'm making a bad decision?