Gold collapsing. Bitcoin UP.

[albin]

On the free-market tip, I sometimes wonder if the small-block obsession with over-engineering the resource cost of a full node is actually a kind of subsidy to the non-mining full node operator.

In a free-market context, the decision to run a full node is going to be voluntary and based on the utility of having that full node versus the cost of using computer and bandwidth resources.

Based on Metcalfe value, yadda yadda yadda, wouldn't it be plausible to infer that as Bitcoin adoption increases, the utility of having a node should also? Right now, running a non-mining node is mainly a hobbyist curiosity (or act of principled altruism) unless you're specifically running some kind of Bitcoin business or service. In a world where Bitcoin is say a major method of ecommerce payment, or international b2b settlement, or any number of significant use cases, wouldn't having a non-mining full node be orders of magnitude more valuable than right now?

Why does paranoia that full nodes might decrease demand that system design economically coddle operators? Isn't the greatest threat to node count that nobody ends up finding Bitcoin useful in the long run?

 

[Melbustus]

In a world where Bitcoin is say a major method of ecommerce payment, or international b2b settlement, or any number of significant use cases, wouldn't having a non-mining full node be orders of magnitude more valuable than right now?

Yes. I think @Justus Ranvier is right that a market for node services should and will develop eventually: https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/

Isn't the greatest threat to node count that nobody ends up finding Bitcoin useful in the long run?

Yes, absolutely.

 

[cypherdoc]

@albin

you're asking good questions. you'd think the answers would be obvious.

i'm fond of asking the question, which is more valuable? a system of 100K nodes and 1B users or one with 100K users and 1B nodes? miniblockists love to scoff at that question by criticizing the numbers but to many of us it should be obvious. it's the directional ratio that is important afaic, with nodes supporting a great many more users worldwide. that's just the way it's always been in Bitcoin but you'd think the way guys like LukeJr talk, you'd guess he might rather see 100K users and 1B nodes.

 

[AdrianX]

Completely agree; however, I see this as elegant. You said "the network incentives (orphan risk) regulate blocksize but then also nodes do, too" and you referred to this as "duplicative." I see the actions of nodes as a cohesive part of what defines what the orphan risk actually is. The curve that describes the probability of orphaning versus block size will thus be partly a result of technical limitations (bandwidth, latency, etc.) and partly an emergent phenomenon based on the transport rules (for large blocks) that each node implements individually.

OK I'm warming up to the idea. if the majority of node support restricted blocks that will result in fee pressure that goes to the miners. (previously I felt it's just the technical limitation of nodes that should limit block size) now I see that there may be some benefit in that nodes can voluntarily limit block size to increase network fees, I've yet to fully understand how this impacts the incentive schema or why its good, but I'm open to the idea none the less.

What are the benefits of this behavior thinking long term?

 

[cypherdoc]

someone help me here.

is there a short term effective way to deal with an exablock sprung on the network by a malicious miner? or is it reasonable to think this is an attack scenario that just won't happen?

it would have to be a gvt or bank that invests in a small mining farm in hopes of generating this attack block even if it had to wait months to find it. or would this attacker conclude that there is a cheaper more effective way to disrupt Bitcoin?

 

[AdrianX]

a massive block could be accepted if it's mined on top of. the real inconvenience is to the nodes who have to store it. if other blocks are added after it it's not a successful attack, if no one can build on top of it in time it doesn't propagate and everyone but the attacker is better off. If just headers are used in a relay type network it would be possible to jam up transactions until miners decided to orphan the chain built on top of it.

I'm binning to like IBLT it may be possible to optimize blocks that have a larger size but contain many transactions -v- those blocks equal in size that have few transactions but store books in transactions like the books Luke-jr encoded in to the blockchain, that way optimizing blocks for mempool relief, relative to block size and orphaning risk.

 

[Peter R]

"you'd think the way guys like LukeJr talk, you'd guess he might rather see 100K users and 1B nodes."

From what I've seen from his writing, he doesn't differentiate between users and nodes. I believe he considers himself to be a "node" for example and views people not running Bitcoin Core to not be participants of Bitcoin. As for me, I view users as entities (I define an entity as something with volition) and I view nodes as computer systems operated by certain users.

Personally, I don't think it is important to have a large number of nodes. As long miners and certain other groups are running nodes (e.g., payment processors, university labs, governments, Bitcoin whales, etc.), and as long as I can poll multiple nodes for data, then I don't see how running my own node really gives me any more security. What matters is that I have the option to run a node should I become worried that the other nodes are lying to me.
[doublepost=1447202809][/doublepost]

someone help me here.

is there a short term effective way to deal with an exablock sprung on the network by a malicious miner? or is it reasonable to think this is an attack scenario that just won't happen?

it would have to be a gvt or bank that invests in a small mining farm in hopes of generating this attack block even if it had to wait months to find it. or would this attacker conclude that there is a cheaper more effective way to disrupt Bitcoin?

That's what the meta-cognition stuff was for that we were discussing several weeks ago. Nodes would still have their own block size limit, but they would accept an "excessive" block only once it was buried at a certain depth. The exablock would need to be buried so deeply in the longest chain that it would simply never be accepted.

 

[cypherdoc]

@Peter R

Personally, I don't think it is important to have a large number of nodes. As long miners and certain other groups are running nodes (e.g., payment processors, university labs, governments, Bitcoin whales, etc.), and as long as I can poll multiple nodes for data, then I don't see how running my own node really gives me any more security. What matters is that I have the option to run a node should I become worried that the other nodes are lying to me.

i totally concur with this viewpoint.

The exablock would need to be buried so deeply in the longest chain that it would simply never be accepted.

can you expound on the mechanism of why this wouldn't happen?

 

[Peter R]

"can you expound on the mechanism of why this wouldn't happen?"

Sure, but I'll need to give some background first...

Imagine that all nodes and miners have the ability to easily set their own block size limits and communicate what those limits are to the rest of the network. I think most of us agreed that we'd see a "spontaneous consensus" around a certain limit--let's say 8 MB--with some nodes accepting 16 MB, 32 MB, etc. With that information known, no miner would dare to publish a block greater than 8 MB as it would most certainly be rejected. The situation would be nearly what it is today except with a higher limit (8 MB).

The problem comes when we start approaching the new 8 MB limit. What we'll see is more and more nodes signalling acceptance of blocks up to 16 MB instead. There will be a brief moment during this "consensus phase change" when a malicious miner could attempt to split the network by publishing a block that was 8.1 MB. That would be bad (although not the end of the world).

To solve this "network split attack," we had discussed the idea that it's more important for a node to track consensus than dogmatically adhere to an arbitrary limit. To track consensus then, the nodes that haven't increased their limits yet would still fork over to the chain that contains the 8.1 MB block as soon as it was, for example, 1 or 2 blocks deep in what had become the longest chain.

So how would an exablock ever get included in the blockchain? The only way I could conceive of it happening is if the attacker also mined, for example, hundreds of blocks on top of the exablock and convinced all these other miners and nodes to accept it, somehow fooling them into thinking that consensus was legitimately with the chain that contained the exablock. I don't see that ever happening.

 

[Justus Ranvier]

Imagine a node that has two conflicting priorities:

1. They want to know the current state of the best chain
2. They want to minimize their storage costs.

Depending on how strong their preference for 2 is relative to 1, they might hold off accepting and relaying a particular block when they would have relayed a smaller block in the hopes that somebody will orphan the larger block.

If the rest of the network does not agree with them and nobody orphans the large block, at some point their preference for 1 will override 2 and they'll concede.

This works until blocks have been shrunk into constant size header announcements, at which point the same effect could play out but at the granularity of individual transactions rather than blocks.

 

[cypherdoc]

@Peter R
ok, that's interesting b/c i thought we had discussed how full node BU owners would be shipped a default limit of infinity (or very, very high) and how most would leave it there. instead, you foresee a way for an entity like Bitnodes to monitor an initial freely chosen average limit which you conclude might start off being around 8MB. why would node owners set this level initially?

 

[Peter R]

I originally wanted the limit to default to 8 MB

Anyways, I think the result would be the same regardless of what the defaults were, because node operators and miners aren't zombies and would adjust them as necessary to keep the network healthy. I think an infinite default is fine too. What I cared most about was making it easy for node operators to control their own limits.

 

[Peter R]

I should add that even if every node and miner had an extremely high limit (say 1 GB), that the probability of having a very large block orphaned is so high that the attacker would have to try hundreds or thousands of times before one "stuck" (losing 25 BTC each time it failed). The chart below (from my fee market paper) shows the cost for an attacker to publish a large spam block versus the network propagation impedance. My hunch is that the propagation impedance is presently around 7 sec / MB, meaning that it would cost about 10,000 BTC to publish a 512 MB block in the "no limit" case.

 

[cypherdoc]

@Peter R

you better check to see i got this right:

 

[theZerg]

@Peter R
i totally concur with this viewpoint.
can you expound on the mechanism of why this wouldn't happen?

Yes the freedom is more important than the actuality. I, you and everyone else have the freedom to modify Linux and Android OS but how many of us actually do? Very few... but when we do we absolutely need to and need to do it NOW.

People always argue "you can run a home node b/c you live in the US of A and have awesome infrastructure, etc etc..." but what about other people. And I have replied "If they REALLY needed a full node, they could band together with 10-50 similar individuals and afford one."
[doublepost=1447208237][/doublepost]WRT the withheld block attack. The answer is simple and exactly the sort of real life situation that theory does not capture:

I can sell the block to the excluded miners, and nobody will know who did it.

 

[AdrianX]

@Peter R
ok, that's interesting b/c i thought we had discussed how full node BU owners would be shipped a default limit of infinity (or very, very high) and how most would leave it there. instead, you foresee a way for an entity like Bitnodes to monitor an initial freely chosen average limit which you conclude might start off being around 8MB. why would node owners set this level initially?

Maybe they would set it at 8MB to avoid a spam attack. Are we not back to the same situation where a spammer can force feed up because there is a block size limit?

 

[cypherdoc]

@AdrianX

i'm not worried about spammers b/c i think the network can bankrupt a spammer thru harvesting his fees. it's the self constructed block from an attacking miner that creates a huge # tx's to pay himself with the fees looking to disrupt the network with an exablock that bothers me.

in @Peter R's example of a soft limit @8MB, a spammer couldn't really force higher fees cuz nodes can keep elevating their limits to accomodate the paying spam.

 

[theZerg]

AdrianX who is "they" in your comment? There is no "they". Instead we are "herding cats". People will be at 8, 16, 64 and many points inbetween. In a spam attack many people might temporarily jack their limit up. Or they might choose to drop these txns from their mempool. Or a few miners/ pool operators might collude temporarily to consume it all in a few blocks and pull the rest of the network temporarily along because they follow the longest chain. Whatever response makes sense at the time.

The point is that rather then it be some gigantic network wide discussion, patch, and deployment to come up with an appropriate response the kernel of a solution could germinate from just a few nodes and then spread out (if and only if it is acceptable to the rest). This "free market" approach gives the network flexibility.

This is basically the difference between a "tightly coupled" and "loosely coupled" distributed system. Bitcoin needs to recognize that it is the latter if it is going to evolve and survive. I can run whatever I want and you can't stop me, so we might as well take advantage of that fact instead of let it hinder us.

Right now, for example, I've got a prototype BU node taking advantage of the XT testnet excitement going on.

 

[Melbustus]

...
People always argue "you can run a home node b/c you live in the US of A and have awesome infrastructure, etc etc..." but what about other people. And I have replied "If they REALLY needed a full node, they could band together with 10-50 similar individuals and afford one."
...

...
Personally, I don't think it is important to have a large number of nodes. As long miners and certain other groups are running nodes (e.g., payment processors, university labs, governments, Bitcoin whales, etc.), and as long as I can poll multiple nodes for data, then I don't see how running my own node really gives me any more security. What matters is that I have the option to run a node should I become worried that the other nodes are lying to me.
...

I would distill the above and define what's important as: "People need the ability to affordably obtain credible blockchain-state information". I agree that is NOT synonymous with "everyone should always be able to trivially run their own fully-validating-of-every-tx node on their personal hardware". I think this is a critical fundamental disagreement between large- and small-blockers, or just that small-blockers aren't thinking it through reasonably.

 

[AdrianX]

yes "they" is a herd of cats with nodes set to 8, 16, 64 and many points in-between.
[doublepost=1447212229][/doublepost]

I would distill the above and define what's important as: "People need the ability to affordably obtain credible blockchain-state information". I agree that is NOT synonymous with "everyone should always be able to trivially run their own fully-validating-of-every-tx node on their personal hardware". I think this is a critical fundamental disagreement between large- and small-blockers, or just that small-blockers aren't thinking it through reasonably.

I've also had small blockest tell me the network of nodes is practically reverent saying it's only mining nodes that are relevant.

I'd say there are some very diverse opinions on how people think bitcoin works, how it actually works, how the code is programmed to work, how the incentives work, how the incentives are designed to work.