Bitcoin Forum
December 03, 2016, 04:50:59 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 ... 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 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1803442 times)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 29, 2015, 06:59:39 PM
 #29481

i think this proves that miners are perfectly capable of handling bigger blocks as evidenced by the "no delays" in confirmation intervals.  if anything i find it interesting that they get sped up to <10 min during these attacks.  with bigger blocks, we'd clear out that mempool in an instant:

1480740659
Hero Member
*
Offline Offline

Posts: 1480740659

View Profile Personal Message (Offline)

Ignore
1480740659
Reply with quote  #2

1480740659
Report to moderator
1480740659
Hero Member
*
Offline Offline

Posts: 1480740659

View Profile Personal Message (Offline)

Ignore
1480740659
Reply with quote  #2

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

Posts: 1480740659

View Profile Personal Message (Offline)

Ignore
1480740659
Reply with quote  #2

1480740659
Report to moderator
1480740659
Hero Member
*
Offline Offline

Posts: 1480740659

View Profile Personal Message (Offline)

Ignore
1480740659
Reply with quote  #2

1480740659
Report to moderator
1480740659
Hero Member
*
Offline Offline

Posts: 1480740659

View Profile Personal Message (Offline)

Ignore
1480740659
Reply with quote  #2

1480740659
Report to moderator
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 29, 2015, 07:00:39 PM
 #29482

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 29, 2015, 07:02:02 PM
 #29483

clearing out the mempool quickly would solidify the attackers losses and gratify the previous tx validation work already done by all full nodes in the network.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 29, 2015, 07:05:32 PM
 #29484

notice how the extra fees paid by full blocks actually strengthened the mining hashrate during the last attacks.  probably the extra revenue from tx fees encouraged miners to bring on more hashrate.  that's a good thing and could actually be even better if they were allowed to harvest/clear all the additional fees in the bloated mempools:

NewLiberty
Legendary
*
Offline Offline

Activity: 1064


Gresham's Lawyer


View Profile WWW
July 29, 2015, 07:09:03 PM
 #29485

i think this proves that miners are perfectly capable of handling bigger blocks as evidenced by the "no delays" in confirmation intervals.  if anything i find it interesting that they get sped up to <10 min during these attacks.  with bigger blocks, we'd clear out that mempool in an instant:



Well, no.
Bigger blocks just make the "attacks" marginally more expensive.  
Individually, I could also swamp the mempool at any of the proposed sizes.

The "attacks" are providing some funding, so I don't really mind them all that much.  This tragedy of the commons is not quite so tragic as the UTXO set growth and chain size would be with a similar attack on larger blocks, especially if combined with a validation time attack (TX with many inputs and outputs in a tangled array).
Very large blocks would be a much more vulnerable environment in which to conduct such an attack.  We'll get to the point of ameliorating these vulnerabilities, and the right people are working on it.

Patience...  Bitcoin is still in beta, its so young.  Lets give it the chance to grow up without breaking it along the way.

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

Activity: 1064


Gresham's Lawyer


View Profile WWW
July 29, 2015, 07:12:00 PM
 #29486

notice how the extra fees paid by full blocks actually strengthened the mining hashrate during the last attacks.  probably the extra revenue from tx fees encouraged miners to bring on more hashrate.  that's a good thing and could actually be even better if they were allowed to harvest/clear all the additional fees in the bloated mempools:



Yes Smiley

More "attacks" please.

Just not really big blocks yet.

1-3mb are ok.  8mb is too much right now (yes the miners are wrong, there's bad stuff they haven't seen yet).
Getting blocks that take >10mins to validate is not a good thing.

Fortunately with better code optimization, we may get that validation time down even more, as well as the other advances to make this safer.

We'll get there.

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

Activity: 1764



View Profile
July 29, 2015, 07:32:48 PM
 #29487

i think this proves that miners are perfectly capable of handling bigger blocks as evidenced by the "no delays" in confirmation intervals.  if anything i find it interesting that they get sped up to <10 min during these attacks.  with bigger blocks, we'd clear out that mempool in an instant:



Well, no.
Bigger blocks just make the "attacks" marginally more expensive.  
Individually, I could also swamp the mempool at any of the proposed sizes.

The "attacks" are providing some funding, so I don't really mind them all that much.  This tragedy of the commons is not quite so tragic as the UTXO set growth and chain size would be with a similar attack on larger blocks, especially if combined with a validation time attack (TX with many inputs and outputs in a tangled array).
Very large blocks would be a much more vulnerable environment in which to conduct such an attack.  We'll get to the point of ameliorating these vulnerabilities, and the right people are working on it.

Patience...  Bitcoin is still in beta, its so young.  Lets give it the chance to grow up without breaking it along the way.

so looking at the peak of the last attack ~40BTC per day worth of tx fees were harvested.  let's say we go to 20MB blocks tomorrow.  since real tx's only amount to ~500kB per block worth of data, you'd have to essentially fill the 20MB all by yourself and spend 20*40BTC=800BTC per day give or take.  at $290/BTC that would equal $232000 per day.  and then you'd have to sustain that to even dent the network; say for a month.  that would cost you $7,000,000 for one month.  you sure you can do that all by yourself?

NewLiberty
Legendary
*
Offline Offline

Activity: 1064


Gresham's Lawyer


View Profile WWW
July 29, 2015, 07:36:30 PM
 #29488

i think this proves that miners are perfectly capable of handling bigger blocks as evidenced by the "no delays" in confirmation intervals.  if anything i find it interesting that they get sped up to <10 min during these attacks.  with bigger blocks, we'd clear out that mempool in an instant:



Well, no.
Bigger blocks just make the "attacks" marginally more expensive.  
Individually, I could also swamp the mempool at any of the proposed sizes.

The "attacks" are providing some funding, so I don't really mind them all that much.  This tragedy of the commons is not quite so tragic as the UTXO set growth and chain size would be with a similar attack on larger blocks, especially if combined with a validation time attack (TX with many inputs and outputs in a tangled array).
Very large blocks would be a much more vulnerable environment in which to conduct such an attack.  We'll get to the point of ameliorating these vulnerabilities, and the right people are working on it.

Patience...  Bitcoin is still in beta, its so young.  Lets give it the chance to grow up without breaking it along the way.

so looking at the peak of the last attack ~40BTC per day worth of tx fees were harvested.  let's say we go to 20MB blocks tomorrow.  since real tx's only amount to ~500kB per block worth of data, you'd have to essentially fill the 20MB all by yourself and spend 20MB*40BTC=800BTC per day give or take.  at $290/BTC that would equal $232000 per day.  and then you'd have to sustain that to even dent the network; say for a month.  that would cost you $7,000,000 for one month.  you sure you can do that all by yourself?



Why would you doubt it?

But in your example of 20MB, there are much easier and cheaper ways to DoS the network, as mentioned.

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
awemany
Newbie
*
Offline Offline

Activity: 28


View Profile
July 29, 2015, 07:36:56 PM
 #29489


1-3mb are ok.  8mb is too much right now (yes the miners are wrong, there's bad stuff they haven't seen yet).
Getting blocks that take >10mins to validate is not a good thing.


I believe Gavin wants to limit TXN size to 100kiB at the same time the bigger block hard fork comes into effect. Shouldn't this very much remove your worries about an increase in blocksize?

And, yes, I agree, faster validation is even better than putting another artificial limit into the code base.
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1498


Crypto is the separation of Power and State.


View Profile WWW
July 29, 2015, 07:37:10 PM
 #29490

The introduction of sidechains, LN and whatever other solutions is a complicated solution. It's also a solution motivated by a desire to fix a perceived economic issue, rather than sticking to the very simple issue at hand. It is the very opposite of what you are claiming to be important, that software should be kept simple.

That is a contradiction.

The simple solution is to remove the artificial cap. A cap that was put in place to prevent DDOS.

Your reference of CVE-2013-2292 is just distraction. It is a separate issue, one that exists now and would continue to exists with a larger block size.

Bloating Layer 1 is a complicated solution; scaling at Level 2+ is an elegant one.

You still don't understand Tannenbaum's maxim.  Its point isn't 'keep software simple FOREVER NO MATTER WHAT.'  That is your flawed simpleton's interpretation.

"Fighting features" means ensuring a positive trade-off in terms of security and reliability, instead of carelessly and recklessly heaping on additional functionality without the benefit of an adversarial process which tests their quality and overall impact.

One does not simply "remove the artificial cap."  You may have noticed some degree of controversy in regard to that proposal.  Bitcoin is designed to strenuously resist (IE fight) hard forks.  Perhaps you were thinking of WishGrantingUnicornCoin, which leaps into action the moment anyone has an idea and complies with their ingenious plan for whatever feature or change they desire.

Like DoS, CVE-2013-2292, as an issue that exists now, is fairly successfully mitigated by the 1MB cap.  It is not a separate concern because larger blocks exacerbate the problem in a superlinear manner.  You don't get to advocate 8MB blocks, but then wave your hands around eschewing responsibility when confronted with the immediate entailment of purposefully constructed 8MB tx taking 64 times longer to process than a 1MB one.  The issue is intrinsic to larger blocks, which is why Gavin proposed a 100k max tx size be married to any block size increase.

Fully parsed, what you are claiming is

Quote
The simple solution is to remove the artificial cap hard fork Bitcoin.

Do you realize how naive that makes you look?

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
Fungibility provides privacy as a side effect.  Adam Back 2014
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Wallets - Podcats - Roadmap - Dice - Blackjack - Github - Android }


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


"I believed @Dashpay instamine was a bug & not a feature but then read: https://bitcointalk.org/index.php?topic=421615.msg13017231#msg13017231
I'm not against people making money, but can't support questionable origins."
https://twitter.com/Tone_LLT/status/717822927908024320


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

"Hard forks cannot be co
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 29, 2015, 07:50:22 PM
 #29491

i think this proves that miners are perfectly capable of handling bigger blocks as evidenced by the "no delays" in confirmation intervals.  if anything i find it interesting that they get sped up to <10 min during these attacks.  with bigger blocks, we'd clear out that mempool in an instant:



Well, no.
Bigger blocks just make the "attacks" marginally more expensive.  
Individually, I could also swamp the mempool at any of the proposed sizes.

The "attacks" are providing some funding, so I don't really mind them all that much.  This tragedy of the commons is not quite so tragic as the UTXO set growth and chain size would be with a similar attack on larger blocks, especially if combined with a validation time attack (TX with many inputs and outputs in a tangled array).
Very large blocks would be a much more vulnerable environment in which to conduct such an attack.  We'll get to the point of ameliorating these vulnerabilities, and the right people are working on it.

Patience...  Bitcoin is still in beta, its so young.  Lets give it the chance to grow up without breaking it along the way.

so looking at the peak of the last attack ~40BTC per day worth of tx fees were harvested.  let's say we go to 20MB blocks tomorrow.  since real tx's only amount to ~500kB per block worth of data, you'd have to essentially fill the 20MB all by yourself and spend 20MB*40BTC=800BTC per day give or take.  at $290/BTC that would equal $232000 per day.  and then you'd have to sustain that to even dent the network; say for a month.  that would cost you $7,000,000 for one month.  you sure you can do that all by yourself?



Why would you doubt it?

b/c i'm assuming it would be cost prohibitive for you?  and pretty much anyone else i might add altho i'm sure you'd argue not for a gvt; which actually might be true which is why i advocate NO LIMIT as that would throw a huge amount of uncertainty as to just how successfully one could jack the mempool in that scenario as it removes user disruption and thus greatly increases the financial risk ANY attacker would be subject o.

Quote
But in your example of 20MB, there are much easier and cheaper ways to DoS the network, as mentioned.

i know; your normal sized convoluted multi-input block that would have to, btw, be constructed as a non-standard tx block that is self mined by a miner which makes it unlikely b/c you'd have to believe a miner would be willing to risk his reputation and financial viability by attacking the network in such a way which has repercussions. that's also good news in that it removes a regular spammer or gvt attacker (non-miner) from doing this. and finally, that type of normal sized but convoluted validation block will propagate VERY slowly which risks orphaning which makes that attack also unlikely.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 29, 2015, 07:52:01 PM
 #29492


1-3mb are ok.  8mb is too much right now (yes the miners are wrong, there's bad stuff they haven't seen yet).
Getting blocks that take >10mins to validate is not a good thing.


I believe Gavin wants to limit TXN size to 100kiB at the same time the bigger block hard fork comes into effect. Shouldn't this very much remove your worries about an increase in blocksize?

And, yes, I agree, faster validation is even better than putting another artificial limit into the code base.


he's backed off the 100kB tx limit in deference to limiting the #sigops and simplifying the hashing process.  for details, someone provide the link to his ML post.
awemany
Newbie
*
Offline Offline

Activity: 28


View Profile
July 29, 2015, 07:58:50 PM
 #29493

he's backed off the 100kB tx limit in deference to limiting the #sigops and simplifying the hashing process.  for details, someone provide the link to his ML post.

Thanks for the update! The effect on transaction validation time should be essentially the same, though... it should be enough to make 'overly complicated' blocks impossible for the time being.
brg444
Hero Member
*****
Offline Offline

Activity: 630

Bitcoin replaces central, not commercial, banks


View Profile
July 29, 2015, 08:03:16 PM
 #29494

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009727.html

Greg's reply.

This is entertaining  Cheesy

"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
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1498


Crypto is the separation of Power and State.


View Profile WWW
July 29, 2015, 08:08:23 PM
 #29495

-
#rekt

   >It was _well_ .... understood that the users of Bitcoin would wish to protect its decenteralization by limiting the size of the chain to keep it verifyable on small devices.

No it wasn't. That is something you invented yourself much later. "Small devices" isn't even defined anywhere, so there can't have been any such understanding.

Hearn #rekt confirmed:

Quote
In the above statement you're outright backwards-- there was a clear
expectation that all who ran nodes would mine.

Gmax nailed this, Hearn's understanding (only miners run nodes) of Satoshi's original design (all nodes are miners) is completely bungled.

Now its Frap.doc's turn to get rekt:

Piling every proof-of-work quorum system in the world into one dataset doesn't scale.

Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.


 Cheesy

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
Fungibility provides privacy as a side effect.  Adam Back 2014
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Wallets - Podcats - Roadmap - Dice - Blackjack - Github - Android }


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


"I believed @Dashpay instamine was a bug & not a feature but then read: https://bitcointalk.org/index.php?topic=421615.msg13017231#msg13017231
I'm not against people making money, but can't support questionable origins."
https://twitter.com/Tone_LLT/status/717822927908024320


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

"Hard forks cannot be co
thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
July 29, 2015, 08:21:55 PM
 #29496

anyone concerned about the BTC lower high?
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 29, 2015, 08:22:56 PM
 #29497

Now its Frap.doc's turn to get rekt:

Piling every proof-of-work quorum system in the world into one dataset doesn't scale.

Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.


 Cheesy

i find it amusing that you bash Satoshi on the one hand but when you find a morsel quote of his (which you've misread) you latch onto it as gospel.

if you read the actual link you posted, Satoshi was talking about how Bitcoin should not be combined with BitDNS.  he's not even talking about tx's.  he wanted them to be separate with their own fates.  he also drew an extreme example of how BitDNS might want to include other huge datasets while Bitcoin might want to keep it small as an example of how the decision making might diverge btwn the two.  not that Bitcoin users wanted to keep a small blockchain.
brg444
Hero Member
*****
Offline Offline

Activity: 630

Bitcoin replaces central, not commercial, banks


View Profile
July 29, 2015, 08:28:21 PM
 #29498

Now its Frap.doc's turn to get rekt:

Piling every proof-of-work quorum system in the world into one dataset doesn't scale.

Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.


 Cheesy

i find it amusing that you bash Satoshi on the one hand but when you find a morsel quote of his (which you've misread) you latch onto it as gospel.

if you read the actual link you posted, Satoshi was talking about how Bitcoin should not be combined with BitDNS.  he's not even talking about tx's.  he wanted them to be separate with their own fates.  he also drew an extreme example of how BitDNS might want to include other huge datasets while Bitcoin might want to keep it small as an example of how the decision making might diverge btwn the two.  not that Bitcoin users wanted to keep a small blockchain.


Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.


 Huh

Are you really trying to spin this one again?

"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 29, 2015, 08:31:43 PM
 #29499


Greg has made it abundantly clear that he is a Bear on Bitcoin.  he should step down as a core dev.

and what's this about him not thinking Bitcoin can be used on small devices?  smartphones are KEY to Bitcoin's long term success.
brg444
Hero Member
*****
Offline Offline

Activity: 630

Bitcoin replaces central, not commercial, banks


View Profile
July 29, 2015, 08:34:45 PM
 #29500


Greg has made it abundantly clear that he is a Bear on Bitcoin.  he should step down as a core dev.

and what's this about him not thinking Bitcoin can be used on small devices?  smartphones are KEY to Bitcoin's long term success.

Yeah... maybe you need to read this again. What did I tell you about putting words in people's mouth.

"A bear on Bitcoin"  Cheesy So much non sense!

"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
Pages: « 1 ... 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 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 ... 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!