I do feel badly if they just looked like misbehaving peers when in fact they were ok. Perhaps some other node can give them what they want/need. Sorry. Hopefully my node doesn't look like a misbehaving peer to anyone else.
I determine a peer is misbehaving based on mostly huge number of Bytes Sent, longest Ping Times, and low Starting Height (although this is least offensive to me). An unknown Sync Height is not attractive.
Topic: . - page 4. (Read 24756 times)
Is there any harm in creating a firewall rule to block inbound attempts from what appear to be abusive peers, e.g. 85.214.11.209?
I've unilaterally cut off another; 93.230.229.149. Blocking these are saving me a ton of bandwidth. 
I think we can distill the core of our argument -- both of our walls of text -- to this single snippet:
For some reason,it seems that you think that a miner who has solved a block is unable to get his solved block to whichever miner will ultimately solve the next block, without intervening independent nodes.
Okay, you can keep thinking that nodes don't exist and that hashpower rules all. The miner very much cares what other nodes think, since nodes determine whether to reject his block or not. You seem to believe that the "longest chain" is all the matters... but nodes enforce the longest, valid chain. Doesn't matter how many blocks a miner extends on top of an invalid block. It seems you're incapable of imagining any situation beyond everyday orphaned blocks. But we're talking about potential attack vectors and contentious hard forks here.
For some reason,it seems that you think that a miner who has solved a block is unable to get his solved block to whichever miner will ultimately solve the next block, without intervening independent nodes.
A miner can propagate that block to whichever nodes he wants. But that miner cannot control who those nodes connect to (or therefore prevent his block from reaching any and all nodes in the network). He cannot control whether the majority of nodes in the network agrees that his block is the next valid block on the longest, valid chain. In this context, there is absolutely no difference between "mining nodes" and "non-mining nodes." Per the whitepaper:
I say that he can -- if only by the fact that this miner also operates a node.
A miner operating a node does not negate the rest of the network, which is also operating nodes. The network can simply reject his proof-of-work if they consider it invalid. Unless he controls enough nodes to re-define what the network considers to be valid (i.e. Sybil attack), he can't ignore the entire network simply by running a node.
If the solved block gets to other miners, and one of those miners builds the next block on top of it, there is absolutely nothing that independent nodes can do about it. Period.
If some group of mining nodes accepts it as the next valid block, the rest of the network can still reject it. This is why miners can carry out block withholding attacks. By withholding the next valid block (by timestamp) and continuing to build on it, Miner A can force the rest of the network to orphan Miner B's later block(s) by eventually publishing a longer, valid chain built on top of an earlier, valid block. Even if Miner B has built multiple blocks on top of a valid blockchain, his blocks can still be forked off by the rest of the network.
The longest chain is irrelevant if it is built on top of an invalid block. It doesn't matter if that miner keeps building on the invalid chain; he has simply been forked off.
nodes determine whether to reject his block or not.
No - not in a system-wide sense. If the block makes it to other miners, and those miners consider the block valid, they will build a new block atop it.
That doesn't address whether the network views this block as valid. If most of it doesn't, the miners are irrelevant -- forked off. Even if most miners agree at first that it was the next valid block, the network may later disagree and fork it off. (E.g. in the case of a less-propagated valid block that was found earlier by timestamp than a better-propagated valid block that is now to to become a stale block)
The only power an independent node has is to choose not to participate in forwarding the block to other nodes or other miners. No independent node can have any effect upon any path in the connectivity graph, of which it is not a part.
Indeed, a node will not forward an invalid block to the rest of the network. If most of the network agrees it is an invalid block, it will not be retained on the longest, valid chain. Miners be damned. You are sort of implying that independent nodes are not part of the network at all. But they have the same power to reject invalid blocks that mining nodes do, by virtue of enforcing the same rules on the same network. For those nodes to be bypassed, they would need to be on a different network entirely.
but nodes enforce the longest, valid chain.
No. Miners enforce the longest valid chain. If a chain makes it to a miner, and that miner considers it the longest valid chain, that miner will attempt to build the next block on top of it. The only power an independent node has is to choose not to participate in forwarding the chain to other nodes or other miners.Actually, nodes -- both mining and non-mining -- are what enforces the longest, valid chain. Not hashpower. That's the very purpose and function of nodes -- validating transactions and blocks. Hashpower has nothing to do with validation.
What a miner considers to be the longest, valid chain may be completely irrelevant -- that miner is working off incomplete information. Until that chain is accepted by the majority of nodes -- and built upon with subsequent blocks to diminish the likelihood of being orphaned -- it can still be forked off by the network.
The only thing that matters is what the entire network of nodes considers to be the longest, valid chain. It doesn't matter if some miners agree on the next valid block early on -- or even mine on top of it -- because the network can still reject it as invalid.
From the looks of things, my node sends about 10x as much as it receives; so, I figure at least I am not a drag on the network. Valid thinking?
Yes.
I think we can distill the core of our argument -- both of our walls of text -- to this single snippet:
For some reason,it seems that you think that a miner who has solved a block is unable to get his solved block to whichever miner will ultimately solve the next block, without intervening independent nodes. I say that he can -- if only by the fact that this miner also operates a node. If the solved block gets to other miners, and one of those miners builds the next block on top of it, there is absolutely nothing that independent nodes can do about it. Period.
No - not in a system-wide sense. If the block makes it to other miners, and those miners consider the block valid, they will build a new block atop it. The only power an independent node has is to choose not to participate in forwarding the block to other nodes or other miners. No independent node can have any effect upon any path in the connectivity graph, of which it is not a part.
No. Miners enforce the longest valid chain. If a chain makes it to a miner, and that miner considers it the longest valid chain, that miner will attempt to build the next block on top of it. The only power an independent node has is to choose not to participate in forwarding the chain to other nodes or other miners.
Okay, you can keep thinking that nodes don't exist and that hashpower rules all. The miner very much cares what other nodes think, since nodes determine whether to reject his block or not. You seem to believe that the "longest chain" is all the matters... but nodes enforce the longest, valid chain. Doesn't matter how many blocks a miner extends on top of an invalid block. It seems you're incapable of imagining any situation beyond everyday orphaned blocks. But we're talking about potential attack vectors and contentious hard forks here.
For some reason,it seems that you think that a miner who has solved a block is unable to get his solved block to whichever miner will ultimately solve the next block, without intervening independent nodes. I say that he can -- if only by the fact that this miner also operates a node. If the solved block gets to other miners, and one of those miners builds the next block on top of it, there is absolutely nothing that independent nodes can do about it. Period.
nodes determine whether to reject his block or not.
No - not in a system-wide sense. If the block makes it to other miners, and those miners consider the block valid, they will build a new block atop it. The only power an independent node has is to choose not to participate in forwarding the block to other nodes or other miners. No independent node can have any effect upon any path in the connectivity graph, of which it is not a part.
but nodes enforce the longest, valid chain.
No. Miners enforce the longest valid chain. If a chain makes it to a miner, and that miner considers it the longest valid chain, that miner will attempt to build the next block on top of it. The only power an independent node has is to choose not to participate in forwarding the chain to other nodes or other miners.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
Neat; I feel better about my non-mining full node. I'm not crystal clear how much difference it makes but just feeling like I am contributing is nice. I would dearly like to be able to quantify my contribution but haven't a real clue how to start.
It helps. Most users don't run full nodes, that's the reality.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
Madjules and jbreher I think maybe you guys are talking past each other.
I think its a bit of semantics too:
You can say that non mining nodes don't add to the security of the network itself since anyone running they own node can verify for themselves what is the longest valid chain.... Yet at the same time , those that do run non mining modes add security for those folks who do not. Whether you call this 'network secuirty' or not is your choice.
I think its a bit of semantics too:
You can say that non mining nodes don't add to the security of the network itself since anyone running they own node can verify for themselves what is the longest valid chain.... Yet at the same time , those that do run non mining modes add security for those folks who do not. Whether you call this 'network secuirty' or not is your choice.
Quote
Proof-of-work is essentially one-CPU-one-vote
It's not one-user-one-vote. My nodes are simply enforcing the consensus rules that the rest of the network is, i.e. honest nodes. How is that gaming the system?
He's good at this.
...
I'm running nodes to keep the network decentralized.
...
I'm running nodes to keep the network decentralized.
...
Oy vey, a core sybil attack! Halp!
So, centralization endangers security and fungibility, but "the network would operate just fine" if validators were centralized into smaller and smaller groups that omitted the vast majority of the userbase? At what point does it become "too centralized?"
Move goalposts much? As long as there is the _ability_ for anyone to run a node (i.e. no regulatory or exclusionary barrier), I am unconcerned about any amount of node centralization. After all, independent nodes add zero value. They can always be routed around by any other network entities. They are essentially non-entities as far as the network is concerned.
How have I moved the goalposts? The whole point is that as block size has increased, the ability for anyone to run a node, on average, has decreased. We have reason to believe this will continue until bandwidth bottlenecks are mitigated.
You keep saying "independent nodes add zero value" but you've done nothing to prove it. How exactly can nodes simple be "routed" around? How does one discriminate among nodes that are enforcing the same consensus rules? When your node connects with other nodes, you can't control which nodes they connect to. Unless a single entity controls a majority of nodes in the network, independent nodes absolutely cannot be "routed around."
Again:
Perhaps you can explain to me -- in detailed fashion -- exactly what value you think it is that independent nodes provide? What task do they perform that cannot be countered? How exactly does their presence prevent nefarious action?
Here is a summary:
Quote
Every node must receive and process every transaction in every block. That distributes blockchain data to all nodes who enforce the rules, rather than a system where nodes trust a central source. [i.e. decentralization as a solution for the security faults of trust]
Quote
The more nodes that exist that are enforcing the same rules, the more likely the longest valid blockchain data that you receive from them is accurate.
Quote
If there are only mining nodes, the userbase, by definition, trusts miners. Hence why the existence of non-mining nodes secures bitcoin: by decentralizing hash power from validating nodes.
Quote
One of the primary determining factors in whether a Sybil attack is possible is how cheaply identities (nodes) can be generated. The more nodes there are, and the more decentralized said nodes are, the bigger the cost of mounting a Sybil attack, since attackers must set up more nodes in more distinct locations.
Quote
There have been past double-spend attacks by miners, so we know that rational miners will attack nodes if it is profitable to do so. That they have not used Sybil attacks specifically does not prove that it is not (and was not historically) possible to do so, but it certainly does not help your claim that non-mining nodes do nothing to secure the system. If they did nothing -- like padlocks on the lawn -- wouldn't that suggest it was cheap enough to attack them with Sybils?
Quote
Non-mining nodes obviously aren't impotent because we are talking about theoretical Sybil attacks, not historical ones.
In summation: Nodes enable a decentralized, trustless system to exist in the first place (securing users' funds from centralization failure). They are the system's defense against Sybil attacks (preventing double-spending and censorship attacks) from miners or other attackers. Further, nodes, by self-validating, also decrease the number and scope of attacks on users of the system by eliminating trust-based protocols.
Quote
Hash power is already highly centralized among a handful of pools; merchants almost entirely transact through two central processors (Bitpay and Coinbase); there are a handful of prominent exchanges and a couple handfuls more of dodgy, scammy ones. The network would run just fine if the entire userbase trusted these few entities to uphold the integrity of all transactions?
It doesn't matter whether or not we trust this small set. Any other nodes can be routed around.
Firstly, no, they can't be. Not unless an attacker can control who the network connects to (i.e. a Sybil attack). Secondly, this unfounded idea that all honest nodes can be trivially bypassed has nothing to do with the point I alluded to -- that node centralization introduces trust to the network by reducing redundancy and increasing reliance on a smaller group of validators.
But to answer your implied question, as long as transaction originators (i.e. exchanges, merchants, and wallets) are necessary nodes on the network, I expect their users will keep them honest. This does not omit the majority of the userbase, these entities are representative of the userbase.
Why should we trust that a business' customers will keep them honest? The whole point of having a network of peers propagating redundant information is that we don't need to place trust in Coinbase to be honest.
Bitcoin is P2P. We have no need for entities to "represent" us. The protocol does that for us. All we need to do is run nodes.
That's right. Bitcoin was conceived of as a trustless, P2P protocol. I'm beginning to wonder what coin you're talking about.
Quote
If the entire userbase stopped running nodes (save for this few dozen entities), are you suggesting that it would not be easier for say, a miner or a government, to mount a Sybil attack on the network?
Why don't you first explain to me why you think independent nodes provide any sort of protection from Sybil attacks? Actually, first, why don't you describe to me exactly what form of Sybil attack you are concerned about here?
Regarding the first question, see the summary I quoted above. Regarding the second:
https://en.bitcoin.it/wiki/Weaknesses
Quote
Honesty is not the issue here; network security is the issue.
Agreed. However, the Core SegWit Omnibus Changeset requires as much or more data transfer and storage by each fully validating node than does a simple 2MB bump. The necessary consequence of this is that using 'ZOMG centralization of the poor nodes' as a reason for Core SegWit Omnibus Changeset over simple 2MB is absolute twaddle.
How so? Operators that don't update their nodes out of bandwidth concerns aren't pressured to drop offline. Operators that update to Segwit see reduced fees by using less block space, and increased throughput by segregating signature data. That's the beauty of backwards compatibility and it's win-win for both capacity and decentralization.
Well, duh. We already have a solution for not-fully-validating wallets. Explain what you mean by 'externalizing the cost to all nodes' -- sounds an awful lot like 'trusting others to do the validation'. Care to explain how it differs?
If you're suggesting that SPV nodes are comparable to non-Segwit nodes, back up your claim. You keep suggesting that segregating signature data leads to trust issues. Signatures authorize TX outputs from the original owners. Notably, fully validating signature data means maintaining gigabytes of signatures that are buried under years of proof-of-work (Segwit also allows for pruning of this historical data). Signature data does not impact the TX ID; it has never been in the UTXO set; it's just a piece of data that is included with the TX hash. In other words, Segwit is optimizing transaction throughput by segregating the part of transactions that do not affect transaction validity (block validation will need to be addressed per the current architecture, though). And that's the case under the current rules. This aspect of Segwit is more akin to blockchain pruning than anything you're suggesting.
If you are suggesting a potential attack vector that exploits the segregation of signature data, please outline it. (crickets)
https://en.wikipedia.org/wiki/Cost_externalizing
Quote
I don't think anyone here is really arguing about disk space. But could you provide some evidence that "an insignificant proportion of current nodes will stop node-ing" if block size doubles? No data I've seen appears to support that, but maybe you could provide some.
Merely a rationally reasoned conclusion. Can you support an assertion to the contrary?
So... you cite no evidence.
I see you cite no evidence as well.
I guess you missed the quote below, as you conveniently ignored it. Statistical, logical and anecdotal evidence. We cannot "prove" why operators have persistently chosen to shut down their nodes as block size has steadily increased. But the point here is not proof. The point is that logically, and based on infrastructural bandwidth limits, bandwidth bottlenecks are a plausible cause that fits the correlation. As such, we need to plan for it. Engineering, particularly when dealing with large scale systems, is about planning for worst case scenarios... not assuming that nothing can ever go wrong. Proof of worst case scenarios does not exist until they occur.
Anyway:
For starters, there is a clear negative correlation between node health and block size. As average block size increases, average node count falls. This is a recurrent trend over past years.
Logically, since bandwidth is the only major infrastructural bottleneck for nodes, one could surmise that if bandwidth requirements were low enough, non-broadband -- mobile, dialup, ham radio, etc. -- users could operate a node, and further, that some would run nodes (after all, some users evidently still run nodes despite the availability of SPV). Conversely, as bandwidth requirements increase against a static bandwidth cap (as is commonly in place for cable customers), that decreases the bandwidth a user can allocate towards running a node or towards another bandwidth-heavy activity, increasing the likelihood that the node will simply be shut down for lack of resources. When only 25% in a highly industrialized country (the US) have fiber connections, it's prudent to assume that most people are limited to at best cable internet (frequently bandwidth-capped), and at worst non-broadband connections that prohibit users from running a node at all.
Given the persistent negative correlation between node health and growth in block size, and given that upload bandwidth is a measurable pressure on nodes who are known to have bandwidth limits (speed in the case of DSL and satellite, and total bandwidth consumed in the case of cable), we have good reason to believe that there is a causal relationship at work here between node health and growth in block size.
Anecdotally, many on this forum have echoed the sentiment -- as do I -- that bandwidth is the only pressure that has ever caused us to shut down our nodes. I was recently lucky enough to upgrade to a fiber connection, but as recently as a few months ago, I refused to run a node full-time due to being capped by Time Warner Cable. Further, the operation of VPS nodes (which we cannot realistically estimate the quantity of) is in theory problematic since these nodes are not physically controlled by the operator, causing us to question how much it really adds to decentralization in attack scenarios.
Logically, since bandwidth is the only major infrastructural bottleneck for nodes, one could surmise that if bandwidth requirements were low enough, non-broadband -- mobile, dialup, ham radio, etc. -- users could operate a node, and further, that some would run nodes (after all, some users evidently still run nodes despite the availability of SPV). Conversely, as bandwidth requirements increase against a static bandwidth cap (as is commonly in place for cable customers), that decreases the bandwidth a user can allocate towards running a node or towards another bandwidth-heavy activity, increasing the likelihood that the node will simply be shut down for lack of resources. When only 25% in a highly industrialized country (the US) have fiber connections, it's prudent to assume that most people are limited to at best cable internet (frequently bandwidth-capped), and at worst non-broadband connections that prohibit users from running a node at all.
Given the persistent negative correlation between node health and growth in block size, and given that upload bandwidth is a measurable pressure on nodes who are known to have bandwidth limits (speed in the case of DSL and satellite, and total bandwidth consumed in the case of cable), we have good reason to believe that there is a causal relationship at work here between node health and growth in block size.
Anecdotally, many on this forum have echoed the sentiment -- as do I -- that bandwidth is the only pressure that has ever caused us to shut down our nodes. I was recently lucky enough to upgrade to a fiber connection, but as recently as a few months ago, I refused to run a node full-time due to being capped by Time Warner Cable. Further, the operation of VPS nodes (which we cannot realistically estimate the quantity of) is in theory problematic since these nodes are not physically controlled by the operator, causing us to question how much it really adds to decentralization in attack scenarios.
Quote
Then you cite "rationality" as the basis for your claims, without explaining the rationale.
Waah. Where's your rationale?
That decentralization is paramount to any other concerns, and that increasing block size (under the current bandwidth requirements and limitations) will quite obviously increase node centralization -- the extent to which is unclear.
Whatevs. Anyone running a node today is quite evidently interested in bitcoin. After all, they've devoted more than three dollars worth of disk space to the activity. And enough bandwith to (almost) carry on a Skype conversation. I don't think such a person is going to be deterred from running a node just because the cost rises to six bux and change in disk, and a bit more bandwidth than a Skype conversation. That's my rationale.
Right, right. Nodes get chopped in half in a couple years and...no one could ever be deterred from running a node because...Skype.
But it really doesn't matter, as independent nodes add no value to the network (see above).
They do. (See above)
Quote
For starters, there is a clear negative correlation between node health and block size. As average block size increases, average node count falls.
If there's a point there, you're not making it. Coincidence does not imply causality. And your correlation is poor. Need more rigor if you're trying to claim causality here.
That's just dishonest of you. I stated the correlation, then went on to write three paragraphs laying out the statistical, logical and anecdotal evidence to suggest that there may be a case for causality. You simply ignored it. I re-quoted it above for you.
Since I've made quite an effort to provide evidence for causality, perhaps you could explain the negative correlation between node health and block size. Can you not even entertain the possibility that increasing bandwidth requirements deters the operation of nodes? If not, then at least formulate some sort of argument.
Quote
If miners could trivially bypass any nodes, that would suggest that a Sybil attack would be trivial to mount, correct?
Before I can either disagree or agree with your proposition, you are going to first have to define the characteristics of this Sybil attack of which you speak. Then you are going to have to explain to me why you think any independent node might prevent such an attack. Care to do so?
I've done so above. Rather, it's a robust network of nodes that defends against Sybils. The very basis of a Sybil attack is filling the network with nodes you control. The more honest nodes there are, the more difficult such an attack is to mount. This is very, very basic.
Or more germane, which part of my statement are you trying to refute, by ignoring it in favor of your own proposition? Do you disagree that any miner could implement their own forwarding node? Do you disagree that said miner could connect explicitly to specific nodes? Do you disagree that these other nodes might be owned by other miners? Do you disagree that these other miners might plausibly have the same game intent as others? Or that the cost of such node be essentially noise to an industrial mining operation? What else in my assertion could you possibly be disagreeing with?
I didn't ignore anything. I plainly laid out why your assertion that miners can simply "route around" any nodes they want and therefore attack the system as they please was ridiculous.
A miner can communicate with whoever they want. They can communicate with other miners, sure. Other miners may share the same intentions (though we could never assume that; they are competing entities). But past the first degree of contact -- said miners have zero control over whom the nodes they connect to, connect to. Unless an attacker physically controls a node, he cannot control who it connects to. The network effect among nodes prevents any such "bypassing" of nodes. They can't "route around" anything unless they control a majority of either hash power or nodes.
And the cost of running a node =/= the cost of mounting a Sybil attack.
Quote
--as they could simply bypass all honest nodes. Miners have carried out attacks in the past, so why not Sybil attacks? If it's so easy to bypass the entire decentralized node system, why aren't miners attacking the userbase for profit on that basis? If miners can trivially control most nodes, they can censor and double-spend all day until the cows come home. Yet.... this doesn't happen. Why?
Bullshit. But I'll first answer your questions - because it is not in their rational self interest.
Miners have carried out attacks in the past. Double spend attacks, withholding attacks. "But..... I thought they would never do that because of rational self-interest!!!" No. If an attack is profitable, a miner will carry it out. That's what logic says, that's what history says. Miners are fairly anonymous too; there is really no rational reason not to attack nodes or other miners if it is profitable to do so. After the attack, they can simply point their hashpower elsewhere, pools can shut down and reopen under new names, etc.
You trust miners far too much.
What proportion of miners do you think it is that does not broadcast to other miners? Do you understand that every hop in the chain adds latency, and thereby increases the chance that their block will be orphaned? In the light of this, why on earth would they trust the broadcast to some ad-hoc association of fly-by-night independent nodes, when they can broadcast directly to other miners? Or to the (oddly centralized) relay network?
I'm unsure why you're so obsessed with this idea of miners communicating with miners. Miners are not the only actors; nodes determine blockchain validity, not hashpower. Miners still need to propagate to the network; their blocks are still subject to validation by the every node in the network. You can keep telling yourself that some cabal of miners is responsible for validating the blockchain... but they answer to a much larger network of nodes that tells miners what is the longest valid blockchain:
I never said miners could control most nodes, I said that independent nodes are of no value in keeping miners in check.
That's because you fundamentally misunderstand why the inability for miners to control most nodes, by definition, prevents them from being able to mount certain attacks on the userbase.
Any given miner cannot truly censor any given transaction, when the next miner to solve a block might include the 'censored' transaction. No value in trying. And independent nodes would have no power to stop this anyhow. Each miner is the sole determinant of what transactions to include in any given block. What power does any node have to 'anti-censor'?
We're not only talking about miners. Governments, for instance, may have reason to launch censorship attacks. In a successful Sybil attack, it doesn't matter if another miner tries to include the censored transaction. If the attacker controls most nodes, he determines what transactions and blocks are valid or invalid to the rest of the network; he can simply render those blocks invalid.
Any given miner attempting to double-spend will find his double-spent transactions (thereby blocks) ignored by the rest of the mining network. Thereby losing his entire block reward. And independent nodes would have no power to stop this anyhow. Explain why you think otherwise?
Not if he has enough hashing power.
I'm not sure what kind of attack you're referring to. But as I've made the case for several times, the existence of nodes is the only defense against particular frauds based on a Sybil attack. If nodes were sufficiently centralized that an attacking miner could control the majority of nodes, the rest of the mining network is irrelevant. Again, hashpower is irrelevant to blockchain validity. The attacker can double spend all he wants, since he controls what the networks agrees is valid.
Quote
That miner you mention is also competing against all other miners to have his blocks validated by most nodes accepted by the next miner to mine a block, so the presence of honest nodes miners disincentivizes him from attempting any attack on that basis ... "Bypassing any set of independent nodes" is meaningless if most nodes miners on the network are still enforcing the same rules. Either the miner is honest and bypassing any nodes is a moot point, or the miner is dishonest and bypassing any nodes causes his blocks to be rejected (e.g. as with double-spends) if he does not control most nodes miners.
^FTFY. The miner that solves a block doesn't give a rat's ass about what other nodes think. His interest is to have the next miner to solve a block to build on the chain he already extended. Period. This is fundamental.
Okay, you can keep thinking that nodes don't exist and that hashpower rules all. The miner very much cares what other nodes think, since nodes determine whether to reject his block or not. You seem to believe that the "longest chain" is all the matters... but nodes enforce the longest, valid chain. Doesn't matter how many blocks a miner extends on top of an invalid block. It seems you're incapable of imagining any situation beyond everyday orphaned blocks. But we're talking about potential attack vectors and contentious hard forks here.
Quote
Ignoring hashpower-based attacks, I don't see any basis for your point unless this miner (or mining consortium) controls most nodes on the entire network, or sufficiently clusters Sybils in a given area sufficient to censor or double-spend transactions in that region. If he does not control most of the network, bypassing independent nodes accomplishes nothing.
There you go moving the goalposts again. The proposition under discussion is not whether it is in the interest of any miner to bypass independent nodes, it is that independent nodes add no ability to the network to keep miners in check. I have demonstrated above that there is nothing that independent nodes can do that any given miner cannot route around.
There you go with that misplaced goalposts phrase again. I'll make this one simple (and oversimplified):
Scenario A: 6000 nodes. It would take 6000+ nodes to mount a Sybil attack.
Scenario B: 100 nodes. It would take 100+ nodes to mount a Sybil attack.
Under which scenario are users more secure from attackers (miners or otherwise)? If the existence of nodes makes it more expensive or logistically difficult to mount a Sybil attack, that surely adds to the network's security.
But to hear you tell it, miners will never, ever attack anyone because it's not in their rational self-interest to do so.
You haven't demonstrated in the slightest that "any given miner" can "route around" any and all nodes.
A necessary corollary of this is that attempts to maximize independent node count is useless.
Please elaborate.
Quote
I don't think you've provided a modicum of evidence for #2.
And I don't think you've provided a modicum of evidence against it. I agree, simple reasoning is weak in the face of contrary evidence. Yet, I have not seen any contrary evidence yet - from you or other.
The difference is, I actually addressed this point and provided considerable evidence backing it up. And what did you do? You deleted all of it from your quotes and brushed it under the rug. Speaks volumes.
See near the top of the post, from "I guess you missed the quote below, as you conveniently ignored it."
Quote
Regarding #3, the utility of, and incentive to run[ning] a node are elusive but not non-existent.
We're not arguing about the incentive for an individual to run a node, we're arguing about whether or not independent nodes add any value to the network. I say no, and I think I've conclusively demonstrated so. I await your rebuttal.
Actually, we were talking about the incentive for an individual to run a node at the time. Likewise, I await your rebuttal.
Quote
Non-mining nodes are essential to maintaining the integrity and security of the protocol, and many on this forum including myself and David Rabahy above me, can attest to running nodes because we want the system to succeed and/or are invested in its success.
You may be running a node because you want bitcoin to succeed. I think your reasoning is incorrect. As far as David Rabahy, I certainly got the impression that he agreed with me that independent nodes add no value to the network.
I'm running nodes to keep the network decentralized.
Logically, hoarders have an incentive to keep the system robust and decentralized -- i.e. running a node, even if not transacting.
Me exactly.Quote
But the more you squeeze node operators, the less of us there will be.
While probably true, this is only relevant to #2, and I deny the assertion that doubling storage and bandwidth requirements provides a significant squeeze.
Deny all you want. Any basis for that, or just intuition?
Well, increasing the blocksize limit seems good to me. It seems trivial to get it right. Doing both seems ok to me but does contradict the wisdom of only making one change at a time. Can we change one and then a little later the other or is there some compelling reason to do them at the same time? One thing I wonder about is how to motivate miners to fill up blocks; partial blocks when there's a backlog is pretty dumb. Here's my thought; when a block is announced then look at the backlog and if the backlog is big enough then keep working on the pre-announced work trying to find a fuller block. Orphaning partial blocks motivates the miners to fill up the blocks. Full blocks will attract subsequent work and eventually build a longer chain. Everyone on the fuller (and hopefully longer) chain wins; everyone on chains with partial blocks lose....
Does not compute:
Probably. Which makes it A Good Thing that anyone who is concerned about such centralization is free to run a full node.
So, centralization endangers security and fungibility, but "the network would operate just fine" if validators were centralized into smaller and smaller groups that omitted the vast majority of the userbase? At what point does it become "too centralized?"
You seem to be suggesting that miners, merchants, and exchanges are the only entities (or people...) running nodes.
My claim is that the network would operate just fine without any but merchants, miners, and exchanges running a node. Independents add little to no value to the system. Further, as you acknowledge, there is no economic incentive for an independent to run a node.Quote
Would you agree that the entire economy depending on a single node for validation endangers security and fungibility?
Probably. Which makes it A Good Thing that anyone who is concerned about such centralization is free to run a full node.
So, centralization endangers security and fungibility, but "the network would operate just fine" if validators were centralized into smaller and smaller groups that omitted the vast majority of the userbase? At what point does it become "too centralized?"
Move goalposts much? As long as there is the _ability_ for anyone to run a node (i.e. no regulatory or exclusionary barrier), I am unconcerned about any amount of node centralization. After all, independent nodes add zero value. They can always be routed around by any other network entities. They are essentially non-entities as far as the network is concerned.
Perhaps you can explain to me -- in detailed fashion -- exactly what value you think it is that independent nodes provide? What task do they perform that cannot be countered? How exactly does their presence prevent nefarious action?
Classic increases the block size in a honest manner. Core increases the block size as well through chicanery. A fully validating node still needs signatures, so it's actual Max block size is anywhere from 1MB to ~4MB, depending upon how much multisig is in that block.
Honesty is not the issue here; network security is the issue.
Agreed. However, the Core SegWit Omnibus Changeset requires as much or more data transfer and storage by each fully validating node than does a simple 2MB bump. The necessary consequence of this is that using 'ZOMG centralization of the poor nodes' as a reason for Core SegWit Omnibus Changeset over simple 2MB is absolute twaddle.
Quote
I don't think anyone here is really arguing about disk space. But could you provide some evidence that "an insignificant proportion of current nodes will stop node-ing" if block size doubles? No data I've seen appears to support that, but maybe you could provide some.
Merely a rationally reasoned conclusion. Can you support an assertion to the contrary?
So... you cite no evidence.
I see you cite no evidence as well.
Quote
Non-mining nodes, by not trusting mining nodes and enforcing the protocol are integral to the integrity of the p2p system.
No, they are not. It is trivial for any miner to implement their own forwarding node, connecting explicitly to other miners which share their philosophy, completely bypassing any set of independent nodes.
If miners could trivially bypass any nodes, that would suggest that a Sybil attack would be trivial to mount, correct?
Before I can either disagree or agree with your proposition, you are going to first have to define the characteristics of this Sybil attack of which you speak. Then you are going to have to explain to me why you think any independent node might prevent such an attack. Care to do so?
Or more germane, which part of my statement are you trying to refute, by ignoring it in favor of your own proposition? Do you disagree that any miner could implement their own forwarding node? Do you disagree that said miner could connect explicitly to specific nodes? Do you disagree that these other nodes might be owned by other miners? Do you disagree that these other miners might plausibly have the same game intent as others? Or that the cost of such node be essentially noise to an industrial mining operation? What else in my assertion could you possibly be disagreeing with?
Summary [eta: still stands]:
1) 'Node Centralization' is no reason to choose between 1MB Core and 2MB other
2) Doubling block size will have negligible impact upon node count
3) In the end, nodes are negligible marginal utility anyhow.
1) 'Node Centralization' is no reason to choose between 1MB Core and 2MB other
2) Doubling block size will have negligible impact upon node count
3) In the end, nodes are negligible marginal utility anyhow.
With IBLTs and weak blocks, and after segwit, I'd be more confident in #1.
Good...
1) agreed; the debate is fees vs. adoption; I, for one, would rather delay the onset of fees in favor of adoption for now
2) agreed; with >5800 full nodes, I sincerely doubt all that many will be forced off the network unable to keep up
3) agreed; which is unfortunate; I, for one, would like to see non-mining full nodes paid at least a little bit
2) agreed; with >5800 full nodes, I sincerely doubt all that many will be forced off the network unable to keep up
3) agreed; which is unfortunate; I, for one, would like to see non-mining full nodes paid at least a little bit
As for me, I run a node because I am not gonna trust my Bitcoin to any other -- no way, no how. But this benefits me, not the network.
Quote
But the more you squeeze node operators, the less of us there will be.
While probably true, this is only relevant to #2, and I deny the assertion that doubling storage and bandwidth requirements provides a significant squeeze.
What kind of p2p network is this that miners, merchants, and exchanges are the only entities we expect to run nodes? Did I misread the whitepaper or are we talking about two different coins? SPV has its place but I don't agree that virtually the entire userbase of bitcoin should trust "miners, merchants, and exchanges" -- no matter how centralized they become -- to validate their transactions. In a sentence, that defeats the purpose of bitcoin.
There is a clear negative correlation between node health and block size. As average block size increases, average node count falls. This is a recurrent trend over past years.
Yes, there is no tangible economic benefit [to running a full node], hence the importance of curbing the primary disincentive to running a node -- bandwidth requirements.
Where's the upvote button?
There is a clear negative correlation between node health and block size. As average block size increases, average node count falls. This is a recurrent trend over past years.
Yes, there is no tangible economic benefit [to running a full node], hence the importance of curbing the primary disincentive to running a node -- bandwidth requirements.
Where's the upvote button?
Does not compute:
Probably. Which makes it A Good Thing that anyone who is concerned about such centralization is free to run a full node.
So, centralization endangers security and fungibility, but "the network would operate just fine" if validators were centralized into smaller and smaller groups that omitted the vast majority of the userbase? At what point does it become "too centralized?" Hash power is already highly centralized among a handful of pools; merchants almost entirely transact through two central processors (Bitpay and Coinbase); there are a handful of prominent exchanges and a couple handfuls more of dodgy, scammy ones. The network would run just fine if the entire userbase trusted these few entities to uphold the integrity of all transactions?
If the entire userbase stopped running nodes (save for this few dozen entities), are you suggesting that it would not be easier for say, a miner or a government, to mount a Sybil attack on the network?
Honesty is not the issue here; network security is the issue. Sure, a fully validating node still needs signatures. And in approaching the increased cost (upload bandwidth) of increased throughput, we can externalize the cost to all nodes or we can distribute the cost to those who are using it (and who can pay for it). Again, if you are suggesting this is a trust issue, can you outline a theoretical attack that exploits the signature chain?
Similar increase in throughput without externalizing the cost to all nodes and thereby causing the perpetual drop in nodes to continue.
Merely a rationally reasoned conclusion. Can you support an assertion to the contrary?
So... you cite no evidence. Then you cite "rationality" as the basis for your claims, without explaining the rationale. That's called an opinion, nothing more.
For starters, there is a clear negative correlation between node health and block size. As average block size increases, average node count falls. This is a recurrent trend over past years.
Logically, since bandwidth is the only major infrastructural bottleneck for nodes, one could surmise that if bandwidth requirements were low enough, non-broadband -- mobile, dialup, ham radio, etc. -- users could operate a node, and further, that some would run nodes (after all, some users evidently still run nodes despite the availability of SPV). Conversely, as bandwidth requirements increase against a static bandwidth cap (as is commonly in place for cable customers), that decreases the bandwidth a user can allocate towards running a node or towards another bandwidth-heavy activity, increasing the likelihood that the node will simply be shut down for lack of resources. When only 25% in a highly industrialized country (the US) have fiber connections, it's prudent to assume that most people are limited to at best cable internet (frequently bandwidth-capped), and at worst non-broadband connections that prohibit users from running a node at all.
Given the persistent negative correlation between node health and growth in block size, and given that upload bandwidth is a measurable pressure on nodes who are known to have bandwidth limits (speed in the case of DSL and satellite, and total bandwidth consumed in the case of cable), we have good reason to believe that there is a causal relationship at work here between node health and growth in block size.
Anecdotally, many on this forum have echoed the sentiment -- as do I -- that bandwidth is the only pressure that has ever caused us to shut down our nodes. I was recently lucky enough to upgrade to a fiber connection, but as recently as a few months ago, I refused to run a node full-time due to being capped by Time Warner Cable. Further, the operation of VPS nodes (which we cannot realistically estimate the quantity of) is in theory problematic since these nodes are not physically controlled by the operator, causing us to question how much it really adds to decentralization in attack scenarios.
No, they are not. It is trivial for any miner to implement their own forwarding node, connecting explicitly to other miners which share their philosophy, completely bypassing any set of independent nodes.
If miners could trivially bypass any nodes, that would suggest that a Sybil attack would be trivial to mount, correct?--as they could simply bypass all honest nodes. Miners have carried out attacks in the past, so why not Sybil attacks? If it's so easy to bypass the entire decentralized node system, why aren't miners attacking the userbase for profit on that basis? If miners can trivially control most nodes, they can censor and double-spend all day until the cows come home. Yet.... this doesn't happen. Why?
That miner you mention is also competing against all other miners to have his blocks validated by most nodes, so the presence of honest nodes disincentivizes him from attempting any attack on that basis unless he can profitably mount a Sybil attack. "Bypassing any set of independent nodes" is meaningless if most nodes on the network are still enforcing the same rules. Either the miner is honest and bypassing any nodes is a moot point, or the miner is dishonest and bypassing any nodes causes his blocks to be rejected (e.g. as with double-spends) if he does not control most nodes (failed Sybil attack).
Ignoring hashpower-based attacks, I don't see any basis for your point unless this miner (or mining consortium) controls most nodes on the entire network, or sufficiently clusters Sybils in a given area sufficient to censor or double-spend transactions in that region. If he does not control most of the network, bypassing independent nodes accomplishes nothing.
You seem to be suggesting that miners, merchants, and exchanges are the only entities (or people...) running nodes.
My claim is that the network would operate just fine without any but merchants, miners, and exchanges running a node. Independents add little to no value to the system. Further, as you acknowledge, there is no economic incentive for an independent to run a node.Quote
Would you agree that the entire economy depending on a single node for validation endangers security and fungibility?
Probably. Which makes it A Good Thing that anyone who is concerned about such centralization is free to run a full node.
So, centralization endangers security and fungibility, but "the network would operate just fine" if validators were centralized into smaller and smaller groups that omitted the vast majority of the userbase? At what point does it become "too centralized?" Hash power is already highly centralized among a handful of pools; merchants almost entirely transact through two central processors (Bitpay and Coinbase); there are a handful of prominent exchanges and a couple handfuls more of dodgy, scammy ones. The network would run just fine if the entire userbase trusted these few entities to uphold the integrity of all transactions?
If the entire userbase stopped running nodes (save for this few dozen entities), are you suggesting that it would not be easier for say, a miner or a government, to mount a Sybil attack on the network?
Classic increases the block size in a honest manner. Core increases the block size as well through chicanery. A fully validating node still needs signatures, so it's actual Max block size is anywhere from 1MB to ~4MB, depending upon how much multisig is in that block.
Honesty is not the issue here; network security is the issue. Sure, a fully validating node still needs signatures. And in approaching the increased cost (upload bandwidth) of increased throughput, we can externalize the cost to all nodes or we can distribute the cost to those who are using it (and who can pay for it). Again, if you are suggesting this is a trust issue, can you outline a theoretical attack that exploits the signature chain?
Because core requires as much or more data transfer and storage as does classic, as per proportion of multisig.
Similar increase in throughput without externalizing the cost to all nodes and thereby causing the perpetual drop in nodes to continue.
Quote
I don't think anyone here is really arguing about disk space. But could you provide some evidence that "an insignificant proportion of current nodes will stop node-ing" if block size doubles? No data I've seen appears to support that, but maybe you could provide some.
Merely a rationally reasoned conclusion. Can you support an assertion to the contrary?
So... you cite no evidence. Then you cite "rationality" as the basis for your claims, without explaining the rationale. That's called an opinion, nothing more.
For starters, there is a clear negative correlation between node health and block size. As average block size increases, average node count falls. This is a recurrent trend over past years.
Logically, since bandwidth is the only major infrastructural bottleneck for nodes, one could surmise that if bandwidth requirements were low enough, non-broadband -- mobile, dialup, ham radio, etc. -- users could operate a node, and further, that some would run nodes (after all, some users evidently still run nodes despite the availability of SPV). Conversely, as bandwidth requirements increase against a static bandwidth cap (as is commonly in place for cable customers), that decreases the bandwidth a user can allocate towards running a node or towards another bandwidth-heavy activity, increasing the likelihood that the node will simply be shut down for lack of resources. When only 25% in a highly industrialized country (the US) have fiber connections, it's prudent to assume that most people are limited to at best cable internet (frequently bandwidth-capped), and at worst non-broadband connections that prohibit users from running a node at all.
Given the persistent negative correlation between node health and growth in block size, and given that upload bandwidth is a measurable pressure on nodes who are known to have bandwidth limits (speed in the case of DSL and satellite, and total bandwidth consumed in the case of cable), we have good reason to believe that there is a causal relationship at work here between node health and growth in block size.
Anecdotally, many on this forum have echoed the sentiment -- as do I -- that bandwidth is the only pressure that has ever caused us to shut down our nodes. I was recently lucky enough to upgrade to a fiber connection, but as recently as a few months ago, I refused to run a node full-time due to being capped by Time Warner Cable. Further, the operation of VPS nodes (which we cannot realistically estimate the quantity of) is in theory problematic since these nodes are not physically controlled by the operator, causing us to question how much it really adds to decentralization in attack scenarios.
Quote
Intelligent miner =/= honest miner. Non-mining nodes reflect the interests of non-mining users, serving as a check on the power of miners. Non-mining nodes, by not trusting mining nodes and enforcing the protocol are integral to the integrity of the p2p system.
No, they are not. It is trivial for any miner to implement their own forwarding node, connecting explicitly to other miners which share their philosophy, completely bypassing any set of independent nodes.
If miners could trivially bypass any nodes, that would suggest that a Sybil attack would be trivial to mount, correct?--as they could simply bypass all honest nodes. Miners have carried out attacks in the past, so why not Sybil attacks? If it's so easy to bypass the entire decentralized node system, why aren't miners attacking the userbase for profit on that basis? If miners can trivially control most nodes, they can censor and double-spend all day until the cows come home. Yet.... this doesn't happen. Why?
That miner you mention is also competing against all other miners to have his blocks validated by most nodes, so the presence of honest nodes disincentivizes him from attempting any attack on that basis unless he can profitably mount a Sybil attack. "Bypassing any set of independent nodes" is meaningless if most nodes on the network are still enforcing the same rules. Either the miner is honest and bypassing any nodes is a moot point, or the miner is dishonest and bypassing any nodes causes his blocks to be rejected (e.g. as with double-spends) if he does not control most nodes (failed Sybil attack).
Ignoring hashpower-based attacks, I don't see any basis for your point unless this miner (or mining consortium) controls most nodes on the entire network, or sufficiently clusters Sybils in a given area sufficient to censor or double-spend transactions in that region. If he does not control most of the network, bypassing independent nodes accomplishes nothing.
Summary:
1) 'Node Centralization' is no reason to choose between 1MB Core and 2MB other
2) Doubling block size will have negligible impact upon node count
3) In the end, nodes are negligible marginal utility anyhow.
1) 'Node Centralization' is no reason to choose between 1MB Core and 2MB other
2) Doubling block size will have negligible impact upon node count
3) In the end, nodes are negligible marginal utility anyhow.
With IBLTs and weak blocks, and after segwit, I'd be more confident in #1. For now, the trend in node health gives cause to be wary of putting any unnecessary pressure on bandwidth. In reality, the biggest reason to choose between 1MB Core and 2MB Classic (that is the only option based on released software) is that a hard fork implemented without miner consensus is very likely to permanently break bitcoin into multiple ledgers. I don't think you've provided a modicum of evidence for #2. Regarding #3, the utility of, and incentive to run[ning] a node are elusive but not non-existent. Non-mining nodes are essential to maintaining the integrity and security of the protocol, and many on this forum including myself and David Rabahy above me, can attest to running nodes because we want the system to succeed and/or are invested in its success. But the more you squeeze node operators, the less of us there will be.
You seem to be suggesting that miners, merchants, and exchanges are the only entities (or people...) running nodes.
Not at all. Indeed, I am neither a miner, merchant, nor exchange, yet I run a full node. My claim is that the network would operate just fine without any but merchants, miners, and exchanges running a node. Independents add little to no value to the system. Further, as you acknowledge, there is no economic incentive for an independent to run a node.That canard has no place in a 'core vs classic' compariso.
It does, as one team has just released node software to increase the block size limit.
Fact is, any fully validating core node with the SegWit Omnibus Changeset implemented will need the signatures in order to validate. The fact that they have been repartitioned into a separate chain means nothing to such a node - it still needs the signatures in order to validate. Accordingly, The SegWit Omnibus Changeset is as big a disincentive to operating a node than is classic.
How, specifically, is this as big of a disincentive to operating a node as Classic?
Because core requires as much or more data transfer and storage as does classic, as per proportion of multisig.
But it's really kind of irrelevant - as has been pointed out, an insignificant proportion of current nodes will stop node-ing simply because the disk space required goes up from $3.09 worth to $6.18 worth, nor if they need to go from 10 MB upload every 10 min to 20 MB upload every 10 minutes.
I don't think anyone here is really arguing about disk space. But could you provide some evidence that "an insignificant proportion of current nodes will stop node-ing" if block size doubles? No data I've seen appears to support that, but maybe you could provide some.
Merely a rationally reasoned conclusion. Can you support an assertion to the contrary?.
But it is still really kind of irrelevant - the dirty little secret is that independent nodes essentially fulfill zero marginal utility. Sure, every node validates transactions. Guess what - so does every intelligent miner. They would not risk building a block that has a transaction included that would be rejected by the rest of the network.
Intelligent miner =/= honest miner. Non-mining nodes reflect the interests of non-mining users, serving as a check on the power of miners. Non-mining nodes, by not trusting mining nodes and enforcing the protocol are integral to the integrity of the p2p system.
No, they are not. It is trivial for any miner to implement their own forwarding node, connecting explicitly to other miners which share their philosophy, completely bypassing any set of independent nodes.
Summary:
1) 'Node Centralization' is no reason to choose between 1MB Core and 2MB other
2) Doubling block size will have negligible impact upon node count
3) In the end, nodes are negligible marginal utility anyhow.
[/quote ]
1) 'Node Centralization' is no reason to choose between 1MB Core and 2MB other
2) Doubling block size will have negligible impact upon node count
3) In the end, nodes are negligible marginal utility anyhow.
[/quote ]