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

I'm not sure I'm following.  Based on the ratio of empty blocks to non-empty blocks, it looks like the mean time to process a block is 16 sec and 35 sec for F2Pool and AntPool, respectively.  Are you suggesting they're "faking it"?

They gain a 600ms advantage on the verification, then another few seconds on the download, depending on their bandwidth. 600 seconds average in a block, so if they manage to get an advantage of 10 seconds, that's 10/600 or 2% greater profitability than other miners. There will be less incentive for that when the reward halvings happen (fees double relative to subsidy). *shrug* Maybe they are also making some political point, or simply can't be bothered dealing with the txns. But the recent orphans should have cost them a bit. They are playing their own sort of game theories, and not always winning.

Thanks Mixles!  Do you have any thoughts on why F2Pool and AntPool are mining so many empty blocks if the previous block can be validated so quickly?

Not sure if any solution is merged yet (see my edit above). But we are talking less than 600ms even without the extra speedup, or 10ms with the speedup.

Thanks.  So it looks like the fix was implemented this February, and that now TXs are not re-verified if they're already in mempool?

It would be stupid to forward unverified txns, and it would also be stupid to verify them twice. Easy to fix, so there's no reason for it to verify twice.

About 600 milliseconds to verify a 1MB block, will be reduced to about 10 ms

https://github.com/bitcoin/bitcoin/pull/6077

https://github.com/bitcoin/bitcoin/pull/5835

Great point.  Does anyone know how Bitcoin Core currently works in this regards?  Is every transaction in a block (re-) verified?  Or are the transactions first hashed, and if matched to a TX in mempool not re-verified, thus saving time. 

Yes.

Moreover, I don't see why the time spent verifying would be significant. The vast majority of transactions would have been verified by a full node before being included in the block, and then it is just a case of checking the hash, and looking up that the txn was previously mempool verified. The verification time for a block should be insignificant relative to its download time (unless it's a flood attack of new txns by a miner). Or am I missing something?

I'd like to hear Holliday's take on replace-by-fee. And DeathAndTaxes take on this too (where did he go??).

Cool.  Seems we agree then.

Clearly F2Pool messed up.  And they lost 100 BTC because of it.  But that wasn't for SPV mininig during the short amount of time it takes to process the previous block; it was for not bothering to validate the previous block at all.

SPV mining while the previous block is being verified is the profitable strategy, as shown here.  It also serves to produce "defensive blocks" that limit the effective blocksize without the need for a protocol-enforced blocksize limit, as discussed here.

I personally don't see much wrong with replace-by-fee, but I'm old-school and believe that everyone who uses native Bitcoin should do so based on confirmations and tuning the number of confirmations one needs based on the value and importance of a given transaction, operational aspects of the functioning system at a given time, etc. This was, to me, always a fundamental concept of Bitcoin.  Trying to mold Bitcoin into a real-time system has resulted in the problems and hassles which simply do not need to exist, and that is even more the case when sidechains can proxy Bitcoin via a more purpose-oriented instant transaction solutions.

RBF has been described as 'vandalism'.  I don't see it that way as much as a timely and necessary lesson delivered in a way that will make more people perk up their ears and listen before it is to late (if it is not already.)  Irrespective of Satoshi's writings I consider SPV to be fraught with risks and dangers.

The only possible upside here is that perhaps these dick-head miners will pay the ultimate price and that we'll be more-or-less forced to entirely re-do (and more closely tie) the mining and transfer functions of the network.  In doing so, throwing sha256 out on it's ass as an side-effect would be quite positive to my way of thinking.

I can see why one might want to spin it that way. In fact Monero's dominance was largely assured by the fact that it was the first (even remotely) fairly launched cryptonote coin. The 82% ninja premine fraud was never going to fly. None of the others were sufficiently better in terms of features, leadership, community or anything else, to overcome that lead.


Again, the dominance was never really in question, but it also isn't clear that "features" are needed (or at least  they don't need to be rushed out in some sort of race) or that a feature war is that way to go. A large part of the user base simply wants a non-transparent blockchain with a credibly reviewed, sufficiently refined, and well maintained (and therefore for these three reasons relatively secure and stable) code base.


There is an ongoing question (requiring actually analysis and research, not just forum posts) whether this change to the privacy model is needed or desired. It is being considered.

I'm surprised to hear this from you, Holliday.  Can you explain why you think mining on the blockheader during the short time it takes to validate the block is bad?  It is clearly the profit-maximizing strategy, and I also believe it is ethically sound (unlike replace-by-fee).  

...inciting to talk about myself--LOL.

Until you offer your own coin for peer review, you're going to sound like that know-it-all brat on the basketball court who points out the flaws in everyone else's game, goes on endlessly about how great he is, but never picks up a ball and backs up the talk. Since your American, you've probably heard this: Put up or shut up.

Again, it's not that you are criticizing or refusing peer review, it's that you are simultaneously criticizing and refusing to put your project up for peer review--it may be a good (or even correct) strategy, but don't bitch when others point out its annoyance factor.

interesting, isn't it?

Except I've already proven three times in my history (twice as main author and the last and most successful as the ONLY* author), that I am also builder of popular software.

https://www.google.com/search?q=neocept+wordup (late 80s and early 90s)
http://relativisticobserver.blogspot.com/2012/01/illustrated-evolution-of-painter-ui.html (mid 90s)
https://www.google.com/search?q=3Dize+coolpage (late 90s and early 00s)

I fell off the cliff in the mid-00s due to mostly what I can summarize as "Philippines" and family background. The details are blinding (see light & dark only) an eye, lost marriage, mid-life crisis, severe STD infection in last week of May 2006 (leading to M.S. by now) and murder of my only non-step sister in last week May 2006, etc..

I really hate this being incited to talk about myself. I know people are going to use this against me. Besides I am interested in creating new things, not the past.

P.S. Armstrong's 8.6 cycle (1000 x Pi days) added to last week of May 2006, is Feb 2015. That was exactly when I began coding a social network which I did ship. First software I've shipped since 2006. Note in 2008 - 2011 period I got off into learning new programming languages such as Haxe, Haskell, and Scala and completely new ways to think about programming. In that period I messed around with numerous projects without shipping any, which maybe was a required gestation period for the new insights and to recharge artistic inspiration. I also got acutely ill (ER, ICU) in May 2012 and chronically hence.

Edit: I am not really acting as a critic, i.e. I haven't changed what I've always done. I am doing engineering analysis for design work. I just happen to share it, which turns out to be critical against inferior engineering.

* except for the 2-3 weeks of coding for the Objects window, for which I paid $30,000 in 2001 (inflation-adjust that!) to a former programmer of Borland C (because I was face down in the bed with gas in my eye to hold the 100% detached retina in place so the lasered joins could solidify).

Wrong assertion of why people (at least me and some observable others) are criticizing you. Maybe, someone is, but certainly not everyone....

Gene Siskel, the better half of the movie critic duo Siskel and Ebert, was asked about if he ever wanted to direct--since he was so knowledgeable and his love of films was evident. He stated that he did want to direct, but as long as he was a critic, thought any directing efforts would be a conflict of interest. To put it more simply, he knew he could game his fans into believing his techniques were the best techniques and didn't want the potential to delude himself or the audience--even if his efforts were a sincere and earnest attempt at making a great film.

Rarely, do good critics make better artist. ATM Ben Jonson, the poet/critic is the only example I can think of, but that is more of a tie than him being better at one or the other.

This is an example of myopic, one-dimensional 'thinking' (illogic) that is promulgated widely by n00bs.

Centralization isn't a bottleneck. Monopolies don't restrict degrees-of-freedom. Neither are an outcome of increasing orphan rate by increasing blocksize relative to block period.

I think these metrics should specifically exclude the two pools above as they are the ones who were SPV mining and not switching to using a validated block-header as soon as possible.

Don't get put-off from posting by Greg's feedback as it is easy to be silenced by someone-who-knows-best and let them run the show.
My big takeaway from his comment is how you got him into arguing from a position that big blocks are OK (handclap and kudos to you). In fact, I have learnt now that even 7.5GB blocks are today theoretically tolerable in at least one respect (validation where tx are pre-validated), although l suspect not in quite a number of other crucial respects.
Wasn't Gavin's doubling end-point 8GB in 2036? Effectively the same end-point!

I am reminded of Mike Hearn's words of wisdom:

One less bottleneck to expect with larger blocks.