Bitcoin Forum
December 09, 2016, 11:45:45 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [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 ... 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 [514] 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1807089 times)
impulse
Full Member
***
Offline Offline

Activity: 151


View Profile
August 07, 2014, 12:25:43 AM
 #10261

If the transaction throughput was not limited in the original design the original design was flawed. Removing the transaction limit from Bitcoin could be it's undoing.

Miners still get to decide which transactions that they want to include, and bloating blocks with too many transactions limits propagation times, which is why we even now we are seeing block sizes artificially limited. Even if there were no limit, I don't believe that miners would choose to include every transaction if it were not in their interest or if it in any way imposed a penalty on them. Furthermore, we have only two choices moving forward, both of which are just different versions of the same beast, either a) block size is limited and by necessity most transactions are pushed off the blockchain and managed by large "centralized" transaction processing companies like BitPay and Coinbase; or b) Block limits are raised and transactions of any size can be transmitted to the blockchain directly, at the expense of large "centralized" mining companies like ghash.io. Personally, I prefer the option b.

Mining is a marginal activity and always will be. As the network grows it will be in the best interest of all participants to have a functioning protocol, and large companies in the space will undoubtedly subsidize large mining operations in order to ensure that the network continues to support their other business needs. I am not worried about mining centralization.

Sorry if some of this escapes me, but is there not some kind of "option c" wherein transaction fees scale dynamically to limit abuse? I guess this could make bitcoin unfriendly to microtransactions (one of it's finer points) and maybe easy to get around by scripting different origination addresses for each transaction if it were some kind of per-address limitation. Hmmm.

But let me better understand the current situation; Miners are already excluding transactions that are not worth their while? I assume they are doing this on the basis of fees paid? If this is the case, it would seem that removing the limit wouldn't change anything.... right? I mean, spammy transactions can already be assigned low priority and pushed into other blocks, so wouldn't that mitigate the problem all on it's own? Or is the fear that this could be abused by one of these entities spamming high fee transactions to themselves, solving the block making it "free", and thus excluding legitimate transactions? If this were the case, I don't see how a block size limit is doing anything to prevent this....

Option c is really just option b. I think that what you have outlined is exactly right, miners DO decide what to include, and right now there are minimum fees that all nodes enforce (not just miners) to prevent spamming. The fear is that by raising the limit, you raise the burden of maintaining a "full node", which reduces the number of full nodes and thus the reduces the number of participants enforcing the network rules, and the other consensus mechanisms. Removing the limit would make no difference to the miners really, they make their own rules.
1481283945
Hero Member
*
Offline Offline

Posts: 1481283945

View Profile Personal Message (Offline)

Ignore
1481283945
Reply with quote  #2

1481283945
Report to moderator
1481283945
Hero Member
*
Offline Offline

Posts: 1481283945

View Profile Personal Message (Offline)

Ignore
1481283945
Reply with quote  #2

1481283945
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Adrian-x
Legendary
*
Offline Offline

Activity: 1330



View Profile
August 07, 2014, 12:25:51 AM
 #10262

Sorry if some of this escapes me, but is there not some kind of "option c" wherein transaction fees scale dynamically to limit abuse?

ironical the commodity in short supply that we are talking about preserving is space and bandwidth, charging transaction fees to reword miners does nothing to curb the miners from taking advantage of the limited space.

now if miners had to buy a claim to mine from a full node then fees would reflect the available bandwidth and space on the web.  

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
impulse
Full Member
***
Offline Offline

Activity: 151


View Profile
August 07, 2014, 12:28:57 AM
 #10263

Miners still get to decide which transactions that they want to include...

And some miners do stupid things.  "BCPool" created 17,976 single-satoshi dust outputs from that "1Enjoy" address by mining a bunch of spam transactions in block #309657 and again in block #309740.  Assuming each output is 50 bytes, that's 17,976 x 50 B = ~1 MB of garbage that will possibly forever sit in each node's RAM, as ouputs are not prunable if they never get spent (and these ones cost more to spend than they are worth!).  

I'm not saying the limit shouldn't be raised, I'm just trying to present some empirical data that illustrates some things that have gone wrong.  

Code:
BLOCK #309740:  10,486 DUST OUTPUTS
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS    
===================================================================================================================                      
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2b6112e73cbe0937a1b60c9abfc4c2ca6e26b2612c90ec598b1cd28787a553e 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5e5d17901378b8835861d8cc0df2b5f9bf3c86759c3821f96470cd852344d799 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2bf7525618ed5402024d5bff6f477a2093965d3f11ececbc2b6a9b5bbe1f5d5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3df8f4a7e06486bb3b0700935a16fc6d4fad397dcb6c88b9c4b6a7453301aa54 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ae05ddfc8aa206b213c71ec0e96723dcd4ff03a71ca76b469d225d1c60d9e262 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f75b455b4df94bcdcd54985b4aeea9948d2a1dca0f63c65b85ad2d941050c5cf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ee61b911610f66f539832699fbbf4ab3955c8bd5ad0cfa570ff500dedcde5bf8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a22186cbcf82cac66da17183209f20f76088934c931bec131fe71ad2f250e8f8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 0469286403543b7d794fe52661135a80142c47ac541793c703fd637a4e9dc0bf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a71dc9abd8bae377b661b0c288222acf2ab62fc7bf96b0bab2dd5354fbc91643 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f437d94c1cfe818c44f4505f3e6506839113ec747d815a867e953a4164276047 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z eb95d902eb841ce23c9c1466e010cbb05d43d1c248376440f9dd56ee1bc8b3e5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b62416ceb3453d6dcba95213e4e222915438a4b70eba37e09099110b20be0d52 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f3aba1c064e9c9a1d49db3bce42c07c184a0b329366994000fa49f0bc8f3ba16 749

BLOCK #309657: 7,490 DUST OUTPUTS
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS    
===================================================================================================================  
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 2e7fdb43e2a0fe17cfe2d283a2da4d375204700aef4bf2c31056125f4383b121 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3d1105d7c2cd36705b2163fa2d0f74973377467aefea72156a30444f330acf71 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5c4e56943f3128629ebecb41f5916bd7bc1dceaccc37f29e59c385464f2bf558 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 536adfb745ffaa8c1fb698414475f5ca7d82846eadd912cfe0a76045d78c3198 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 45c7544374e88de47d9be2e3e100f4aa10aafd9469c4dba8d55a870f83c312ab 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z e7ae2378a44a940a8c872a63e43fa67c5a023df4df3f9ca8011611422fc2861c 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z d864e3cc07dc79f221bd91210b274e136159ccbb5c9eafad906d9d08c5558ce5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3dedbc086d5cfc81bd3614a1b3fab1bb4d73d8982d9552e811f84f0118a1fc12 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 7337d7ac353a9283c65a1ab99d28f97997784a0fb26d0dc0b59f2fa2556c4460 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 634a7fdcba3fe91da07f44e6b9bee1c659cbfca27076bd8b61984d062c071651 749


Sure, I'm not actually in favor of no limits either, but I am in favor of increased block sizes.
Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
August 07, 2014, 12:45:22 AM
 #10264

Sure, I'm not actually in favor of no limits either, but I am in favor of increased block sizes.

Me too.  

...right now there are minimum fees that all nodes enforce (not just miners) to prevent spamming….

This isn't quite right, and it's part of the worry.  A miner could mine a block that is 100% non-standard spam transactions regardless of fees and it would still be accepted as valid since nodes accept non-standards blocks and miners build on top of them.  Blocks #309657 and #309740 are proof of this.  The spam filters are achieved with the isStandard() method call and only prevent nodes from relaying transactions without the requisite fees or those that include dust outputs--these TXs can still get mined though.    

In case anyone's interested, currently about a third of the UTXO database is spam (a lot from SatoshiDice before the dust limits were implemented).  


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

Activity: 1498



View Profile WWW
August 07, 2014, 12:48:59 AM
 #10265

If the transaction throughput was not limited in the original design the original design was flawed. Removing the transaction limit from Bitcoin could be it's undoing.

I've always found your posts insightful and I know that you are a very intelligent person; I'm interested in your rationale for keeping the blocksize static.  

The argument that "if the blocksize doesn't really matter, then why was a limit added?" seems valid to me.  A smaller blocksize also limits growth of the UTXO database, which is actually the more critical resource.  I'd like to see a healthy fee market develop along with a push towards off-chain transactions (perhaps using m-of-n Oracle sidechains).  A smaller blocksize would incentivize that.  That being said, Solex recently presented a helpful graphic that showed the increase in internet bandwidth since bitcoin's inception, indicating that 3MB blocks now would represent the same % of typically-available BW as 1 MB blocks did in 2009.  So the argument can be made that "we can safely increase the blocksize in parallel with internet speeds."  The Metcalfe value chart also shows a strong correlation between TXs per day and market cap, so an empirically-based argument can be made that limiting bitcoin's TX bandwidth would also limit its value.  

One point you made that I think is not valid is the notion that a 1 MB blocksize is a core part of the coin's definition (i.e., part of the "Satoshi Social Contract" in the same way the 21 M coin limit is).  There's plenty of evidence that indicates the 1 MB limit was never intended to be permanent.  Of course, this doesn't mean that it's necessarily a good idea to increase it without careful thought and debate either.  

Okay sure Smiley

For miners, the cost lies not in including transactions. Say the situation where a miner includes n transactions in a block or n+1 is equivalent in cost*. The cost for a miner lies in hashing the block with a nonce so the hash starts with a certain number of zeros (the difficulty).

Anyway, if I am a miner and I'm hashing away, I'm going to include every single transaction that pays any fee whatsoever in the block I'm hashing (if the block size is unlimited) simply because it costs me nothing to add the transaction and it does increase the amount I'm gaining when I find the right hash. Therefore, considering the situation with no size limit for a block and a set of rational miners all transactions will have a long term transaction fee of 1 Satoshi (or whatever the minimum unit is for the transaction in that time in the future).

Therefore the miners will receive payment of 1 Statoshi*the number of transactions for their job of securing the network and I believe this is insufficient as it would require 25*6*24/1^-8= 3.6*10^11 transactions daily to match the current block rewards. Granted, the exchange rate will increase in that time but not by a factor >10^6 (a factor 10^6 would imply $580M per Bitcoin).

Of course, in today's situation not all transactions are accepted even though we haven't touched the limit yet. This is because miners are not yet acting rationally but merely accepting the default recommended transaction fee guidelines proposed by the devs. This makes sense because the subsidy is still so high in comparison. It's a bit naive to think this situation will continue indefinitely though with an infinitely decreasing block subsidy.

Conclusion: for transaction fees to ever pay for the securing of the network a limit on the block chain is indispensable. Granted, this limit could have been larger than 1MB. However, if we increase it now, this will make it easier to increase it in the future as well because we create a precedent. As such it would continuously increase undermining the whole system. It would be like saying: we'll increase the maximum available Bitcoins to 100M. yes we'll only do it this once. Sure  Roll Eyes no-one will believe that.

The actual numbers may be arbitrary. Keeping them static however is far more important than people in this topic seem to realize.

Anyway, please tell me I'm wrong. I love being wrong Smiley. Please explain to me why anyone would pay a transaction fee above 1 Satoshi when the block subsidy has run out and the block size is not limited.

*I'm simplifying the situation here for number of transactions to be able to talk about it more naturally. It seems obvious the same holds for number of bytes in the block.

wachtwoord
Legendary
*
Offline Offline

Activity: 1498



View Profile WWW
August 07, 2014, 12:51:45 AM
 #10266

Sure, I'm not actually in favor of no limits either, but I am in favor of increased block sizes.

If we increase the limit every time we run into it we effectively have no limit.

impulse
Full Member
***
Offline Offline

Activity: 151


View Profile
August 07, 2014, 12:54:44 AM
 #10267

Sure, I'm not actually in favor of no limits either, but I am in favor of increased block sizes.

Me too.  

...right now there are minimum fees that all nodes enforce (not just miners) to prevent spamming….

This isn't quite right, and it's part of the worry.  A miner could mine a block that is 100% non-standard spam transactions regardless of fees and it would still be accepted as valid since nodes accept non-standards blocks and miners build on top of them.  Blocks #309657 and #309740 are proof of this.  The spam filters are achieved with the isStandard() method call and only prevent nodes from relaying transactions without the requisite fees or those that include dust outputs.  

In case anyone's interested, currently about a third of the UTXO database is spam (a lot from SatoshiDice before the dust limits were implemented).  



Yes, a valid correction, and these are the reasons why block limits are still important.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
August 07, 2014, 01:03:11 AM
 #10268

Say the situation where a miner includes n transactions in a block or n+1 is equivalent in cost*.
This situation does not exist.

The cost is very real and not-insubstantial - the increased orphan risk which you completely glossed over above.

The marginal cost can - and should - be brought very low but it will never reach zero.

The amount of transactions a miner can process in a ten minute interval is finite, therefore it is scarce, therefore the service of including transactions in a block will always have a price.
Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
August 07, 2014, 01:03:26 AM
 #10269

Anyway, please tell me I'm wrong. I love being wrong Smiley. Please explain to me why anyone would pay a transaction fee above 1 Satoshi when the block subsidy has run out and the block size is not limited.

Because of the orphan cost.  Each kB added to your block increases its propagation time and thus the probability that it will be orphaned.  

Consider the question "is it profitable to include another 500 kB of TXs (and keep the extra 0.1 BTC of fees)?"  The answer is "yes" only if the probability that your block isn't orphaned doesn't increase by more than 0.1/25 = 0.4%.  Imagine that by including the extra 500 kB, the chance that your block is orphaned increases by 1%.  This means that you'd lose 0.25 BTC on average by including the 500 kB of TXs.  Since those extra TXs only give you 0.1 BTC of fees, the answer is that you shouldn't include them.  

As internet speeds increase, the "orphan cost" goes down and it then becomes economical to accept a larger number of transactions.  

EDIT: I see JR beat me by 15 seconds.  My post had a larger word count and now it gets orphaned Sad

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

Activity: 1498



View Profile WWW
August 07, 2014, 01:06:27 AM
 #10270

Anyway, please tell me I'm wrong. I love being wrong Smiley. Please explain to me why anyone would pay a transaction fee above 1 Satoshi when the block subsidy has run out and the block size is not limited.

Because of the orphan cost.  Each kB added to your block increases its propagation time and thus the probability that it will be orphaned.  

For example, is it profitable to include another 500 kB of TXs (and keep the extra 0.1 BTC of fees)?  The answer is "yes" only if the probability that your block isn't orphaned doesn't increase by more than 0.1/25 = 0.4%.  Imagine that be including the extra 500 kB, the chance that your block is orphaned increases by 1%.  This means that you'd lose 0.25 BTC on average by including the 500 kB of TXs.  Since those extra TXs only give you 0.1 BTC of fees, the answer is that you shouldn't include them.  

As internet speeds increase, the "orphan cost" goes down and it then becomes economical to accept a larger number of transactions.  

EDIT: I see JR beat my by 25 seconds Smiley


Are these figures factual? I assumed the orphan chance to increase but only by a very small amount, small enough to completely ignore it. Does adding 500KB to a block really increase the orphan chances by 0.4%? I thought it would be many orders of magnitude less.

Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
August 07, 2014, 01:12:59 AM
 #10271

Are these figures factual? I assumed the orphan chance to increase but only by a very small amount, small enough to completely ignore it. Does adding 500KB to a block really increase the orphan chances by 0.4%? I thought it would be many orders of magnitude less.

I think it was Gavin who estimated the orphan cost per kB, and it was not insignificant.  I can't find the post off hand, but perhaps someone else can point us to it.  I'd like to be reminded of the actual numbers too.  

I do know that the core devs want to reduce the orphan cost by propagating blocks by TX hash whenever possible.  High orphan costs are sometimes blamed for the hesitation of some miners to build larger blocks.  

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

Activity: 1498



View Profile WWW
August 07, 2014, 01:17:55 AM
 #10272

Are these figures factual? I assumed the orphan chance to increase but only by a very small amount, small enough to completely ignore it. Does adding 500KB to a block really increase the orphan chances by 0.4%? I thought it would be many orders of magnitude less.

I think it was Gavin who estimated the orphan cost per kB, and it was not insignificant.  I can't find the post off hand, but perhaps someone else can point us to it.  I'd like to be reminded of the actual numbers too.  

I do know that the core devs want to reduce the orphan cost by propagating blocks by TX hash whenever possible.  High orphan costs are sometimes blamed for the hesitation of some miners to build larger blocks.  

Anyway, thank you both, I'll need to do some more reading/investigating on this. I'll check back here tomorrow whether someone did find that post Smiley

justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
August 07, 2014, 01:35:26 AM
 #10273

I do know that the core devs want to reduce the orphan cost by propagating blocks by TX hash whenever possible.  High orphan costs are sometimes blamed for the hesitation of some miners to build larger blocks.
Of course they do, just like how McDonalds wants to reduce the marginal cost of cooking a Big Mac and a FedEx wants to reduce the marginal cost of shipping a package.

Allowing the network to process more transactions at a lower cost is a good thing.
Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
August 07, 2014, 01:57:54 AM
 #10274

Allowing the network to process more transactions at a lower cost is a good thing.

Agreed.

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

Activity: 364


View Profile
August 07, 2014, 02:11:11 AM
 #10275

cypherdoc, I think this is the best thread ever.  What's the secret?  Running up a huge page count so that most new posters don't want to sift through all the info?

Somehow, present company excepted, this thread manages to attract thoughts and posts almost exclusively from thoughtful, knowledgeable, and thorough members.  It's my only real can't-miss thread every day.
NewLiberty
Legendary
*
Offline Offline

Activity: 1064


Gresham's Lawyer


View Profile WWW
August 07, 2014, 02:32:28 AM
 #10276

Say the situation where a miner includes n transactions in a block or n+1 is equivalent in cost*.
This situation does not exist.

The cost is very real and not-insubstantial - the increased orphan risk which you completely glossed over above.

The marginal cost can - and should - be brought very low but it will never reach zero.

The amount of transactions a miner can process in a ten minute interval is finite, therefore it is scarce, therefore the service of including transactions in a block will always have a price.

QFT!
The marginal cost decreases with the block reward proportionate to the mining fee.
So while the n vs n+1 will never be equivalent, they should be expected to increasingly approach the risk/reward for orphaning.
This should then also be expected to increase the desirability of including the n+1 transaction in the block.

At some future time the transaction fees may be more than the block rewards, as block sizes increase and the block rewards decrease.
This future time will likely be after a much longer term bitcoin price stability than anything in its history.  This may well be for younger people than I to observe.  
So far, bitcoin valuation has increased so much faster than block rewards decrease, and so transaction fees have decreased faster than block rewards.  We should not expect this to be true forever, just for a long time to come, and also for block sizes to increment over time.

tl;dr The protocol works very well and these considerations are baked in.  Bitcoin is quite secure in this regard.

FREE MONEY1 Bitcoin for Silver and Gold NewLibertyDollar.com and now BITCOIN SPECIE (silver 1 ozt) shows value by QR
Bulk premiums as low as .0012 BTC "BETTER, MORE COLLECTIBLE, AND CHEAPER THAN SILVER EAGLES" 1Free of Government
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
August 07, 2014, 02:38:38 AM
 #10277

tl;dr The protocol works very well and these considerations are baked in.  Bitcoin is quite secure in this regard.
So many people get caught up in the trap of "how will we make sure a market will arrive at the correct price for a service" without understanding that the question itself is invalid.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 07, 2014, 02:57:52 AM
 #10278

what i don't get is why isn't Gavin moving to increase block size now as opposed to when we're in the middle of the next bubble or two when tx size will have surely increased along with price and his back is against the wall?  i'm not advocating this, just asking the question.

he's already shown a reticence to make changes to the protocol.  not that i'm complaining, mind you, as i think he's done a stellar job as lead dev.  but at that point, it may be such a political hot potato that nothing may get done at all.  
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
August 07, 2014, 02:59:01 AM
 #10279

what i don't get is why isn't Gavin moving to increase block size now as opposed to when we're in the middle of the next bubble or two when tx size will have surely increased along with price and his back is against the wall?

he's already shown a reticence to not make changes to the protocol.  not that i'm complaining, mind you, as i think he's done a stellar job as lead dev.  but at that point, it may be such a political hot potato that nothing may get done at all.
It may be the case that we don't get any protocol improvements until Bitcoin Core loses its monopoly on the full node network.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 07, 2014, 03:01:21 AM
 #10280

what i don't get is why isn't Gavin moving to increase block size now as opposed to when we're in the middle of the next bubble or two when tx size will have surely increased along with price and his back is against the wall?

he's already shown a reticence to not make changes to the protocol.  not that i'm complaining, mind you, as i think he's done a stellar job as lead dev.  but at that point, it may be such a political hot potato that nothing may get done at all.
It may be the case that we don't get any protocol improvements until Bitcoin Core loses its monopoly on the full node network.

i don't see that ever happening as long as Gavin remains lead dev.  there's no one even close to him that has the political capital, trust, or good will he has generated.
Pages: « 1 ... 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 [514] 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 ... 1560 »
  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!