Regardless of one’s opinion on block size, the fact that we now have an alternative client is good for Bitcoin’s resilience. There is no longer one point of failure in terms of client development. I hope more Bitcoin clients will be developed, all with minor differences yet aimed at reaching consensus. Sure this will lead to more minor hiccups when consensus now and then fail (read: forks) but sporadic minor forks are good for safety, in my opinion. It will make Bitcoin more antifragile.
For Counterparty problems like daily reorg would hopefully be resolved. Now every Counterparty node is down/busy reorganizing twice a day. This is because of an issue with Bitcoin Core. More clients, more solutions to choose from.
Hmmm, if you don’t like daily reorgs, I think you’ll hate occasional forks.
Why do you think larger blocks would have fewer reorgs?
If anything, reorgs would contain more - not less - transactions to be re-parsed. Maybe there would be fewer reorgs, but with a block size 8 times larger, there should be 88% fewer reorgs to make things better.
I’m against XT because it is my impression that the XT team is reckless and cannot be trusted. That’s the main reason.
Bitcoin Core devs came up with a proposal to increase the block size before XT people, and by now there are several other proposals some of which are better. With the network running at 30% (or thereabout) capacity, there’s no reason to hurry and switch to this unproven code.
if you don’t like daily reorgs, I think you’ll hate occasional forks.
Cannot be compared. Occasional forks would happen unexpectedly because of bugs, and for each little hiccup people would adopt and the system would grow stronger. E.g. the miners who lost blocks due to the SPV optimization recently is related to this. A little bit of mess is good for the system.
Why do you think larger blocks would have fewer reorgs?
I don’t think so. An expert would have to explain the details of this. From what I understand Core does reorgs twice daily at specified blocks. A trivial change to Core could be to let the user choose frequency of reorgs (or fork the Core code and only change this). Then running these two versions of Core would mean that at any time there would be at least one not doing reorg. Counterparty would have 100% uptime.
My point has nothing do with XT per se, just that more Bitcoin clients would mean more diversity, which would benefit the entire ecosystem, including Counterparty.
From this chart* it appears reorgs are random (not scheduled and not predictable) and on average there’s less than 2 a day (which you can tell by looking at the number of orphaned blocks per day - if the number is less than 2, then it can’t be more than one reorg).
It doesn’t seem all that clear to me that Bitcoin XT and Bitcoin Core could improve the impact of reorgs. As long as they don’t fork, the both seem to work the same way.
I haven’t tested btcd (it uses a lot of resources), but I would bet it “discovers” reorgs at exactly the same time as Bitcoin Core (and Bitcoin XT). It’s only a matter of who can handle them faster.
counterparty-lib can use btcd (but it hasn’t been well tested) and someone could try to setup 2 instances of Counterparty server and see whether the one with btcd discovers reorgs differently. The same could be done with Bitcoin Core and Bitcoin XT, although personally I am unlikely to do this because I think it’s even less likely we’ll see much difference.
If one of bitcoin servers were to be optimized to deal with reorgs faster, that would certainly be helpful. Some people are looking at making the back end use NoSQL so that reorgs can be processed within seconds, then Counterparty would be able to recover more quickly.
I hope I’m not wrong and I’m open to corrections.
If I had more time I’d really like to run an instance of btcd and Bitcoin Core to see how they react to reorgs, but at the moment I don’t have the resources to do that. Last time I tried to run just btcd, it was using 2GB of RAM.