Bitcoin Forum
March 19, 2024, 05:34:13 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
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 ... 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 [1362] 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 ... 1557 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2032123 times)
sickpig
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile
June 23, 2015, 10:53:47 PM
 #27221



As far as I remember the debate about the max block size cap started a "long" time ago,
an it risked to stall indefinitely.

In my opinion Gavin's conduct has objectively an accelerating effect on the decision
process. I dare to say that such "extreme" attitude had stimulated a lot devs
in focusing to find a solution and to come to a compromise.

I'm not saying that his proposal is perfect or better than any others on the table, just
stating that his strategy have moved the situation toward a new equilibrium by a long shot.

I agree. Gavin's threat of a unilateral hardfork did successfully concentrate minds on coming up with solutions to the problem. How do you know that his intention was not to stage a dev-team coup? He behaved exactly as if he really intended to, nothing suggested otherwise (although I don't claim to be aware of every bit of public commentary Gavin has made, as previously mentioned, I am not a twitter user  Grin)

I don't know as any other person who based his opinion on fact. I can for sure observe public community  reactions to Gavin's behaviour, though.

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
1710826453
Hero Member
*
Offline Offline

Posts: 1710826453

View Profile Personal Message (Offline)

Ignore
1710826453
Reply with quote  #2

1710826453
Report to moderator
1710826453
Hero Member
*
Offline Offline

Posts: 1710826453

View Profile Personal Message (Offline)

Ignore
1710826453
Reply with quote  #2

1710826453
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710826453
Hero Member
*
Offline Offline

Posts: 1710826453

View Profile Personal Message (Offline)

Ignore
1710826453
Reply with quote  #2

1710826453
Report to moderator
1710826453
Hero Member
*
Offline Offline

Posts: 1710826453

View Profile Personal Message (Offline)

Ignore
1710826453
Reply with quote  #2

1710826453
Report to moderator
Odalv
Legendary
*
Offline Offline

Activity: 1400
Merit: 1000



View Profile
June 23, 2015, 10:56:57 PM
 #27222

that's quite encouraging.  the more i hear from this Rusty guy, the more i like him:

"Cheers,
Rusty.
PS. I work for Blockstream.  And I'm supposed to be working on
    Lightning, not this."


"this Rusty guy" is https://en.m.wikipedia.org/wiki/Rusty_Russell

to make a long story short he wrote Linux kernel packets filtering system ipchains/iptables (aka Linux firewall), lguest virtualization system (ancestor of docker/lxc) and contribute to samba/cifs  (a way to let Linux and ms win talk together), just to name a few.

edit: fix misattribution about samba/cifs projecf

no, i know who he is.  i like his independent spirit.

Wow, what happened. Do you like "for profit" and  "blockstream" developer ?

NO, I DON'T.

You have no clue how to develop software.
It seems you live in illusion and you even believe it is you and your "bitcointalk speculation thread" who developed bitcoin.
Adrian-x
Legendary
*
Offline Offline

Activity: 1372
Merit: 1000



View Profile
June 23, 2015, 10:57:21 PM
 #27223

But polls show that Gavin has a clear majority... its just certain core devs who object and not on technical grounds.  And most of them are working for a single organization.  How is that "hectoring a community"?


It isn't. Who said that?

There is a difference between "we need a hard fork to increase the block size" and "Gavin's plan is the way to do it, (which ever plan he settles upon)"

Most all the devs want a hard fork to increase block size.  Very few are on board with Gavin's plan.
Anyhow, it looks like the Bitcoin Core hard fork will be more likely to progress from gmaxwell's BIP, and the XT fork from Gavins perhaps.
They may remain compatible until there is a block that one would process and the other wouldn't.

You can include me in that contingent: we do need a hard fork to increase the block size (and only for what that will achieve, buying time). Very few people are debating that now, and I myself have been aware of the scalability issue for almost as long as I've been interested in bitcoin.

Re: which designs will be implemented on which fork; I thought Gavin had decided against the hostile fork?

the use of the term hostile is propaganda.

its not hostile, it's only hostile if you are feeling threatened like maybe the majority of Core developer working on another another hard fork and want to leverage block size increase with your proposed improvements.

if you're a user choosing the software to protect your investment is a way of expressing decentralization from a centralized control system run by the Core developers.  


Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1197



View Profile
June 23, 2015, 10:59:04 PM
 #27224

If he had done this, the blocksize limit would be set at 11.4 MB now and I bet everyone would be pretty happy.  It would just be taken for granted that "of course the limit grows with time because the systems grows with time too!"

More likely the 1 MB would have started at a much lower number as 1 MB was both overkill for near-term usage and hard to support with current technology at the time. 1 MB was clearly chosen with an expectation that it wouldn't be changed very soon. So given an autoscaling limit, it might well have been something more like 50K + 50%/year, giving us approximately 600K now.

FWIW, I think 600K would still be a reasonable limit for the present (if that were in effect we'd likely see better fee management tooling), but I also think something like 2-3 MB is reasonable, or maybe 1 MB plus 50% per year (or a tapering growth rate or something). As you say getting it exactly right is difficult and unnecessary.
Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
June 23, 2015, 11:02:04 PM
 #27225

If he had done this, the blocksize limit would be set at 11.4 MB now and I bet everyone would be pretty happy.  It would just be taken for granted that "of course the limit grows with time because the systems grows with time too!"

More likely the 1 MB would have started at a much lower number as 1 MB was both overkill for near-term usage and hard to support with current technology at the time. 1 MB was clearly chosen with an expectation that it wouldn't be changed very soon. So given an autoscaling limit, it might well have been something more like 50K + 50%/year, giving us more like 600K now.

FWIW, I think 600K would still be a reasonable limit for the present (if that were in effect we'd likely see better fee management tooling), but I also think something like 2-3 MB is reasonable, or maybe 1 MB plus 50% per year (or a tapering growth rate or something). As you say getting it exactly right is difficult and unnecessary.

Good point.  He likely would have started at a cap less than 1 MB (not sure about 50k though Wink).  Seems we both agree that getting it exactly right is unnecessary and difficult. 

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

Activity: 3430
Merit: 3068



View Profile
June 23, 2015, 11:05:41 PM
 #27226

I would rather see voting by miners done in the future for changes to be made in the future, than see guesses made today applied far into the future.

For readers who have studied feedback control systems:

   Q. How do you get a good closed-loop response?

   A. Start with a good open-loop one.  

The point is that the Bitcoin system will need tweaking (feedback) at some point in time in the future.  It is best if these tweaks are as small as possible.  That means that the guesses we make now about the future (realize that there's no way not to guess) should be as realistic as possible, thereby giving us a good open-loop response that needs as little feedback as possible to correct.  

There's a faint suggestion here that there is only one possible way to make bitcoin scale up, and it involves guessing which block size corresponds to which required rate of transactions. Which implies you believe the whole thing scales up using block size increases only. Is this really what you're implying?

No, I'm just trying to make the point that there's no way not to guess.  A lot of people think the "static" 1 MB limit is somehow neutral while a growing cap is more of a guess.  They're both guesses.  One will turn out to be more accurate than the other and thus require less tweaking going forward...

Ok, so if you accept that the blocksize is not the only solution to the problem, then would you also accept that your guess for the rate of block size increase can only be sensibly made when the overall context you are applying it to is known? i.e. design first how you intend to mitigate the problems that bigger blocks bring, then you come up with your goldilocks increase curve?

One that note, starting with a good open-loop response is not the only way to get a good closed-loop one.  There's another way: throw a lot of energy at your system!  Or in Bitcoin's case, a lot of debate and arguments!!    

If only raw hot air could solve this problem, we'd have finished with this probelm a long time ago  Cheesy

Vires in numeris
Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3068



View Profile
June 23, 2015, 11:10:55 PM
 #27227



As far as I remember the debate about the max block size cap started a "long" time ago,
an it risked to stall indefinitely.

In my opinion Gavin's conduct has objectively an accelerating effect on the decision
process. I dare to say that such "extreme" attitude had stimulated a lot devs
in focusing to find a solution and to come to a compromise.

I'm not saying that his proposal is perfect or better than any others on the table, just
stating that his strategy have moved the situation toward a new equilibrium by a long shot.

I agree. Gavin's threat of a unilateral hardfork did successfully concentrate minds on coming up with solutions to the problem. How do you know that his intention was not to stage a dev-team coup? He behaved exactly as if he really intended to, nothing suggested otherwise (although I don't claim to be aware of every bit of public commentary Gavin has made, as previously mentioned, I am not a twitter user  Grin)

I don't know as any other person who based his opinion on fact. I can for sure observe public community  reactions to Gavin's behaviour, though.

Well, the facts are that Gavin literally did just that; an alternative, hardforked client with a 20 MB block limit, and anyone from the core deve team that didn't like that could watch while he lobbies miners, services and merchants to accept the new client. That was what he said, he has not retracted it, nor confessed the ulterior motive you are affording him. Those are the facts, are they not?

Vires in numeris
Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3068



View Profile
June 23, 2015, 11:13:45 PM
 #27228

But polls show that Gavin has a clear majority... its just certain core devs who object and not on technical grounds.  And most of them are working for a single organization.  How is that "hectoring a community"?


It isn't. Who said that?

There is a difference between "we need a hard fork to increase the block size" and "Gavin's plan is the way to do it, (which ever plan he settles upon)"

Most all the devs want a hard fork to increase block size.  Very few are on board with Gavin's plan.
Anyhow, it looks like the Bitcoin Core hard fork will be more likely to progress from gmaxwell's BIP, and the XT fork from Gavins perhaps.
They may remain compatible until there is a block that one would process and the other wouldn't.

You can include me in that contingent: we do need a hard fork to increase the block size (and only for what that will achieve, buying time). Very few people are debating that now, and I myself have been aware of the scalability issue for almost as long as I've been interested in bitcoin.

Re: which designs will be implemented on which fork; I thought Gavin had decided against the hostile fork?

the use of the term hostile is propaganda.

its not hostile, it's only hostile if you are feeling threatened like maybe the majority of Core developer working on another another hard fork and want to leverage block size increase with your proposed improvements.

Telling the entire core dev team, the commercial bitcoin players and the bitcoin user community that if they didn't like it, they were powerless to stop him? This is friendly gesture in your eyes?

I'm not even being rhetorical using the word "hostile", Gavin and Mike's attitude was exactly that: hostile.

Vires in numeris
Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
June 23, 2015, 11:15:39 PM
 #27229

Ok, so if you accept that the blocksize is not the only solution to the problem, then would you also accept that your guess for the rate of block size increase can only be sensibly made when the overall context you are applying it to is known? i.e. design first how you intend to mitigate the problems that bigger blocks bring, then you come up with your goldilocks increase curve?

I think you changed the wording a bit.  I said no to this:

...you believe the whole thing scales up using block size increases only. Is this really what you're implying?

Which I took to mean that "I accept that off-chain solutions could play a role in the future to help with scaling."  I never meant to imply that I believed there could be a solution that doesn't involve blocksize scaling at all.  I think regardless of the role played by off-chain solutions, we must scale up the blocksize for all the good reasons DeathAndTaxes lists here.  Only later will we find out how much demand there is for off-chain TXs.    


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

Activity: 4564
Merit: 1276


View Profile
June 23, 2015, 11:19:16 PM
 #27230


One of the nice things about having a 'benevolent dictator' is that it will be much easier to make decisions about these things going forward.
...

My god, cheezes christ, what a socialist pile of crap.

These socialists should be forced to spread their wealth. 'Maybe like a dividend to be distributed to all existing addresses'.

Zikes!  You guys make some pretty strong arguments and have convinced me of the error of my ways.  Let it be known that I hereby drop my support (however brief) for switching Bitcoin to be under a 'benevolent dictator' and under XT.

Thanks for setting me right guys.


You're saying Mike Hearn was performing an altruistic power grab? That's not so terrible is it? Who wouldn't want one person to control the way their monetary system develops, the sort of person you can rely on to ignore everything that anyone else has to say and override it with a unilateral hard fork, all because that person knows better? What's wrong with Mike, with his superior understanding of what I want for myself, making more of my decisions for me? Why not all of them? He's a smart guy, and there's no way he'd make decisions on my behalf that benefit him.

My take was that Mike was nominating Gavin for the role, but they seem to have quite a good 'alignment' on solutions to 'problems'.  Apparently the two had been somewhat covertly meeting with various financial services and other captains of industry and there was a strong consensus that it would be better to have a 'point man' who they could rely on to make things happen in the Bitcoin ecosystem faster and more reliably.  One of the things I noted in Adam Back's characteristically polite and to-the-point note to Mike was him asking for more information on these meetings since most of rest of the developers were unaware of them and a bit surprised.


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

Activity: 420
Merit: 255


View Profile
June 23, 2015, 11:26:30 PM
 #27231


I like Satoshi's quote on this:

Quote from: satoshi
...
Coins have to get initially distributed somehow, and a constant rate seems like the best formula.
...
http://www.mail-archive.com/cryptography%40metzdowd.com/msg09979.html

The nonchalance, to me, indicates a nice trust in markets to do their job of optimizing allocation over time. But - if Bitcoin ever starts to become a serious global economic force, mainstream economists are going to flip out over the above quote, given the initial-distribution algo didn't go through some deep analysis, etc...  

I think it's interesting how the engineering decision of making a simple/transparent (easy to implement, thus more secure) distribution algorithm trumped any potential detailed economic complexity, presumably due to Satoshi's understanding that the market would eventually allocate the capital optimally anyways, given the transparency of the current and future supply.

One of the nice things about having a 'benevolent dictator' is that it will be much easier to make decisions about these things going forward.

We already know that in the noble interest of getting a 'critical mass' in order to 'outrun regulation', it is critical  to subsidize transaction costs.  We also know with some reasonable certainty that one of the early attractions of Bitcoin was that people could 'make free money' with only a token effort.  People like free shit.  Always will.

In order to spread the wealth there are two choices.

 - make more wealth and give it away (e.g., screw the obsolete 21 million cap thingy.)

 - appropriate existing or lost money and hand it out.

Idea!  We can be pretty sure that if/when XT takes over, coin tainting is not far behind.  Why don't we use the otherwise wasted value to pass around to the masses.  Maybe like a dividend to be distributed to all existing addresses.  To be more fair and reduce gaming, however, it makes sense that people would need to appropriately register their true identities in order to receive the dividend though.

You've just restated Gresham's Law.

Hard money is a delusion.

What you really want is soft money that is decentralized and thus remains permission-less (censorship-free).

Kudos for this post because you've influenced some of my thinking about perpetual debasement in such an idealized system.

My prior comments on this issue:

Subsidies are great if you want to get applicants who qualify, It should be called a subsidiary not a reward for good reason, the problem is there are developers who feel the economics are wrong and Bitcoin needs to be fixed, I may not be able to express why but to my understanding the mechanism seems well balanced and considered in my view, the onus is on the people who have a problem with how Bitcoin works to prove its broken, and build a better mousetrap not change this one.

My position is that it would be great if we could have started Bitcoin up without a block subsidy, but since the currency has to be issued via some method, and since the only way to produce a truly optimal initial distribution would require an entity that was both omnipotent and omniscient, issuing the currency via block subsidy spread out over time is the least terrible way to do it.

Other than the wealth effect, much of the real capital (at least initially until the NWO-directed ecosystem was bootstrapped) went to the utility, hardware, and usury industry to which miners are beholden. If that was the optimum way to bootstrap an ecosystem, then it was correct.

In my view, it was the only way to build a global ecosystem amongst conflicting interests because it is unassailable until it scales to the point where it becomes distributed but centralized, then at that point it can only be assailed by the TPTB.

Similarly, because 95% has been mined, I am not so sure that people will use bitcoin over an altcoin as a means of p2p transfer. It's supply in 2024 will be far too small to facilitate hundreds of million of people buying in to actually use it. Because by 2024, either the legacy rail has taken over and bitcoin is far too expensive relative to it's supply OR, it will not have happened and bitcoin will be worth nothing. Perhaps this is too simplistic an argument to make, but 10 years is not actually very long.

It didnt use to concern me, but it does now.

Unless they are given BTC loans. The masses have always used leveraged money (fractional reserves) and not real money, because the capitalists have all the real money.

The real game here is not changing whether the masses will use leveraged money. (nothing will ever change that)

It is the game of protecting the (knowledge age) capitalists from the State (industrial age capitalists+masses).

I have argued that a Knowledge Age is replacing the Industrial Age and the age of high fixed capital is being replaced by active knowledge. Knowledge capitalists don't want to be dictated to by a State because it is incompatible with knowledge production.

BitcoinIsLiberty
Newbie
*
Offline Offline

Activity: 55
Merit: 0


View Profile
June 23, 2015, 11:27:09 PM
 #27232

Perhaps the bitcoin economy has matured enough that a set max block size is not actually needed anymore?!

What if we had some type of patch that eliminated "silly sized blocks" and allowed miners to set any soft limit they want? Have it something like: allow any size as long as it's not more than x3 (or other number) the previous months average block size.

Market incentives will drive each mining pools soft limits. Increasing the limits will stimulate growth (increase centralization if done too fast compared to technology because of resources needed) while smaller blocks will increase fees. Some may like smaller blocks because of risk of orphans while others will want large blocks to grow the user base of people using bitcoins. Allowing a x3 size block means that as long as a minority are making small blocks, those who want larger ones can still help grow the "silly size" limit and those who have weak internet connections just have to download the blocks and can continue making small ones.

A spam attacker could only create large blocks that were bigger than all the pools soft limits only by mining it himself and the largest block he could create would be a x3 of the blocks on the system. And just like it's in their economic self interest to not get bigger than 51% it would also be in pools own self interest to not have a soft limit that would risk too much centralization of the system by making it too large for current technology and allows for the system to rapidly adapt at the time. The fact that most mining is done by pools means that the soft limit can be more fluid.

Ultimately if we let pools set any limit they want would they set limits that would allow bitcoin to thrive? If we assume the majority of pools act in the interest of a growing decentralized system would max block size be needed anymore other than something to prevent a "silly size" block?
Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
June 23, 2015, 11:40:33 PM
 #27233

Perhaps the bitcoin economy has matured enough that a set max block size is not actually needed anymore?!

What if we had some type of patch that eliminated "silly sized blocks" and allowed miners to set any soft limit they want? Have it something like: allow any size as long as it's not more than x3 (or other number) the previous months average block size.

Market incentives will drive each mining pools soft limits. Increasing the limits will stimulate growth (increase centralization if done too fast compared to technology because of resources needed) while smaller blocks will increase fees. Some may like smaller blocks because of risk of orphans while others will want large blocks to grow the user base of people using bitcoins. Allowing a x3 size block means that as long as a minority are making small blocks, those who want larger ones can still help grow the "silly size" limit and those who have weak internet connections just have to download the blocks and can continue making small ones.

A spam attacker could only create large blocks that were bigger than all the pools soft limits only by mining it himself and the largest block he could create would be a x3 of the blocks on the system. And just like it's in their economic self interest to not get bigger than 51% it would also be in pools own self interest to not have a soft limit that would risk too much centralization of the system by making it too large for current technology and allows for the system to rapidly adapt at the time. The fact that most mining is done by pools means that the soft limit can be more fluid.

Ultimately if we let pools set any limit they want would they set limits that would allow bitcoin to thrive? If we assume the majority of pools act in the interest of a growing decentralized system would max block size be needed anymore other than something to prevent a "silly size" block?


Welcome to the thread! 

I've seen ideas like "3x the average of the last N blocks" before.  I don't think it's necessarily a bad idea.  The problem I see, though, is that there's no hard limit at all in that case.  I predict that people will then want another limit on top of this 3x dynamic limit in order to feel safe.  Now we're back to the same place as we are now…but with increased complexity (dynamic + hard limit). 

That being said, I do think the risk of miners publishing "ginormous" blocks if there was no cap at all is small.  Based on real data, TradeBlock today estimated that it would take 137 seconds for a 8 MB block to propagate to half the nodes.  By the time a 100 MB spam-block propagated, miners would have found another two and the spam block would be orphaned.  The probability of success of such a spam attack is thus inversely proportional to the damage it can cause. 

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 255


View Profile
June 23, 2015, 11:41:17 PM
 #27234

cypherdoc changed his mind because Gavin did presumably.  Gavin did because it was easier to do this as quitely as possible than to try to change the laws of arithmetic.

Both of them know that it's the exponential growth that is the critical element here since it is pretty certain to sink Bitcoin eventually.  (Actually, cypherdoc may or may not know that or may or may not care much if he can make a buck in the interim.)

Quite clever wasn't it to start with 20MB then appear to compromise with some bloc of obscure "Chinese miners" who want 8MB and quietly slip in the exponential scaling.

Rothschilds (and the CIA) would be proud of the deception.

http://www.globalresearch.ca/editor-of-major-german-newspaper-says-he-planted-stories-for-the-cia/5429324

USG has no power abroad  Huh

smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1197



View Profile
June 23, 2015, 11:42:49 PM
 #27235

That being said, I do think the risk of miners publishing "ginormous" blocks if there was no cap at all is small.  Based on real data, TradeBlock today estimated that it would take 137 seconds for a 8 MB block to propagate to half the nodes.  By the time a 100 MB spam-block propagated, miners would have found another two and the spam block would be orphaned.  The probability of success of such a spam attack is thus inversely proportional to the damage it can cause. 

This is an incorrect or at least misleading analysis. The block doesn't need to propagate to 50% of the nodes, only 50% of the hash rate.

In the case of (simplifying for illustration here) two large pools that together constitute 50% of the hash rate, that could mean propagating to exactly one other node.
Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3068



View Profile
June 23, 2015, 11:44:30 PM
 #27236

Ok, so if you accept that the blocksize is not the only solution to the problem, then would you also accept that your guess for the rate of block size increase can only be sensibly made when the overall context you are applying it to is known? i.e. design first how you intend to mitigate the problems that bigger blocks bring, then you come up with your goldilocks increase curve?

I think you changed the wording a bit.  I said no to this:

...you believe the whole thing scales up using block size increases only. Is this really what you're implying?

Which I took to mean that "I accept that off-chain solutions could play a role in the future to help with scaling."  I never meant to imply that I believed there could be a solution that doesn't involve blocksize scaling at all.  I think regardless of the role played by off-chain solutions, we must scale up the blocksize for all the good reasons DeathAndTaxes lists here.  Only later will we find out how much demand there is for off-chain TXs.    



Sorry, I didn't mean off-chain solutions at all, the contenders there are perhaps too experimental and unproven to be planned around at this stage. I will refine the question: do you think bitcoin scales up to it's widest potential user base (everyone) using only block size increases, and remain peer to peer? We're all aware that's not possible, no?

Vires in numeris
Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
June 23, 2015, 11:44:46 PM
 #27237

That being said, I do think the risk of miners publishing "ginormous" blocks if there was no cap at all is small.  Based on real data, TradeBlock today estimated that it would take 137 seconds for a 8 MB block to propagate to half the nodes.  By the time a 100 MB spam-block propagated, miners would have found another two and the spam block would be orphaned.  The probability of success of such a spam attack is thus inversely proportional to the damage it can cause. 

This is an incorrect or at least misleading analysis. The block doesn't need to propagate to 50% of the nodes, only 50% of the hash rate.


I agree, but it's the data they cite.  So I used it.  I think we can still infer something from it.  

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

Activity: 1764
Merit: 1002



View Profile
June 23, 2015, 11:46:04 PM
 #27238

Perhaps the bitcoin economy has matured enough that a set max block size is not actually needed anymore?!

What if we had some type of patch that eliminated "silly sized blocks" and allowed miners to set any soft limit they want? Have it something like: allow any size as long as it's not more than x3 (or other number) the previous months average block size.

Market incentives will drive each mining pools soft limits. Increasing the limits will stimulate growth (increase centralization if done too fast compared to technology because of resources needed) while smaller blocks will increase fees. Some may like smaller blocks because of risk of orphans while others will want large blocks to grow the user base of people using bitcoins. Allowing a x3 size block means that as long as a minority are making small blocks, those who want larger ones can still help grow the "silly size" limit and those who have weak internet connections just have to download the blocks and can continue making small ones.

A spam attacker could only create large blocks that were bigger than all the pools soft limits only by mining it himself and the largest block he could create would be a x3 of the blocks on the system. And just like it's in their economic self interest to not get bigger than 51% it would also be in pools own self interest to not have a soft limit that would risk too much centralization of the system by making it too large for current technology and allows for the system to rapidly adapt at the time. The fact that most mining is done by pools means that the soft limit can be more fluid.

Ultimately if we let pools set any limit they want would they set limits that would allow bitcoin to thrive? If we assume the majority of pools act in the interest of a growing decentralized system would max block size be needed anymore other than something to prevent a "silly size" block?


That's my ultimate vote; no block size limit.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 255


View Profile
June 23, 2015, 11:49:07 PM
Last edit: June 24, 2015, 12:43:39 AM by TPTB_need_war
 #27239

Nope, it is confirmed there is no global elite.

http://armstrongeconomics.com/archives/33771


Whether the society and its elite is national or international or both is irrelevant. Relevant is: Do you promote the society (collectivism/paternalism) or the community (anarchy, self-sufficiency).

I promote the local and global community with my cryptocoin (and other technology) work and my concept of the coming Knowledge Age. But for you this must be absolute and preclude knowledge sharing in a "global community of exchange / sharing". The latter part is where we differ and you are all tied up into your Mathusianism which clouds your vision.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 255


View Profile
June 23, 2015, 11:51:31 PM
 #27240

That's my ultimate vote; no block size limit.

Then you hand Bitcoin Core to Circle, Coinbase, Paylay, etc which will flood it with micropayments to force the mining onto (perhaps Google's) powerful servers.

If you argue IBLT is a solution, it would just force the smaller nodes to let the powerful nodes do the transaction verification and censorship.

Pages: « 1 ... 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 [1362] 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 ... 1557 »
  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!