Bitcoin Forum
September 21, 2017, 07:38:48 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   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 ... 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 [1447] 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1978037 times)
tvbcof
Legendary
*
Offline Offline

Activity: 2268


View Profile
July 16, 2015, 08:44:37 PM
 #28921


i'll be offline for the next 3d camping.  have fun with your new Master "iCEBlow"  et al!

2d without your FUD and bitcoin is at $318.
...

The guy comes back and we drop down into the $270's.  Go figure.

yeah, and you're full of shit.  when i got back it was already down to $292 and dropping.  do you enjoy being such an idiot?

Sometimes.


1506022728
Hero Member
*
Offline Offline

Posts: 1506022728

View Profile Personal Message (Offline)

Ignore
1506022728
Reply with quote  #2

1506022728
Report to moderator
1506022728
Hero Member
*
Offline Offline

Posts: 1506022728

View Profile Personal Message (Offline)

Ignore
1506022728
Reply with quote  #2

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

Posts: 1506022728

View Profile Personal Message (Offline)

Ignore
1506022728
Reply with quote  #2

1506022728
Report to moderator
1506022728
Hero Member
*
Offline Offline

Posts: 1506022728

View Profile Personal Message (Offline)

Ignore
1506022728
Reply with quote  #2

1506022728
Report to moderator
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1778


http://DashNdrink.com


View Profile WWW
July 16, 2015, 08:46:56 PM
 #28922


i'll be offline for the next 3d camping.  have fun with your new Master "iCEBlow"  et al!

2d without your FUD and bitcoin is at $318.
...

The guy comes back and we drop down into the $270's.  Go figure.

yeah, and you're full of shit.  when i got back it was already down to $292 and dropping.  do you enjoy being such an idiot?

Sometimes.


LOL rekt

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange  |  Buy XMR with fiat
Fungibility provides privacy as a side effect.  Adam Back 2014

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004
Odalv
Legendary
*
Offline Offline

Activity: 1204



View Profile
July 16, 2015, 09:03:04 PM
 #28923

The guy comes back and we drop down into the $270's.  Go figure.

+1

I posted this message to show him mirror. In (cypherdoc's)reality it is "The core devs and Blockstream" who suppressed the bitcoin price. :-)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 16, 2015, 09:54:25 PM
 #28924

i'm glad the VC's are starting to focus in on what the real problem is:

https://a16z.com/2015/07/13/a16z-podcast-bitcoins-growing-pains-and-possibilities/
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1778


http://DashNdrink.com


View Profile WWW
July 17, 2015, 12:06:16 AM
 #28925

i'm glad the VC's are starting to focus in on what the real problem is:

https://a16z.com/2015/07/13/a16z-podcast-bitcoins-growing-pains-and-possibilities/

Oh how nice to hear the view from 2865 Sand Hill Road, courtesy of In-Q-Tel (AKA CIA) partner A16 and Hearn@sigint.google.mil.

27 seconds in, and we've already being treated to hard-selling, counterfactual exaggeration in the form of "there not much time left to make changes before Bitcoin blockchain capacity runs out."

"1MB kludge"  No, wrong, a sanity check/DOS regulator is not a "kludge." 

 Angry  FFS, I'm struggling to not attribute to malice what can be explained by ignorance, but Hearn should know better.  Especially as Gavin as told us the sky will not fall because of full 1MB blocks.

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange  |  Buy XMR with fiat
Fungibility provides privacy as a side effect.  Adam Back 2014

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004
smooth
Legendary
*
Offline Offline

Activity: 1540



View Profile
July 17, 2015, 12:15:23 AM
 #28926

i'm glad the VC's are starting to focus in on what the real problem is:

https://a16z.com/2015/07/13/a16z-podcast-bitcoins-growing-pains-and-possibilities/

Oh how nice to hear the view from 2865 Sand Hill Road, courtesy of In-Q-Tel (AKA CIA) partner A16 and Hearn@sigint.google.mil.

27 seconds in, and we've already being treated to hard-selling, counterfactual exaggeration in the form of "there not much time left to make changes before Bitcoin blockchain capacity runs out."

"1MB kludge"  No, wrong, a sanity check/DOS regulator is not a "kludge."  

 Angry  FFS, I'm struggling to not attribute to malice what can be explained by ignorance, but Hearn should know better.  Especially as Gavin as told us the sky will not fall because of full 1MB blocks.

To this day, nobody has explained why satoshi felt it was necessary to limit block size to prevent DoS yet suddenly today because there is more usage the threat of DoS no longer exists (?) and we should have huge/no/exponentially-growing block limits.

As I said before, until there is some other replacement mechanism added to guard against the attack vector identified by satoshi which motivated the 1 MB limit, there is no rational basis for removing or radically increasing that limit. (I don't see anything wrong with a modest increase in line with hardware improvements since 2009-10, which is maybe something like 3x; the exact ratio depends on which of the relevant hardware resources you consider important or most important.)
MarketNeutral
Sr. Member
****
Offline Offline

Activity: 364


View Profile
July 17, 2015, 12:28:13 AM
 #28927

i'm glad the VC's are starting to focus in on what the real problem is:

https://a16z.com/2015/07/13/a16z-podcast-bitcoins-growing-pains-and-possibilities/

Oh how nice to hear the view from 2865 Sand Hill Road, courtesy of In-Q-Tel (AKA CIA) partner A16 and Hearn@sigint.google.mil.

27 seconds in, and we've already being treated to hard-selling, counterfactual exaggeration in the form of "there not much time left to make changes before Bitcoin blockchain capacity runs out."

"1MB kludge"  No, wrong, a sanity check/DOS regulator is not a "kludge."  

 Angry  FFS, I'm struggling to not attribute to malice what can be explained by ignorance, but Hearn should know better.  Especially as Gavin as told us the sky will not fall because of full 1MB blocks.
You give Hearn far more benefit of the doubt than I do. I think he knows better. Malice? I wouldn't go so far. Hubris, perhaps. I don't know what Hearn's ulterior motives are, but I'd wager more than a few bitcoins than he has a long-term stratagem in the back of his mind. Is he the bad cop to Gavin's good cop? Are Wlad and company on board with Hearn? Are the other devs naïve? I can only speculate, and I prefer to give the devs the benefit of the doubt, but Hearn is the only dev that regularly leaves me disconcerted. At this point, I defer to Gavin's opinion over Hearn's.

EDIT: Nick Szabo recently tweeted, "Hearn's views in this debate are very far from Bitcoin developer mainstream."
https://twitter.com/NickSzabo4/status/621773448298147840
MarketNeutral
Sr. Member
****
Offline Offline

Activity: 364


View Profile
July 17, 2015, 12:35:43 AM
 #28928

i'm glad the VC's are starting to focus in on what the real problem is:

https://a16z.com/2015/07/13/a16z-podcast-bitcoins-growing-pains-and-possibilities/

Oh how nice to hear the view from 2865 Sand Hill Road, courtesy of In-Q-Tel (AKA CIA) partner A16 and Hearn@sigint.google.mil.

27 seconds in, and we've already being treated to hard-selling, counterfactual exaggeration in the form of "there not much time left to make changes before Bitcoin blockchain capacity runs out."

"1MB kludge"  No, wrong, a sanity check/DOS regulator is not a "kludge."  

 Angry  FFS, I'm struggling to not attribute to malice what can be explained by ignorance, but Hearn should know better.  Especially as Gavin as told us the sky will not fall because of full 1MB blocks.

To this day, nobody has explained why satoshi felt it was necessary to limit block size to prevent DoS yet suddenly today because there is more usage the threat of DoS no longer exists (?) and we should have huge/no/exponentially-growing block limits.

As I said before, until there is some other replacement mechanism added to guard against the attack vector identified by satoshi which motivated the 1 MB limit, there is no rational basis for removing or radically increasing that limit. (I don't see anything wrong with a modest increase in line with hardware improvements since 2009-10, which is maybe something like 3x; the exact ratio depends on which of the relevant hardware resources you consider important or most important.)

I've wondered about this, as well. Some people have opined that satoshi chose arbitrary values for some aspects of bitcoin's design, but I am more inclined towards the opposite view, despite us not fully understanding why he chose some figures.
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
July 17, 2015, 01:14:51 AM
 #28929

To this day, nobody has explained why satoshi felt it was necessary to limit block size to prevent DoS yet suddenly today because there is more usage the threat of DoS no longer exists (?) and we should have huge/no/exponentially-growing block limits.

We do know why Satoshi felt it necessary to limit the size in the way he did. Mike gives the background here: https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e

Quote
The limit was intended to be removed. In fact, Satoshi intended it to be removed as soon as SPV wallets were developed.

I know this because at the end of 2010 I emailed him to ask about it. He responded,

A higher limit can be phased in once we have actual use closer to the limit and make sure it’s working OK.
Eventually when we have client-only implementations, the block chain size won’t matter much. Until then, while all users still have to download the entire block chain to start, it’s nice if we can keep it down to a reasonable size.


So, the 1MB was a "sanity check" later described as a general spam limiting measure. When Satoshi did the commits to put this limit in everyone who used bitcoins had to run a full node. Many of them had low-power hardware and were just learning about his new form of electronic money. He did not want a rogue miner to create a series of large blocks which were >1000x the prevailing average block size, and put people off at such a delicate time. Also, the first mention of FPGA mining on bitcointalk was made then.

Clearly, a rogue miner using FPGA tech was the thing Satoshi feared at that time. Satoshi did not always explain his actions and one reason for this is that detailing an attack vector increases the probability that it will be acted upon.

NewLiberty
Legendary
*
Offline Offline

Activity: 1162


Gresham's Lawyer


View Profile WWW
July 17, 2015, 01:16:50 AM
 #28930

A bad thing is when people like cypherdoc derive from the conflict of interest malicious intents without proof other than "I don't trust them"
What actually happened is that when Blockstream was announced multiple noted that it created the appearance of a potential conflict of interest.

Instead of acknowledging this potential (fairly standard practice in many business situations!), the Blockstream founders took the bizarre route of denying even the possibility of a conflict of interest.

That choice of actions is what lead to ongoing concern about their motives, not the founding of Blockstream itself.
I had not seen this comment until it was pointed out to me today:

https://www.reddit.com/r/IAmA/comments/2k3u97/we_are_bitcoin_sidechain_paper_authors_adam_back/clhy7kk?context=1

There clearly were some accurate acknowledgements of potential conflicts of interests in that Reddit post.

I'd not seen it either, and it is a bit reassuring.
It would be nice to see some method for evaluating and accommodating if it is really something they recognize.

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
MarketNeutral
Sr. Member
****
Offline Offline

Activity: 364


View Profile
July 17, 2015, 01:31:13 AM
 #28931

To this day, nobody has explained why satoshi felt it was necessary to limit block size to prevent DoS yet suddenly today because there is more usage the threat of DoS no longer exists (?) and we should have huge/no/exponentially-growing block limits.

We do know why Satoshi felt it necessary to limit the size in the way he did. Mike gives the background here: https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e

Quote
The limit was intended to be removed. In fact, Satoshi intended it to be removed as soon as SPV wallets were developed.

I know this because at the end of 2010 I emailed him to ask about it. He responded,

A higher limit can be phased in once we have actual use closer to the limit and make sure it’s working OK.
Eventually when we have client-only implementations, the block chain size won’t matter much. Until then, while all users still have to download the entire block chain to start, it’s nice if we can keep it down to a reasonable size.


So, the 1MB was a "sanity check" later described as a general spam limiting measure. When Satoshi did the commits to put this limit in everyone who used bitcoins had to run a full node. Many of them had low-power hardware and were just learning about his new form of electronic money. He did not want a rogue miner to create a series of large blocks which were >1000x the prevailing average block size, and put people off at such a delicate time. Also, the first mention of FPGA mining on bitcointalk was made then.

Clearly, a rogue miner using FPGA tech was the thing Satoshi feared at that time. Satoshi did not always explain his actions and one reason for this is that detailing an attack vector increases the probability that it will be acted upon.

Thank you for clarifying things.
NewLiberty
Legendary
*
Offline Offline

Activity: 1162


Gresham's Lawyer


View Profile WWW
July 17, 2015, 01:51:21 AM
 #28932

Clearly, a rogue miner using FPGA tech was the thing Satoshi feared at that time. Satoshi did not always explain his actions and one reason for this is that detailing an attack vector increases the probability that it will be acted upon.

There's still ways to make nasty blocks.
Blocks as small as 8mb that would take >10 mins to verify, and radically expand the UTXO dataset.  It isn't as though we are out of the woods.  The economic incentive to do something like this is that the miner could be building on it immediately whereas everyone else is still verifying, (or they just skip doing that, which fine but brings its own set of issues).

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
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
July 17, 2015, 02:58:09 AM
 #28933

Clearly, a rogue miner using FPGA tech was the thing Satoshi feared at that time. Satoshi did not always explain his actions and one reason for this is that detailing an attack vector increases the probability that it will be acted upon.

There's still ways to make nasty blocks.
Blocks as small as 8mb that would take >10 mins to verify, and radically expand the UTXO dataset.  It isn't as though we are out of the woods.  The economic incentive to do something like this is that the miner could be building on it immediately whereas everyone else is still verifying, (or they just skip doing that, which fine but brings its own set of issues).

Honestly, I'm the last person who wants to see the limit increased and a host of other problems appear. My original opinion was that an adaptive, dynamic block size limit was best, just like you argued all along. It was only when Gavin preferred a fixed scheduled increasing limit that I went with that, for the reason that any workable solution to the 1MB is better than no solution at all, and finally we are seeing with BIP 102 what must be the lowest common denominator in this whole saga. Even BIP 102 is a hell of a lot better than doing nothing.

Regarding >10 mins verification. Those monster tx of nearly 1MB took a lot of people by surprise, except Core Dev who knew about this risk and had a 100KB relay limit. Unfortunately the "nasty" 25 sec verification tx were out-of-band and fed directly into Discus Fish. Maybe tx size should be limited to 10% of block size limit at the protocol level and this needs to go in with any >1MB change?

I really like the anti-fragility aspect of Bitcoin which is amazing because every curve ball sent its way gets dealt with in the software making it stronger in the future.

brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
July 17, 2015, 03:34:43 AM
 #28934

Clearly, a rogue miner using FPGA tech was the thing Satoshi feared at that time. Satoshi did not always explain his actions and one reason for this is that detailing an attack vector increases the probability that it will be acted upon.

There's still ways to make nasty blocks.
Blocks as small as 8mb that would take >10 mins to verify, and radically expand the UTXO dataset.  It isn't as though we are out of the woods.  The economic incentive to do something like this is that the miner could be building on it immediately whereas everyone else is still verifying, (or they just skip doing that, which fine but brings its own set of issues).

Honestly, I'm the last person who wants to see the limit increased and a host of other problems appear. My original opinion was that an adaptive, dynamic block size limit was best, just like you argued all along. It was only when Gavin preferred a fixed scheduled increasing limit that I went with that, for the reason that any workable solution to the 1MB is better than no solution at all, and finally we are seeing with BIP 102 what must be the lowest common denominator in this whole saga. Even BIP 102 is a hell of a lot better than doing nothing.

Regarding >10 mins verification. Those monster tx of nearly 1MB took a lot of people by surprise, except Core Dev who knew about this risk and had a 100KB relay limit. Unfortunately the "nasty" 25 sec verification tx were out-of-band and fed directly into Discus Fish. Maybe tx size should be limited to 10% of block size at the protocol level and this needs to go in with any >1MB change?

I really like the anti-fragility aspect of Bitcoin which is amazing because every curve ball sent its way gets dealt with in the software making it stronger in the future.

I am not yet convinced that forking the network for a 1MB change to the block size is "better than doing nothing".

"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
July 17, 2015, 03:45:55 AM
 #28935

I am not yet convinced that forking the network for a 1MB change to the block size is "better than doing nothing".

Then please explain how Bitcoin scales to handle increased demand by users?
Don't forget that Pieter Wuille has said that sidechains are not a scaling solution. However, feel free to rebut that in your response.

brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
July 17, 2015, 04:01:12 AM
 #28936

I am not yet convinced that forking the network for a 1MB change to the block size is "better than doing nothing".

Then please explain how Bitcoin scales to handle increased demand by users?
Don't forget that Pieter Wuille has said that sidechains are not a scaling solution. However, feel free to rebut that in your response.

My point is : is putting on the network the pressure of a hard fork to kick the can down the road just a bit is really worth it?

It seems a lot in this thread forget the danger of hard forks.

Increased demand has in fact been well answered by the network over the last few days. Strangely this is a rather encouraging fact that not too many people seem to mention or acknowledge.

To be clear I am not referring to shitty software and other amateurs node implementations. These got properly crushed because THEIR models and code were not able to handle the increased demand.

I feel much less urgency going forward... unless we hit a 5K$ bubble in the next coming months  Smiley

"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 17, 2015, 04:04:29 AM
 #28937

Clearly, a rogue miner using FPGA tech was the thing Satoshi feared at that time. Satoshi did not always explain his actions and one reason for this is that detailing an attack vector increases the probability that it will be acted upon.

There's still ways to make nasty blocks.
Blocks as small as 8mb that would take >10 mins to verify, and radically expand the UTXO dataset.  It isn't as though we are out of the woods.  The economic incentive to do something like this is that the miner could be building on it immediately whereas everyone else is still verifying, (or they just skip doing that, which fine but brings its own set of issues).

why would you think a bloat block that large, so soon (while everyone else is mining 1MB), wouldn't get orphaned?  esp after seeing how the relay network appears to be having issues:

https://bitcointalk.org/index.php?topic=766190.msg11898189#msg11898189
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 17, 2015, 04:18:18 AM
 #28938


Regarding >10 mins verification. Those monster tx of nearly 1MB took a lot of people by surprise, except Core Dev who knew about this risk and had a 100KB relay limit. Unfortunately the "nasty" 25 sec verification tx were out-of-band and fed directly into Discus Fish. Maybe tx size should be limited to 10% of block size limit at the protocol level and this needs to go in with any >1MB change?


you're referring to the 1MB single tx block that f2pool constructed as a non std tx to help reduce the UTXO set?

why was that a bad thing?  it was a one off to help consolidate all that dust and required that a miner self construct this type of block and transmit it.  that wouldn't be a repeatable, viable attack to inflict on the network by a rogue miner looking to gain an advantage over other miners for the following reasons:

1.  constructing an 8MB bloat block while the rest of the network is making 1MB blocks runs the severe risk of orphaning
2.  if the pool consists mainly of hashers, they would react by redirecting their hash away from the attacking pool to preserve the network
3.  if it was coming out of China from a large miner, that miner runs even more risk of orphaning due to the GFC.
4.  other miners receiving such a bloat block could react defensively by switching to mining a 0 tx block during the validation process.
5.  game theory suggests a miner wouldn't even begin to do this attack for preservation of BTC value and his hardware investment.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 17, 2015, 04:23:45 AM
 #28939

solex, where do you go to get your mempool size info?  there seems to be discrepancies btwn sources.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 17, 2015, 04:43:22 AM
 #28940

I am not yet convinced that forking the network for a 1MB change to the block size is "better than doing nothing".

Then please explain how Bitcoin scales to handle increased demand by users?
Don't forget that Pieter Wuille has said that sidechains are not a scaling solution. However, feel free to rebut that in your response.

My point is : is putting on the network the pressure of a hard fork to kick the can down the road just a bit is really worth it?

It seems a lot in this thread forget the danger of hard forks.

it's a reflection of how badly we want out from under a core dev regime who has abandoned Satoshi's original vision for their own involving proprietary products which they stand to profit from.  yes, i'd much rather hard fork back to a decentralized core dev, or no core dev at all, to a sound money platform that exists solely for the public good and allows widespread dissemination of Bitcoin to all corners of the earth for maximum decentralization and security.
Quote

Increased demand has in fact been well answered by the network over the last few days. Strangely this is a rather encouraging fact that not too many people seem to mention or acknowledge.

i've been saying just that as a perfect reason for why bigger blocks can be handled as evidenced by that continuous stream of full blocks occurring right on time. 
Quote

To be clear I am not referring to shitty software and other amateurs node implementations. These got properly crushed because THEIR models and code were not able to handle the increased demand.

I feel much less urgency going forward... unless we hit a 5K$ bubble in the next coming months  Smiley

yeah, Mycelium was your prime example of a wallet trying to establish a fee mkt in response to user frustration from unconf tx's.  now that they blow up, you throw them under the bus forgetting they were a justification for your argument in the first place.
Pages: « 1 ... 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 [1447] 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 ... 1558 »
  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!