Bitcoin Forum
June 28, 2017, 02:29:54 PM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 [1549] 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1923339 times)
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
August 17, 2015, 04:52:21 PM
 #30961

564

Still no blocks though apparently. There needs to be statements from the pool operators telling miners how they are voting. Right now I think most are being neutral to not lose anyone (either way), but at some point miners will want to know what the pools plan to do so they can migrate to pools aligned with them.  

i've counted 3 pools so far.  it's early:

https://www.reddit.com/r/bitcoinxt/comments/3hbbxz/two_new_p2pools_you_can_join_mining_on_xt/

The reason P2Pool never took off is because it's performance and rewards are sub-optimal and pay out less than other pools (only slightly but it's been enough to keep P2Pool from having wide adoption. )

So far as I can tell none of the major pools have committed either way and no mined XT blocks have been found.
1498660194
Hero Member
*
Offline Offline

Posts: 1498660194

View Profile Personal Message (Offline)

Ignore
1498660194
Reply with quote  #2

1498660194
Report to moderator
POLONIEX TRADING SIGNALS
+50% Profit and more via TELEGRAM
ALTCOINTRADER.CO
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1498660194
Hero Member
*
Offline Offline

Posts: 1498660194

View Profile Personal Message (Offline)

Ignore
1498660194
Reply with quote  #2

1498660194
Report to moderator
1498660194
Hero Member
*
Offline Offline

Posts: 1498660194

View Profile Personal Message (Offline)

Ignore
1498660194
Reply with quote  #2

1498660194
Report to moderator
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
August 17, 2015, 04:57:26 PM
 #30962

People taking action at reddit against thermos

https://www.reddit.com/r/btc/comments/3hbmxz/theymos_is_breaking_3_rules_of_the_moddiquette_is/

It seems he has pretty clearly broken several basic rules for moderators. But reddit rarely takes action in these situations. I personally have only used reddit for /r/bitcoin. This is enough to make me simply delete my account and leave reddit entirely.

Then again this seems to work well enough
https://www.reddit.com/r/bitcoinxt/comments/3ha129/thoughts_on_normalizing_this_new_sub_and_killing/cu5t75i
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 17, 2015, 05:06:38 PM
 #30963

564

Still no blocks though apparently. There needs to be statements from the pool operators telling miners how they are voting. Right now I think most are being neutral to not lose anyone (either way), but at some point miners will want to know what the pools plan to do so they can migrate to pools aligned with them.  

i've counted 3 pools so far.  it's early:

https://www.reddit.com/r/bitcoinxt/comments/3hbbxz/two_new_p2pools_you_can_join_mining_on_xt/

The reason P2Pool never took off is because it's performance and rewards are sub-optimal and pay out less than other pools (only slightly but it's been enough to keep P2Pool from having wide adoption. )

So far as I can tell none of the major pools have committed either way and no mined XT blocks have been found.

this is true.  but i'd argue, this is exactly what we want to see and represents creative destruction in process.

disadvantaged p2pools are seeing an opportunity to level the playing field by attracting pro-XT hashers over to their pools to gain marketshare.  if we are correctly surmising the "economic majority" favoring XT, then large traditional pools need to be concerned with this migration if it occurs.  they stand to lose hashers.  of course, the flipside is true as well, by declaring one's use of XT software, they too could lose pro-Core hashers.  i still think XT is on the right side of this ultimately though.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 17, 2015, 05:15:59 PM
 #30964

564

Still no blocks though apparently. There needs to be statements from the pool operators telling miners how they are voting. Right now I think most are being neutral to not lose anyone (either way), but at some point miners will want to know what the pools plan to do so they can migrate to pools aligned with them.  

i've counted 3 pools so far.  it's early:

https://www.reddit.com/r/bitcoinxt/comments/3hbbxz/two_new_p2pools_you_can_join_mining_on_xt/

The reason P2Pool never took off is because it's performance and rewards are sub-optimal and pay out less than other pools (only slightly but it's been enough to keep P2Pool from having wide adoption. )

So far as I can tell none of the major pools have committed either way and no mined XT blocks have been found.

this is true.  but i'd argue, this is exactly what we want to see and represents creative destruction in process.

disadvantaged p2pools are seeing an opportunity to level the playing field by attracting pro-XT hashers over to their pools to gain marketshare.  if we are correctly surmising the "economic majority" favoring XT, then large traditional pools need to be concerned with this migration if it occurs.  they stand to lose hashers.  of course, the flipside is true as well, by declaring one's use of XT software, they too could lose pro-Core hashers.  i still think XT is on the right side of this ultimately though.

one other thing.  if hashers move to p2pool, what we'll get is increasing decentralization of mining, which would be a side effect of this split in ideology.  and not just by hashers moving away from larger pools but by adopting the p2pool concept in general.

that is a good thing.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 17, 2015, 05:17:57 PM
 #30965

573
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
August 17, 2015, 05:40:31 PM
 #30966

564

Still no blocks though apparently. There needs to be statements from the pool operators telling miners how they are voting. Right now I think most are being neutral to not lose anyone (either way), but at some point miners will want to know what the pools plan to do so they can migrate to pools aligned with them.  

i've counted 3 pools so far.  it's early:

https://www.reddit.com/r/bitcoinxt/comments/3hbbxz/two_new_p2pools_you_can_join_mining_on_xt/

The reason P2Pool never took off is because it's performance and rewards are sub-optimal and pay out less than other pools (only slightly but it's been enough to keep P2Pool from having wide adoption. )

So far as I can tell none of the major pools have committed either way and no mined XT blocks have been found.

this is true.  but i'd argue, this is exactly what we want to see and represents creative destruction in process.

disadvantaged p2pools are seeing an opportunity to level the playing field by attracting pro-XT hashers over to their pools to gain marketshare.  if we are correctly surmising the "economic majority" favoring XT, then large traditional pools need to be concerned with this migration if it occurs.  they stand to lose hashers.  of course, the flipside is true as well, by declaring one's use of XT software, they too could lose pro-Core hashers.  i still think XT is on the right side of this ultimately though.

one other thing.  if hashers move to p2pool, what we'll get is increasing decentralization of mining, which would be a side effect of this split in ideology.  and not just by hashers moving away from larger pools but by adopting the p2pool concept in general.

that is a good thing.

I think what is more likely is a small percentage of miners move to p2pool for this issue and then a larger pool adopts XT to both stop the blead and to capture share. Then the dam breaks
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 17, 2015, 05:42:40 PM
 #30967

564

Still no blocks though apparently. There needs to be statements from the pool operators telling miners how they are voting. Right now I think most are being neutral to not lose anyone (either way), but at some point miners will want to know what the pools plan to do so they can migrate to pools aligned with them.  

i've counted 3 pools so far.  it's early:

https://www.reddit.com/r/bitcoinxt/comments/3hbbxz/two_new_p2pools_you_can_join_mining_on_xt/

The reason P2Pool never took off is because it's performance and rewards are sub-optimal and pay out less than other pools (only slightly but it's been enough to keep P2Pool from having wide adoption. )

So far as I can tell none of the major pools have committed either way and no mined XT blocks have been found.

this is true.  but i'd argue, this is exactly what we want to see and represents creative destruction in process.

disadvantaged p2pools are seeing an opportunity to level the playing field by attracting pro-XT hashers over to their pools to gain marketshare.  if we are correctly surmising the "economic majority" favoring XT, then large traditional pools need to be concerned with this migration if it occurs.  they stand to lose hashers.  of course, the flipside is true as well, by declaring one's use of XT software, they too could lose pro-Core hashers.  i still think XT is on the right side of this ultimately though.

one other thing.  if hashers move to p2pool, what we'll get is increasing decentralization of mining, which would be a side effect of this split in ideology.  and not just by hashers moving away from larger pools but by adopting the p2pool concept in general.

that is a good thing.

I think what is more likely is a small percentage of miners move to p2pool for this issue and then a larger pool adopts XT to both stop the blead and to capture share. Then the dam breaks

yes, that is exactly what i was implying.
jmw74
Full Member
***
Offline Offline

Activity: 236


View Profile
August 17, 2015, 05:53:34 PM
 #30968

The reason P2Pool never took off is because it's performance and rewards are sub-optimal and pay out less than other pools (only slightly but it's been enough to keep P2Pool from having wide adoption. )

So far as I can tell none of the major pools have committed either way and no mined XT blocks have been found.

I mined a bit on p2pool and I'm pretty sure this is not true.

The rewards on p2pool are exactly the same as any other pool. There's larger variance than some pools, but honestly I have no idea why this is such a huge concern. It's as if people are going to mine for 1 minute only, and they want their 1 minute's worth of reward and they're not prepared to wait longer than that for the variance to even out.
Peter R
Legendary
*
Offline Offline

Activity: 1036



View Profile
August 17, 2015, 06:04:56 PM
 #30969

Hey Guys,

I'm thinking it's time for me to leave /r/bitcoin (or at least begin making an exit).  There seem to be three good migration choices:

/r/bitcoin_uncensored        1,403 subscribers

/r/bitcoinxt                      2,390 subscribers
 
/r/btc                              625 subscribers

On a strictly "what is the best name?" basis, I prefer /r/btc.  Bitcoin_uncensored will come across as dramatic and childish when this ordeal blows over and bitcoinxt will appear too tightly-coupled to a particular implementation of bitcoin (the very problem we are trying to avoid). 

So, I think I prefer /r/btc; however, it has the smallest readership at the moment.  What are other peoples' thoughts?

I unsubscribed from /r/bitcoin and subscribed to all of the above. Not sure which is the right path, but they are all better than thermos' Stalinist utopia. 

use this:  https://www.reddit.com/r/bitcoinxt/comments/3ha129/thoughts_on_normalizing_this_new_sub_and_killing/cu5ufhl

Awesome!  I didn't know you could do that.  For those that didn't follow the link, to create a "custom" reddit that shows the feeds more multiple subs, use:

https://www.reddit.com/r/Bitcoin+BTC+bitcoinXT+bitcoin_uncensored

Then, just remember to hit the back button when you're done browsing a post.  Using this technique we can naturally decentralize the Bitcoin discussion on reddit yet still view the important submission on a single webpage. 

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
August 17, 2015, 06:17:36 PM
 #30970

Picked a bad weekend to not check the forums.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 17, 2015, 06:21:39 PM
 #30971

Hey Guys,

I'm thinking it's time for me to leave /r/bitcoin (or at least begin making an exit).  There seem to be three good migration choices:

/r/bitcoin_uncensored        1,403 subscribers

/r/bitcoinxt                      2,390 subscribers
 
/r/btc                              625 subscribers

On a strictly "what is the best name?" basis, I prefer /r/btc.  Bitcoin_uncensored will come across as dramatic and childish when this ordeal blows over and bitcoinxt will appear too tightly-coupled to a particular implementation of bitcoin (the very problem we are trying to avoid). 

So, I think I prefer /r/btc; however, it has the smallest readership at the moment.  What are other peoples' thoughts?

I unsubscribed from /r/bitcoin and subscribed to all of the above. Not sure which is the right path, but they are all better than thermos' Stalinist utopia. 

use this:  https://www.reddit.com/r/bitcoinxt/comments/3ha129/thoughts_on_normalizing_this_new_sub_and_killing/cu5ufhl

Awesome!  I didn't know you could do that.  For those that didn't follow the link, to create a "custom" reddit that shows the feeds more multiple subs, use:

https://www.reddit.com/r/Bitcoin+BTC+bitcoinXT+bitcoin_uncensored

Then, just remember to hit the back button when you're done browsing a post.  Using this technique we can naturally decentralize the Bitcoin discussion on reddit yet still view the important submission on a single webpage. 

furthermore, if you use Bacon Reader on Android, you can set up what's called "multireddit" which does the same thing; merges all subreddits you wish to follow into one.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 17, 2015, 06:22:21 PM
 #30972

577
awemany
Newbie
*
Offline Offline

Activity: 28


View Profile
August 17, 2015, 06:30:53 PM
 #30973

Hi folks,

as announced and also proposed by Peter__R around here, I created the draft what should become a BIP on Bitcoin/Core for a completely user-defined limit.

Note that I didn't ask Peter__R yet but put him into the document as an author - so do not take it as his endorsement!

The link to the PDF is here:

https://github.com/awemany/bslconfig/releases/download/first-draft/bslconfig.pdf

And here is the link to the github repo, feel free to fork it and make it better (for example, fix the language of this non-native English speaker):

https://github.com/awemany/bslconfig/

I am looking forward to any feedback on this!

EDIT: I am sorry, new to github 'releases'. Links should work now!
domob
Legendary
*
Offline Offline

Activity: 974


View Profile WWW
August 17, 2015, 06:31:00 PM
 #30974

We have been reminded, by the pretention nodes, that there is always a risk of a largeblock being orphaned, especially the first one, then the next one that is larger, and so on. Not only due to timing, verification of the block, the technical stuff, but also the willingness of others to build on it. In business, the risk transforms directly to cost.

After a block of 2MB for example, the risk is reduced for blocks up to and including that exact size. We will therefore in the future see step increases in the blocksize, with retraction in between due to the varying demand. The typical leg up, stability, another leg up pattern, all market based.

Yes, tip  toeing forward according to fundamentals, both technical and economic.

"Step increases" and "top toeing forward" won't help much here.  If the main concern is acceptance of the larger block (which I think it is and which you seem to imply with the reference to pretention nodes), then 1.001 MB and 8 MB blocks are, roughly speaking, "the same".  A node either accepts both (if it allows larger blocks) or it rejects both (if it does not).  So while I agree that miners may be reluctant to accept (and especially build on their own) large blocks, I don't think there is any particular reason to "tip toe forward" once they are on a chain that is invalid according to the old rules.  Unless, of course, verification and relaying timing is a concern.  But then the fork should actually have never been done in the first place and XT failed already during the planning stage.

Use your Namecoin identity as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
HeliKopterBen
Hero Member
*****
Offline Offline

Activity: 622



View Profile
August 17, 2015, 07:11:42 PM
 #30975

Hi folks,

as announced and also proposed by Peter__R around here, I created the draft what should become a BIP on Bitcoin/Core for a completely user-defined limit.

Note that I didn't ask Peter__R yet but put him into the document as an author - so do not take it as his endorsement!

The link to the PDF is here:

https://github.com/awemany/bslconfig/releases/download/first-draft/bslconfig.pdf

And here is the link to the github repo, feel free to fork it and make it better (for example, fix the language of this non-native English speaker):

https://github.com/awemany/bslconfig/

I am looking forward to any feedback on this!

EDIT: I am sorry, new to github 'releases'. Links should work now!

This is a great idea and further adds to decentralization.  However, I think you may run into a problem if you don't have a preset default.  Many non-technical users or users that have not followed the debate may not understand this setting or be fully aware of all of its implications.  If the user enters 1 mb as the limit while the network is producing >1mb blocks, then they run the risk of getting routed to a bad fork.  I would suggest having a default despite perception of bias, to protect users only.  Perhaps you could even have no limit as the default.

For example, you could have two radio buttons.  One with a default value and the caption "choose this setting if you don't fully understand the block size limit."  The other that enables a text box or drop-down menu that let's the user input the block size limit of their choosing with the caption "advanced - leave blank for no limit" - or something similar.

Counterfeit:  made in imitation of something else with intent to deceive:  merriam-webster
awemany
Newbie
*
Offline Offline

Activity: 28


View Profile
August 17, 2015, 07:15:41 PM
 #30976

[...]
This is a great idea and further adds to decentralization.  However, I think you may run into a problem if you don't have a preset default.  Many non-technical users or users that have not followed the debate may not understand this setting or be fully aware of all of its implications.  If the user enters 1 mb as the limit while the network is producing >1mb blocks, then they run the risk of getting routed to a bad fork.  I would suggest having a default despite perception of bias, to protect users only.  Perhaps you could even have no limit as the default.

For example, you could have two radio buttons.  One with a default value and the caption "choose this setting if you don't fully understand the block size limit."  The other that enables a text box or drop-down menu that let's the user input the block size limit of their choosing with the caption "advanced - leave blank for no limit" - or something similar.

Thank you! I specifically worded it like I did because I think it only has a chance of adoption by staying as neutral as possible. Default == no limit won't fly with the Blockstreamers, but at least with the current edition, it should get them sweating for answers that do not eventually point to them being some bogus authorities.

And don't get me wrong: I agree on the issue of lack of user education. We need to make sure as the community then that new full node operators do not shoot themselves in the foot.

And, yes, personally if this ever gets accepted, I will argue for putting in a very high value (and maybe I should add a suggestion for a a 'max' setting?) with any new full node operator that I might interact with.

So, again, yes, I completely see your point, but I think this variant is the only one neutral enough to have a chance at acceptance or at least stirring things up. And before I get accused of being an agent of chaos by saying 'to stir things up': I mean it in the sense of furthering the blocksize discussion.
Peter R
Legendary
*
Offline Offline

Activity: 1036



View Profile
August 17, 2015, 07:28:18 PM
 #30977

We have been reminded, by the pretention nodes, that there is always a risk of a largeblock being orphaned, especially the first one, then the next one that is larger, and so on. Not only due to timing, verification of the block, the technical stuff, but also the willingness of others to build on it. In business, the risk transforms directly to cost.

After a block of 2MB for example, the risk is reduced for blocks up to and including that exact size. We will therefore in the future see step increases in the blocksize, with retraction in between due to the varying demand. The typical leg up, stability, another leg up pattern, all market based.

Yes, tip  toeing forward according to fundamentals, both technical and economic.

"Step increases" and "top toeing forward" won't help much here.  If the main concern is acceptance of the larger block (which I think it is and which you seem to imply with the reference to pretention nodes), then 1.001 MB and 8 MB blocks are, roughly speaking, "the same".  A node either accepts both (if it allows larger blocks) or it rejects both (if it does not).  So while I agree that miners may be reluctant to accept (and especially build on their own) large blocks, I don't think there is any particular reason to "tip toe forward" once they are on a chain that is invalid according to the old rules.  Unless, of course, verification and relaying timing is a concern.  But then the fork should actually have never been done in the first place and XT failed already during the planning stage.

I think Erdogan's insight into the game theory behind the block size limit was correct.

But to recognize his insight, I think we need to stop thinking in terms of "valid blocks" and start thinking in terms of "valid transactions."  All blocks that are composed exclusively of valid transactions are valid. 

Now instead of thinking that only Core and XT exist, imagine that there are dozens (and in the future possibly hundreds) of competing implementations of Bitcoin.  Each implementation has its own rules for what block size it will build upon.  From this viewpoint, the "effective limit" is the size of the largest block that's ever been included in the Blockchain.  If a miner wants to create a larger block (e.g., to collect more fees), then he has to weigh the chances that his block is orphaned with his desire to create a larger block.  If we imagine that the block size limit across the network forms some distribution as shown in the chart labelled "NEW THINKING" below, then, since the miner can't be 100% sure what this distribution is, it is rational for him to use the tip-toe method to minimize risk.



   

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
smoothie
Legendary
*
Offline Offline

Activity: 2030


LEALANA Monero Physical Silver Coins


View Profile
August 17, 2015, 07:35:55 PM
 #30978

577

what site are you getting these numbers from?

currently I see: 538 on https://getaddr.bitnodes.io/nodes/?q=/Bitcoin%20XT:0.11.0/

███████████████████████████████████████

            ,╓p@@███████@╗╖,           
        ,p████████████████████N,       
      d█████████████████████████b     
    d██████████████████████████████æ   
  ,████²█████████████████████████████, 
 ,█████  ╙████████████████████╨  █████y
 ██████    `████████████████`    ██████
║██████       Ñ███████████`      ███████
███████         ╩██████Ñ         ███████
███████    ▐▄     ²██╩     a▌    ███████
╢██████    ▐▓█▄          ▄█▓▌    ███████
 ██████    ▐▓▓▓▓▌,     ▄█▓▓▓▌    ██████─
           ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌          
           ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌          
    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─  
     ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩    
        ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀       
           ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀`          
                   ²²²                 
███████████████████████████████████████

. ★☆ WWW.LEALANA.COM        My PGP fingerprint is A764D833.        SMOOTHIE'S HEALTH AND FITNESS JOURNAL          History of Monero development Visualization ★☆ .
LEALANA  PHYSICAL MONERO COINS 999 FINE SILVER.
 
MarketNeutral
Sr. Member
****
Offline Offline

Activity: 364


View Profile
August 17, 2015, 07:37:45 PM
 #30979

Lest we forget, lead bitcoin devs Wladamir, Greg, and Pieter are opposed to GavinMikeCoin.
smoothie
Legendary
*
Offline Offline

Activity: 2030


LEALANA Monero Physical Silver Coins


View Profile
August 17, 2015, 07:38:39 PM
 #30980

We have been reminded, by the pretention nodes, that there is always a risk of a largeblock being orphaned, especially the first one, then the next one that is larger, and so on. Not only due to timing, verification of the block, the technical stuff, but also the willingness of others to build on it. In business, the risk transforms directly to cost.

After a block of 2MB for example, the risk is reduced for blocks up to and including that exact size. We will therefore in the future see step increases in the blocksize, with retraction in between due to the varying demand. The typical leg up, stability, another leg up pattern, all market based.

Yes, tip  toeing forward according to fundamentals, both technical and economic.

"Step increases" and "top toeing forward" won't help much here.  If the main concern is acceptance of the larger block (which I think it is and which you seem to imply with the reference to pretention nodes), then 1.001 MB and 8 MB blocks are, roughly speaking, "the same".  A node either accepts both (if it allows larger blocks) or it rejects both (if it does not).  So while I agree that miners may be reluctant to accept (and especially build on their own) large blocks, I don't think there is any particular reason to "tip toe forward" once they are on a chain that is invalid according to the old rules.  Unless, of course, verification and relaying timing is a concern.  But then the fork should actually have never been done in the first place and XT failed already during the planning stage.

I think Erdogan's insight into the game theory behind the block size limit was correct.

But to recognize his insight, I think we need to stop thinking in terms of "valid blocks" and start thinking in terms of "valid transactions."  All blocks that are composed exclusively of valid transactions are valid. 

Now instead of thinking that only Core and XT exist, imagine that there are dozens (and in the future possibly hundreds) of competing implementations of Bitcoin.  Each implementation has its own rules for what block size it will build upon.  From this viewpoint, the "effective limit" is the size of the largest block that's ever been included in the Blockchain.  If a miner wants to create a larger block (e.g., to collect more fees), then he has to weigh the chances that his block is orphaned with his desire to create a larger block.  If we imagine that the block size limit across the network forms some distribution as shown in the chart labelled "NEW THINKING" below, then, since the miner can't be 100% sure what this distribution is, it is rational for him to use the tip-toe method to minimize risk.



   


cost of mining a larger block = self regulating block sizes


███████████████████████████████████████

            ,╓p@@███████@╗╖,           
        ,p████████████████████N,       
      d█████████████████████████b     
    d██████████████████████████████æ   
  ,████²█████████████████████████████, 
 ,█████  ╙████████████████████╨  █████y
 ██████    `████████████████`    ██████
║██████       Ñ███████████`      ███████
███████         ╩██████Ñ         ███████
███████    ▐▄     ²██╩     a▌    ███████
╢██████    ▐▓█▄          ▄█▓▌    ███████
 ██████    ▐▓▓▓▓▌,     ▄█▓▓▓▌    ██████─
           ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌          
           ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌          
    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─  
     ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩    
        ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀       
           ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀`          
                   ²²²                 
███████████████████████████████████████

. ★☆ WWW.LEALANA.COM        My PGP fingerprint is A764D833.        SMOOTHIE'S HEALTH AND FITNESS JOURNAL          History of Monero development Visualization ★☆ .
LEALANA  PHYSICAL MONERO COINS 999 FINE SILVER.
 
Pages: « 1 ... 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 [1549] 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 »
  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!