Author

Topic: Gold collapsing. Bitcoin UP. - page 153. (Read 2032248 times)

legendary
Activity: 4690
Merit: 1276
July 04, 2015, 11:46:00 AM
...
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.

Paymium sat on more BTC than this of mine for quite a while.  They published a plan to return funds and lived up to it in my case.  Although I'm pretty sure the 'accident' was for the purpose of privatizing the unclaimed value contained in the Instawallet system, they didn't permanently injure me personally.  I called them out for their likely malfeasance as a service to the public, but did not give them a neg rating.

If cypherdoc collected, say, 10% of the money that people sent to Hashfast in compensation for his role as a feeder in the scam, it seems rational that the funds would be gladly refunded if he were unaware of the scammy nature of Hashfast, and forcible refunded if he was.  If he voluntarily disgorged the ill-gotten gains, one would not wish to give him a negative rating.  Indeed, just the opposite would be appropriate so withdrawing a temporary negative rating would be appropriate.

I don't watch very many mainstream movies, but in Silicon Valley we were hearded down to the theater to take a break regularly and I caught 'the Minority Report' that way.  I remember the ex-con eye doctor who made a living covertly replacing people's eyes.  Somehow the Hashfast goings-on reminded me of this work of fiction.

legendary
Activity: 1764
Merit: 1002
July 04, 2015, 11:33:09 AM
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?
legendary
Activity: 1764
Merit: 1002
July 04, 2015, 11:15:37 AM
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?
legendary
Activity: 1764
Merit: 1002
July 04, 2015, 10:52:56 AM
 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.
legendary
Activity: 1764
Merit: 1002
July 04, 2015, 10:44:10 AM
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.
legendary
Activity: 1764
Merit: 1002
July 04, 2015, 10:38:41 AM
 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.
legendary
Activity: 1764
Merit: 1002
July 04, 2015, 10:28:05 AM
...
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.
legendary
Activity: 1764
Merit: 1002
July 04, 2015, 10:23:47 AM
...
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.
legendary
Activity: 1764
Merit: 1002
July 04, 2015, 10:16:11 AM
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.
newbie
Activity: 2
Merit: 0
July 04, 2015, 10:08:53 AM
^^I catch on quick Cool
legendary
Activity: 1764
Merit: 1002
July 04, 2015, 10:05:09 AM
...
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!

legendary
Activity: 1764
Merit: 1002
July 04, 2015, 10:03:49 AM
...
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.
legendary
Activity: 1260
Merit: 1116
July 04, 2015, 10:00:04 AM
...
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!
newbie
Activity: 2
Merit: 0
July 04, 2015, 09:57:28 AM
...
look up the definition of a shill.

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

https://bitcointalk.org/index.php?action=trust;u=8389
legendary
Activity: 1764
Merit: 1002
July 04, 2015, 09:47:22 AM
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.

 
legendary
Activity: 1764
Merit: 1002
July 04, 2015, 09:30:58 AM

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?
legendary
Activity: 1162
Merit: 1007
July 04, 2015, 08:54:01 AM
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.
legendary
Activity: 1162
Merit: 1007
July 04, 2015, 08:40:57 AM

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.  
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
July 04, 2015, 07:28:55 AM
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
legendary
Activity: 1473
Merit: 1086
July 04, 2015, 03:55:18 AM
How did this religious bullshit end up in this informative thread?
Jump to: