5 ms·

Raising the block size is complete nonsense. It will simply kill of nodes and at best create increased transactions per block proportional to the block size inc

by 127 6y ago

Raising the block size is complete nonsense. It will simply kill of nodes and at best create increased transactions per block proportional to the block size increase. A very poor trade-off.

CryptoPunk 6y ago
Nodes can handle far more than 7 transactions per second of throughput, even if you 4X the data size of that to account for propagation to multiple peers. 10 KB/s is nothing. Keeping nodes so light so that you can validate with a Raspberry Pi with a dialup connection, at the cost of preventing 100X more people from using Bitcoin, is a terrible tradeoff. There is no technological bottleneck preventing a 100X raising of the throughput limit: not Initial Blockchain Download, which is already being expedited with trusted third party set checkpoints, not computation, not storage and not bandwidth. The vast majority of Bitcoin agreed with my sentiment, and that was the sentiment expressed by Satoshi any time he commented on it. It was just irresponsible, overly timid leadership allowing a loud minority to sabotage Bitcoin's widely supported roadmap. Responding to the comment below: 1. You can prune spent transactions. Only the UTXO set needs to be stored, so you don't need to store 5 TB more each year. But even that wouldn't be prohibitively costly for thousands of hobbyists worldwide. So even if pruning wasn't an option - and it is - Bitcoin's censorship resistance would remain totally secure. 2. You can use checkpointing in initial sync up, instead of downloading the entire transaction history. The hash of the true chain is widely disseminated and Bitcoin nodes already use a form of checkpointing, where they skip validation for transactions before the checkpoint flag, to expedite Initial Blockchain Download.
- 127 6y ago
  If you have to be a server farm to prune past 1 week, Bitcoin will no longer be decentralized and censorship resistant, losing its main point in the first place.
  - CryptoPunk 6y ago
    A single modern consumer-grade PC can validate 100X larger blocks in real time. The average web page these days is over 1 MB. The idea that you need to limit every once-in-every-10-minute block to 1 or 1.6 MB is not, from everything I can see, close to approaching a sound balancing of competing priorities.
    - mtrycz2 6y ago
      My RPi4 can handle 256MB blocks on BCH's scalenet, just fine. There never was a scaling issue.
      - CryptoPunk 6y ago
        Exactly. Even 100X larger blocks, meaning 100 MB blocks, would allow for very high levels of decentralization.
- jart 6y ago
  Raising the limit 100x means the blockchain would grow 5tb a year. So personal computers would not be able to use Bitcoin anymore. Only companies like Google would have the resources to participate in the Bitcoin network.
  - cheaprentalyeti 6y ago
    The block limit has nothing to do with the transaction rate. You'll just wind up waiting longer for a block. Bitcoin core has had since the Big Forks a larger number of transactions than Bitcoin Cash, which was forked to allegedly fix the transaction rate. If the rest of you had actually tried /running a node/ instead of just copying and pasting the fifty cent army's argument of the day maybe you'd realize that.
    - nullc 6y ago
      I don't think you're disagreeing with the post you're replying to.
- pcdoodle 6y ago
  Get out of here with this bullshit. Do you know it is bitcoins resistance to change that makes it appealing? Layer 2 is where the scaling happens. END OF STORY.
  - EVa5I7bHFq9mnYK 6y ago
    Problem is, there is no working layer 2, after all these years and tremendous effort. That project has failed. END OF STORY.
- tromp 6y ago
  Checkpointing very much runs counter to the decentralizing philosophy of bitcoin. Nodes should be able to fully verify the transaction history with reasonable resources.
  - CryptoPunk 6y ago
    In practice, checkpoint is not a big deal. For history older than X, where X is a sufficiently distant time in the past, there will always be widespread consensus on the hash of the true chain, and numerous reputable parties that the hash of the true chain can be obtained from. Some poison node attack where fraudulent websites provide a hash of a fake history will not be viable. Checkpointing is also currently being utilized in Bitcoin Core, so relying on it further is not a major departure on how things are currently done. And at 100X current block sizes, validating the entire history with no checkpoints will still be possible for thousands of hobbyists with beefed up but still modest hardware/bandwidth. The empowerment from 100X more people being able to write transactions to the main chain, with their own private keys, will be well worth the relatively tolerable compromises on full node validation.
    - tromp 6y ago
      Bitcoin Core never did checkpointing in the sense of skipping prior history. They merely required a particular block at a particular height. Not fully verifying history is a complete departure from how things are done in bitcoin full nodes. And Bitcoin Core removed even those checkpoints [1]. [1] https://bitcoin.stackexchange.com/questions/75733/why-does-bitcoin-no-longer-have-checkpoints https://bitcoin.stackexchange.com/questions/75733/why-does-b...
      - CryptoPunk 6y ago
        Bitcoin Core removed that form of checkpointing, and added in another. Currently it has checkpointing in the form of assumevalid, which by default causes a full node to skip validation of transaction older than the checkpoint when synchronizing. [1] [1] https://bitcoin.stackexchange.com/questions/88652/does-assumevalid-lower-the-security-of-bitcoin https://bitcoin.stackexchange.com/questions/88652/does-assum...
- 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.
SnowProblem 6y ago
Bitcoin's creator thought the block size should be raised and nodes would end up in server farms. Whether you agree with this or not, that was the original vision of Bitcoin. Now, start-ups pivot, and it's great that there are experiments, but BTC should not have used the Bitcoin name to do this. That is the point being made.
- nullc 6y ago
  That is really misleading, in one of Satoshi's last public messages he wrote: > 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 has always been a challenging trade-off here, which is presumably why he limited the size in the first place. This trade-off was widely acknowledged in the community going back essentially as far as records do. And as time has gone on we've only learned more about how some ideas don't work. For example, Satoshi believed businesses would run nodes to verify their own transactions-- but we've found in practice few do, instead outsourcing it to centralized third parties often with dubious security practices.
  - CryptoPunk 6y ago
    Why don't you quote all of the instances where he endorsed large blocks? You're singling out one expression of mildly small-block sentiment and overlooking multiple expressions of strongly large-block sentiment by Satoshi.
    - nullc 6y ago
      There aren't any? He _implemented_ the block size limit, nothing forced him to. Had he wanted it to change automatically he could have coded it that way. Instead, he tended to describe the design as being mostly set in stone. When someone tried to remove the limit he urgently yelled at them to stop (and stated if it were ever needed it could be phased in). I'm sure that his, like everyone elses, understanding of the requirements evolved over time too. Meanwhile, scaling Bitcoin via layers was endorsed explicitly by essentially every technical voice in the space for years until some got wrapped up with scammers. Satoshi even built specific affordances for payment channels directly into the transaction format, and was the first person to describe their use.

by 127 6y ago

Raising the block size is complete nonsense. It will simply kill of nodes and at best create increased transactions per block proportional to the block size increase. A very poor trade-off.

CryptoPunk 6y ago

Nodes can handle far more than 7 transactions per second of throughput, even if you 4X the data size of that to account for propagation to multiple peers. 10 KB/s is nothing. Keeping nodes so light so that you can validate with a Raspberry Pi with a dialup connection, at the cost of preventing 100X more people from using Bitcoin, is a terrible tradeoff. There is no technological bottleneck preventing a 100X raising of the throughput limit: not Initial Blockchain Download, which is already being expedited with trusted third party set checkpoints, not computation, not storage and not bandwidth. The vast majority of Bitcoin agreed with my sentiment, and that was the sentiment expressed by Satoshi any time he commented on it. It was just irresponsible, overly timid leadership allowing a loud minority to sabotage Bitcoin's widely supported roadmap. Responding to the comment below: 1. You can prune spent transactions. Only the UTXO set needs to be stored, so you don't need to store 5 TB more each year. But even that wouldn't be prohibitively costly for thousands of hobbyists worldwide. So even if pruning wasn't an option - and it is - Bitcoin's censorship resistance would remain totally secure. 2. You can use checkpointing in initial sync up, instead of downloading the entire transaction history. The hash of the true chain is widely disseminated and Bitcoin nodes already use a form of checkpointing, where they skip validation for transactions before the checkpoint flag, to expedite Initial Blockchain Download.

127 6y ago
If you have to be a server farm to prune past 1 week, Bitcoin will no longer be decentralized and censorship resistant, losing its main point in the first place.
- CryptoPunk 6y ago
  A single modern consumer-grade PC can validate 100X larger blocks in real time. The average web page these days is over 1 MB. The idea that you need to limit every once-in-every-10-minute block to 1 or 1.6 MB is not, from everything I can see, close to approaching a sound balancing of competing priorities.
  - mtrycz2 6y ago
    My RPi4 can handle 256MB blocks on BCH's scalenet, just fine. There never was a scaling issue.
    - CryptoPunk 6y ago
      Exactly. Even 100X larger blocks, meaning 100 MB blocks, would allow for very high levels of decentralization.
jart 6y ago
Raising the limit 100x means the blockchain would grow 5tb a year. So personal computers would not be able to use Bitcoin anymore. Only companies like Google would have the resources to participate in the Bitcoin network.
- cheaprentalyeti 6y ago
  The block limit has nothing to do with the transaction rate. You'll just wind up waiting longer for a block. Bitcoin core has had since the Big Forks a larger number of transactions than Bitcoin Cash, which was forked to allegedly fix the transaction rate. If the rest of you had actually tried /running a node/ instead of just copying and pasting the fifty cent army's argument of the day maybe you'd realize that.
  - nullc 6y ago
    I don't think you're disagreeing with the post you're replying to.
pcdoodle 6y ago
Get out of here with this bullshit. Do you know it is bitcoins resistance to change that makes it appealing? Layer 2 is where the scaling happens. END OF STORY.
- EVa5I7bHFq9mnYK 6y ago
  Problem is, there is no working layer 2, after all these years and tremendous effort. That project has failed. END OF STORY.
tromp 6y ago
Checkpointing very much runs counter to the decentralizing philosophy of bitcoin. Nodes should be able to fully verify the transaction history with reasonable resources.
- CryptoPunk 6y ago
  In practice, checkpoint is not a big deal. For history older than X, where X is a sufficiently distant time in the past, there will always be widespread consensus on the hash of the true chain, and numerous reputable parties that the hash of the true chain can be obtained from. Some poison node attack where fraudulent websites provide a hash of a fake history will not be viable. Checkpointing is also currently being utilized in Bitcoin Core, so relying on it further is not a major departure on how things are currently done. And at 100X current block sizes, validating the entire history with no checkpoints will still be possible for thousands of hobbyists with beefed up but still modest hardware/bandwidth. The empowerment from 100X more people being able to write transactions to the main chain, with their own private keys, will be well worth the relatively tolerable compromises on full node validation.
  - tromp 6y ago
    Bitcoin Core never did checkpointing in the sense of skipping prior history. They merely required a particular block at a particular height. Not fully verifying history is a complete departure from how things are done in bitcoin full nodes. And Bitcoin Core removed even those checkpoints [1]. [1] https://bitcoin.stackexchange.com/questions/75733/why-does-bitcoin-no-longer-have-checkpoints https://bitcoin.stackexchange.com/questions/75733/why-does-b...
    - CryptoPunk 6y ago
      Bitcoin Core removed that form of checkpointing, and added in another. Currently it has checkpointing in the form of assumevalid, which by default causes a full node to skip validation of transaction older than the checkpoint when synchronizing. [1] [1] https://bitcoin.stackexchange.com/questions/88652/does-assumevalid-lower-the-security-of-bitcoin https://bitcoin.stackexchange.com/questions/88652/does-assum...
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.

SnowProblem 6y ago

Bitcoin's creator thought the block size should be raised and nodes would end up in server farms. Whether you agree with this or not, that was the original vision of Bitcoin. Now, start-ups pivot, and it's great that there are experiments, but BTC should not have used the Bitcoin name to do this. That is the point being made.

nullc 6y ago
That is really misleading, in one of Satoshi's last public messages he wrote: > 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 has always been a challenging trade-off here, which is presumably why he limited the size in the first place. This trade-off was widely acknowledged in the community going back essentially as far as records do. And as time has gone on we've only learned more about how some ideas don't work. For example, Satoshi believed businesses would run nodes to verify their own transactions-- but we've found in practice few do, instead outsourcing it to centralized third parties often with dubious security practices.
- CryptoPunk 6y ago
  Why don't you quote all of the instances where he endorsed large blocks? You're singling out one expression of mildly small-block sentiment and overlooking multiple expressions of strongly large-block sentiment by Satoshi.
  - nullc 6y ago
    There aren't any? He _implemented_ the block size limit, nothing forced him to. Had he wanted it to change automatically he could have coded it that way. Instead, he tended to describe the design as being mostly set in stone. When someone tried to remove the limit he urgently yelled at them to stop (and stated if it were ever needed it could be phased in). I'm sure that his, like everyone elses, understanding of the requirements evolved over time too. Meanwhile, scaling Bitcoin via layers was endorsed explicitly by essentially every technical voice in the space for years until some got wrapped up with scammers. Satoshi even built specific affordances for payment channels directly into the transaction format, and was the first person to describe their use.