Bitcoin Forum
December 12, 2017, 01:03:19 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Proposal: dynamic max blocksize according to difficulty  (Read 2907 times)
99Percent
Full Member
***
Offline Offline

Activity: 190



View Profile
August 31, 2015, 08:57:45 PM
 #1

I propose a very simple solution to determine the new maximum blocksize:

Increase or decrease to the maximum blocksize at the same rate as how difficulty is increased or decreased. This can be set at every 2016 blocks or a multiple of such.

For example currently the blocksize is 1,000,000B and the difficulty rate of the last 20160 blocks has increased by 9.72%  (from 49,446,390,688 to 54,256,630,328) then the new block size = 1,097,277B

We could do an initial jump to 2MB, since I believe there is consensus that this is what is needed to begin with.

Rationale: Even though hardware advances do not exactly match in different computing areas, for example network vs computation speed, it is roughly similar (perhaps some research can be made) to the degree that it gives us at least some guidance as to what the network can support in terms of block relaying latency.

A very big advantage is that implementation would be trivial.

1513040599
Hero Member
*
Offline Offline

Posts: 1513040599

View Profile Personal Message (Offline)

Ignore
1513040599
Reply with quote  #2

1513040599
Report to moderator
1513040599
Hero Member
*
Offline Offline

Posts: 1513040599

View Profile Personal Message (Offline)

Ignore
1513040599
Reply with quote  #2

1513040599
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
99Percent
Full Member
***
Offline Offline

Activity: 190



View Profile
September 02, 2015, 04:25:14 AM
 #2

Either my idea is so bad its not worth commenting or its so good nobody has been able to find an objection?

What am I missing?

Lets explore this proposal a bit, by examining different scenarios.

1. The hash rate shoots through the roof and difficulty increase at a disproporcionate rate: The max blocksize also increases and the risk of spamming the blockchain becomes more plausible. But this risk is negated by the fact that blockchain itself is a lot stronger because of the increased hash rate. The network might not be able to sustain such mega blocks. However if blocks becomed orphaned and all the hashing that went into building such a block disappears from the aggregate calculating difficulty, so it contributes to a lower difficulty and consequently to lower max blocksize.

2. The demand for blockchain space increases at a faster rate than the difficulty: In this case there will be pressure in fees, so miners will have more profits and consequently more incentivize to invest in hardware for mining. It will then lead to higher hashrates and consequently larger max blocksize which will then satisfy the demand for blockchain space.

3. The amount of transactions fees fall, leading to lower miner income and thus lower hashrate and thus lower blocksizes.

In summary, the chain of causation is like this

Increasing:

More demand for blockchain space -> more transaction fees -> increased miner profits -> increase in mining investment -> more hashing power -> increased difficulty -> larger blocks

Decreasing:

Less transactions -> less transaction fees -> decreasing miner profits -> less miners hashing -> less hashing power -> lower difficulty -> smaller blocks sizes

Another way to explore this proposal is assuming it was adopted earlier:

Lets suppose this BIP was incorporated when Satoshi established the 1MB max blocksize. This was in July of 2010. The average blocksize was about 1k then. Satoshi decides to set the max blocksize at 2k. The difficulty was about 1,379,000 and the current difficulty is 54,256,630,328. If this proposal had been implemented then the current max blocksize would be: 2000 * 57,432,508,738 / 1,379,000 =832,958,792 bytes (832MB). Clearly this is not right and the reason for such a large disparity is that obviously bitcoin mining hardware has had a lot of catching up to do (CPU>GPU>FPGA>Asic>Huh). However I believe this to be nearing its maximum efficiency and closing in with Moore's Law.

Lets instead suppose this BIP was incorporated exactly one year ago.

The max block size was 1MB and difficulty 27,428,630,902. This is roughly to half of what is now, so the max blocksize now would be 2MB. A much more reasonable increase. In fact it would be a very healthy limit right now. There is an 80% consensus that this should be the minimum  max blocksize increase.

Also the economic dynamics will be much more applicable when the block reward subsidy is reduced.

Other advantages of this proposal:

1. Very clear and simple. Everyone can see what the impact of such a hard fork will be.
2. Changes in the max blocksize will be gradual and change at a predicted rate, much like how difficulty will affect the profitability of miners.
3. Trivial to implement and test in testnet.
4. Ties changes to the max blockchain to the strength of the bitcoin network itself. The more mining power there is, the bigger blocks can exists.
5. Allows for wallets to more easily determine the right transaction fee per kilobyte.
6. Gives us steady adjustments of max blocksize for the long term, without requiring another hard fork in a while at least.

A further way to refine this, which I think is even better (at the cost of a bit more complexity), is to factor in the block reward subsidy. I would propose a formula of new maxblocksize * (1 +(1 - coinbase/50)).

So when the block reward is 25 BTC the increases/decreases are reduced by 50% of the difficulty change. When the block reward is 12.5 BTC, max blocksize increase/decrease are reduced by 25% and so on. When we reach 0 BTC block rewards, the max blocksize becomes on par with the difficulty.

I really wish some input on my proposal. Even though there is a question of whether the hashrate can grow to accomodate to the increasing demand of transactions and therefore more space in the blockchain (transaction fees should pressure this in the end), I think this solution is vastly superior to the other proposals so far.
Was
Member
**
Offline Offline

Activity: 75

We are Satoshi.


View Profile
September 02, 2015, 04:56:05 AM
 #3

I like great ideas, but great ideas do not fair well on the forums.

Dynamic Block size with min. change to 2MB no doubt.

Whether or not the change is proportionate to difficulty of mining is not really what I would call relevant. The main concern is latency when blocks begin to get into the double digits but people overlook the added incentive of increased transaction volumes = increased incentive.

We could keep 1MB until it starts slowing down the network and then go to a Fibonacci Sequence that increases dynamically based upon whether the block size is deemed too small by Core. Say if Mempools start crashing Nodes etc...

1MB,2MB,3MB, 5MB,8MB, 13MB, 21MB etc

I really appreciate your time and contribution but I believe all the Core developers have already been bought out by Blockstream so they can be the First Lightning Network hub and take fees from miners and keep 1MB forever because they want to capitalize on the inability of the community to reach consensus without arguing.

People like you are who keep bitcoin going. Thank you. Remember, We Are Satoshi.

was

We Are Satoshi.
99Percent
Full Member
***
Offline Offline

Activity: 190



View Profile
September 02, 2015, 05:20:10 AM
 #4

I like great ideas, but great ideas do not fair well on the forums.
thanks
Quote

Dynamic Block size with min. change to 2MB no doubt.

Whether or not the change is proportionate to difficulty of mining is not really what I would call relevant. The main concern is latency when blocks begin to get into the double digits but people overlook the added incentive of increased transaction volumes = increased incentive.
As I said the problem with latency is resolved when blocks get orphaned by the miners. This affects difficulty directly because the hash rate is affected by the wasted block - the hashes that went into generating the discarded block are lost.
Quote
We could keep 1MB until it starts slowing down the network and then go to a Fibonacci Sequence that increases dynamically based upon whether the block size is deemed too small by Core. Say if Mempools start crashing Nodes etc...

1MB,2MB,3MB, 5MB,8MB, 13MB, 21MB etc
That seems to be a part of another suggestion to hard fork. You would need to elaborate.
Quote
I really appreciate your time and contribution but I believe all the Core developers have already been bought out by Blockstream so they can be the First Lightning Network hub and take fees from miners and keep 1MB forever because they want to capitalize on the inability of the community to reach consensus without arguing.
I really detest any suggestion of politics or buying out of core developers in this discussion. FWIW I fully support the Lightning Network. I think its a fantastic idea. The Lightning network also needs an increase in max blocksize btw.
Quote
People like you are who keep bitcoin going. Thank you. Remember, We Are Satoshi.

was
thanks
Was
Member
**
Offline Offline

Activity: 75

We are Satoshi.


View Profile
September 02, 2015, 05:28:40 AM
 #5

FWIW isn't Lightning Network a band-aid solution?

We Are Satoshi.
99Percent
Full Member
***
Offline Offline

Activity: 190



View Profile
September 02, 2015, 05:31:54 AM
 #6

FWIW isn't Lightning Network a band-aid solution?
No, far from it. I suggest you seriously look into it.
Carlton Banks
Legendary
*
Offline Offline

Activity: 1848



View Profile
September 02, 2015, 10:43:35 AM
 #7


I really appreciate your time and contribution but I believe all the Core developers have already been bought out by Blockstream so they can be the First Lightning Network hub and take fees from miners and keep 1MB forever because they want to capitalize on the inability of the community to reach consensus without arguing.

That's as it may be, but the other camp are far worse: the only significant supporters of BIP101 are commercial companies like Circle and Bitpay, who are variously funded by:

  • Goldman Sachs
  • Moneygram
  • Lightspeed Ventures (the company behind Ripple)

I know there are even more dubious interests involved with the BIP101 supporters, I will be researching it some time soon.



Blockstream are developing a whole range of ideas besides Lightning, any of which could become a competitor to Lightning, and so many more that have got nothing to do with scaling. Not only do the other contingents have no proposals like this on the table, but their main supporters have been "bought out" as you say by manifestly pernicious interests.

Bitcoin is about financial and monetary freedom, and that's not what Moneygram and Goldman Sachs are about.

Vires in numeris
goatpig
Legendary
*
Offline Offline

Activity: 1694

Armory Developer


View Profile
September 02, 2015, 11:18:21 AM
 #8

Generally this kind of proposals cannot function without a second factor, which is meant to define a resizing threshold.

How is your code supposed to distinguish between the release of a new ASIC and actual growth in block space demand?

Quote
However I believe this to be nearing its maximum efficiency and closing in with Moore's Law.

Not necessarily. Consider that Intel is a $55B business whereas the Bitcoin as a whole has a $3~4B market capitalization. We're not yet at a stage where professional chip manufacturers have an incentive to build ASICs.

And generally, what makes you believe block space demand will grow at least at the same pace as Moore's Law?

Your proposal has no thresholds. It simply links block size evolution to difficulty. I believe difficulty changes are a good metric to define by how much the block size should be changed, but difficulty is not a good enough metric to reflect block size demand.

You need another factor to track block size demand, and use that as a trigger for resizing. On top of that, a decay function would be preferable for when the resizing condition doesn't trigger. That's a safety harness that will correct the effect of spam attacks, large miners trying to game the system, and too large a jump in block ceiling.

NeuroticFish
Legendary
*
Offline Offline

Activity: 1330


Tooth Fairy, do you have an USB miner for me?


View Profile
September 02, 2015, 11:24:24 AM
 #9

1. I think that first we need to force the miners don't "run away" with finder's fee and a few transactions confirmed when there are old transactions waiting and max (current) size not filled yet.
This is a much bigger problem than block size, because the block size doesn't matter at all if miners don't use it well.

2. Then, maybe the block size could be adjusted - with some smart formula - to be bigger only when bigger is needed (edit: meaning when there are old transactions waiting for more than a certain time). So a "smart" BIP1xx.

.BITSLER.                 ▄███
               ▄████▀
             ▄████▀
           ▄████▀  ▄██▄
         ▄████▀    ▀████▄
       ▄████▀        ▀████▄
     ▄████▀            ▀████▄
   ▄████▀                ▀████▄
 ▄████▀ ▄████▄      ▄████▄ ▀████▄
█████   ██████      ██████   █████
 ▀████▄ ▀████▀      ▀████▀ ▄████▀
   ▀████▄                ▄████▀
     ▀████▄            ▄████▀
       ▀████▄        ▄████▀
         ▀████▄    ▄████▀
           ▀████▄▄████▀
             ▀██████▀
               ▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄            
▄▄▄▄▀▀▀▀    ▄▄█▄▄ ▀▀▄         
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄      
█  ▀▄▄  ▀█▀▀ ▄      ▀████   ▀▀▄   
█ █▄  ▀▄   ▀████       ▀▀ ▄██▄ ▀▀▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█  ▀▀       ▀▄▄ ▀████      ▄▄▄▀▀▀  █
█            ▄ ▀▄    ▄▄▄▀▀▀   ▄▄  █
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█ ▄▄   ███   ▀██  █           ▀▀  █ 
█ ███  ▀██       █        ▄▄      █ 
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  
▀▄            █        ▀▀      █  
▀▀▄   ███▄  █   ▄▄          █   
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀    
▀▀▄   █   ▀▀▄▄▄▀▀▀         
▄▄▄▄▄▄▄▄▄▄▄█▄▄▀▀▀▀              
              ▄▄▄██████▄▄▄
          ▄▄████████████████▄▄
        ▄██████▀▀▀▀▀▀▀▀▀▀██████▄
▄     ▄█████▀             ▀█████▄
██▄▄ █████▀                ▀█████
 ████████            ▄██      █████
  ████████▄         ███▀       ████▄
  █████████▀▀     ▄███▀        █████
   █▀▀▀          █████         █████
     ▄▄▄         ████          █████
   █████          ▀▀           ████▀
    █████                     █████
     █████▄                 ▄█████
      ▀█████▄             ▄█████▀
        ▀██████▄▄▄▄▄▄▄▄▄▄██████▀
          ▀▀████████████████▀▀
              ▀▀▀██████▀▀▀
            ▄▄▄███████▄▄▄
         ▄█▀▀▀ ▄▄▄▄▄▄▄ ▀▀▀█▄
       █▀▀ ▄█████████████▄ ▀▀█
     █▀▀ ███████████████████ ▀▀█
    █▀ ███████████████████████ ▀█
   █▀ ███████████████▀▀ ███████ ▀█
 ▄█▀ ██████████████▀      ▀█████ ▀█▄
███ ███████████▀▀            ▀▀██ ███
███ ███████▀▀                     ███
███ ▀▀▀▀                          ███
▀██▄                             ▄██▀
  ▀█▄                            ▀▀
    █▄       █▄▄▄▄▄▄▄▄▄█
     █▄      ▀█████████▀
      ▀█▄      ▀▀▀▀▀▀▀
        ▀▀█▄▄  ▄▄▄
            ▀▀█████
[]
Was
Member
**
Offline Offline

Activity: 75

We are Satoshi.


View Profile
September 02, 2015, 10:30:58 PM
 #10

Generally this kind of proposals cannot function without a second factor, which is meant to define a resizing threshold.

How is your code supposed to distinguish between the release of a new ASIC and actual growth in block space demand?

Quote
However I believe this to be nearing its maximum efficiency and closing in with Moore's Law.

Not necessarily. Consider that Intel is a $55B business whereas the Bitcoin as a whole has a $3~4B market capitalization. We're not yet at a stage where professional chip manufacturers have an incentive to build ASICs.

And generally, what makes you believe block space demand will grow at least at the same pace as Moore's Law?

Your proposal has no thresholds. It simply links block size evolution to difficulty. I believe difficulty changes are a good metric to define by how much the block size should be changed, but difficulty is not a good enough metric to reflect block size demand.

You need another factor to track block size demand, and use that as a trigger for resizing. On top of that, a decay function would be preferable for when the resizing condition doesn't trigger. That's a safety harness that will correct the effect of spam attacks, large miners trying to game the system, and too large a jump in block ceiling.

In addition, the "larger" Bitcoin becomes, the more incentive exists for any company that deals with money (I would assume most do) to invest in it remaining capable of handling transaction volume. This means dedicated internet connections for nodes and things of that nature. A business that deals with credit card processors, for example, save 3% a year, which can be put back into the business and increase the next years profits.

But I also believe Satoshi was correct in saying "I suspect we need a better incentive for users to run nodes instead of relying solely on altruism." Last month.

We Are Satoshi.
Was
Member
**
Offline Offline

Activity: 75

We are Satoshi.


View Profile
September 02, 2015, 10:37:32 PM
 #11

FWIW isn't Lightning Network a band-aid solution?
No, far from it. I suggest you seriously look into it.

Right, I've looked into it. It seems like instead of taking the necessary steps to outfit Bitcoin, nodes and miners with the ability to handle VISAs volume of transactions, we should just do transactions off-chain and trust Hubs? I don't believe this was a part of the creator's vision for bitcoin. Transactions large and small are supposed to be affordable to do on the blockchain, and if Lightning is adopted it would only be because of altruism or it is too expensive for people to use the blockchain.

Is this what we want? This all creates complications that people are fearful of.

Like keeping the internet strictly HTML forever in 2000 because most people only had 56k?

We Are Satoshi.
Carlton Banks
Legendary
*
Offline Offline

Activity: 1848



View Profile
September 02, 2015, 11:01:05 PM
 #12

FWIW isn't Lightning Network a band-aid solution?
No, far from it. I suggest you seriously look into it.

Right, I've looked into it. It seems like instead of taking the necessary steps to outfit Bitcoin, nodes and miners with the ability to handle VISAs volume of transactions, we should just do transactions off-chain and trust Hubs? I don't believe this was a part of the creator's vision for bitcoin. Transactions large and small are supposed to be affordable to do on the blockchain, and if Lightning is adopted it would only be because of altruism or it is too expensive for people to use the blockchain.

Is this what we want? This all creates complications that people are fearful of.

Like keeping the internet strictly HTML forever in 2000 because most people only had 56k?

Dynamic sizing is better then, because a successful implementation should cover all eventualities. If Lightning, and every other attempt at an overlay network, fail, then on-chain will be there. It's likely that all competing methods will find a balance, as long as the incentives are appropriately structured. It's a big ask though, I won't deny that.

Vires in numeris
99Percent
Full Member
***
Offline Offline

Activity: 190



View Profile
September 03, 2015, 03:53:20 AM
 #13

Generally this kind of proposals cannot function without a second factor, which is meant to define a resizing threshold.

How is your code supposed to distinguish between the release of a new ASIC and actual growth in block space demand?
When the hash rate increases because of new ASIC, the difficulty rises, this will allow for the max block size to increase. This increases supply so transaction fees go down, which will cause an increase in block space demand. All of which if you think it over, it makes sense. The bitcoin network has gotten stronger because of a massive increase of hash rate due to new ASIC, therefore it stands to reason it should support more transaction throughput.
Quote
Quote
However I believe this to be nearing its maximum efficiency and closing in with Moore's Law.

Not necessarily. Consider that Intel is a $55B business whereas the Bitcoin as a whole has a $3~4B market capitalization. We're not yet at a stage where professional chip manufacturers have an incentive to build ASICs.
Intel has been around for decades, bitcoin only 6 years, of which 3 has shown dramatic growth.
Quote
And generally, what makes you believe block space demand will grow at least at the same pace as Moore's Law?
It doesn't matter really at which rate block space demand grows. If it grows slowly, then transaction fees stay low and investment in mining will be low.
Quote
Your proposal has no thresholds. It simply links block size evolution to difficulty. I believe difficulty changes are a good metric to define by how much the block size should be changed, but difficulty is not a good enough metric to reflect block size demand.

You need another factor to track block size demand, and use that as a trigger for resizing. On top of that, a decay function would be preferable for when the resizing condition doesn't trigger. That's a safety harness that will correct the effect of spam attacks, large miners trying to game the system, and too large a jump in block ceiling.
Unfortunately we don't have any other metric to determine the max blocksize. All the other proposals so far only arbitrarily set this limit, or in the case of BIP 100 it gives the miners a way to set it via voting which the more I think about it, the more I tend to believe its a terrible idea.

I really appreciate your input. I have been obsessing over my solution for this max blocksize conundrum and I really think it is the best one by far.
99Percent
Full Member
***
Offline Offline

Activity: 190



View Profile
September 03, 2015, 04:30:46 AM
 #14

1. I think that first we need to force the miners don't "run away" with finder's fee and a few transactions confirmed when there are old transactions waiting and max (current) size not filled yet.
This is a much bigger problem than block size, because the block size doesn't matter at all if miners don't use it well.

2. Then, maybe the block size could be adjusted - with some smart formula - to be bigger only when bigger is needed (edit: meaning when there are old transactions waiting for more than a certain time). So a "smart" BIP1xx.

I have thought about this.

We can publish a bitcoin node that does not relay *new* blocks which have a certain percentage of transactions that were never seen in the mempool, and also blocks that are not near max blocksize if there are still many transactions with fees pending in the mempool. 

This will make miners very very afraid to mine mini blocks or with fake transactions (transactions that were never released to the mempool) since the risk of having their block orphaned increases exponentially against other miners who do mine the transactions that were in the mempool. This bitcoin node doesn't even have to be running, just the idea that it might be out there would be very frightening to miners.
NeuroticFish
Legendary
*
Offline Offline

Activity: 1330


Tooth Fairy, do you have an USB miner for me?


View Profile
September 03, 2015, 10:18:53 AM
 #15

1. I think that first we need to force the miners don't "run away" with finder's fee and a few transactions confirmed when there are old transactions waiting and max (current) size not filled yet.
This is a much bigger problem than block size, because the block size doesn't matter at all if miners don't use it well.

2. Then, maybe the block size could be adjusted - with some smart formula - to be bigger only when bigger is needed (edit: meaning when there are old transactions waiting for more than a certain time). So a "smart" BIP1xx.

I have thought about this.

We can publish a bitcoin node that does not relay *new* blocks which have a certain percentage of transactions that were never seen in the mempool, and also blocks that are not near max blocksize if there are still many transactions with fees pending in the mempool. 

This will make miners very very afraid to mine mini blocks or with fake transactions (transactions that were never released to the mempool) since the risk of having their block orphaned increases exponentially against other miners who do mine the transactions that were in the mempool. This bitcoin node doesn't even have to be running, just the idea that it might be out there would be very frightening to miners.


If this can be done, I'd propose to be done for real. Because if you say so, they may or may not believe you. Instead, if they indeed see this happening (blocks found, then rejected/orphaned) they'll stop playing with fire.

.BITSLER.                 ▄███
               ▄████▀
             ▄████▀
           ▄████▀  ▄██▄
         ▄████▀    ▀████▄
       ▄████▀        ▀████▄
     ▄████▀            ▀████▄
   ▄████▀                ▀████▄
 ▄████▀ ▄████▄      ▄████▄ ▀████▄
█████   ██████      ██████   █████
 ▀████▄ ▀████▀      ▀████▀ ▄████▀
   ▀████▄                ▄████▀
     ▀████▄            ▄████▀
       ▀████▄        ▄████▀
         ▀████▄    ▄████▀
           ▀████▄▄████▀
             ▀██████▀
               ▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄            
▄▄▄▄▀▀▀▀    ▄▄█▄▄ ▀▀▄         
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄      
█  ▀▄▄  ▀█▀▀ ▄      ▀████   ▀▀▄   
█ █▄  ▀▄   ▀████       ▀▀ ▄██▄ ▀▀▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█  ▀▀       ▀▄▄ ▀████      ▄▄▄▀▀▀  █
█            ▄ ▀▄    ▄▄▄▀▀▀   ▄▄  █
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█ ▄▄   ███   ▀██  █           ▀▀  █ 
█ ███  ▀██       █        ▄▄      █ 
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  
▀▄            █        ▀▀      █  
▀▀▄   ███▄  █   ▄▄          █   
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀    
▀▀▄   █   ▀▀▄▄▄▀▀▀         
▄▄▄▄▄▄▄▄▄▄▄█▄▄▀▀▀▀              
              ▄▄▄██████▄▄▄
          ▄▄████████████████▄▄
        ▄██████▀▀▀▀▀▀▀▀▀▀██████▄
▄     ▄█████▀             ▀█████▄
██▄▄ █████▀                ▀█████
 ████████            ▄██      █████
  ████████▄         ███▀       ████▄
  █████████▀▀     ▄███▀        █████
   █▀▀▀          █████         █████
     ▄▄▄         ████          █████
   █████          ▀▀           ████▀
    █████                     █████
     █████▄                 ▄█████
      ▀█████▄             ▄█████▀
        ▀██████▄▄▄▄▄▄▄▄▄▄██████▀
          ▀▀████████████████▀▀
              ▀▀▀██████▀▀▀
            ▄▄▄███████▄▄▄
         ▄█▀▀▀ ▄▄▄▄▄▄▄ ▀▀▀█▄
       █▀▀ ▄█████████████▄ ▀▀█
     █▀▀ ███████████████████ ▀▀█
    █▀ ███████████████████████ ▀█
   █▀ ███████████████▀▀ ███████ ▀█
 ▄█▀ ██████████████▀      ▀█████ ▀█▄
███ ███████████▀▀            ▀▀██ ███
███ ███████▀▀                     ███
███ ▀▀▀▀                          ███
▀██▄                             ▄██▀
  ▀█▄                            ▀▀
    █▄       █▄▄▄▄▄▄▄▄▄█
     █▄      ▀█████████▀
      ▀█▄      ▀▀▀▀▀▀▀
        ▀▀█▄▄  ▄▄▄
            ▀▀█████
[]
goatpig
Legendary
*
Offline Offline

Activity: 1694

Armory Developer


View Profile
September 03, 2015, 10:38:28 AM
 #16

When the hash rate increases because of new ASIC, the difficulty rises, this will allow for the max block size to increase. This increases supply so transaction fees go down, which will cause an increase in block space demand. All of which if you think it over, it makes sense. The bitcoin network has gotten stronger because of a massive increase of hash rate due to new ASIC, therefore it stands to reason it should support more transaction throughput.

Again there is no link between increased hash rate and block space demand. If a new ASIC tech is unleashed on the market tomorrow, why would transaction volume go up? Your local bank gets a new paint job, a larger parking lot, a McD right next to it and a larger safe, and your reaction is "ima purchase more goods and services"? Where is your extra purchasing power coming from? Isn't the fact that your bank is upgrading the result of the fees it's been charging its customers? What leads you to believe said customer are somehow wealthier as a result of this? If anything, shouldn't it be the opposite?

You have demonstrated yourself that if your algorithm was applied from day one, the current block size would be completely bloated and unrealistic. Your argument for supporting your method is that ASIC technology has caught up to its technological debt and is now dependent on Moore's law.

The implication is simple: difficulty growth is only a valid metric within certain bounds (that's your proposition, not mine, I'm just deducing). So again, how does your algorithm deals with situations where difficulty grows outside of its "healthy" bounds?

Quote
Intel has been around for decades, bitcoin only 6 years, of which 3 has shown dramatic growth.

That's not my point. My point is Intel is not building Bitcoin ASIC miners right now. If Bitcoin's market cap grows big enough for Intel to start building mining hardware, chances are difficulty will be growing much faster than Moore's law dictate for a few extra years.

Quote
It doesn't matter really at which rate block space demand grows. If it grows slowly, then transaction fees stay low and investment in mining will be low.

The fee market is not an end in and of itself. It is a mean to support certain network mechanics, one of which is to pay miners enough to have acceptable blockchain security. Not just security, but high enough that it is more profitable for a brute force attacker to just mine blocks than to try and rewrite block history.

You should design your proposal with the purpose of the fee market as your goal, not to simply sustain any fee market.

Quote
Unfortunately we don't have any other metric to determine the max blocksize.

There are plenty of other metrics in the blockchain to represent block space demand. Over a difficulty period consider total fees paid, average fee density, UTXO set, total value transfered, average value per UTXO, straight up average block size. Plenty of stuff to get creative with.

99Percent
Full Member
***
Offline Offline

Activity: 190



View Profile
September 04, 2015, 02:50:07 PM
 #17

When the hash rate increases because of new ASIC, the difficulty rises, this will allow for the max block size to increase. This increases supply so transaction fees go down, which will cause an increase in block space demand. All of which if you think it over, it makes sense. The bitcoin network has gotten stronger because of a massive increase of hash rate due to new ASIC, therefore it stands to reason it should support more transaction throughput.
Again there is no link between increased hash rate and block space demand. If a new ASIC tech is unleashed on the market tomorrow, why would transaction volume go up? Your local bank gets a new paint job, a larger parking lot, a McD right next to it and a larger safe, and your reaction is "ima purchase more goods and services"? Where is your extra purchasing power coming from? Isn't the fact that your bank is upgrading the result of the fees it's been charging its customers? What leads you to believe said customer are somehow wealthier as a result of this? If anything, shouldn't it be the opposite?
Thanks again for replying.

Remember that currently the market for transactions is distorted severely because of the block reward subsidy. As it goes down, transactions fees become much more significant and will further force the miner to consider which transaction to add to his block. More hashing power makes the bitcoin network stronger, so everyone benefits. More users can lead to increase of bitcoin price, etc
Quote
Quote
It doesn't matter really at which rate block space demand grows. If it grows slowly, then transaction fees stay low and investment in mining will be low.

The fee market is not an end in and of itself. It is a mean to support certain network mechanics, one of which is to pay miners enough to have acceptable blockchain security. Not just security, but high enough that it is more profitable for a brute force attacker to just mine blocks than to try and rewrite block history.

You should design your proposal with the purpose of the fee market as your goal, not to simply sustain any fee market.

Quote
Unfortunately we don't have any other metric to determine the max blocksize.

There are plenty of other metrics in the blockchain to represent block space demand. Over a difficulty period consider total fees paid, average fee density, UTXO set, total value transfered, average value per UTXO, straight up average block size. Plenty of stuff to get creative with.

Unfortunately we cannot use transaction data (volume, fees etc) or block sizes as a metric because these can be manipulated by the miners themselves leading to tragedy of commons scenarios. UTXO sizes can also be manipulated with fake transactions. But if we could some how force the miners to always include transactions that had appeared it the mempool, or at least make it a risk not too then this problem would be solved.
goatpig
Legendary
*
Offline Offline

Activity: 1694

Armory Developer


View Profile
September 06, 2015, 08:25:19 AM
 #18

Remember that currently the market for transactions is distorted severely because of the block reward subsidy. As it goes down, transactions fees become much more significant and will further force the miner to consider which transaction to add to his block. More hashing power makes the bitcoin network stronger, so everyone benefits. More users can lead to increase of bitcoin price, etc

Higher price commands higher difficulty. The other way around is not true. You cannot deduce price has increased because difficulty went up. The only thing it means is that profitability per hash has increased. A wealth of factors can affect that, not just price.

An increase in price itself does not equate to an increase in block space demand. The tps can go up when price goes down and vice versa. There is no economic evidence of the contrary.

Your proposal has to account for situations when reality contradicts the meaning you give your indicators. I agree that in general, in the absence of a coinbase reward, a growth in difficulty will mean an increase in fee subsidy, and thus block space demand.

However, that does not always stand true, and you need a contingency plan for when that is the case. This is actually a pretty uncommon situation right now, as fee subsidy are about 1% of miner revenue. How much of a solution is your proposal if it only works when the stars align? Some people choose to discuss proposals for the now, others prefer to work on solutions that can also withstand the absence of inflation. However at this rate, you are designing a solution that will only start to make sense in some 20 odd years.

Quote
Unfortunately we cannot use transaction data (volume, fees etc) or block sizes as a metric because these can be manipulated by the miners themselves leading to tragedy of commons scenarios.

Not really. The emergence of relay networks and IBLT largely increases the cost of these attacks. To fake transaction volume under these conditions means a miner needs to emit txs to himself to recover its own fees. The implies they can't publish these transactions publicly until they are mined, or other miners will pick them up and end making the ill intentioned miner actually pay for the attack. However, relay networks and IBLT produce a coding gain in block propagation by forwarding block content before a solution is found, i.e. each miner is telling others what tx set they are working on.

A miner deliberately slowing down his propagation is exposing himself to a lot of natural orphaning, and past a certain point, he is so easy to identify and such a nuisance that other miners have motivation to just out right orphan him on purpose. Add a decay function on top of it and not only miners will have to pay for spam attacks like any other spammer, but their effort will also be lost in the mid term, as the decay function will correct the effect of the attack.

Quote
But if we could some how force the miners to always include transactions that had appeared it the mempool, or at least make it a risk not too then this problem would be solved.

That's inane. the first and best spam filter is letting miners pick transactions based on economic factors. As long as the incentives are not completely warped, this system works. What you are proposing is making any tx spam attack completely trivial. It would also make DoS attacks by high OPs count and low size tx very effective. A lot more than currently, as they can easily be thwarted by their own nature: low miner profit.

NeuroticFish
Legendary
*
Offline Offline

Activity: 1330


Tooth Fairy, do you have an USB miner for me?


View Profile
September 07, 2015, 04:55:50 PM
 #19

Quote
But if we could some how force the miners to always include transactions that had appeared it the mempool, or at least make it a risk not too then this problem would be solved.

That's inane. the first and best spam filter is letting miners pick transactions based on economic factors. As long as the incentives are not completely warped, this system works. What you are proposing is making any tx spam attack completely trivial. It would also make DoS attacks by high OPs count and low size tx very effective. A lot more than currently, as they can easily be thwarted by their own nature: low miner profit.

OK, but does this look correct to you? : some pools got the finder fee + a few transactions and moved on, while people were crying on forum(s) that their transaction is stuck for .. days, though they paid the normal fee or even more in some cases (certainly I don't care about the transactions tried out with 0 fee, those are on their own risk).

So while some miners / pools played fair, some not. And this is something that has to be fixed / enforced.


And then the "spam attacks" or "test" like done not that long ago should not cause so much trouble. And then they could stop (because if nobody notices, it's costly, and boring, and useless).

.BITSLER.                 ▄███
               ▄████▀
             ▄████▀
           ▄████▀  ▄██▄
         ▄████▀    ▀████▄
       ▄████▀        ▀████▄
     ▄████▀            ▀████▄
   ▄████▀                ▀████▄
 ▄████▀ ▄████▄      ▄████▄ ▀████▄
█████   ██████      ██████   █████
 ▀████▄ ▀████▀      ▀████▀ ▄████▀
   ▀████▄                ▄████▀
     ▀████▄            ▄████▀
       ▀████▄        ▄████▀
         ▀████▄    ▄████▀
           ▀████▄▄████▀
             ▀██████▀
               ▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄            
▄▄▄▄▀▀▀▀    ▄▄█▄▄ ▀▀▄         
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄      
█  ▀▄▄  ▀█▀▀ ▄      ▀████   ▀▀▄   
█ █▄  ▀▄   ▀████       ▀▀ ▄██▄ ▀▀▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█  ▀▀       ▀▄▄ ▀████      ▄▄▄▀▀▀  █
█            ▄ ▀▄    ▄▄▄▀▀▀   ▄▄  █
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█ ▄▄   ███   ▀██  █           ▀▀  █ 
█ ███  ▀██       █        ▄▄      █ 
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  
▀▄            █        ▀▀      █  
▀▀▄   ███▄  █   ▄▄          █   
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀    
▀▀▄   █   ▀▀▄▄▄▀▀▀         
▄▄▄▄▄▄▄▄▄▄▄█▄▄▀▀▀▀              
              ▄▄▄██████▄▄▄
          ▄▄████████████████▄▄
        ▄██████▀▀▀▀▀▀▀▀▀▀██████▄
▄     ▄█████▀             ▀█████▄
██▄▄ █████▀                ▀█████
 ████████            ▄██      █████
  ████████▄         ███▀       ████▄
  █████████▀▀     ▄███▀        █████
   █▀▀▀          █████         █████
     ▄▄▄         ████          █████
   █████          ▀▀           ████▀
    █████                     █████
     █████▄                 ▄█████
      ▀█████▄             ▄█████▀
        ▀██████▄▄▄▄▄▄▄▄▄▄██████▀
          ▀▀████████████████▀▀
              ▀▀▀██████▀▀▀
            ▄▄▄███████▄▄▄
         ▄█▀▀▀ ▄▄▄▄▄▄▄ ▀▀▀█▄
       █▀▀ ▄█████████████▄ ▀▀█
     █▀▀ ███████████████████ ▀▀█
    █▀ ███████████████████████ ▀█
   █▀ ███████████████▀▀ ███████ ▀█
 ▄█▀ ██████████████▀      ▀█████ ▀█▄
███ ███████████▀▀            ▀▀██ ███
███ ███████▀▀                     ███
███ ▀▀▀▀                          ███
▀██▄                             ▄██▀
  ▀█▄                            ▀▀
    █▄       █▄▄▄▄▄▄▄▄▄█
     █▄      ▀█████████▀
      ▀█▄      ▀▀▀▀▀▀▀
        ▀▀█▄▄  ▄▄▄
            ▀▀█████
[]
99Percent
Full Member
***
Offline Offline

Activity: 190



View Profile
September 07, 2015, 06:48:03 PM
 #20

Remember that currently the market for transactions is distorted severely because of the block reward subsidy. As it goes down, transactions fees become much more significant and will further force the miner to consider which transaction to add to his block. More hashing power makes the bitcoin network stronger, so everyone benefits. More users can lead to increase of bitcoin price, etc

Higher price commands higher difficulty. The other way around is not true. You cannot deduce price has increased because difficulty went up. The only thing it means is that profitability per hash has increased. A wealth of factors can affect that, not just price.

An increase in price itself does not equate to an increase in block space demand. The tps can go up when price goes down and vice versa. There is no economic evidence of the contrary.

Your proposal has to account for situations when reality contradicts the meaning you give your indicators. I agree that in general, in the absence of a coinbase reward, a growth in difficulty will mean an increase in fee subsidy, and thus block space demand.

However, that does not always stand true, and you need a contingency plan for when that is the case. This is actually a pretty uncommon situation right now, as fee subsidy are about 1% of miner revenue. How much of a solution is your proposal if it only works when the stars align? Some people choose to discuss proposals for the now, others prefer to work on solutions that can also withstand the absence of inflation. However at this rate, you are designing a solution that will only start to make sense in some 20 odd years.
That is why after thinking a bit more, the max blocksize increases according to difficulty must factor in the current subsidy coming from the block reward by coinbase. I thought of 100% when we reach 0 BTC per block (in 2140) and 75% now at 25 BTC per block. But I realize this is very arbitrary. Then again all other proposals out there are even more arbitrary.
Quote
Quote
Unfortunately we cannot use transaction data (volume, fees etc) or block sizes as a metric because these can be manipulated by the miners themselves leading to tragedy of commons scenarios.

Not really. The emergence of relay networks and IBLT largely increases the cost of these attacks. To fake transaction volume under these conditions means a miner needs to emit txs to himself to recover its own fees. The implies they can't publish these transactions publicly until they are mined, or other miners will pick them up and end making the ill intentioned miner actually pay for the attack. However, relay networks and IBLT produce a coding gain in block propagation by forwarding block content before a solution is found, i.e. each miner is telling others what tx set they are working on.

A miner deliberately slowing down his propagation is exposing himself to a lot of natural orphaning, and past a certain point, he is so easy to identify and such a nuisance that other miners have motivation to just out right orphan him on purpose. Add a decay function on top of it and not only miners will have to pay for spam attacks like any other spammer, but their effort will also be lost in the mid term, as the decay function will correct the effect of the attack.
Very true and it is very likely that as difficulty increases, the risk for orphaned blocks becomes more significant, specially when the block reward subsidy goes down. So in the end maybe this whole problem about increasing the max block size is overblown. I am tending to think now, lets just go to hard fork to 8MB and kick the can for a long term solution, to several years from now.
Quote
Quote
But if we could some how force the miners to always include transactions that had appeared it the mempool, or at least make it a risk not too then this problem would be solved.

That's inane. the first and best spam filter is letting miners pick transactions based on economic factors. As long as the incentives are not completely warped, this system works. What you are proposing is making any tx spam attack completely trivial. It would also make DoS attacks by high OPs count and low size tx very effective. A lot more than currently, as they can easily be thwarted by their own nature: low miner profit.
Sorry I misstated what I meant to say. What I meant is if we could force the miners to only include transactions seen in the mempool (not ALL transactions), so that miners cannot include bogus tx that only pay fees to themselves with the purpose of manipulating the discussed metrics.  But I cannot think of any way to do this, basically because different nodes can have different sets of transactions in their mempool because it is designed that new transactions that will cause a double spend be discarded.
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!