Bitcoin 20MB Fork

[RoadStress]

No, the people arguing against this hardfork do indeed have some valid concerns. We don't want one or a few centralized sources to store archival or reference full historical nodes for us to bootstrap pruned nodes or partial DHT based nodes from.

So because people don't want to invest XXX$ for a X TB HDD you think that they have a valid concern? People need to learn that they need to pay for services if they want to be their own bank. Investing in a dedicated HDD for keeping the full blockchain should be viewed as a personal security measure, not something that should be rejected from the start. The banks charge people huge amounts of fees that offer a huge variety of hidden services for the customers (safety of their vaults, safety when moving money, safety when it comes to hackers, safety when it comes to failures etc). People think that if they get rid of their bank they will never have to pay any other fee and that is simply wrong. 

The question is how many would be sufficient to secure the network?

How many miners do we need to secure the network? The answer is that we do not know, but we can make it very expensive and not efficient for someone to try to trick the system. Just like we did with mining where someone would need to invest a shitload of money in order to disrupt the network. It's simply not economical to do so. We can have it the same with the blockchain, but only if people stop being so against everything and start thinking of reasonable ways to deal with the problem.

We live in a consumerism world where people gladly pay $600+ for a phone which they use for 1-3 years, but they do not want to pay 50$-200$+ for something which guarantees them their security when it comes to bitcoin. That's stupid and it shows what a limited view people generally have when it comes to being able to manage their stuff alone. I am sure that this will change, but it will take a bit of time because we need some time to digest this just like with everything else.

P.S... While I applaud TBF attempt at addressing our concerns with the lack of full nodes with this program -
https://getaddr.bitnodes.io/nodes/incentive/

I think it is insufficient and frankly quite pathetic attempt at a real growing problem.

May I ask you what have you done about this? How many full nodes have you setup? Or you are just waiting for others to solve this issue? A decentralized consensus network needs to be sustained by everyone and everyone should be involved somehow. Waiting only for others to solve issues is not the correct way to do it. You/Everyone need/s to get involved instead of just complaining about various things. (btw this is not a personal attack. it's just a general speaking)

[1714958123]

1714958123

[1714958123]

1714958123

[1714958123]

1714958123

[1714958123]

1714958123

[1714958123]

1714958123

[inBitweTrust]

No, the people arguing against this hardfork do indeed have some valid concerns. We don't want one or a few centralized sources to store archival or reference full historical nodes for us to bootstrap pruned nodes or partial DHT based nodes from.

So because people don't want to invest XXX$ for a X TB HDD you think that they have a valid concern?

The HD space is marginal and the greater concerns are with bandwidth costs. The cost to run a full node will likely increase from 20 usd a year to ~5 dollars a month for many people in the future. This isn't a lot of money but still may put further downward pressure upon the amount of nodes. This isn't unresolvable but we should be aware of it.

How many miners do we need to secure the network? The answer is that we do not know, but we can make it very expensive and not efficient for someone to try to trick the system. Just like we did with mining where someone would need to invest a shitload of money in order to disrupt the network. It's simply not economical to do so. We can have it the same with the blockchain, but only if people stop being so against everything and start thinking of reasonable ways to deal with the problem.

Your not making a lot of sense here, most of these people in this thread all want what is best for bitcoin and we just disagree on the solution to get there. I have been discussing specific solutions to resolve this problem, and am trying to get more specifics as to what degree of security or decentralization people against the hard fork expect to move forward.
You suggest that we cannot know how many miners it takes to secure the network but this also isn't true as we can make very good estimates of the costs it takes to attack the network and what the risks are based upon the amount of hashing power.

May I ask you what have you done about this? How many full nodes have you setup? Or you are just waiting for others to solve this issue? A decentralized consensus network needs to be sustained by everyone and everyone should be involved somehow. Waiting only for others to solve issues is not the correct way to do it. You/Everyone need/s to get involved instead of just complaining about various things. (btw this is not a personal attack. it's just a general speaking)

I have setup over a tremendous amount of full nodes and maintain multiple ones myself personally, not that any of that matters to the discussion at hand.  Again , I am discussing specific proposals and trying to move this conversation along.

My questions are aimed at the people against this hardfork to understand what degree of decentralization and security which would make them comfortable as their primary concern deals with the risk of centralization and decrease of nodes.

[RoadStress]

The HD space is marginal and the greater concerns are with bandwidth costs. The cost to run a full node will likely increase from 20 usd a year to ~5 dollars a month for many people in the future. This isn't a lot of money but still may put further downward pressure upon the amount of nodes. This isn't unresolvable but we should be aware of it.

5$ per month while you control your own money seems good for me. You definitely pay more to your bank and you do not control your money. Also this issue is only for US (I guess). There are places where internet is cheaper and places where internet is more expensive so this 5$/mo doesn't apply to everyone.

Your not making a lot of sense here, most of these people in this thread all want what is best for bitcoin and we just disagree on the solution to get there. I have been discussing specific solutions to resolve this problem, and am trying to get more specifics as to what degree of security or decentralization people against the hard fork expect to move forward.
You suggest that we cannot know how many miners it takes to secure the network but this also isn't true as we can make very good estimates of the costs it takes to attack the network and what the risks are based upon the amount of hashing power.

And this can not be applied to full nodes too? I am sure that we can estimate here too.

My questions are aimed at the people against this hardfork to understand what degree of decentralization and security which would make them comfortable as their primary concern deals with the risk of centralization and decrease of nodes.

I wasn't aware that this topic was aimed at the people against the hardfork. My mistake.

[inBitweTrust]

how much security do we need ? It's hard to quantify security:
I think we should be ultra conservative and try to reach maximal possible security level.
Don't forget that those who have potential to kill bitcoins are not Trolls...

Maximal possible security in regards to node decentralization = every user have full unpruned node active.
This was never the plan for bitcoin as you can read from the original whitepaper and is not possible unless you want bitcoin to only be used by a small group of people which incidentally makes it insecure because you are keeping bitcoin
a small fringe project that could easily be squashed, thus because it is impractical to scale it actually leaves you with less security.

Personally, I don't agree with Satoshi's vision of most people using SPV nodes either and want the bitcoin network to remain more decentralized.

I don't think the problem has to do so much with a total node count but other factors like ASN distribution and different interests in control of the nodes. Thus a ratio of 1 full unpruned node per 10k users is fine if you have a ratio of 1 full pruned node(coming in 0.11) to 50-100 SPV clients distribution if and only if those full unpruned nodes are distributed in the right manner.

Thus when you look at this map of the 6.5k nodes - https://getaddr.bitnodes.io you don't see a wide distribution per country. I would want at least 1 full node per country, and at least 1 full node in most of the large ISP's. Additionally, most of these full nodes are coming from miners and mining pools which further unbalances the power dynamic as they have already most of the influence because they control the hashing power and everything that entails so I would want the full unpruned node distribution to be controlled by a combination of miners,  hobbyists , non profits , merchant processors, and businesses more equally. The reason this isn't the case right now is there is no incentive to do so, and the solutions to this problem where discussed in my previous post where I gave 6 different examples.
 
This only is addressing security of the network in regards to node distribution, and there are many other ways bitcoin is very fragile that need to be discussed but that is for another thread.

Do people agree with my opinion, why or why not with specific reasons cited?

[NewLiberty]

My questions are aimed at the people against this hardfork to understand what degree of decentralization and security which would make them comfortable as their primary concern deals with the risk of centralization and decrease of nodes.

Thank you for your valuable attention and contribution to this! 

Over its history, Bitcoin users per nodes has declined from >1:1 to now something like <1:700 (from the calcs upthread). 

Looking at it another way... # of nodes contributes an element of security (resilience) where N is the minimum to run, N+1 is with one 'hot failover' system for backup, we have something like N+7000... which so far has been more than enough.

The question posed here boils down to: 'how much security is needed?'.  An honest answer to this is always going to be: 'I don't know until we don't have enough.'  So far, Bitcoin has had enough.  So far Bitcoin has also had enough space in the blocks for meaningful transactions.  These two virtues are come into conflict with this proposed fork.

So where the (A) number of meaningful transactions, is empirically observable; and (B) the amount of security needed, is only knowable after it has failed.

From this, a simplified risk analysis.

As (A) increases, Bitcoin's value increases.  As (B) increases, Bitcoin's cost increases. 

Increasing either (A) or (B) also increases risk to Bitcoin:  In brief,  The more value Bitcoin has, the greater the incentive to subvert it.  The greater cost to Bitcoin, the easier it is to subvert.

The optimal management of this A:B ratio for greatest Bitcoin value and security would be a block size that permits all meaningful transactions to be swiftly included in blocks, but not so large that it permits excessive spurious transactions for which the cost is borne by all...  So a hard fork to accomplish this is desirable, just not "at any cost".

This brought me to needing a proposal for such a fork that is "Not both inaccurate and indefinite". 

[R2D221]

Exactly, in countries where bandwith costs a lot, full nodes will tend to disapear.
So we will start to make holes in the mesh network.

It's not like most nodes are located in Europe and the US East, according to the map here: https://getaddr.bitnodes.io/

If you think distribution has been fair so far, then you're wrong.

[inBitweTrust]

Over its history, Bitcoin users per nodes has declined from >1:1 to now something like <1:700 (from the calcs upthread).  

Looking at it another way... # of nodes contributes an element of security (resilience) where N is the minimum to run, N+1 is with one 'hot failover' system for backup, we have something like N+7000... which so far has been more than enough.
....

As (A) increases, Bitcoin's value increases.  As (B) increases, Bitcoin's cost increases.

Thus if <1:~700 has been sufficient with a market cap of 3-4 billion one could extrapolate a minimum of full nodes desired with a more valuable economy as there is a loose correlation between the incentive to attack a more valuable network and the costs inherent to do so. So if Bitcoin grows to a market cap of 8 billion we would want around  <1:~350 full nodes. 16 billion we would want <1:~175 nodes. This shouldn't be a linear ratio continuously as supporting that level of security for growth isn't realistic even if we keep the block limit at 1MB. Perhaps if we start considering pruned nodes as having a certain amount of value in the total node count it can be extended much further.

I still believe what is more important is the type, quality, whom controls,  and distribution of the nodes vs just the total node count but am fine if bitcoin is over-engineered where it focuses on both considerations. Additionally, I believe we should consider the value of 1GB pruned full nodes in context to the discussion with subsidizing security.

Thus we could either incorporate an incentive structure through price discovery methods to incentivize nodes and/or optimize core and add pruning, or we can have some external methods as discussed to accomplished these shared goals.
What we cannot do is simply sit idly by and assume nothing needs to be done either. To be fair many people who oppose this fork are actually working on projects like the 10k extra pogo nodes to address this issue. I think that if we have a comprehensive plan of action before the hardfork we can satisfy all our values and objectives.

There are more important things that can be done like setting up libbitcoin Obelisk nodes/servers to support other implementations than simply focusing on total node count for bitcoin core, but if the requirements are realistically achievable like you outlined with scaling up the total node count with market cap than there is no reason we cannot accomplish both at the same time.

So moving forward, if a plan is in place, with an incentive structure built that will sustain decentralization realistically, and we are achieving said goals before the hard fork, than is anyone opposed to increasing the blocksize limit and has specific objections in doing so?

[picolo]

I dont know if someone actually made a similar poll since search engine is down so here we go..

Bitcoin fork proposal by respected Bitcoin lead dev Gavin Andresen, to increase the block size from 1MB to 20MB.

Interesting read about it: https://bitcointalk.org/index.php?topic=919629.0 (locked )

Feel free to discuss it further.

Most devs are in favor of it but I have no idea.

[R2D221]

Exactly, in countries where bandwith costs a lot, full nodes will tend to disapear.
So we will start to make holes in the mesh network.

It's not like most nodes are located in Europe and the US East, according to the map here: https://getaddr.bitnodes.io/

If you think distribution has been fair so far, then you're wrong.

I don't think if distribution is fair or not.

OK, so what were you trying to say?

[inBitweTrust]

Most devs are in favor of it but I have no idea.

Thus far Peter Todd and Amir are 2 devs that seem to oppose it and I respect both their opinions.

Peter Todd is often the contrarian to motivate others and critically analyze any proposals weaknesses which has great value in itself and doesn't necessarily mean he will oppose a hard fork if certain conditions are met.  

Most other devs have been very subtle and have avoided directly answering the question as they are looking for more specific proposals to discuss and once BIP's are submitted they will certainly start giving their opinions as always have done.

From what I have read and heard almost all devs are ok with increasing the block limit but are more conservative than Gavin and want very special conditions to be met in doing so.

in countries where bandwith costs a lot, full nodes will tend to disapear.
Over

So all we must do is create an incentive structure to value a distributed range of ASN's to solve this problem. We don't even need to do so solely on a charity base like TBF is doing either because there is great value in those distributed IP ranges that can also function as nodes on VPS's setup across the world.

So if your concerns are addressed you have no problem with increasing the block limit?

[Sheldor333]

Well this should happen. It's natural to increase fork size, the more people use Bitcoins we need it to be able to handle more transactions per fork. Still with today's speeds it doesn't mean much to most who mine.

[NewLiberty]

Over its history, Bitcoin users per nodes has declined from >1:1 to now something like <1:700 (from the calcs upthread).  

Looking at it another way... # of nodes contributes an element of security (resilience) where N is the minimum to run, N+1 is with one 'hot failover' system for backup, we have something like N+7000... which so far has been more than enough.
....

As (A) [meaningful transactions] increases, Bitcoin's value increases.  As (B) [node quantity] increases, Bitcoin's cost increases.

Thus if <1:~700 has been sufficient with a market cap of 3-4 billion one could extrapolate a minimum of full nodes desired with a more valuable economy as there is a loose correlation between the incentive to attack a more valuable network and the costs inherent to do so. So if Bitcoin grows to a market cap of 8 billion we would want around  <1:~350 full nodes. 16 billion we would want <1:~175 nodes. This shouldn't be a linear ratio continuously as supporting that level of security for growth isn't realistic even if we keep the block limit at 1MB. Perhaps if we start considering pruned nodes as having a certain amount of value in the total node count it can be extended much further.

Extrapolation with only these variables is not such a great idea, but I take your meaning.  Yes, add in pruned nodes when they materialize at some value less than their percentage (they are worth nothing alone).

I still believe what is more important is the type, quality, whom controls,  and distribution of the nodes vs just the total node count but am fine if bitcoin is over-engineered where it focuses on both considerations. Additionally, I believe we should consider the value of 1GB pruned full nodes in context to the discussion with subsidizing security.

Thus we could either incorporate an incentive structure through price discovery methods to incentivize nodes and/or optimize core and add pruning, or we can have some external methods as discussed to accomplished these shared goals.
What we cannot do is simply sit idly by and assume nothing needs to be done either. To be fair many people who oppose this fork are actually working on projects like the 10k extra pogo nodes to address this issue. I think that if we have a comprehensive plan of action before the hardfork we can satisfy all our values and objectives.

There are more important things that can be done like setting up libbitcoin Obelisk nodes/servers to support other implementations than simply focusing on total node count for bitcoin core, but if the requirements are realistically achievable like you outlined with scaling up the total node count with market cap than there is no reason we cannot accomplish both at the same time.

So moving forward, if a plan is in place, with an incentive structure built that will sustain decentralization realistically, and we are achieving said goals before the hard fork, than is anyone opposed to increasing the blocksize limit and has specific objections in doing so?

Sure...  but the perfect is the enemy of the good (or the better).  You listed some risk mitigation efforts, there are also other threat vectors.  If you might be willing to imagine that the USG is anti-Bitcoin, you might posit things like Project BULLRUN, or the Equation Group's capabilities to take over any computer with storage and an EEPROM based on it matching a pattern of data on its storage (say, the genesis block, for example).  So this doesn't move the needle much.  We still won't know how much security is needed until there isn't enough.  

We can also consider recovery modes, a bandwidth attack may not end Bitcoin entirely due to its anti-fragile nature.  The biggest full failure modes come with adding pernicious risks, ones that build over time to eventually kill it.  I believe this is part of why satoshi dropped it from 32MB to 1MB in the first instance (and maybe also TOR).

An external incentive structure is a good thing, but being external, it is also untrustable by the code (it could disappear and we'd be left with code that was written assuming it is there).

So with this impasse, I'll re-propose the progression mentioned above with just a little more detail.

1) A hard fork with a definite increase (8MB maybe, some moderate yet arbitrary number that doesn't fix the core of the problem).  Nothing exponentially increasing, but maybe a best guess at providing enough time for (1.5).
1.5) Adding code for all the stuff needed to measure block size within the block chain, or number of transactions per block in the chain (something clever with the Merkle tree maybe?)

2)  A dynamic limit hard fork (indefinite in term, but not inaccurate) which sets a max block size to accommodate transaction growth within a range thereby preventing spam/attacks but with some room to grow, (maybe 10x the average size).  The goal here is to rightsize the block size within the block chain.

3) No block size limit (because the transaction cost supports all network costs appropriately).  JustusRanvier's discussion papers allude to methods for this.  There are practical problems, lots of them, too many to list.  This is however the end-game for perfectly scalability whilst maintaining security using a decentralized free-market economic incentive structure.  No one knows how to do this yet.  The problem with indefinite exponential increasing limit is that it is too close to this and assumes too much.

For what its worth, there may well be a decade in between each of these phases, what we need from our scientists is the massive amount of work and planning to get from (1) to (3).  Bitcoin ought not skip steps due to fear of its opposition, to do so would play into the hands of the feared opposition.

Gavin's proposal is a great one, it is well reasoned, and I think it is well meaning.  I agree with him that it is likely "the simplest that could work".  However it unnecessarily creates more risk than benefits.  Please, let us take only necessary risks and not unnecessary ones?  Let us keep the highest standards for ourselves, and for posterity.  We owe this to all those that have contributed so very much to this project.

============

There are some "no fork for blocksize" folks that see increasing the capability of transactions as a sort of inflation and thus unacceptable.

www.contravex.com/2015/01/12/bitcoin-doesnt-need-a-hard-fork-it-needs-hard-people/

This is what it boils down to: scarcity. There’s no room in Bitcoin for inflation of any kind. Other applications and whatnot can be built on top of it as is. It’s for the world to adapt and conform to Bitcoin, not the other way around.

I don't see transaction volume increase as a change in inflation so much as a change in velocity.  Henry Hazlitt who is credited with bringing Austrian Economic theory to the English speaking world, would I think agree that is not something that ought to be artificially influenced either by constraint or encouragement.  Hitting the limit would be an artificial constraint, removing it ahead of (3) would be an encouragement, but for inflation it is a no-op.

Money is always in someone's hand. For consumers to spend and "circulate" money at a rapid rate, there needs to be a party willing to accept the currency. That is, the average per capita holding of currency will remain the same

[justusranvier]

This is what it boils down to: scarcity. There’s no room in Bitcoin for inflation of any kind. Other applications and whatnot can be built on top of it as is. It’s for the world to adapt and conform to Bitcoin, not the other way around.

I don't see transaction volume increase as a change in inflation so much as a change in velocity.  Henry Hazlitt who is credited with bringing Austrian Economic theory to the English speaking world, would I think agree that is not something that ought to be artificially influenced either by constraint or encouragement.  Hitting the limit would be an artificial constraint, removing it ahead of (3) would be an encouragement, but for inflation it is a no-op.

With some people, watching them wield economics terms of art they do not understand is like watching a child run with scissors.

[danielpbarron]

This is what it boils down to: scarcity. There’s no room in Bitcoin for inflation of any kind. Other applications and whatnot can be built on top of it as is. It’s for the world to adapt and conform to Bitcoin, not the other way around.

I don't see transaction volume increase as a change in inflation so much as a change in velocity.  Henry Hazlitt who is credited with bringing Austrian Economic theory to the English speaking world, would I think agree that is not something that ought to be artificially influenced either by constraint or encouragement.  Hitting the limit would be an artificial constraint, removing it ahead of (3) would be an encouragement, but for inflation it is a no-op.

With some people, watching them wield economics terms of art they do not understand is like watching a child run with scissors.

Your "understanding" is your stumbling block. There has never before been such a thing as bitcoin; your comparisons are moot. Block size does not correspond to velocity. It's never before been the case that in order to use a money, I'd need to have a copy of every previous transaction. Any attempt to equate bitcoin to something else comes from stupidity or malice. Or both.

[solex]

It's never before been the case that in order to use a money, I'd need to have a copy of every previous transaction.

Keeping a copy of every transaction is a temporary early state of Bitcoin, which looks like it will be 2009-15. After that most full nodes will be able to have a pruned version of the blockchain: a UTXO database, a full set of block headers, and a random, but complete, segment of the blockchain which can be 1%, 5%, 10%, whatever the full node owner decides.

A bootstrapping node will either be able to obtain the full blockchain from one the many archive nodes, which still have it, or build it from the segments held by numerous other nodes.

Constraining Bitcoin usage permanently because of a temporary reason is short-sighted and unnecessary.

[danielpbarron]

It's never before been the case that in order to use a money, I'd need to have a copy of every previous transaction.

Keeping a copy of every transaction is a temporary early state of Bitcoin, which looks like it will be 2009-15. After that most full nodes will be able to have a pruned version of the blockchain: a UTXO database, a full set of block headers, and a random, but complete, segment of the blockchain which can be 1%, 5%, 10%, whatever the full node owner decides.

A bootstrapping node will either be able to obtain the full blockchain from one the many archive nodes, which still have it, or build it from the segments held by numerous other nodes.

Constraining Bitcoin usage permanently because of a temporary reason is short-sighted and unnecessary.

Obviously I can't stop you from cutting your own legs off, but I will not follow suit.

The abomination you have described may coincidentally be compatible with my full node, but I wouldn't count on it, and I wouldn't call it bitcoin.

[justusranvier]

In order to serve its function, the Bitcoin doesn't need a permanent record of every transaction that has ever happened - it needs an unimpeachable proof that the supply of Bitcoins has been maintained as promised (this is another way of saying "preventing double spending").

Every node keeping a permanent record of every transaction ever is the simplest way to generate the proof.

It does not necessarily follow that this is the only way of possible way of preventing double spending.

[hdbuck]

In order to serve its function, the Bitcoin doesn't need a permanent record of every transaction that has ever happened - it needs an unimpeachable proof that the supply of Bitcoins has been maintained as promised (this is another way of saying "preventing double spending").

Every node keeping a permanent record of every transaction ever is the simplest way to generate the proof.

It does not necessarily follow that this is the only way of possible way of preventing double spending.

what is bitcoin's function?

[justusranvier]

what is bitcoin's function?

Money

[hdbuck]

what is bitcoin's function?

Money

hum i figured thats kinda too rudimental for such brilliant technology.