|
This is a Q&A record about Bitcoin Unlimited in a WeChat group. Participants: -Andrew Stone (thezerg), BU Development Team Leader -Andrea Suzanne (sickpig) -Peter.Tschipper (ptschip)
Andrea Suisani : Hi, I'm Andrea (sickpig), BU dev. My main focus is testing, CI and doc.
Peter Tschipper : Hello, I am Peter Tschipper (ptschip) and a member of the BU development team. Q: Can you tell us how BU solves the block size problem?
A: Basically, BU solves the block size problem by using Emergent Consensus. In a voting-based way among miners and node operators, we let the free market reach a block size under natural consensus. We believe that a larger block network is fully capable of handling this, which is better than artificially limiting the block size. (ptschip)
BU allows full nodes and miners to vote for the block size limit they want. But if the rest of the network exceeds a certain number of clients that "reluctantly" accept oversized blocks, these larger blocks can be rejected. This strategy allows us to recognize that "Nakamoto consensus" is the top priority. In general, if the principles of Bitcoin's monetary function cannot be guaranteed, a consensus of full nodes following the longest chain will also be destroyed. (thezerg)
Q: Can you elaborate on the difference from Core? Is only BUIP-001 changed? Also, can you explain what exactly happens when a fork occurs, and whether BIPs (Bitcoin Improvement Protocols) will not be integrated by BU?
A : BU is a branch of Core 0.12 but removes the RBF function. The main added functions are Xthin blocks, Xpedited, and natural consensus (sickpig). We don’t need to list all the changes, because most of them are bug fixes and small improvements. For example, you can run “getpeerinfo <IP address>” to get data from only one node. But the big changes are emergent consensus, Xthin blocks, Expedited blocks, traffic shaping, mempool and DOS protection (thezerg)
Q: How can different development teams better collaborate in this area? (I know some of us are already collaborating on mempool sync logic, but I'm wondering how you think we can improve it and make it happen?) A: In terms of how the development team can work better together, I really hope... we can have good open communication with the XT and Classic teams, and we have been working together for a while. (ptschip)
Additional question: I don't think this is a one-sided matter, but considering that xt/classic/bu are projects that "don't run in production (while Core does run in production)", the lack of communication before is understandable, and what I'm asking is how we can improve it. As for teams and implementations, the more the better (sickpig) Unlimited cannot do a great job on the Core project because of the need to periodically rebasing on Core. However, I hope that in the near future we will no longer be at loggerheads over block size, but can work more directly together. Unfounded comments from your (Core) developers and leadership that other development teams are incapable are not helpful. (I would like to elaborate on a tweet from Adam Back, but there are already too many) (thezerg) We welcome open communication and dialogue at any time. I think the problem between Core and other implementations is that there are obvious differences in ideas about block size and concerns about transaction fees. In our philosophy, what is a free market and how transaction fees should develop are quite clear. This is a huge gap in the philosophy of the two development teams. (ptschip)
Q: Can we hard fork to solve the block size issue on a daily basis? A: Our plan is to remove the block size limit from the code and leave it to the free market to decide. So increasing the block size limit every day does not require a hard fork. (sickpig)
Additional question: I think he means accidental hard forks, where miners might occasionally fork away from the main chain, or will they always end up back on the main chain? Unless miners explicitly choose a value close to infinity, miners will return to the main chain after a few blocks. (thezerg) I think you mean running the BU logic on the blockchain. That's not what I mean, if you run BU without a hard fork to change the block size limit, there will be no hard fork later. Of course, in actual operation, there are not enough transactions, and miners can propagate mining information through thin blocks (Xthin blocks) before broadcasting the whole block. (thezerg)
Q: From what I understand from @海洋ViaBTC's blog, I understand that a miner running BU can accept a larger block at any time, as long as the larger block can continue the Bitcoin blockchain longer than the Bitcoin blockchain with a small block. Does this mean that super large blocks can ignore the block size that miners voted to accept? For example : If a miner says he will accept 2MB blocks, but the longest chain is a 2.1MB block, does the miner have to accept it anyway? Does this mean that any blocks mined by the miner before switching to the longest chain will be orphaned?
A: Unless miners explicitly choose a value close to infinity, miners will return to the main chain after a few blocks. (thezerg) About: "Reluctant blockchain switching", when I last detected "Once a chain exceeds AD (acceptance depth), even if additional blocks exceeding EB are added to the chain, the code will remain on the top of the chain unless there are no blocks exceeding EB on the chain for 24 hours. If that happens, colde will return to mining the original chain." @Andrew Stone further explained. (Translator's note: The EB value is the block size value that miners set to support.) Yes, exactly, except that the "24 hour period" is actually defined in the block. (thezerg) EB? EB = Block size exceeded (sickpig) So it seems to me that if miners want to keep orphan rates low, they will be forced to set AD to 0? Or set the exceeded block size (EB) value higher... (thezerg)
Q: What is the code review and deployment process? Who has the right to commit? A: Selected developers have commit access. Everyone else submits pull requests, which are reviewed by me and others before being merged into the main codebase. Small bug fixes go to the "master" branch, and larger features go to different branches that are then merged after extensive testing. thezerg) The code development group management process can be found in this article: https://www.bitcoinunlimited.info/articles. At the same time, more features must be voted by support staff. (sickpig)
Q: Will SegWit be included in the upcoming release? Or are you against it? Also, what are your plans for Schnorr?
A: Ultimately the membership will vote on whether to adopt Segregated Witness (SegWit). Personally, I think it is inelegant and it could be implemented much more elegantly with a hard fork. I also don't like a block size of 4MB total, but only 1.7MB of valid transaction storage. This becomes very painful when you increase the block size - the reasonable value is to increase it to 2MB, but in fact the block size is 8MB for some reason? And I find it hard to believe that there will be companies designing products around the Bitcoin payment system when scalability is only a very small increase. (thezerg)
Q: I’m curious because everyone talks about sigops growing quadratically and how this will become a big problem with increasing block sizes, do you think this is something to worry about? If not, what changes have you made? What challenges, if any, do you think you’ll need to face from increasing block sizes?
A: We are working on and are close to completing Parallel Block verification. We can verify several blocks at the same time through parallel threads, which can relieve the central processing thread. In this way, it is impossible to block a node or miner with a super large block. The super large block attacker will only make his block become an orphan block. (ptschip) Re: sigops attack, it's pretty trivial to add scaling rules - sigops have to be 20k per MB or something like that. This solves the quadratic growth problem. However, it might eliminate future use cases (if a script we consider "weird" today suddenly becomes useful), so we're looking into parallel verification. (thezerg)
Q: How often do you think "reluctant chain switches" will happen? Will it happen multiple times a day, or less often? How can miners prevent this from happening without losing money; just set a lower acceptance depth? If the acceptance depth is generally low, how can the consensus mechanism be attacked by attackers to achieve manipulated block size? Q: Is the bu team full-time programming? Or is it in addition to your "full-time job" (i.e. part-time)? A: I know we have at least two full-time developers. (ptschip)
Q: I would like to know how to expand the BU team? Q: How about the BU fund? I mean how to pay the salaries to the two developers? A: I can’t say who pays the developers, but we recently received a 500K donation, which will be used to pay developers bonuses. (ptschip)
Q: @Peter Tschipper Why not try to collaborate in areas where there are no consensus issues and work from there? A: We are willing to cooperate. Just a few weeks ago Matt Corallo reminded us that Core wanted to identify blocks only by block headers. So I told him that we are happy and open the door to them (Core) and told him that we have plans to do so. I don't think our cooperation was delayed much. (ptschip)
Additional question: I don’t know – there are complaints about the BIP process, which is why I’m asking… …are BU developers continuing to oppose the BIP process? How can we build a process that encourages collaboration even if it’s not a BIP process? (because oppositional network behavior is really bad) I think the problem with the BIP process is that it's your process, not our process, and we use the BUIP. How do we bridge this gap, and what is the way these two processes should communicate? Usually we contact other development groups and communicate with them. I don't know if it has to be that complicated, unless you want a more formal process? (ptschip)
Q: I think the BIP is a step in the right direction. At least in the big picture. The changes you propose are big enough to disrupt the market. In that respect, I'm interested in why BU thinks they can better meet market needs than Core. How do you think you can provide what the market needs? @Andrew Stone A: We have a formal process for proposing and accepting BUIPs. I cannot prevent members from overruling me. Please read our article and then join the Bitcoin Unlimited development group where you can vote. (thezerg) You can find the article here: https://www.bitcoinunlimited.info/articles (sickpig) For example, I am a committer on BU, but I do not control the codebase, nor can I hijack it. The president controls who gets commits. But I control DNS resolution, so if the president hijacks the codebase, then I can point the site away from it – and so on… checks and balances. (thezerg)
Q: Is BU membership open to anyone, or only code contributors? Have any of you been code contributors before ?
A: Anyone can participate, yes, I was a code contributor before I joined. (ptschip)
Q: There are complaints about the BIP process, which is why I asked… to do it — the BU development group continues to oppose the BIP process? How can we establish a process that encourages collaboration, even if it is not a BIP process?
A: Some of the BU members left to get away from the kind of "bro-coder" culture that exists on the Core forums. And to get away from the censorship of the forums. A few months ago, I tried to issue a BIP to use a feature bit that was never assigned a number, because it really wasn't fully explained and justified on Core. But the BIP process needs to understand that I shouldn't be forced into their processes, their culture, and their communication channels for censorship just to coordinate activities. There's no way we can submit another one... maybe things have changed. But I think we're looking for a more effective signal for change, and doing something like reimplementing Xthin finds it really meaningful to oppose the signal. (thezerg)
Q: Can you explain Xthin? Will the xthin performance change if the block size increases? A: I think Xthin blocks (95% bandwidth reduction on average) will improve performance with large blocks, since a smaller mempool is needed. (sickpig)
Additional question: Smaller memory pool size? Do you mean larger? Counter-question: Why bigger? (sickpig)
Additional question: I am confused, could you please explain the performance of the memory pool :) Additional answer: I think a congested network cannot meet the packaging needs of txs, which will lead to a large memory pool (sickpig) As block sizes increase, performance remains dependent on mempool synchronization. I would expect some degradation, e.g. if we are talking about 1MB blocks vs 10MB blocks and higher tx growth rates, mempool syncs may diverge slightly. (ptschip) xthin tl;dr (Translator's note: I don't understand what these two characters mean yet) Only send one transaction during the time period between one block and the next block. (sickpig) A cool thing is that if a miner plays "game" and keeps adding transactions to blocks, then Xthin's performance will be worse. So in theory a miner stuffing a block with fake transactions in order to make a huge block, such an attack would be hard to succeed because such blocks would not be broadcast well. These "attack blocks" would have a much higher orphan rate, and the potential empty blocks that follow would then corrupt this large "attack block"... (thezerg)
Q: @Andrew Stone Do you believe a single committed architecture is better than multiple? Q: If a concept is approved, how do you control the quality of the code?
A: When someone submits a performance requirement code, I (and others) review and test it. I read every line of code, which is why larger performance requirements code takes more time. In the future, if my time becomes a bottleneck, I will delegate the responsibility of the first review to other developers. We run and scale the normal tests "make check" and python qa. We also have a private network of nodes running globally that we use for testing on multiple blockchains (mainchain, testnet, nol chain). I have personal miners and mining pool software running on these nodes for operational testing, and I have Windows, Linux 32/64, MAC and 4 ARM machines that I run BU on. So we have a lot of power to test this software in real world situations (thezerg) I don't think our programs are all that different from Core. We have code reviews, we have unit and regression tests. We are currently using Travis to automate regressions so we know that when performance requirements are committed, all the tests have passed. (ptschip) For big performance improvements, we have proper reviews, testing, CI and BUIP, which is what we are doing and will continue to do (CI = continuous integration). (sickpig)
Translator's note: Because this is a quiz show in a WeChat group, the grammar and vocabulary are not particularly rigorous, which makes translation very difficult. If there are any mistakes in the translation, please forgive me and point them out. Thank you. The original text has not been moved to the web page yet, I uploaded it to Baidu Netdisk for interested friends to download and read. Link: https://pan.baidu.com/s/1eSHTW10 Password: 6vii The original document was compiled and provided by @jake Lu Rui.
| 
