Pages:
Author

Topic: Funding of network security with infinite block sizes - page 9. (Read 24563 times)

legendary
Activity: 1106
Merit: 1004
That doesn't make sense to me. The formula wouldn't need to be arbitrary; it could be based on actual data.

But the formula remains arbitrary. You can't come up with an algorithm capable of measuring actual demand and actual supply, since these units are impossible to measure. So you can't really know how many security is demanded (remember, demand is subjective!), nor how such demand would compete for Earth's scarce resources. You need to be omniscient to know all that.
 
If your sentiment were true the difficulty target wouldn't work.

The difficulty target aims to make one block at every 10min. But why 10min? This is an arbitrary value. It may be too much sometimes, too little at other times. It's certainly not optimal. That said, it's not such a big deal, and trying to improve it would not be worth the risks.

Concerning mining remuneration, if we can go directly to spontaneous order - and that's the closest you'll ever get from "optimal" -, then why not? Why try to come up with arbitrary formulas? That would be "presumption of knowledge".
Politically, a cap is a less radical departure from the soft and hard block limit which people know about. Psychologically, it maintains a perceived need to add fees, and might price out SD-like flooding.

SD is not flooding anything. They're not attacking the network, Bitcoin users want to use their services.
Of all business, they're likely the one that has mostly contributed to miners via transaction fees.

It also prevents the chance that an unexpected monster block gets accepted and built on causing problems for some miners.

Miners have no interest in keeping a "monster block". And they can easily choose not to build on top of such block, unless it is N blocks deep already, what would likely get the monster block rejected by the network.
legendary
Activity: 1078
Merit: 1006
100 satoshis -> ISO code
Block size is effectively infinite right now because they are nowhere near being full to the 500KB soft limit.
Bandwidth is NOT effectively infinite right now,...
-MarkM-

MarkM, I still read your posts because you embed enough useful feedback within your stream-of-consciousness padding to make it worthwhile, but it is a struggle at times.

Clearly bandwidth is finite, but the increase in propagation time between 50KB, 500KB or 5MB blocks is not very significant in a 10 minute time window. The increase in verification time seems to be the real limiting factor.

I used to support such idea, until I realize that a dynamic cap implies in an arbitrary formula, and that's an attempt to guess subjective demands and unpredictable supplies. It's impossible, and fortunately, not necessary.

The advantages are nice to have, not mission critical:
Politically, a cap is a less radical departure from the soft and hard block limit which people know about. Psychologically, it maintains a perceived need to add fees, and might price out SD-like flooding. It also prevents the chance that an unexpected monster block gets accepted and built on causing problems for some miners.


legendary
Activity: 1050
Merit: 1002
Have there been good arguments against a dynamic cap?

I used to support such idea, until I realize that a dynamic cap implies in an arbitrary formula, and that's an attempt to guess subjective demands and unpredictable supplies. It's impossible, and fortunately, not necessary.

That doesn't make sense to me. The formula wouldn't need to be arbitrary; it could be based on actual data. If your sentiment were true the difficulty target wouldn't work.
legendary
Activity: 1106
Merit: 1004
The fact that solutions are being proposed to a problem that can be so trivially shown not to exists calls into question the real motives of the people pushing said solutions.

I believe their motive is to try to convince those who want to cripple Bitcoin to a 1Mb block size limit that such crippling is not a good idea...

Have there been good arguments against a dynamic cap?

I used to support such idea, until I realize that a dynamic cap implies in an arbitrary formula, and that's an attempt to guess subjective demands and unpredictable supplies. It's impossible, and fortunately, not necessary.
legendary
Activity: 2940
Merit: 1090
Block size is effectively infinite right now because they are nowhere near being full to the 500KB soft limit.

Bandwidth is NOT effectively infinite right now, because there still exists at least one entity or nation on the planet that has enough bandwidth and processing power to process blocks.

Before it reaches effectively infinite, it will reach effectively too much for anyone other than the one global mega best at it cartel to handle.

-MarkM-
legendary
Activity: 2940
Merit: 1090
What orphan rate? Miners who cannot service the large population markets hardly even count, do they? If you are serving billions of people, who will even care that a bunch of third world nation peasants local miners fail to rubber-stamp megacorp's blocks?

Heck if merely having more bandwidth isn't enough to nuke the competition and gain a monopoly, why not buy some hashing power too fergoshsakes?

If your huge nuke the smaller people blocks aren't making you enough money to buy up a majority of hashing power too, maybe you aren't doing it right or are doing it too soon or are merely too bandwidth-centric and not balancing your bandwidth advantage with hashing advantage.

Maybe you can get together with number two and together try harder?

-MarkM-
legendary
Activity: 1400
Merit: 1013
The problem is the network cost is tiny, yet has nothing to do with the long-term cost of storing the UTXO set, and also is fixed so that profitability for larger, more centralized, pools is always higher than smaller pools.
There is a marginal cost to the miner for increasing the UTXO set in the form of capital investment of memory and fast storage to store it in. When the UTXO set gets large enough to be a problem miners will have an economic incentive to reduce their hardware costs by favouring transactions that shrink the set over those that grow the set.

Even the miners with lower capital costs will have an incentive to limit the size of the set because it affects the speed at which other nodes can validate their blocks and thus their orphan rate.
legendary
Activity: 1050
Merit: 1002
Block size is effectively infinite right now because they are nowhere near being full to the 500KB soft limit.

That's something that occurred to me too...

Empirical evidence is preferred over theoretical chains of cause and effect, and this shows a steady long-term increase in fees already. The chart below is in BTC, ignoring the USD equivalent one...
https://blockchain.info/charts/transaction-fees?showDataPoints=false×pan=&show_header=true&daysAverageString=7&scale=0&address=

What is being done in the field to increase fees, right now, is WORKING.

All that needs to happen is allow the 1MB to be replaced by a capping algorithm which just keeps pace ahead of demand. Then see what happens to fees. If they plateau at too low a level - then try to fix it. Why fix something which is not broken (except the need to avoid the sudden train wreck due to an arbitrary constant).

Have there been good arguments against a dynamic cap?
legendary
Activity: 1078
Merit: 1006
100 satoshis -> ISO code
Block size is effectively infinite right now because they are nowhere near being full to the 500KB soft limit.

Empirical evidence is preferred over theoretical chains of cause and effect, and this shows a steady long-term increase in fees already. The chart below is in BTC, ignoring the USD equivalent one...
https://blockchain.info/charts/transaction-fees?showDataPoints=false×pan=&show_header=true&daysAverageString=7&scale=0&address=

What is being done in the field to increase fees, right now, is WORKING.

All that needs to happen is allow the 1MB to be replaced by a capping algorithm which just keeps pace ahead of demand. Then see what happens to fees. If they plateau at too low a level - then try to fix it. Why fix something which is not broken (except the need to avoid the sudden train wreck due to an arbitrary constant).
legendary
Activity: 1050
Merit: 1002
I don't see that you've shown something I missed (not trying to be sarcastic). It sounds like you're describing my point.

Ah, you're saying that because miners have a time limit, they won't want to fill up their blocks.

What I'm saying, and now I think you do understand, is that mining is a random process so miners should send every block out with whatever transactions they included in it when they found the correct PoW; we're in agreement on that point.

However, without a limit, what reason do I have to send the miner a high fee in the first place? Provided marginal cost of including my transaction, based on network costs and the increased chance the block will be orphaned, is less than the fee I attached they'll include it. So naturally fees will settle down to that marginal cost. The problem is the network cost is tiny, yet has nothing to do with the long-term cost of storing the UTXO set, and also is fixed so that profitability for larger, more centralized, pools is always higher than smaller pools. The other side of the cost, the orphaning chance, goes down as fees go down, essentially because if fees aren't significant, the loss due to orphaning isn't significant either, so you can take more risks and try to stuff more low-fee transactions into your blocks.

It's a nasty race to the bottom - a textbook example of how capital intensive businesses where efficiency goes up as capital investment tends to result in oligopolies or monopolies in the long run.

OK, got it, thanks. Yes, I was missing something. That's what I get for reading too quickly. The following, which I quoted earlier, is actually right:

...

The argument is that unless there is a hard block size limit, miners are incentivised to include any transaction no matter how small its fee because the cost of doing so is practically zero (less than a microdollar, according to Gavins calculations). Therefore if a bunch of transactions stack up in the memory pool that pay a smaller percentage than "normal", some miner will include them anyway because it costs nothing to do so and maximizes short term profit. Hence, you get a race to the bottom and you need some kind of hard network rule saying you can't do that. We already have one in the form of block byte size, so the debate becomes "let's keep the size limit" vs "let's remove it".

In my mind I was thinking of this text from the OP:

One question that comes up often in the block size debate is how will mining be funded if there's no competition for block space.

I took that as meaning no fees, but the other quote is about low/marginal fees, not zero fees.

My response about blocks being limited by time addresses zero fees, not low fees, as miners will prioritize transactions with any fee (even if very low) first.

I see what you mean about the race to the bottom now for marginal fees. I remember reading that point in another debate thread.
legendary
Activity: 1120
Merit: 1152
I don't see that you've shown something I missed (not trying to be sarcastic). It sounds like you're describing my point.

Ah, you're saying that because miners have a time limit, they won't want to fill up their blocks.

What I'm saying, and now I think you do understand, is that mining is a random process so miners should send every block out with whatever transactions they included in it when they found the correct PoW; we're in agreement on that point.

However, without a limit, what reason do I have to send the miner a high fee in the first place? Provided marginal cost of including my transaction, based on network costs and the increased chance the block will be orphaned, is less than the fee I attached they'll include it. So naturally fees will settle down to that marginal cost. The problem is the network cost is tiny, yet has nothing to do with the long-term cost of storing the UTXO set, and also is fixed so that profitability for larger, more centralized, pools is always higher than smaller pools. The other side of the cost, the orphaning chance, goes down as fees go down, essentially because if fees aren't significant, the loss due to orphaning isn't significant either, so you can take more risks and try to stuff more low-fee transactions into your blocks.

It's a nasty race to the bottom - a textbook example of how capital intensive businesses where efficiency goes up as capital investment tends to result in oligopolies or monopolies in the long run.
legendary
Activity: 1050
Merit: 1002
Hang on a second. Am I missing something? I don't think miners need a hard block size limit to have incentive to stop accepting transactions. They will do so because there is always a time limit.

The difficulty target is adjusted to regulate time between blocks, and results in a target with a probability a correct hash will be found within a certain time (regardless the total hashing power of the network). Every second a miner waits to include more transactions in their block the probability is increased a competing miner will find a correct hash for their own block.

Yeah you're missing something.

Miners are always constantly hashing to try to find a new block that would include the most profitable set of transactions that they could include in that block. If they find a hash that meets the target they should immediately send the block they found to the network and start trying to find a hash that would build on the block they found.

Under no circumstance does it ever make sense to withhold a solution. If they find two blocks in a row, splitting the transactions they could have included in the blocks between the two blocks, that's actually better for the miner because it makes it harder for other miners to orphan those blocks, and thus collect the fees themselves.

You have to remember that mining is a random process. It's not like you work towards solving a block, it's more like you have this machine that spits out lottery tickets, and you are scratching them off as fast as possible hoping for a winner. You might get lucky and have two winners in a row, or unlucky and go for days before finding another one, but either way ever winner you do find you should cash in immediately however much it's worth.

I don't see that you've shown something I missed (not trying to be sarcastic). It sounds like you're describing my point.
legendary
Activity: 1120
Merit: 1152
Hang on a second. Am I missing something? I don't think miners need a hard block size limit to have incentive to stop accepting transactions. They will do so because there is always a time limit.

The difficulty target is adjusted to regulate time between blocks, and results in a target with a probability a correct hash will be found within a certain time (regardless the total hashing power of the network). Every second a miner waits to include more transactions in their block the probability is increased a competing miner will find a correct hash for their own block.

Yeah you're missing something.

Miners are always constantly hashing to try to find a new block that would include the most profitable set of transactions that they could include in that block. If they find a hash that meets the target they should immediately send the block they found to the network and start trying to find a hash that would build on the block they found.

Under no circumstance does it ever make sense to withhold a solution. If they find two blocks in a row, splitting the transactions they could have included in the blocks between the two blocks, that's actually better for the miner because it makes it harder for other miners to orphan those blocks, and thus collect the fees themselves.

You have to remember that mining is a random process. It's not like you work towards solving a block, it's more like you have this machine that spits out lottery tickets, and you are scratching them off as fast as possible hoping for a winner. You might get lucky and have two winners in a row, or unlucky and go for days before finding another one, but either way ever winner you do find you should cash in immediately however much it's worth.
legendary
Activity: 1050
Merit: 1002
I think that's rather harsh. People are processing Bitcoin problems (scalability, block size, etc.) in different parts, from different aspects, and with differing information. I don't think calling anything obvious is fair.
I didn't necessarily mean it should have been obvious to you, but it should be for the person you were quoting, especially since it's been brought up many times in the past.

Yes, that's what I meant. I've always believed the time between blocks factor was the thing giving miners incentive to broadcast hurriedly, but I don't recall reading that in any block size debate thread. That's what I mean about people processing problems from different aspects and with different information sets. How do you know most everyone has seen that point mentioned?
legendary
Activity: 1400
Merit: 1013
I think that's rather harsh. People are processing Bitcoin problems (scalability, block size, etc.) in different parts, from different aspects, and with differing information. I don't think calling anything obvious is fair.
I didn't necessarily mean it should have been obvious to you, but it should be for the person you were quoting, especially since it's been brought up many times in the past.
legendary
Activity: 1050
Merit: 1002
Hang on a second. Am I missing something? I don't think miners need a hard block size limit to have incentive to stop accepting transactions. They will do so because there is always a time limit.

The difficulty target is adjusted to regulate time between blocks, and results in a target with a probability a correct hash will be found within a certain time (regardless the total hashing power of the network). Every second a miner waits to include more transactions in their block the probability is increased a competing miner will find a correct hash for their own block.

When the network receives more than one valid block version within close time proximity it holds both and waits to see which is extended longest breaking the tie. Again, every second a miner waits to announce a block it increases the chance their found block won't be permanently regarded as valid. Physical block size is not a factor in that, and miners will naturally stuff their block with most profitable transactions first.
This is exactly true, and rather obvious.

The fact that solutions are being proposed to a problem that can be so trivially shown not to exists calls into question the real motives of the people pushing said solutions.

I think that's rather harsh. People are processing Bitcoin problems (scalability, block size, etc.) in different parts, from different aspects, and with differing information. I don't think calling anything obvious is fair.
legendary
Activity: 1400
Merit: 1013
Hang on a second. Am I missing something? I don't think miners need a hard block size limit to have incentive to stop accepting transactions. They will do so because there is always a time limit.

The difficulty target is adjusted to regulate time between blocks, and results in a target with a probability a correct hash will be found within a certain time (regardless the total hashing power of the network). Every second a miner waits to include more transactions in their block the probability is increased a competing miner will find a correct hash for their own block.

When the network receives more than one valid block version within close time proximity it holds both and waits to see which is extended longest breaking the tie. Again, every second a miner waits to announce a block it increases the chance their found block won't be permanently regarded as valid. Physical block size is not a factor in that, and miners will naturally stuff their block with most profitable transactions first.
This is exactly true, and rather obvious.

The fact that solutions are being proposed to a problem that can be so trivially shown not to exists calls into question the real motives of the people pushing said solutions.
legendary
Activity: 1050
Merit: 1002
...

The argument is that unless there is a hard block size limit, miners are incentivised to include any transaction no matter how small its fee because the cost of doing so is practically zero (less than a microdollar, according to Gavins calculations). Therefore if a bunch of transactions stack up in the memory pool that pay a smaller percentage than "normal", some miner will include them anyway because it costs nothing to do so and maximizes short term profit. Hence, you get a race to the bottom and you need some kind of hard network rule saying you can't do that. We already have one in the form of block byte size, so the debate becomes "let's keep the size limit" vs "let's remove it".

Hang on a second. Am I missing something? I don't think miners need a hard block size limit to have incentive to stop accepting transactions. They will do so because there is always a time limit.

The difficulty target is adjusted to regulate time between blocks, and results in a target with a probability a correct hash will be found within a certain time (regardless the total hashing power of the network). Every second a miner waits to include more transactions in their block the probability is increased a competing miner will find a correct hash for their own block.

When the network receives more than one valid block version within close time proximity it holds both and waits to see which is extended longest breaking the tie. Again, every second a miner waits to announce a block it increases the chance their found block won't be permanently regarded as valid. Physical block size is not a factor in that, and miners will naturally stuff their block with most profitable transactions first.

sr. member
Activity: 247
Merit: 250
The funding of network security is self-regulated via transaction fees.  If the network starts being attacked, people will either try to save it or cash out.  Saving it will mean increased transaction fees to pay for a higher hash rate.  No other mechanism is necessary.  Artificially limiting block size will only cause the network to be overpaying for security which will cause people to leave bitcoin for another currency.
legendary
Activity: 1120
Merit: 1152
If you're holding Bitcoins but not spending them, you're still using the services of the bitcoin network. The service being - in this case - storing your captial. You're relying on the activity in the network around you (the miners) to hold the value of that capital. Why shouldn't you pay for that service?

It's unfortunate that the economics of the PoW system have a kind of "asymmetrical warfare" aspect to them in that the amount of funds an attacker needs to spend to destroy the system with a 51% attack will always be far less than the value that they have destroyed. It's a simple market cap thing: if we spend 1% of the market cap per year on hashing power an attacker only needs to to spend just over 1% to attack the other 99% of value. Even if you assume the attacker can't rent the hashing power and that mining has a significant capital cost, you're probably looking at something like 5% of the market cap to attack the other 95%

An emergency proof of stake system is a doable option, but getting any of them to work - even the really simple pseudo-PoS idea of just prioritizing based on coin-age spent in the block - without requiring every node to have a UTXO set copy is going to be tricky.
Pages:
Jump to: