> For running a full node, a VPS costing $12 - $15 USD
So your solution to centralization pressures is to use a centralized service for decentralization?
> You are talking about bandwidth and the numbers are simple to calculate and come out to trivial amounts.
I provided more evidence on the bandwidth requirements than your incomplete understanding of how bitcoin works multiplied by your flawed opinion.
> 2. Bitcoin is literally working right now with 0 hiccups except for full blocks and high fees.
No-one is forcing you to use it. There are a multitude of other options if you feel that bitcoin isn't meeting your use-case.
> You say hand waving while not backing up a single thing you've said
I provided evidence that backed up my opinion. You should try it.
> This is about how ridiculous the 1MB limitation is, you can try to divert from that, but lets see you confront it.
Nah. You can use another service if you feel that the 10's of thousands of nodes somehow don't have a better understanding of the constraints of running a node than you. No-one is holding a gun to your head. Ever heard of Bitcoin Cash? Perhaps that might better suit your needs.
> I provided more evidence on the bandwidth requirements than your incomplete understanding of how bitcoin works multiplied by your flawed opinion.
No, you didn't. You didn't confront my numbers for syncing, you for some reason think the option to pay for a cheap VPS to run a node is centralization. You also seem to that a single node is uploading to 8 people at all times, no more, no less not to mention that your assertion revolves around thinking that 48KB/s to run a full node is a lot when hundreds of millions of people can do that now with their home internet connections, not to mention buisnesses. Kids are running around streaming live video from their phones, how can you cling to such nonsense and why won't you confront it directly?
> No-one is forcing you to use it. There are a multitude of other options if you feel that bitcoin isn't meeting your use-case.
So instead of confronting these absurd statements, you say 'then don't use it'. This is about whether what you are saying makes sense and so far I haven't seen anything more than trying to avoid the simple numbers that make the answer obvious.
> I provided evidence that backed up my opinion. You should try it.
I'm not really sure what you want or how you can say that. I've broken down the numbers for you in terms of bandwidth, people that have access to that bandwidth, previously running systems, and widespread use cases of other technology that already uses more resources.
> Nah. You can use another service if you feel that the 10's of thousands of nodes somehow don't have a better understanding of the constraints of running a node than you. No-one is holding a gun to your head. Ever heard of Bitcoin Cash? Perhaps that might better suit your needs.
So anyone who can do simple math and questions bizarre statements should 'go somewhere else' ?
> I said it depends on how many people are connected and that it is such a trivial amount that it barely matters.
And I provided evidence that contradicts that unfounded belief.
> How is -one option- to running a full node by paying for a cheap VPS centralization in any respect?
If you have to explain that, you don't even have a concept of what decentralization means.
> why don't you explain how there is so much torrent traffic zipping
Because people don't care if their torrent takes a few hours to download, where in a multi-agent system with rigorous consensus rules, it's important that nodes are aligned as quickly as possible, because bitcoin block-propagation is an adversarial system that leads to orphaning, and potential loss of funds, when nodes aren't aligned. Yet again, to have to explain this O.o
You really don't understand this bitcoin thing at all. Like at all.
> with your comparison to YouTube, is completely incorrect
Not for syncing. For running a full node, a VPS costing $12 - $15 USD per month has orders of magnitude more bandwidth. I already have you the math of full 8MB blocks, there is no way you can say that these aren't trivial bandwidth numbers.
> What I've found in the past is the people who hold your views are only cursorily aware of the constraints of decentralization, and use unrelated justifications in order to hand wave away problems.
That's big talk when:
1. You are talking about bandwidth and the numbers are simple to calculate and come out to trivial amounts.
2. Bitcoin is literally working right now with 0 hiccups except for full blocks and high fees. The people working on it right now didn't do that, they kicked out the people who did.
3. You say hand waving while not backing up a single thing you've said or confronting what I've said. 8MB block when 100% full takes 13KB/s to sync. Is that wrong? Twitch streams are 250KB/s. Most people don't even want to or need to sync.
> But you can now prove me wrong! Instead of using bitcoin, use bitcoin cash.
This is about how ridiculous the 1MB limitation is, you can try to divert from that, but lets see you confront it.
>Layer 1 scaling is poor design. Larger blockchain = less nodes due to more expensive hardware requirements = more centralization.
>A $10/month VPS will have a 1 gigabit connection.
>Larger blocks = more bandwidth and hd space = more time to download and fully validate.
>You originally said it was all about bandwidth before being proved wrong with how absurd that idea is. Now it's "cloud hosting" even though people are running nodes off of raspberry pis and cable modems.
If you continuously misrepresent what was said a few posts ago then I can tell this conversation is going nowhere and is a waste of time. You were the one that brought up vps pricing and hosting.
I will move on now since it is clear you are out of your depth but good luck trying to change bitcoin. Just know there is good reason nobody will adopt your shortsighted ideas regardless of where you post them, reddit or elsewhere.
> Those are with present numbers which have the 1MB limit in place. Clearly those assumptions won't hold if we have much larger blocks.
There is a lot of head room. Anyone can see this. Ten years of transactions has taken up $6 of hard drive space TOTAL while the average fee PER TRANSACTION is almost $9 right now.
> Sounds like you're not denying the anti-decentralization aspect at all, but rather arguing that it doesn't matter.
That's ridiculous. Decentralization is important and none of this has much effect on decentralization at all. You haven't actually explained why there would be any problem with decentralization because you can't. There is no barrier to entry for anyone who wants to sync with any chain so they can mine it or accept it.
> Specifically "Assume good faith".
Say something reasonable that isn't contradicted by grade school math. You haven't backed up anything you have said with anything that makes sense.
> I don't get it which numbers are made up?
Correct, you don't get it. Your idea that someone has to spend $450 on what would be 24TB is nonsense.
Why don't you explain to me what exactly you think will happen if throughput is more than a few transactions per second? Ethereum already exceeds bitcoin's volume. Bitcoin Cash tested huge blocks years ago, what exactly do you think will happen and why? Maybe you just don't want people to realize that there is no systemic reason for bitcoin being capped, because if they do it will become a relic.
>No, large transaction volumes aren't going to be an issue either way.
elaborate?
>This makes zero sense. Anyone can choose whatever combination of whatever they want and most people never touch the normal chain. This is the reality right now, there are lots of choices, people can use any or all of them. Why would transaction volumes change any of this?
It makes zero sense because I was trying to infer your argument. Let's try again then: what does having multiple chains have to do with scalability?
>That makes absolutely no sense at all. A full node for every crypto currency can be run on a $35 raspberry pi with a hard drive hooked up by anyone that can watch a youtube video. Your numbers are just a lie, the entire bitcoin chain is 1/25th of an 8TB hard drive which can be bought new for $150 USD.
Those are with present numbers which have the 1MB limit in place. Clearly those assumptions won't hold if we have much larger blocks.
>Then it's a good thing that isn't true, since most people never touch it and those that do probably don't have to spend anything at all.
Sounds like you're not denying the anti-decentralization aspect at all, but rather arguing that it doesn't matter.
>These are lies, there is no truth to what you are saying and you know it.
> If there was any validity you would have a better explanation than made up numbers and nothing else.
I don't get it which numbers are made up? The $90/year figure came from a sibling comment that was discussing the hypothetical storage requirement for bitcoin if it processed half of visa's transaction volume. That was surprisingly close to the annual electricity cost for the best selling refrigerator on bestbuy.com[1], so that's what I assumed you were talking about when it comes to costs. If you don't agree with these numbers, feel free to present your calculations.
> > The larger issue is that some of the core developers don't want to scale Bitcoin at all. They would rather have a more decentralized, less widely used Bitcoin.
> do you think 13KB/s AT MOST is too much for your internet connection
You've quoted this number many times now, and it is completely incorrect. The upload bandwidth required for a full node with eight peers is an absolute minimum of 0.39mbps/mb of block size.
The things you're saying are the kind of things that people who really don't have any clue of the resources required by a node would say. In fact, it's pretty clear you don't run a node, have never run a node, and will never run a node. So your opinion as to the security requirements of bitcoin should be viewed in that context.
> Decentralization refers to being able to use money electronically without any third party's permission.
Decentralization refers to many things, it depends on the discussion. I explained the scope of my statements in the parent.
> Non mining nodes...All they can do is relay blocks that the miner decide.
You are wrong here, they also do validation which is why its important for wallet owners and services to run their own nodes even if they dont mine.
>Do you ever stop to think about why other cryptocurrencies don't need a second layer?
Yes, it is because they are highly centralized chains that might as well run on sql and/or ghost chains with no users.
>Do you think the optimal throughput is a few kilobytes per second worth of transactions for the whole world?
Yes, offchain transaction batching is a good scaling strategy. Satoshi recommended it as a solution.
>Have you ever done the math on this?
Yes, bitcoin full nodes are much cheaper to host on a vps than ethereum full nodes for that reason. Larger blocks = more bandwidth and hd space = more time to download and fully validate. I assure you, running one costs a lot more than 10$/month. Perhaps you should check the math on your claim.
>Maybe you should think about who the 'layman' is here.
Its pretty clear by the sidestepping and bad calculations in your responses.
> Blocks take fractions of a second to verify.
We were talking about spinning new nodes, why move the goal posts to make yourself sound reasonable? 10-100x the time it takes to download and fully validate 700,000 blocks in the big block world you want.
>I did all the math for you, you still have no evidence.
Cloud hosting 10-100x (5-50TB) is not a one time $70 cost, not even close. Youre doing bad math.
It's silly and we havent even touched the hardware update frequency required to store the volume of onchain spam this would introduce.
You may be out of your depth in this discussion. High degree of node centralization would be the outcome of the parameters you are proposing. I'm not surprised your posts get deleted from subreddits. Based on your description, the admins seem to expect users to think about 2nd order effects before posting.
>>I have a whole section on available machine resources which cites a ton of sources.
Maybe I'm just terrible at reading comprehension, but I don't see anything at all in the places you mention explaining why your assumption is that Bitcoin needs 90% of the world being able to run a full node for the network to remain safe from an attack. Can you actually copy-paste an excerpt from the analysis that explains this assumption?
>>How do you know how much on-chain space is needed by a full world of users? What assumptions do you make there?
I don't think I even have to provide a detailed analysis to make a high confidence claim that Bitcoin limited to 3 transactions per second cannot be used by the vast majority of the world population. I can't get mired down in over-analysis of every point we can already grant from a common sense deduction, as that will result in me not being allowed to even criticize your central assumptions due to be over-burdened by the analysis requirement.
>>Are you someone that thinks the lightning network won't scale and so all transctions must be on-chain?
The assumption that the lightning network will even work is extremely speculative, and the burden is on those making this assumption to support it, not on me to support the idea that it won't. There is no compelling reason to believe that an experimental network with extremely low adoption levels will ever prove highly useful, and gain widespread usage.
>>Instead it chooses goals and finds what requirements satisfy those goals.
Your paper suggests that Bitcoin can't scale to the point where less than 90% of the world population can run a full node using only 10% of hardware and network resources they already own, and remain safe from network attack, and not merely that it can't scale and satisfy the goal of 90% of the world population being able to run a full node using only 10% of hardware and network resources they already own. It doesn't justify its starting assumption.
>>That is true today becauase its a pain in the ass to run a full node.
I disagree. All it takes is to install the Bitcoin full node software on any computer with sufficient hardware resources, and start running it, with next to no configuration. You can even buy plug-and-play Bitcoin nodes where the full node software comes already installed on the device, to skip that trivial step of downloading and installing the software.
>>It is not neccessarily the case that running bitcoin is only for the minority that are "committed individuals", but instead its, in part, a function of how much resources running a full node takes. In other words, the number of people likely to run a full node is not independent of the resources a full node takes to run.
I don't see how you're justifying your argument that running a full node is not for the minority of people that are "committed individuals". You even argued that "it takes some research to configure" a Bitcoin full node, which supports my claim that under any plausible hardware requirements, it would be predominantly committed individuals who would go through the trouble of doing it.
Moreover, I clearly acknowledged that the resources a full node takes to run affects the number of people likely to run it, as I specifically restricted the percentage of the world population able to run a full node under high-scalability assumptions to 1%, or 80 million, on the basis that only they could afford to purchase those resources, My claim implies 99% of the world population would not be likely to run a full node in a high-scalability scenario, due to the unaffordability of acquiring the hardware and bandwidth resources for this cohort.
>>Part of what underlies that goal is that we need to maximize the number of people running public full nodes. The Bitcoin network is massively underserved by public full nodes, see the section on Sybil and Eclipse attacks: https://github.com/fresheneesz/bitcoinThroughputAnalysis#syb... .
Your analysis negates the existence of strategies for countering Sybil and Eclipse that would be far less costly to Bitcoin's utility, and far more likely to actually work, than imposing extreme restrictions on Bitcoin's throughput, which would only work if the extremely inconsistent assumption that tens of millions of people who currently cannot transact on Bitcoin will run a full node.
>>I disagree. Do you think 10s of millions of people are willing to do that? I very much doubt it. I certainly don't think we can rely on that to happen.
Strawman. I never said that 10s of millions of people would be willing to do that, or this would be needed to maintain resistance to cooption.
>>Lack of outcry is not what I'm claiming. I'm claiming that if >50% of the economic activity on the network is done via SPV nodes, rules can be changed in a way that will instantaneously affect those SPV nodes. People do not react instantaneously.
The attack does not need to be instantaneously neutralized for Bitcoin to survive it. It can incur significant short-term losses, and still not come close to erasing the social gains from allowing Bitcoin to be operational for billions of people for many years.
>>Regardless, even a 1% probability of that happening per century is far too high I think.
This conclusions on an extremely inconsistent set of assumptions. On what basis is 99.9% of the world population not being able to use Bitcoin due to the current extreme restrictions on throughput, a better scenario than there being a 1% probability of a scalable and mass-adopted Bitcoin suffering a failure of the type you describe once per century?
>>Wallets are likely to connect to random SPV servers on the network in the future, just like full nodes connect to random nodes.
There are relatively low-cost ways to prevent that from being the case in the future.
>>A centralized authority is not strictly necessary. This may simply be a contentious change that miners want. Maybe there's a loud minority of users on board too. Think about the bch fork.
It would require more than just miners that want it. It would require the majority of major stakeholders, including those running SPV data servers, to want it, and for that change not to face significant public opposition, or else those SPV data servers who want the change would face social backlash and a mass migration away from reliance on them.
>>One kind of political attack I can think of is one where some group decides they don't like bitcoin, and want to kill it. So they try to make laws that make bitcoin harder to use, or perhaps outright ban it. Increasing bitcoin's adoption would help reduce the number of people who don't have a stake in bitcoin, and thus reduce the number of people who would support such an attack. Increasing on-chain throughput may increase adoption (at what rate, I don't know), which would increase the rate at which we achieve some minimum level of adoption (perhaps 20%-30%?) to where an attack is unlikely to succeed.
Yes, and I think of all the ways to mitigate the risks to Bitcoin, this is the most effective one, that results in the greatest reduction of risk to Bitcoin.
>>Another kind of political attack I can think of is one where some group decides to advocate for some dangerous change to bitcoin. They convince a lot of people to want this change, and thus have the backing to attempt to get people to use that change.
If they can convince real people to support the change, they can also support real people running full nodes to support the change, so this risk is not alleviated by restricting transaction throughput to lower the cost of running a full node.
> convince me that the assumptions make any sense at all from the perspective of someone who wants to see people financially empowered by cryptocurrency
It sounds like you're asking me to bias my assumptions, or to explain to you how my assumptions are biased in a way you like. That honestly sounds a bit hypocrticial.
>>My goal is to find the ideal tradeoffs that make the Bitcoin system be secure against adversarial attacks, not to find tradeoffs that maximize the adoption rate of bitcoin but as a result leave the system vulnerable to significant attacks.
Pursuing the goal of "seeing people financially empowered by cryptocurrency" would also involve pursuing the goal of "mak[ing] the Bitcoin system be secure against adversarial attacks", but it does not hold it as the only goal. It's a broader and more sensible goal to pursue, since a highly secure Bitcoin network is only useful to the extent that people can use it.
>>I'm just going to ignore your accusations for now but if you continue to insult me I might just stop talking to you.
If I see evidence of bias in your writings, I will express my opinion on it.
>Developer centralization is another important point. BTC arguably fails at this when a small group, combined with extensive propaganda campaigns, artificially constrains Bitcoin's throughput. There are no valid arguments against raising the blocksize to 2MB for example.
If a handful of people could effectively destroy a “currency” at any point... it’s not decentralized in any sense of the word that is important for trustworthyness or longevity.
A government could crash its own money, but there is a strong incentive to not do that. Bitcoin or Eth has nothing tied to it, it’s entitely at the whim of some programmers who as I understand it, aren’t economics experts.
That’s the point I made above. You want to say the blockchain and hashing is decentralized, great. But when people use that word, they’re talking about (imo) how it’s “safe” to put money into because “no one owns the crypto coin” and if anyone still believes that latter part, well, they probably aren’t paying attention.
> No it isn't. It is 628 GB. This comes out to about $11.50 USD of hard drive space, which is about the cost of a single ethereum transaction.
These are not full nodes.
> There is no point in making sure everyone can run a full node. Even so, it is trivial. A few of the biggest steam games are the size of the entire chain.
Not trivial when you take into account that to assure decentralization the nodes must also broadcast the whole blockchain. Compare the costs of having to broadcast a 6.5tb file for an average of ~30 nodes per month. It will probably cost >$1 thousand. Not very acessible.
> They aren't instant, your transaction doesn't make it to the main chain. You might as well use a different cryptocurrency instead of a hacky second layer.
That is why I pointed that there is less clearance certainty. But you can still be pretty sure that it is settled. It is about trade-offs. Sure, you could use another crypto that incorporates the same trade-offs as Lightning Network. But why would you bother if the network effect is already building around Bitcoin?
> What numbers are you basing this on? I see people repeat this but they can never back it up with numbers. Bitcoin right now is 1.5KB/s. Watching a single low resolution youtube video ends up being 100x the bandwidth of bitcoin. The average transaction value of bitcoin is over $50,000 USD right now. That's not a network that everyone is participating in. People are buying claims on exchanges because the transactions are $12-$32 USD. That's centralization. Sending more than 1.5KB/s is not centralization.
I don't run a full node. That's up to the community to decide. There is no easy answer as you are seemingly implying.
> Neither of them refute my point, which is that you can trustlessly scale bitcoin basically as much as you want.
This is unsupported. LN is a research project, not a production-ready payment system. It has plenty of limitations (trustlessness is a huge limitation), and the topology of the network doesn’t match that of a real economy (routes to fellow consumers are practically useless, since everyone wants to pay merchants). There’s plenty of work left before LN can scale properly, if it ever manages to (again, trustlessness for both senders and receivers is setting the bar as high as it can possibly go).
Scalability is secondondary for LN, trustlessness is primary. Due to this choice I predict difficulty in scaling sufficiently.
> It's unfortunate that the community wasn't organized enough to come a consensus on "scaling" ...
I thought the principle appeal of bitcoin was its decentralized nature. Why do you want to forge a consensus and remove the best feature bitcoin can claim?
> ...that politics trumped usability
You mean, bitcoin operates in The Real World (tm) operated by humans?
DNS is just one of the many ways email is centralized (email relies in a centralized third party service to resolve domain names and find mail servers for them) but I just mention it near the end in a single sentence. Remove the sentence and my point still stands.
Please read again and understand my comment!
> And in fact neither is IP.
Actually IP is neither centralized nor decentralized. Our current largest scale implementation (which we call the Internet) is centralized, but it's a side-effect, not a requirement.
> As far as I understand nothing in SMTP makes it inherently more centralized than any piece of software that relies on IP
Re-read my comment.
Perhaps you don't know how Bitcoin works? In Bitcoin there are no servers... or rather, everyone is a server. The cool thing is I'm still receiving coins whether I am connected to the Bitcoin network or not. It just works, regardless of who is or isn't connected to the network!
In email, I'm still tied to a provider (even if I'm my own provider) which is a single point of failure.
I'll say it again: if your systems has clients relying on servers (which Bitcoin does not), it is not decentralized.
Come on, this is actually what makes Bitcoin so revolutionary!
> Does bitcoin/bitpost not rely on IP?
It does (remember IP is not inherently centralized), but it does not rely on the Internet.
Even if we're using IP (the protocol), Bitcoin is transport-agnostic. In fact it is a goal for the community to use other transports (such as radio or satellites) to avoid the problem of relying on the centralized Internet.
Even then, IP (the protocol) will probably be used for addressing and such, but in a decentralized manner. It's not a requirement, but IP is a useful protocol and nobody wants to reinvent the wheel.
Would I like Bitcoin to support 10,000x more transactions per second than it does now? Of course. But just because I _want_ it to, doesn't mean it's magically going to be able to. Bitcoin is what it is.
I'd like ships that can go faster than the speed of light, but physics isn't going to bends its rules just because I want it to.
We cannot, physically, increase Bitcoin's throughput 10,000x. We could change one constant, the max blocksize, make it 10GB and ... oops, now the network is broken. No one on Earth can actually validate 10GB blocks in the span of 10 minutes. And even if they could, who could handle 1.4 TB of increasing disk space per day?
10,000x is an extreme example of principals that apply to any blocksize increase. If we increase the blocksize, it means less and less PCs are capable of actually running the Bitcoin software. And it won't take much before the exponential complexity of validating blocks eats everything.
Whether we like it or not, we are dependent on optimizing the Bitcoin network if we want any kind of scale. It will take time and it will take innovation. In the meantime, we have SegWit which enables lightning networks, which we can use for anything we don't need the full guarantees of a Bitcoin transaction for.
> Segwit is all about sidechains, that's the main application, and the real purpose.
You're just wrong. Segwit is about a major malleability bug. It happens to open the way for sidechains, but do you honestly think we shouldn't fix the bug purely because it happens to make sidechains more feasible?
> Side chains mean transactions off chain. Transactions off chain mean less fees for Bitcoin miners. It's not rocket science.
Correct, but you don't seem to be following the problem the same way I am. Your major concern is how much miners get paid. My major concern is network adoption and decentralization. Pretending that your values are the only values is what makes your position distasteful.
> The reason nodes are expensive is because they are doing full historical validation which is almost completely useless and unnecessary. Minor changes to the Bitcoin block header would make that completely irrelevant. The nodes need all data ever argument is total junk.
You just literally dismissed how an open block chain works. If nodes don't have the entire history attacks become arbitrary.
> How much does it cost to open and close a channel on the main bitcoin blockchain at a 1 megabyte limit with millions of users? It's not a free thing, it's very expensive.
And guess whose in the best position to implement channels (and collect the fees associated with it)? miners.
> To say that won't result in centralization is ridiculous.
So your solution to centralization pressures is to use a centralized service for decentralization?
> You are talking about bandwidth and the numbers are simple to calculate and come out to trivial amounts.
I provided more evidence on the bandwidth requirements than your incomplete understanding of how bitcoin works multiplied by your flawed opinion.
> 2. Bitcoin is literally working right now with 0 hiccups except for full blocks and high fees.
No-one is forcing you to use it. There are a multitude of other options if you feel that bitcoin isn't meeting your use-case.
> You say hand waving while not backing up a single thing you've said
I provided evidence that backed up my opinion. You should try it.
> This is about how ridiculous the 1MB limitation is, you can try to divert from that, but lets see you confront it.
Nah. You can use another service if you feel that the 10's of thousands of nodes somehow don't have a better understanding of the constraints of running a node than you. No-one is holding a gun to your head. Ever heard of Bitcoin Cash? Perhaps that might better suit your needs.
reply