Bitcoin Forum
May 25, 2024, 09:14:26 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Why would miners change to 20MB blocks if they are geting revenues from fees ?  (Read 908 times)
knolix (OP)
Member
**
Offline Offline

Activity: 176
Merit: 10

MeVu


View Profile WWW
June 06, 2015, 12:24:03 PM
 #1

Why would miners change to 20MB blocks if they are geting revenues from fees?
If they don't change they will have more revenue as consumers will be forced to higher fees

unamis76
Legendary
*
Offline Offline

Activity: 1512
Merit: 1009


View Profile
June 06, 2015, 12:31:49 PM
 #2

The key here aren't the fees... Let's take your line of thought: would you risk the stability of the entire network just for fees?

If you're worried about fees, think like this: if/when the network gets saturated enough, you'll have many transactions and thus earn more from fees... Smiley
itsAj
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
June 06, 2015, 12:34:01 PM
 #3

Miners mine for the sake of the coins they earn through the actual POW phase not the fee return so like above the fees don't matter if the stability of the network goes then Bitcoin will be worthless.
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
June 06, 2015, 12:34:57 PM
 #4

As has been pointed out in so many of these topics Gavin is no longer suggesting 20MB but instead 4MB or 8MB (but carry on regardless).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
unamis76
Legendary
*
Offline Offline

Activity: 1512
Merit: 1009


View Profile
June 06, 2015, 01:00:40 PM
 #5

As has been pointed out in so many of these topics Gavin is no longer suggesting 20MB but instead 4MB or 8MB (but carry on regardless).


Whatever floats their boat is good for Bitcoin, we really need the block size increase Smiley
knolix (OP)
Member
**
Offline Offline

Activity: 176
Merit: 10

MeVu


View Profile WWW
June 06, 2015, 01:11:52 PM
 #6

Can miners change the block size from current software without updating to new version if the all agree on block size ?

unamis76
Legendary
*
Offline Offline

Activity: 1512
Merit: 1009


View Profile
June 06, 2015, 01:15:22 PM
 #7

Can miners change the block size from current software without updating to new version if the all agree on block size ?

There isn't any easy way for miners to just change the size above 1MB, so a update is needed
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
June 06, 2015, 01:15:47 PM
 #8

Can miners change the block size from current software without updating to new version if the all agree on block size ?

No - the current software has the fixed limit built in so they'd need to change software.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
S4VV4S
Hero Member
*****
Offline Offline

Activity: 1582
Merit: 502


View Profile
June 06, 2015, 01:19:20 PM
 #9

Can miners change the block size from current software without updating to new version if the all agree on block size ?

No - the current software has the fixed limit built in so they'd need to change software.


^^^ What Ian said.
And AFAIK nodes will reject blocks larger than 1mb - though I could be wrong.
anderson00673
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250



View Profile
June 06, 2015, 08:56:48 PM
 #10

The problem is that fees would have to increase quite a bit to slow trafic down enough for 1mb, at least they are projecting that in a year or two.  So you either pay a high fee which defeats one of the major advantages of bitcoins, you can flee to an alt, or you can just say f-it and go back to fiat.  Personally I think that not increasing the block size is in everyone's worst interest.
BitcoinExchangeIndia.com
Sr. Member
****
Offline Offline

Activity: 311
Merit: 264


View Profile
June 06, 2015, 09:47:15 PM
 #11

As has been pointed out in so many of these topics Gavin is no longer suggesting 20MB but instead 4MB or 8MB (but carry on regardless).


Can you please point me to the source where Gavin said it ?

achow101
Staff
Legendary
*
Offline Offline

Activity: 3402
Merit: 6657


Just writing some code


View Profile WWW
June 06, 2015, 10:07:57 PM
 #12

You can find it here: http://sourceforge.net/p/bitcoin/mailman/message/34162473/

I've also quoted it and bolded the part where he agrees to an 8 MB block size below:
Quote from: Gavin Andresen url=www.sourceforge.net/p/bitcoin/mailman/message/34162473/
On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang <1240902@...> wrote:

> I cannot believe why Gavin (who seems to have difficulty to spell my
> name correctly.) insists on his 20MB proposal regardless the
> community. BIP66 has been introduced for a long time and no one knows
> when the 95% goal can be met. This change to the block max size must
> take one year or more to be adopted. We should increase the limit and
> increase it now. 20MB is simply too big and too risky, sometimes we
> need compromise and push things forward. I agree with any solution
> lower than 10MB in its first two years.
>
>
Thanks, that's useful!

What do other people think?  Would starting at a max of 8 or 4 get
consensus?  Scaling up a little less than Nielsen's Law of Internet
Bandwidth predicts for the next 20 years?  (I think predictability is
REALLY important).

I chose 20 because all of my testing shows it to be safe, and all of my
back-of-the-envelope calculations indicate the costs are reasonable.

If consensus is "8 because more than order-of-magnitude increases are
scary" -- ok.


--
--
Gavin Andresen

ebliever
Legendary
*
Offline Offline

Activity: 1708
Merit: 1035


View Profile
June 07, 2015, 12:57:43 AM
 #13

In the long run I think miners will make more in fees if bitcoin grows and becomes more widely distributed, with a higher volume of transactions. Forcing a limited pool of people to pay higher transactions may make a cash cow in the short term, but  cause bitcoin to languish and shrivel over the long run. Whereas if bitcoin grows tenfold because of increased capacity, that should be reflected in proportionately greater fee revenue for the miners.

Luke 12:15-21

Ephesians 2:8-9
lemipawa
Legendary
*
Offline Offline

Activity: 1708
Merit: 1003


View Profile
June 07, 2015, 01:56:37 AM
 #14

In the long run I think miners will make more in fees if bitcoin grows and becomes more widely distributed, with a higher volume of transactions. Forcing a limited pool of people to pay higher transactions may make a cash cow in the short term, but  cause bitcoin to languish and shrivel over the long run. Whereas if bitcoin grows tenfold because of increased capacity, that should be reflected in proportionately greater fee revenue for the miners.
Exactly. As long as people use Bitcoin more and there are more transactions (the charts certainly show a rising trend) then the fees can stay the same keeping people happy, and miners will get more for including more transactions in blocks, which can only happen with bigger blocks.
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
June 07, 2015, 02:02:18 AM
 #15

the fees would actually be MORE if the volume is there and we can accomodate more transactions in a block...
so the question to me doesn't make any sense.

Malin Keshar
Hero Member
*****
Offline Offline

Activity: 616
Merit: 500


View Profile
June 07, 2015, 03:32:57 AM
 #16

Because if the network gets bottlenecked by transaction volume and people stop using Bitcoin, they will get less revenue.

And I think that right now people mine more because the 25 BTC block reward than because of the transaction fees
tvbcof
Legendary
*
Offline Offline

Activity: 4592
Merit: 1276


View Profile
June 07, 2015, 04:01:57 AM
 #17


As has been pointed out in so many of these topics Gavin is no longer suggesting 20MB but instead 4MB or 8MB (but carry on regardless).

The real deal is not what the jump happens to be, but rather the exponential growth and it's exponent.  Even very knowledgeable people who should know better seem to neglect this aspect of various block size increase proposals.

Watch the pea ya'all.


sig spam anywhere and self-moderated threads on the pol&soc board are for losers.
Agestorzrxx
Sr. Member
****
Offline Offline

Activity: 462
Merit: 250


View Profile
June 07, 2015, 08:25:52 AM
 #18

Why would miners change to 20MB blocks if they are geting revenues from fees?
If they don't change they will have more revenue as consumers will be forced to higher fees
Good point.
One of worst things of bitcoin is the miner. They do have the right to refuse to update the block size.
And they are the one who decide to update or not. As a bitcoin holder, if you are not a miner, you only can do it wait. you can'd decide anything. The right of miner are too big.
franky1
Legendary
*
Offline Offline

Activity: 4228
Merit: 4500



View Profile
June 07, 2015, 08:34:15 AM
 #19

Why would miners change to 20MB blocks if they are getting revenues from fees?
If they don't change they will have more revenue as consumers will be forced to higher fees

miners hate 20mb, not due to orphaning, not due to databloat, but purely because they cant blackmail people to pay a fee just to get into the very next block. after all if all 4000 tx's can all fit into a block of potential 80,000 tx's.. then miners can no longer black mail people with lame excuses of 2k-4k limits pressuring people to pay to guarantee first in line entry

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!