Really not understanding the Bitcoin XT thing...

[MoonShadow]

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.

[1715009961]

1715009961

[1715009961]

1715009961

[1715009961]

1715009961

[1715009961]

1715009961

[1715009961]

1715009961

[Carlton Banks]

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.

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.

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.

[MoonShadow]

the necessary change in management that an XT fork would involve,

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.

[Carlton Banks]

the necessary change in management that an XT fork would involve,

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

That, yes.

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.

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.

[HostFat]

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.

- 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

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.

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

Next, we examine the size of confirmed blocks that were involved in an orphan race relative to period averages. The chart below suggests that blocks in an orphan race are, on average, ~100kb / 20% larger than regular blocks that are not part of such races. This is likely the result of larger blocks taking longer to relay.

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

[TransaDox]

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.

[MoonShadow]

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.

[TransaDox]

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.

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.

[HostFat]

We will still need overlay networks with XT.

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

[MoonShadow]

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.

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.

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

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.

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.

[MoonShadow]

We will still need overlay networks with XT.

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

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

[goatpig]

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

On the front page of BitcoinXT's website:

Bitcoin XT is an implementation of a Bitcoin full node that embraces Bitcoin's original vision of simple, reliable, low-cost transactions for everyone in the world.

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.

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

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:

The real reason for the difference is that back then Gavin was the maintainer of Bitcoin Core and he wasn’t afraid to pick something and require a simple majority to activate it, whereas now Wladimir is the maintainer and he requires unanimity. It seems literally every last person in the Bitcoin universe must agree or else a change cannot happen. We think, based on experience, that this can’t ever work.

So in the end, this is all XT is doing leadership wise: going back to the exact same model of decision making we used up until April 2014.

[HostFat]

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

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

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.

[goatpig]

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.

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:

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

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.

[TransaDox]

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.

This is such an important point that rarely gets voiced. Free market evangelists look at Bitcoin and see it as a technology to serve the current status quo if only it had more "market forces" and allowed more "opportunities for profit". The technical trade-offs that are exploitable are seen as designs that should be expanded to make way for more of the same rather than weaknesses in the protocol that should be plugged.

[Carlton Banks]

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.

This is such an important point that rarely gets voiced. Free market evangelists look at Bitcoin and see it as a technology to serve the current status quo if only it had more "market forces" and allowed more "opportunities for profit". The technical trade-offs that are exploitable are seen as designs that should be expanded to make way for more of the same rather than weaknesses in the protocol that should be plugged.

Allow me to help you and others understand: that sentence you are quoting was spoken from the perspective of the XT design ideology, not as a representation of the views of the person that wrote it. The person you quoted does not believe the view you are attributing to them.

I'm sure you wouldn't want to look like you are misrespresenting the situation, so I thought I would inform the thread (careful, someone might accuse you of being yet another dishonest debater, and you don't want that!)

[TransaDox]

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.

This is such an important point that rarely gets voiced. Free market evangelists look at Bitcoin and see it as a technology to serve the current status quo if only it had more "market forces" and allowed more "opportunities for profit". The technical trade-offs that are exploitable are seen as designs that should be expanded to make way for more of the same rather than weaknesses in the protocol that should be plugged.

Allow me to help you and others understand: that sentence you are quoting was spoken from the perspective of the XT design ideology, not as a representation of the views of the person that wrote it. The person you quoted does not believe the view you are attributing to them.

I'm sure you wouldn't want to look like you are misrespresenting the situation, so I thought I would inform the thread (careful, someone might accuse you of being yet another dishonest debater, and you don't want that!)

"Ground control to Troll Station-1. We have found your escapee."

[goatpig]

I guess I'll repeat what Carlton said:

I was trying to present the XT point of view on the fee market, to which I deduce you adhere (if I did a good job at describing it). I was not expressing my point of view.

[kano]

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.

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.

This can only be done by the equivalent of a 51% cartel not accepting blocks from the rest of the network, otherwise the lower their % is the higher the risk of losing blocks ... which miners don't like doing ...
Also, the "size" of the miner isn't all that relevant to % of orphan blocks - the only obvious reduction there is when they confirm their own blocks.
... and you don't "agree not to orphan" ... either your wording is incorrect or your understanding is incorrect.

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.

Any pool can limit the size of the blocks they are generating and thus reduce their orphans - but at the current limit of 1MB that's marginally relevant at best for any well configured miner/pool.
It will of course mean they are getting less txn fees in their blocks ... so once the block reward gets low enough, that will of course be an issue.
At the moment txn fees are averaging around 1% to 0.5% extra reward.

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.

Right, Moore's law has almost nothing to do with the profit from mining - not sure why Gavin can't see that ... other than the fact that he cares close to zero about mining ...
Electricity costs are the biggest factor for most - and finding a source of cheap power.

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

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.

Miners/Pools already softcap block size limits.
They also SPV (and supposedly non-SPV on Eligius) mine empty blocks on certain pools ...

[Carlton Banks]

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.

This is such an important point that rarely gets voiced. Free market evangelists look at Bitcoin and see it as a technology to serve the current status quo if only it had more "market forces" and allowed more "opportunities for profit". The technical trade-offs that are exploitable are seen as designs that should be expanded to make way for more of the same rather than weaknesses in the protocol that should be plugged.

Allow me to help you and others understand: that sentence you are quoting was spoken from the perspective of the XT design ideology, not as a representation of the views of the person that wrote it. The person you quoted does not believe the view you are attributing to them.

I'm sure you wouldn't want to look like you are misrespresenting the situation, so I thought I would inform the thread (careful, someone might accuse you of being yet another dishonest debater, and you don't want that!)

"Ground control to Troll Station-1. We have found your escapee."

seeing as the subject of your mistake agrees with my assessment (that you made a mistake), it appears that your accusation is without merit.

Be careful throwing such accusations around: if you're wrong, it will damage your own reputation, not that of your target.