Topic: Really not understanding the Bitcoin XT thing... - page 3. (Read 5820 times)

Nodes cannot orphan blocks, only other miners can. The average node connection is therefor irrelevant.

Large miners do not stand at a significant risk to be orphaned by smaller miners, only the other way around is true. This creates a situation where a few large pools can agree not to orphan each other (and there already are examples of large pools signing on mutual agreements) and they can easily vampirize the smaller pools market share.

The reality is that without limits on the current system, connectivity will become a barrier to entry to the mining market. By nature, barriers to entry are agents of centralization. The stance of the Core team and supporting members of the technical community is that the network needs first be more efficient before it is scaled up. Otherwise, effectively removing the block size limit is akin to amplifying an analog stream with a poor SNR. The only thing you will achieve is to drown the valid signal in noise.

This argument has been laid out several times by people much more versed on the networking layer of Bitcoin than I am. If you want to engage in a discussion with me on this matter, I would appreciate that you do not ignore this criticism to large blocks. Currently, your insistence on the idea that miners will limit themselves because of orphans instead of using it as an edge to predate on their competitors indicates otherwise.

I would also like to remind you that this isn't the topic of this thread. We are here to discuss the underlying fundamentals of XT, essentially the "why XT", not so much the "how". Gavin made it clear in XT, the end all and be all of the "how" is Moore's law.

So now, to get back on topic, your answer does not refute my presentation of XT's stance on the fee market:


Indeed, say I am wrong and miners will softcap block size to limit orphans. In your best scenario, in which your analyze is right, you perceive the fee market as nothing more than the consequence of a technical limitation, not a feature. The fact that there may or may not be a fee market in XT will not be by design but an unwanted consequence of hardware limitation. Therefor, it wouldn't surprise me to see solutions implemented in XT to entirely get rid of the fee market, like implementing LN, which you are proposing.

There will be a market of fee, if there is the situation where it is needed:

On the front page of BitcoinXT's website:


There is no such intention to maintain a fee market in XT. Hearn wants to replace miner subsidy with some sort of mining insurance contract (that I have not looked at). Maybe someone familiar with the proposal can pitch in.

What is clear is that XT supporters believe any transaction is worthy of the blockchain and that fee competition is detrimental to the network. They only see fees as serving the purpose of mining subsidy so it is expected their proposals to replace the fee market will only cover this aspect, as the filtering and competition in the transaction market are concepts they are fundamentally opposed to.

Simply put, they don't want a transaction market, they only want the validation layer.


The set of lead developers and their leadership philosophies. The idea is not to only change leaders but to change direction altogether. Hearn puts it quite clearly in his XT FAQ:

But we still need a working transaction market in the long term. How is this intention maintained in XT?

You can not join the banking system as a peer, only as a customer.


Decentralization is a relative term, and Bitcoin was not developed with that as a goal.  Decentralization was a tool toward Satoshi's ends.  What makes Bitcoin work is that it is truly peer to peer, if that is what users want to be able to do.  But that's not going to work with a flexible blocksize.  Moving to 8 megs isn't a big deal, but nor does it really change the scalilibilty issue much.  I'm not even opposed to soft limits, so long as Satohsi's original idea of rising transaction fees for larger blocks is preserved; but some kind of transaction fee market needs to exist.  If we screw this up, and the hashrate collapses, it would be catastrophic.  I'm not really opposed to how the XT team is actually using a hard fork as a voting method.  It's actually a good plan, it would appear.  I came here hoping I could get forum members who were better versed in XT than myself to explain the details, but instead I get noise.

And no one is arguing this, we need both without exceptions or virtual limits.

I can join the current banking system as an equal peer and it already has the transaction volume, sales acceptance, speed of verification and so on. Is it probable I would succeed? Not unless I was in the club but it is possible.

If "it has long been the idea that Bitcoin's main network would have to be a backbone mostly between major institutions", then Bitcoin failed long ago when that idea was accepted and it is being falsely marketed. This sounds a lot like what a financial institution would want of Bitcoin so they could carry on their hegemony.

I've been doing some research into the Lightning network proposal, and I'd say that I'd be more in favor of fixing malliability in order to permit such a network to develop, over the XT proposal of larger blocks and better support for light clients; simply because larger blocks don't really solve the scalability problem.  It has long been the idea that Bitcoin's main network would have to be a backbone mostly between major institutions that performed 99.9% of transaction volume.  Centralization really isn't a huge issue, so long as it's always possible for a new player to join the main bitcoin network as an equal peer with the rest.  XT seems to make such an idea more costly, without actually solving the scalability issue in the long run.  We will still need overlay networks with XT.  I remember the payment channels thing, and remember discussing it years ago, in the context of bitcoin banks settling up with each other by being able to identify the customers of another bank by their bitcoin addresses instead of personal data.  We still need these bitcoin banks.

My tuppence!

It is a political battle wrapped in technical FUD.

What is basically being proposed is a rather gentlemanly 51% attack on the current blockchain by a splinter group of devs. Gentlemanly because they are stating when they will do it and given a date by which they will complete the takeover. They hope to persuade enough existing hashpower to force a fork onto their chain so they they can move control of the network onto their software fork. The capabilities of that client is a side-show; the issue here is that the attack is possible without any outlay of resources. If you want to see how a government would do it in the future; this is how. Not by buying a shedload of hardware to out-hash the network, but persuade or force existing miners to switch.

The blocksize is just the crowbar for leverage. The blocksize itself was a kudge to fix what they term spam - micro payments and dust transactions - because the centralisation of mining meant that miners couldn't keep up any more and transaction times were ballooning. It was taking the miners longer to get their pound of financial flesh. It was a quick-fix solution that has now become a permanent feature of the protocol and means whoever has the lowest block size loses as the higher limit is the super-set of acceptance.

 If the network could handle the transactions then the block size would be irrelevant, there would be no limit and there would not be the leverage to force the fork as any limit would be the loser.

- The code that put Tor exit ips on low priority activate it self only during DoS connections attack on the node it self
- The code is disabled if the node is set to use a proxy
- The code is disabled if the node runs with this flag -disableipprio

Miners can't make block of bigger size because they will get them orphaned.

https://tradeblock.com/blog/bitcoin-network-capacity-analysis-part-6-data-propagation
So if blocks are bigger than the the average connection of the nodes, they will be orphans.
This is the natural size limit, that if it is reached, will open the possibility for a market of fee.


An XT FAQ <- But I suggest you to read this.
https://medium.com/@octskyward/an-xt-faq-38e78aa32ff0

That, yes.


Those concerns will end up realised no matter which way the dev team go, max blocksize is increasing above 1MB no matter what. The usage examples you gave will need to take a new approach.



Another less cited new feature of the XT client is a change to chain selection/consensus rules. XT clients don't follow the longest chain, they follow the chain with the highest XT checkpoint embedded into it.

What kind of "change in management" are you referring to here?  The different set of lead developers, perhaps? Or something else?

I'm more than a bit concerned that the big block mod, generally, will force marginal mining nodes off the network.  I know that it would prevent the broadcasting of whole blocks, and likely even naked merkle tree data, over datacasting paths such as Outernet.  If we are going to make changes for scalability, why are we not making naked blocks the standard broadcasting method first?  That alone would reduce redundancy.

Right, well you've amply described why those who consider themselves somewhat aware of the technical aspects underlying this debate dislike XT. I agree with all of that, so your post title is inaccurate, I think you do understand it. I'd just point out in addition that there are 2 other categories (both political, but relevant to development) of contention also; the necessary change in management that an XT fork would involve, and the perhaps inevitable change in development direction.


I had always assumed the "IP blacklisting" stuff was pure made up counter-offensive FUD, but what you're saying implies it has some basis in fact. The interpretation of the new behaviour in respect of Tor nodes is perhaps exaggerated; "deprioritisation" is the description given for what happens to the condition of a Tor node's connection to any given XT node, although they are awarded the harshest score within the de-priority range. How this manifests in practice, I am not yet sure.

I know I have been out of the loop for a while, but I've started to hear about this Bitcoin versus Bitcoin XT "code fork" from semi-mainstream news sources.  I sounds like FUD, so I have checked out the Bitcoin XT website and searched a bit around this forum for details.  One thing that I don't understand is why does Bitcoin XT have the other features, such as auto-dropping of TOR nodes?  And can the Bitcoin XT node be forced into the 'quiet' node format?  From what I have found out, it looks like it leaks the node's IP address while it's supposed to be hidden.

As for the big block mod.  I guess I just don't see the value in it. jumping to 8megs on start, then auto-adjusting for transaction volumes would undermine the transaction fee market that is supposed to develop to priortize transactions.  Also, where are these overlay networks that were supposed to absorb the majority of the lower security transaction volume?  This bitcoin network proper was never supposed to be how Joe Average transacted in the currency, Joe should be using a light client on an overlay network; like Electrum was developing or M-Pesa style light client networks on smartphones.  Why are we still doing the majority of retail business using full clients anyway?

Someone with more intimate knowledge is welcome to correct me on the technical details, but please don't come to me with complaints about how the fee market would never have worked or that Bitcoin proper actually needs to scale to Visa levels; I've been here too long for those arguments to still have any merit.