Bitcoin Forum
December 03, 2016, 09:56:03 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   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 ... 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 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 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1803497 times)
Cconvert2G36
Sr. Member
****
Offline Offline

Activity: 392


View Profile
July 04, 2015, 08:54:49 AM
 #28121

If possible, let's move this to another thread if someone still wants to continue.

Nah, you've said more than I ever could. Terviseks!
1480758963
Hero Member
*
Offline Offline

Posts: 1480758963

View Profile Personal Message (Offline)

Ignore
1480758963
Reply with quote  #2

1480758963
Report to moderator
1480758963
Hero Member
*
Offline Offline

Posts: 1480758963

View Profile Personal Message (Offline)

Ignore
1480758963
Reply with quote  #2

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

Activity: 746



View Profile
July 04, 2015, 08:55:18 AM
 #28122

How did this religious bullshit end up in this informative thread?
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1498


Crypto is the separation of Power and State.


View Profile WWW
July 04, 2015, 12:28:55 PM
 #28123

How did this religious bullshit end up in this informative thread?

Well, Frap.doc joined the heretical efforts to undermine orthodox 1MB blocks, and so the Great Schism moved over here.

Perhaps last night's fork reminded him how lucky we are to have core devs keeping our moon rocket on course?

Things we learned:

-ostensible "95%" compliance with BIP66 was actually 64% (implying GavinCoin's "75%" threshold will be a disaster)

-the free folk must be able to run their own full nodes, because SPV is a cool toy but not reliable for anything critical

-larger blocks, by taking longer to verify, increase private incentive for header-only mining while exacerbating its socialized negative consequences

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
Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
July 04, 2015, 01:40:57 PM
 #28124


The fork is now resolved.  Six blocks were orphaned resulting in a loss of ~100 BTC to F2Pool.  Rather good incentive for F2Pool to update their software for proper BIP66 support so this doesn't happen again!


since BIP66 has been activated only after 95% of the last 2k blocks was v3 blocks, it means f2pool already has produced BIP66 blocks before the incident, in fact last time I checked f2pool had ~20% of the total hashing power.

so by definition f2pool was BIP66 compliant before the fork.

the problem is that a lot of miners are "SPV mining", among them: f2pool and antpool

This is not quite true.  It's important we understand exactly what happened to prevent people from spinning this incident to strengthen their blocksize limit position.

Here's what happened:
   - BTC Nuggets mined block #363,731.  It was not BIP66 compliant.
   - F2Pool began mining on this block before they had validated its contents (SPV mining).
   - F2Pool should have orphaned block #363,731 as soon as they realized it was invalid.
   - However, F2Pool kept mining on this invalid block.
   - F2Pool hit a lucky streak and mined two more blocks (#363,732 and #363,733), pulling this invalid chain further ahead.
   - AntPool seemed to act similarly, and mined block #363,734 ontop of the invalid chain.
   - F2Pool quickly mined two more blocks on this chain (6 confs).
   - Finally, the rest of the network "pulled ahead" (the valid chain became longer) and F2Pool and AntPool finally orphaned their invalid chain.  



The incident was not caused by SPV mining for the few moments it takes to validate the latest block.  It was caused by F2Pool (and AntPool) never getting around to actually validating the blocks.  

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

Activity: 938



View Profile
July 04, 2015, 01:54:01 PM
 #28125

Perhaps last night's fork reminded him how lucky we are to have core devs keeping our moon rocket on course?

The fork resolved itself automatically.  Human intervention wasn't required.  


Do you consider what happened last night "a disaster"?


Did any double-spending occur during this longest forking event since 2013?

Also, if a SPV client was connected to trustworthy full nodes, its user would not be in danger of being double-spent on.  


The problem was they never validated the blocks at all.  It wouldn't have mattered if the blocks were 10 kB or 50 MB.

The great thing is that the 100 BTC loss by F2Pool and the 25 BTC loss by AntPool should motivate them to begin validating the blocks properly.

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

Activity: 1764



View Profile
July 04, 2015, 02:30:58 PM
 #28126


The fork is now resolved.  Six blocks were orphaned resulting in a loss of ~100 BTC to F2Pool.  Rather good incentive for F2Pool to update their software for proper BIP66 support so this doesn't happen again!


since BIP66 has been activated only after 95% of the last 2k blocks was v3 blocks, it means f2pool already has produced BIP66 blocks before the incident, in fact last time I checked f2pool had ~20% of the total hashing power.

so by definition f2pool was BIP66 compliant before the fork.

the problem is that a lot of miners are "SPV mining", among them: f2pool and antpool

This is not quite true.  It's important we understand exactly what happened to prevent people from spinning this incident to strengthen their blocksize limit position.

Here's what happened:
   - BTC Nuggets mined block #363,731.  It was not BIP66 compliant.
   - F2Pool began mining on this block before they had validated its contents (SPV mining).
   - F2Pool should have orphaned block #363,731 as soon as they realized it was invalid.
   - However, F2Pool kept mining on this invalid block.
   - F2Pool hit a lucky streak and mined two more blocks (#363,732 and #363,733), pulling this invalid chain further ahead.
   - AntPool seemed to act similarly, and mined block #363,734 ontop of the invalid chain.
   - F2Pool quickly mined two more blocks on this chain (6 confs).
   - Finally, the rest of the network "pulled ahead" (the valid chain became longer) and F2Pool and AntPool finally orphaned their invalid chain.  



The incident was not caused by SPV mining for the few moments it takes to validate the latest block.  It was caused by F2Pool (and AntPool) never getting around to actually validating the blocks.  

There's a reason I've been updating this thread routinely for the" defensive blocks". It seemed likely something might happen.  No one predicted it would be a fork like this.

Which begs the question, is this a result of consistently hitting an artificial limit that was always meant to be lifted?
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 04, 2015, 02:47:22 PM
 #28127

How did this religious bullshit end up in this informative thread?

Well, Frap.doc joined the heretical efforts to undermine orthodox 1MB blocks, and so the Great Schism moved over here.

Perhaps last night's fork reminded him how lucky we are to have core devs keeping our moon rocket on course?

Things we learned:

-ostensible "95%" compliance with BIP66 was actually 64% (implying GavinCoin's "75%" threshold will be a disaster)

-the free folk must be able to run their own full nodes, because SPV is a cool toy but not reliable for anything critical

-larger blocks, by taking longer to verify, increase private incentive for header-only mining while exacerbating its socialized negative consequences

iCEBLow continuing to blow ice.

I think what this is showing us is that ANY cap is a mistake.

As blocks become increasingly full, as I've said before, spammers become more emboldened as it doesn't cost much to fill blocks (less spam needed than before). I've been watching the defensive blocks closely as is clear what the motivations of f2pool have been as they have told us what they are. Except its worse than what we expected; they aren't bothering to validate the full block. Thus, we get what we got with an upgrade change that wasn't widely implemented.

Without a cap, spammers won't have this well identified ceiling with which to target. It all becomes much more fuzzy and expensive for them. Remember that their primary objective right now is to screw up the user experience to continue to cripple Bitcoin growth. Without a cap, miners will be forced to pay attention not only to fully validating their blocks but building efficiently sized blocks which will solve any latency issues they might encounter. and the spammers would have to dramatically increase their expense.

One doesn't even need to enact the spam scenario. What I've said even applies to organic growth that keeps hitting the 1MB choke.

 
wallcandy
Newbie
*
Offline Offline

Activity: 2


View Profile
July 04, 2015, 02:57:28 PM
 #28128

...
look up the definition of a shill.

"Unprincipled lying scumbag" is, technically, more accurate.

https://bitcointalk.org/index.php?action=trust;u=8389
BlindMayorBitcorn
Hero Member
*****
Offline Offline

Activity: 728


Blockchain Theorist


View Profile
July 04, 2015, 03:00:04 PM
 #28129

...
look up the definition of a shill.

"Unprincipled lying scumbag" is, technically, more accurate.

https://bitcointalk.org/index.php?action=trust;u=8389

You owe a core developer 10BTC? Impressive!

Forgive my petulance and oft-times, I fear, ill-founded criticisms, and forgive me that I have, by this time, made your eyes and head ache with my long letter. But I cannot forgo hastily the pleasure and pride of thus conversing with you.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 04, 2015, 03:03:49 PM
 #28130

...
look up the definition of a shill.

"Unprincipled lying scumbag" is, technically, more accurate.

https://bitcointalk.org/index.php?action=trust;u=8389

You owe a core developer 10BTC? Impressive!

obviously i can't talk about the case itself as it is ongoing.  so your conclusion is premature.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 04, 2015, 03:05:09 PM
 #28131

...
look up the definition of a shill.

"Unprincipled lying scumbag" is, technically, more accurate.

https://bitcointalk.org/index.php?action=trust;u=8389

2 day old account? 

Welcome to Bitcointalk!

wallcandy
Newbie
*
Offline Offline

Activity: 2


View Profile
July 04, 2015, 03:08:53 PM
 #28132

^^I catch on quick Cool
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 04, 2015, 03:16:11 PM
 #28133

i remember yesterday afternoon noticing several more than usual 1 tx blocks coming thru.  i thought, "that's interesting".  

i think this shows us how lazy pool operators can be.  after all, it's not really their hashers doing all the work; they're just in the biz of coordinating it all at the pool level while collecting quite a fair amt of coin.  i don't mean to trivialize their work but it's a good thing that they now have to pick up their game by taking these losses.   it's also important, long run, to get them to establish a fee market with the users and stop depending on core dev to guarantee their profits for them via block caps.

i read an article the other day that one of the largest pools out there in China was making something like $30000/day in BTC which probably is an enormous profit given what they pay for electricity there from a combo of hydro and state subsidy.  given their cheap labor no wonder the top 5 pools are in China.  what we need is more competition and decentralization which makes it apparent why they wanted Gavin to limit his initial increase to 8MB; to sustain their high profits and market share.  without a cap, this core dev subsidy and guarantee goes away and mining pools will be forced to compete on a more equal level.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 04, 2015, 03:23:47 PM
 #28134

...
look up the definition of a shill.

"Unprincipled lying scumbag" is, technically, more accurate.

https://bitcointalk.org/index.php?action=trust;u=8389

You owe a core developer 10BTC? Impressive!

what i find interesting is that for someone who claims to always be community minded, he's willing to take down his negative rating of me if i pay him back, and him only.  if i actually did something wrong in his mind, he shouldn't be willing to take it down ever.  there's a name for that.

oh, and i do have a screenshot of it.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 04, 2015, 03:28:05 PM
 #28135

...
look up the definition of a shill.

"Unprincipled lying scumbag" is, technically, more accurate.

https://bitcointalk.org/index.php?action=trust;u=8389

You owe a core developer 10BTC? Impressive!

what i find interesting is that for someone who claims to always be community minded, he's willing to take down his negative rating if i pay him back, and him only.  if i actually did something wrong in his mind, he shouldn't be willing to take it down ever.  there's a name for that.

oh, and i do have a screenshot of it.

I noticed that too...

actually, there's 2 names for what's he's done.

one, from a moral standpoint, and one from a legal standpoint.  i'll let you figure out what those names are.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 04, 2015, 03:38:41 PM
 #28136

 there's a name for that.

*Mercenary?  
Which invalidates his claims, leaving you as pure as the driven snow. Naturally.

5 day old account?

Welcome to BitcoinTalk!

i'd love for all the new troll accts to keep pushing my message to the top of the Spec Forum.  bring it on.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 04, 2015, 03:44:10 PM
 #28137

so to summarize, block size caps introduce all sorts of deviant and compensatory economic and social behavior. why?  b/c the caps are by definition, centrally planned by core dev.  they can't possibly figure out all the deviant behavior that will result from their actions, no matter how well intentioned.

only by lifting the cap will the free market forces btwn the actual involved economic actors be allowed to play out.  and that is btwn the miners and the users as they negotiate fees based on their own proprietary internal data, analyses, and motivations.  

and yes, they are more than capable of being able to figure out latency limits; if they aren't, they go out of business.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 04, 2015, 03:52:56 PM
 #28138

 there's a name for that.

*Mercenary?  
Which invalidates his claims, leaving you as pure as the driven snow. Naturally.

5 day old account?

Welcome to BitcoinTalk!

i'd love for all the new troll accts to keep pushing my message to the top of the Spec Forum.  bring it on.

Interesting approach -- ignore the the message and discredit the messenger Undecided

there's a name for that.


that's b/c your message is intentionally incomplete and misleading as your 5 day old acct demonstrates. 

you ignore my half of the story.  might i remind you that a verdict has not been rendered.  i believe the allegations have no merit.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 04, 2015, 04:15:37 PM
 #28139

i remember yesterday afternoon noticing several more than usual 1 tx blocks coming thru.  i thought, "that's interesting".  

i think this shows us how lazy pool operators can be.  after all, it's not really their hashers doing all the work; they're just in the biz of coordinating it all at the pool level while collecting quite a fair amt of coin.  i don't mean to trivialize their work but it's a good thing that they now have to pick up their game by taking these losses.   it's also important, long run, to get them to establish a fee market with the users and stop depending on core dev to guarantee their profits for them via block caps.

i read an article the other day that one of the largest pools out there in China was making something like $30000/day in BTC which probably is an enormous profit given what they pay for electricity there from a combo of hydro and state subsidy.  given their cheap labor no wonder the top 5 pools are in China.  what we need is more competition and decentralization which makes it apparent why they wanted Gavin to limit his initial increase to 8MB; to sustain their high profits and market share.  without a cap, this core dev subsidy and guarantee goes away and mining pools will be forced to compete on a more equal level.

i think it's worth emphasizing that the primary motive for a non-economic spammer is to disrupt user growth. certainly new users, but even existing users who get fed up with stuck unconf tx's.  it's the non-economic spammer that we need to be worrying about and focus on for solutions.  user growth is what will cause Bitcoin to square according to Metcalfe's Law.

w/o a cap on block size, this type of spammer becomes powerless to effect user growth as tx's remain affordable and reliable.  no limit takes the user out of the equation.  and the solution to the latency question is that miners have the freedom to choose block sizes based on user feedback.  and they will to prevent orphans and to stay profitable.

this recent disruption from the 1MB choke has disrupted all sorts of wallets and users as tx's now become unreliable.  what more evidence do we need for the increase in the limit?
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 04, 2015, 04:33:09 PM
 #28140

i remember yesterday afternoon noticing several more than usual 1 tx blocks coming thru.  i thought, "that's interesting".  

i think this shows us how lazy pool operators can be.  after all, it's not really their hashers doing all the work; they're just in the biz of coordinating it all at the pool level while collecting quite a fair amt of coin.  i don't mean to trivialize their work but it's a good thing that they now have to pick up their game by taking these losses.   it's also important, long run, to get them to establish a fee market with the users and stop depending on core dev to guarantee their profits for them via block caps.

i read an article the other day that one of the largest pools out there in China was making something like $30000/day in BTC which probably is an enormous profit given what they pay for electricity there from a combo of hydro and state subsidy.  given their cheap labor no wonder the top 5 pools are in China.  what we need is more competition and decentralization which makes it apparent why they wanted Gavin to limit his initial increase to 8MB; to sustain their high profits and market share.  without a cap, this core dev subsidy and guarantee goes away and mining pools will be forced to compete on a more equal level.

i think it's worth emphasizing that the primary motive for a non-economic spammer is to disrupt user growth. certainly new users, but even existing users who get fed up with stuck unconf tx's.  it's the non-economic spammer that we need to be worrying about and focus on for solutions.  user growth is what will cause Bitcoin to square according to Metcalfe's Law.

w/o a cap on block size, this type of spammer becomes powerless to effect user growth as tx's remain affordable and reliable.  no limit takes the user out of the equation.  and the solution to the latency question is that miners have the freedom to choose block sizes based on user feedback.  and they will to prevent orphans and to stay profitable.

this recent disruption from the 1MB choke has disrupted all sorts of wallets and users as tx's now become unreliable.  what more evidence do we need for the increase in the limit?
Pages: « 1 ... 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 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 ... 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!