Code for Litecoin BIP101/4
Posted: Sat Feb 20, 2016 10:56 am
Today, I'm going to provide a status update for BIP101 on litecoin. I also want to make some comments on the current state of bitcoin development, especially in regards to the recent letter calling for delay in implementing Bitcoin Classic.
Those who have been following my writings know that I am opposed to Bitcoin Classic, because it doesn't go far enough in resolving the issue it tries to solve, and because it sets a bad precedent of numerous hard forks and continual argument and delay in the future. We are not upgrading our nodes to Bitcoin Classic for this reason. But regardless of what we believe, it seems that the majority of people also do not support Bitcoin Classic because the node count is not shifting towards Classic. The idea that there are thousands more Classic nodes is correct, but the number of Core nodes has not changed. There is not a major move towards Classic occurring, and we can't say that one is occurring until we see Core nodes being replaced by Classic nodes, rather than people simply spinning up new Classic nodes.
Last week's "a call for consensus" letter was one of the most significant setbacks in recent memory for bitcoin. If you haven't read the letter, read my previous post in this forum for a summary and comments. While I was angered by the letter, the part that stood out most to me was that it was signed by Charlie Lee. It is not possible to argue that Lee signed the letter as a representative of Coinbase, because he listed his title explicitly as "creator of Litecoin." By signing the letter, Lee agreed that the bitcoin community should wait for "consensus" for yet another three weeks - despite that Andresen began calling for consensus in May 2015 and there has been plenty of time for discussion.
When I stated in that Forbes article that I was submitting BIP101 for Litecoin, I had hoped that Lee would at least consider what I had to say. Later, he asked for time to produce an alternate solution, and I again agreed to wait for him to do so. I even told him that I would help, but he never replied or assigned me anything to do. Weeks later, Lee has not come forth with a solution, and the letter significantly damaged Lee's credibility on scaling either network. Lee supported 3 weeks of delay which time has shown (https://medium.com/@bitcoinroundtable/b ... .5o6l37lp2) did not produce a reasonable solution for extending the bitcoin network.
What bothers me most about the entire debate is the secrecy in which many are engaging. I understand that Lee may not have finished his code yet, but why has he not announced what he plans to do in detail? He says that he has developers engaged in writing the solution, but why hasn't he announced who is involved? Why is discussion not occurring in /r/litecoin or elsewhere as to whether Lee's proposed solution is best or not? Besides making people question whether anything has been accomplished at all, writing something in secret and then announcing it risks a critical implementation flaw that could have easily been pointed out before all the work was wasted.
Given that my faith in Lee is shaken after the letter, and being unable to contribute to the other solution because of the ongoing secrecy, I've decided to release what I have to git. It's available at https://github.com/steve-sokolowski/litecoin-bip101-4. The state of the code is the following: it compiles and runs. It passes the unit tests. Nodes can connect to each other and transmit 2MB blocks. However, the bigblocks.py python test in qa/rpc_tests fails at line 243, because the daemon rejects the mined blocks due to a hash that is too easy. It isn't clear whether this issue is related to bigger blocks or whether it has always been present but this particular sequence of steps was never tested.
BIP101 is an improvement that shouldn't require weeks to implement. If I could sit down and put in a full 70-hour week into this, it would probably be done within one or two weeks. Unfortunately, because the pool has had significant performance problems recently, I've been spending about 40 hours at my first job, 20 hours with the pool, and fewer than 10 with this task. The pool's performance improvements are expected to go live this weekend, and since the following weekend is the last of the month when I have mandatory vacation to use, I hope to be able to push to get the bigblocks.py test working on the February 27-29 weekend.
The issues with pool performance expose a significant problem with coin development - it doesn't pay. The reason that the infrastructure around the bitcoin network is so much better than the network is because there is no money to be made in actually contributing features to the network itself. My first priority will need to remain the mining pool, despite the fact that I would be able to complete BIP101 quickly if there were enough time to do so. I was hoping that with this post, someone might be willing to assist with investigating why the test fails so that we can complete this implementation more quickly.
At the same time, I was also hoping that someone may be interested in assisting in maintaining this code should it become necessary to push for its adoption in litecoin. I may be deeply disappointed in the secrecy and lack of openness with Lee's solution - but since BIP101/4 isn't finished yet, we're still willing to wait for a while longer before considering mining blocks.
However, as I've said before, we can't afford to delay indefinitely and go bankrupt while the industry stagnates due to lack of action. First, I urge Lee one last time to come out of the shadows immediately and bring discussion and development of his solution into the open. Please announce what is planned, who is working on what, and what the deadline for adoption will be. If that doesn't happen and continuing secrecy and a lack of progress causes a push for BIP101/4 adoption to become necessary, someone is going to need to lead the charge and follow through afterward. Given my responsibilities with this pool, I can't be that leader, so I'm calling for anyone who would be interested in assisting with a push for BIP101/4 mining and adoption, should it become necessary, to contact us and help fix this last test.
I'll keep everyone updated as the code nears completion. If you are willing to assist in resolving the last issues, please contact us.
Those who have been following my writings know that I am opposed to Bitcoin Classic, because it doesn't go far enough in resolving the issue it tries to solve, and because it sets a bad precedent of numerous hard forks and continual argument and delay in the future. We are not upgrading our nodes to Bitcoin Classic for this reason. But regardless of what we believe, it seems that the majority of people also do not support Bitcoin Classic because the node count is not shifting towards Classic. The idea that there are thousands more Classic nodes is correct, but the number of Core nodes has not changed. There is not a major move towards Classic occurring, and we can't say that one is occurring until we see Core nodes being replaced by Classic nodes, rather than people simply spinning up new Classic nodes.
Last week's "a call for consensus" letter was one of the most significant setbacks in recent memory for bitcoin. If you haven't read the letter, read my previous post in this forum for a summary and comments. While I was angered by the letter, the part that stood out most to me was that it was signed by Charlie Lee. It is not possible to argue that Lee signed the letter as a representative of Coinbase, because he listed his title explicitly as "creator of Litecoin." By signing the letter, Lee agreed that the bitcoin community should wait for "consensus" for yet another three weeks - despite that Andresen began calling for consensus in May 2015 and there has been plenty of time for discussion.
When I stated in that Forbes article that I was submitting BIP101 for Litecoin, I had hoped that Lee would at least consider what I had to say. Later, he asked for time to produce an alternate solution, and I again agreed to wait for him to do so. I even told him that I would help, but he never replied or assigned me anything to do. Weeks later, Lee has not come forth with a solution, and the letter significantly damaged Lee's credibility on scaling either network. Lee supported 3 weeks of delay which time has shown (https://medium.com/@bitcoinroundtable/b ... .5o6l37lp2) did not produce a reasonable solution for extending the bitcoin network.
What bothers me most about the entire debate is the secrecy in which many are engaging. I understand that Lee may not have finished his code yet, but why has he not announced what he plans to do in detail? He says that he has developers engaged in writing the solution, but why hasn't he announced who is involved? Why is discussion not occurring in /r/litecoin or elsewhere as to whether Lee's proposed solution is best or not? Besides making people question whether anything has been accomplished at all, writing something in secret and then announcing it risks a critical implementation flaw that could have easily been pointed out before all the work was wasted.
Given that my faith in Lee is shaken after the letter, and being unable to contribute to the other solution because of the ongoing secrecy, I've decided to release what I have to git. It's available at https://github.com/steve-sokolowski/litecoin-bip101-4. The state of the code is the following: it compiles and runs. It passes the unit tests. Nodes can connect to each other and transmit 2MB blocks. However, the bigblocks.py python test in qa/rpc_tests fails at line 243, because the daemon rejects the mined blocks due to a hash that is too easy. It isn't clear whether this issue is related to bigger blocks or whether it has always been present but this particular sequence of steps was never tested.
BIP101 is an improvement that shouldn't require weeks to implement. If I could sit down and put in a full 70-hour week into this, it would probably be done within one or two weeks. Unfortunately, because the pool has had significant performance problems recently, I've been spending about 40 hours at my first job, 20 hours with the pool, and fewer than 10 with this task. The pool's performance improvements are expected to go live this weekend, and since the following weekend is the last of the month when I have mandatory vacation to use, I hope to be able to push to get the bigblocks.py test working on the February 27-29 weekend.
The issues with pool performance expose a significant problem with coin development - it doesn't pay. The reason that the infrastructure around the bitcoin network is so much better than the network is because there is no money to be made in actually contributing features to the network itself. My first priority will need to remain the mining pool, despite the fact that I would be able to complete BIP101 quickly if there were enough time to do so. I was hoping that with this post, someone might be willing to assist with investigating why the test fails so that we can complete this implementation more quickly.
At the same time, I was also hoping that someone may be interested in assisting in maintaining this code should it become necessary to push for its adoption in litecoin. I may be deeply disappointed in the secrecy and lack of openness with Lee's solution - but since BIP101/4 isn't finished yet, we're still willing to wait for a while longer before considering mining blocks.
However, as I've said before, we can't afford to delay indefinitely and go bankrupt while the industry stagnates due to lack of action. First, I urge Lee one last time to come out of the shadows immediately and bring discussion and development of his solution into the open. Please announce what is planned, who is working on what, and what the deadline for adoption will be. If that doesn't happen and continuing secrecy and a lack of progress causes a push for BIP101/4 adoption to become necessary, someone is going to need to lead the charge and follow through afterward. Given my responsibilities with this pool, I can't be that leader, so I'm calling for anyone who would be interested in assisting with a push for BIP101/4 mining and adoption, should it become necessary, to contact us and help fix this last test.
I'll keep everyone updated as the code nears completion. If you are willing to assist in resolving the last issues, please contact us.