5 ms·

If the throughput of the network equals the throughput of your device, you'll never catch up if you go offline at all. At 90% capacity it will take you 10 hours

by nullc 6y ago

If the throughput of the network equals the throughput of your device, you'll never catch up if you go offline at all. At 90% capacity it will take you 10 hours to catch up for every hour you are behind. Taking long periods of catch up time for outages isn't acceptable. At 100x capacity most conventional equipment right now would fail to complete its initial synchronization before the participant gave up. The security of the system comes from decenteralization, so its goals can't be reached if its only workable for the best funded 10% of the participants. Moreover, the operating cost of a node are only compensated fairly indirectly and are a public good (if everyone else runs an honest node, you don't gain from running your own). As a result, it's not sufficient to just be not-astronomical, it has to be fairly close to painless. Node's ability to keep up is also only one part of the equation. Bitcoin's long term security is absolutely dependant on transaction fees paying for proof of work. With functionally limitless capacity the natural price of transactions is essentially zero-- as has been demonstrated by competing systems which have found that they can only fund security with inflation. Most critically-- while you can make a fine argument that some moderate increases (more like 2x or 5x than 100x) are viable without too much increase in security risks-- those kinds of changes (heck, even 100x) don't categorically change the situation. But we do have technology to categorically change the situation, tech that was thought of and made accordance for before Bitcoin was ever released and has always been part of the long term plans-- regardless of whatever lies motivated parties might want to tell you-- tech like lighthing adds essentially unlimited transaction throughput to Bitcoin because it doesn't require public broadcast for each and every transaction. I was talking to someone this morning who is doing a test sustaining 400 transactions per second. > and that was the sentiment expressed by Satoshi any time he commented on it. Sorry, that is just a flat out lie-- at I pointed out in a prior comment literally the last public statement Satoshi made on the matter of scalablity/resource usage was: "Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices." https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917 https://bitcointalk.org/index.php?topic=1790.msg28917#msg289... There is a long history of the position I'm presenting, going back to many of Bitcoin's earliest participants.

CryptoPunk 6y ago
If you're going to interpret Satoshi's single "tyrannical" reference as endorsement of restraining block sizes to 1 MB, it is a much weaker 'endorsement' than multiple explicit calls for a much higher on-chain throughput, including his directly saying that the intended network configuration for Bitcoin at scale was for validation to be done only by users with server farms, which implies even greater than 100X boosts in throughput from current levels. As for initial synchronization: There is no basis for claiming users cannot keep up with it at 100X current throughput levels, and like I said, relying on trusted third party set checkpoints to completely do away with validating the entire blockchain history is always an option, and already one being utilized to some extent with the flag in Bitcoin Core to skip validation on transactions older than a TTP-set checkpoint. Saying every one should validate, but then limiting the world to 300,000 on-chain writes a day, meaning limiting who can use Bitcoin without third-party intermediaries to 0.1% of the world population, is a bad trade-off. Better 10% of Bitcoiners be able to run their own fully validating node, and all 7 billion people be able to generate transactions *with their own private keys*, than let every one with a PC run a fully validating node, while only 0.1% make writes to Bitcoin with their own private keys. In a scenario where a party cannot write a transaction to Bitcoin, due to limited on-chain capacity, there is little point in running a fully validating node. Emphasizing full node validation accessibility over main chain write accessibility to this extent is not a sensible prioritization. Regarding this off-chain payment channel networks Red Herring, there is no reason to be confident that PCNs like the lightning network can provide a mix of trade-offs that will make them compelling to a wide set of users, and indeed the LN has still failed to get traction nearly 6 years after first being proposed. The capital lock-up requirements, especially in a setting where on-chain transaction fees are high, the need for being online to trustlessly receive funds, and the routing challenges, are all potentially fundamental showstoppers for the LN being a viable technology for widespread utilization/adoption. Finally, even if payment channel networks work - which is a very speculative 'if' and not one that the entire empowerment of humanity with access to electronic cash should be made dependent on - blocks would still need to be on the order of 100X larger to enable global mass-adoption, as payment channel networks do not completely do away with the need to have on-chain throughput.

by nullc 6y ago

CryptoPunk 6y ago

If you're going to interpret Satoshi's single "tyrannical" reference as endorsement of restraining block sizes to 1 MB, it is a much weaker 'endorsement' than multiple explicit calls for a much higher on-chain throughput, including his directly saying that the intended network configuration for Bitcoin at scale was for validation to be done only by users with server farms, which implies even greater than 100X boosts in throughput from current levels. As for initial synchronization: There is no basis for claiming users cannot keep up with it at 100X current throughput levels, and like I said, relying on trusted third party set checkpoints to completely do away with validating the entire blockchain history is always an option, and already one being utilized to some extent with the flag in Bitcoin Core to skip validation on transactions older than a TTP-set checkpoint. Saying every one should validate, but then limiting the world to 300,000 on-chain writes a day, meaning limiting who can use Bitcoin without third-party intermediaries to 0.1% of the world population, is a bad trade-off. Better 10% of Bitcoiners be able to run their own fully validating node, and all 7 billion people be able to generate transactions *with their own private keys*, than let every one with a PC run a fully validating node, while only 0.1% make writes to Bitcoin with their own private keys. In a scenario where a party cannot write a transaction to Bitcoin, due to limited on-chain capacity, there is little point in running a fully validating node. Emphasizing full node validation accessibility over main chain write accessibility to this extent is not a sensible prioritization. Regarding this off-chain payment channel networks Red Herring, there is no reason to be confident that PCNs like the lightning network can provide a mix of trade-offs that will make them compelling to a wide set of users, and indeed the LN has still failed to get traction nearly 6 years after first being proposed. The capital lock-up requirements, especially in a setting where on-chain transaction fees are high, the need for being online to trustlessly receive funds, and the routing challenges, are all potentially fundamental showstoppers for the LN being a viable technology for widespread utilization/adoption. Finally, even if payment channel networks work - which is a very speculative 'if' and not one that the entire empowerment of humanity with access to electronic cash should be made dependent on - blocks would still need to be on the order of 100X larger to enable global mass-adoption, as payment channel networks do not completely do away with the need to have on-chain throughput.