SPV and network splits

[jonald_fyookball]

If there is a network split, how do SPV wallets like Electrum know which blockchain or nodes to connect to (assuming I have a preference)?

[1715069826]

1715069826

[1715069826]

1715069826

[1715069826]

1715069826

[1715069826]

1715069826

[1715069826]

1715069826

[achow101]

They don't. SPV wallets don't verify consensus rules and trusts that the node(s) it is connected to is following the rules that you want. During a hard fork event, you probably don't want to be sending or receiving any Bitcoin as it will be difficult to know what chain your wallet is even following.

[DannyHamilton]

I'm not certain, but I thought SPV typically looked at the block headers from many connected nodes for the longest proof-of-work chain?  As such, all SPV wallets may already be Unlimited compatible as long as Unlimited doesn't build a block larger than 1 megabyte until they have an overwhelming majority of the hash power.

If that's true, then there's going to be unpredictable behaviors for many users creating a LOT of confusion when SPV wallet users all try to send bitcoins from their wallets to an exchange or from an exchange to their wallets if the exchanges insist on not supporting Unlimited.

[jonald_fyookball]

They don't. SPV wallets don't verify consensus rules and trusts that the node(s) it is connected to is following the rules that you want. 

Right... so how will they know what nodes?  I guess it depends on how the wallet is currently implemented, and some may require code changes and it also depends on how the network splits. hmm

[achow101]

Right... so how will they know what nodes?  I guess it depends on how the wallet is currently implemented, and some may require code changes and it also depends on how the network splits. hmm

They won't know, and that's a problem. Your only solution to guarantee that you are using the chain that you want to is to set up your own node and set your SPV wallet to only connect to that.

[Peter R]

I really don't think there is going to be a split.  The miners won't produce a block larger than 1 MB until they're convinced they have so much hash power support for larger blocks that a minority chain won't be viable. 

[AgentofCoin]

I really don't think there is going to be a split.  The miners won't produce a block larger than 1 MB until they're convinced they have so much hash power support for larger blocks that a minority chain won't be viable.  

Wishful thinking.

There are some entities that are too invested to back out now.
If they got to 65% and stall, they may be forced to go fork anyway.
The risk of losing their built momentum would be too great not to.

[jonald_fyookball]

I really don't think there is going to be a split.  The miners won't produce a block larger than 1 MB until they're convinced they have so much hash power support for larger blocks that a minority chain won't be viable.  

Wishful thinking.

There are some entities that are too invested to back out now.
If they got to 65% and stall, they may be forced to go fork anyway.
The risk of losing their built momentum would be too great not to.

Invested how?  Forced how?

I think Peter is saying CORE won't allow the split because they will capitulate at the last minute and adopt the big block mechanism of some kind on the core implementation.

[AgentofCoin]

I really don't think there is going to be a split.  The miners won't produce a block larger than 1 MB until they're convinced they have so much hash power support for larger blocks that a minority chain won't be viable.  

Wishful thinking.

There are some entities that are too invested to back out now.
If they got to 65% and stall, they may be forced to go fork anyway.
The risk of losing their built momentum would be too great not to.

Invested how?  Forced how?

I think Peter is saying CORE won't allow the split because they will capitulate at the last minute and adopt the big block mechanism of some kind on the core implementation.

Peter's point is that the hardfork supporting miners are rational and will wait till there is certainty.
My point is that enough certainty may never come and they may take the risk and cross their fingers.

If CORE does implement anything, it will likely be a 2MB bump max IMO, and I don't think the BUers
would agree to that. BUers want the scaling issue solved for good. Peter's assumption of CORE capitulation
assumes a Total Capitulation, which actually means that CORE's principals of Bitcoin's decentralization and
trustlessness needs to be abandoned. I don't see that happening IMO.

[Peter R]

If CORE does implement anything, it will likely be a 2MB bump max IMO, and I don't think the BUers
would agree to that. BUers want the scaling issue solved for good. Peter's assumption of CORE capitulation
assumes a Total Capitulation, which actually means that CORE's principals of Bitcoin's decentralization and
trustlessness needs to be abandoned. I don't see that happening IMO.

Yes, Core will most likely do a bump to 2 MB so that its users can track the most work chain.  This is the power of the BU approach.  You don't have to agree with us; you just have to loosen your block size rules enough to follow along. 

If Core did this 2 MB bump, then eventually we'd hit the 2 MB limit and the processes would repeat again.  But this time, the community wouldn't be as worried about it because we've done it once before. 

This is what emergent consensus is all about. 

[DannyHamilton]

Peter's point is that the hardfork supporting miners are rational and will wait till there is certainty.
My point is that enough certainty may never come and they may take the risk and cross their fingers.

They've got too much invested to take such a risk.  If they can't continuously stay ahead of Core in number of blocks produced, then their blocks will become orphaned when the Core chain becomes longer. That's a LOT of electricity to pay for, and no revenue to show for it.  On top of that almost ALL miners that are signaling for Unlimited are signalling EB1, so any block larger than 1 megabyte will be orphaned by both Core AND the other Unlimited miners.

If CORE does implement anything, it will likely be a 2MB bump max IMO, and I don't think the BUers
would agree to that.

Actually, Core won't be able to reliably implement a 2MB bump if BU miners BOTH have more than 50% of the hash power AND maintain EB1.  BU miners will continue to ignore the 2MB Core blocks as invalid, and will maintain a longer chain with blocks less than 1 megabyte.  Since those smaller blocks will be "valid" Core blocks, Core miners would be forced to keep their blocks smaller than 1 megabyte if they don't want to waste their money mining orphaned blocks.

If Core has more than 50% of the hash power OR if BU miners increase above EB2, then EB miners won't have a choice about agreeing to it.  With a larger EB, BU is already designed to accept blocks that are smaller than the EB.
With Core above 50%, their blocks will reach any AD depth and BU is already designed to accept any size block that reaches the AD.

BUers want the scaling issue solved for good.

And as such, they may still continue to push for more miners to signal BU.  Perhaps some day they'll get there, perhaps they won't.  Only time will tell.

Peter's assumption of CORE capitulation assumes a Total Capitulation, which actually means that CORE's principals of Bitcoin's decentralization and trustlessness needs to be abandoned.

Nah.  Unlimited is no less decentralization or trustless than Core.  There is some concern that mining could become significantly more centralized if the blocks get too big for smaller miners, but no guarantee that will happen.  As it is, resource availability (ASICs and cheap electricity) is going to push mining in that direction even in Core.

[Holliday]

Unlimited is no less decentralization or trustless than Core.

Except for that time BU released a closed source patch.

[DannyHamilton]

Unlimited is no less decentralization or trustless than Core.

Except for that time BU released a closed source patch.

And anyone can release a closed source patch of Core if they want to.  Doesn't mean users will choose to run it.

[Holliday]

Unlimited is no less decentralization or trustless than Core.

Except for that time BU released a closed source patch.

And anyone can release a closed source patch of Core if they want to.  Doesn't mean users will choose to run it.

Yes, anyone can. No, it certainly doesn't.

[AgentofCoin]

If CORE does implement anything, it will likely be a 2MB bump max IMO, and I don't think the BUers
would agree to that. BUers want the scaling issue solved for good. Peter's assumption of CORE capitulation
assumes a Total Capitulation, which actually means that CORE's principals of Bitcoin's decentralization and
trustlessness needs to be abandoned. I don't see that happening IMO.

Yes, Core will most likely do a bump to 2 MB so that its users can track the most work chain.  This is the power of the BU approach.  You don't have to agree with us; you just have to loosen your block size rules enough to follow along. 

If Core did this 2 MB bump, then eventually we'd hit the 2 MB limit and the processes would repeat again.  But this time, the community wouldn't be as worried about it because we've done it once before. 

This is what emergent consensus is all about. 

Yes, but a 2MB bump is somewhat reasonable, but another bump in a year or so is not.
That is the problem, you would be effectively marching Bitcoin toward centralization more
rapidly than we can handle, since the markets have potentially unlimited consumption.

We would leave ourselves vulnerable to eventual governmental regulation. We have not
now or will in the near future, reach the point that Bitcoin becomes fully invulnerable to
governments, if we keep bumping the blocksize every year or so. Technology has not
caught up to us yet. We need to balance for On-Chain scaling, IMO.

[AgentofCoin]

Peter's point is that the hardfork supporting miners are rational and will wait till there is certainty.
My point is that enough certainty may never come and they may take the risk and cross their fingers.

They've got too much invested to take such a risk.  If they can't continuously stay ahead of Core in number of blocks produced, then their blocks will become orphaned when the Core chain becomes longer. That's a LOT of electricity to pay for, and no revenue to show for it.  On top of that almost ALL miners that are signaling for Unlimited are signalling EB1, so any block larger than 1 megabyte will be orphaned by both Core AND the other Unlimited miners.

I agree with you. My point is that Miners may later choose to jump too soon and think they can either
by normal hash succeed or by creating "chain wars" where outside attack vectors are used to "hold back"
or attack the other chain. That is "allowable" in theory, but is not within the Consensus Mechanism.

Peter's comment was that Miners will wait, assuming they could wait forever, when in reality,
they need to move soon otherwise they may lose support over time. Everyday is a new day since it is
currently contentious. I think some Miners have itchy trigger fingers and may attempt a coup,
("Follow us or die!" mentality). If they are willing to wait forever potentially I would be amazed.

If CORE does implement anything, it will likely be a 2MB bump max IMO, and I don't think the BUers
would agree to that.

Actually, Core won't be able to reliably implement a 2MB bump if BU miners BOTH have more than 50% of the hash power AND maintain EB1.  BU miners will continue to ignore the 2MB Core blocks as invalid, and will maintain a longer chain with blocks less than 1 megabyte.  Since those smaller blocks will be "valid" Core blocks, Core miners would be forced to keep their blocks smaller than 1 megabyte if they don't want to waste their money mining orphaned blocks.

If Core has more than 50% of the hash power OR if BU miners increase above EB2, then EB miners won't have a choice about agreeing to it.  With a larger EB, BU is already designed to accept blocks that are smaller than the EB.
With Core above 50%, their blocks will reach any AD depth and BU is already designed to accept any size block that reaches the AD.

The 2MB bump would be contingent that BU Emergent Consensus is dropped from their client, IMO.
I do not talk for CORE nor know anything about CORE, I am assuming based on past mentalities.

Peter's assumption of CORE capitulation assumes a Total Capitulation, which actually means that CORE's principals of Bitcoin's decentralization and trustlessness needs to be abandoned.

Nah.  Unlimited is no less decentralization or trustless than Core.  There is some concern that mining could become significantly more centralized if the blocks get too big for smaller miners, but no guarantee that will happen.  As it is, resource availability (ASICs and cheap electricity) is going to push mining in that direction even in Core.

My concern of centralization is not with miners or developers, since there are
checks in place to prevent rogue people/miners. My centralization concern is when
the blockchain is so large that mass amounts of individuals can no longer maintain
them on their normal systems. When and if that occurs, the distributed ledger becomes
more centralized within locations that can be regulated by governments. For an example,
imagine BitTorrent, except the file is so big now that BitTorrent outsourced its storage
primarily to Google or Amazon Servers or other Corporate Servers. How long do you
think Bitcoin could resist governmental regulation in that future?

In this any txs welcome, constant on-chain scaling, including for data storage
and not just btc financial txs future, we will need to centralize and trust corporations.

That is my centralization concern. I don't think we should hand our future to corporate
storage services. They will never be loyal to us, but only to the laws of their jurisdictions.
The same way PayPal shut down Wikileaks, those corporations will drop our chain ledger
at the request of the governments. We need for technology to catch up to us.

[jonald_fyookball]

snip

Has any coin tried doing some kind of torrent like distribution where nodes hold redundant pieces of the blockchain but not necessarily the whole chain?

[AgentofCoin]

snip

Has any coin tried doing some kind of torrent like distribution where nodes hold redundant pieces of the blockchain but not necessarily the whole chain?

I don't think so, but others are likely more knowledgeable about that.

The issue is I think someone still needs to maintain the full ledger somewhere
and in this proposed future, the ledger could be too large for one deep dark server
to partition the data and send to others in pieces. Plus, that would be the prime
target (the one or few deep dark servers) to take down this "torrent distributed
ledger network" IMO.

[ranochigo]

snip

Has any coin tried doing some kind of torrent like distribution where nodes hold redundant pieces of the blockchain but not necessarily the whole chain?

I don't think so, but others are likely more knowledgeable about that.

The issue is I think someone still needs to maintain the full ledger somewhere
and in this proposed future, the ledger could be too large for one deep dark server
to partition the data and send to others in pieces. Plus, that would be the prime
target (the one or few deep dark servers) to take down this "torrent distributed
ledger network" IMO.

This is impossible, as far as i can tell. Lets say the blockchain is 'cut' into 50 parts and 2 computers has each part. If both the computer gets shut down, the blocks after that part cannot be verified. It is impossible for the client to know which part they can archive and which part they are supposed to distribute.

This idea creates too many points of failure.

[Jet Cash]

Has any coin tried doing some kind of torrent like distribution where nodes hold redundant pieces of the blockchain but not necessarily the whole chain?

Isn't this in part the thinking behind SegWit?