Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB

[un_ordinateur]

You could check for this by looking at the network hash rate and comparing it to the difficulty. Difficulty being ess than the hashrate would give you the percentage of dud miners. But it would not affect live miners.

The network does no "know" the hashrate. The hashrate as reported by some stats sites is estimated based by the current difficulty and the speed at which blocks are found; averaged over a few hours.

Isn't the hashrate measured based on the speed at which shares are found?

The hashrate of a given pool, as reported by that pool; yes, of course. The hashrate of the whole network, as reported by https://bitcoinwisdom.com/bitcoin/difficulty or http://bitcoin.sipa.be/, no; it is based on blocks found, because it does not know about shares found by every pool or individial miner.

[wizkid057]

No network wide hashrate stat could ever be as accurate as a pool-wide hashrate.

You can't sum all pool hashrates to get the total because of solo miners, private pools, lucky cpu miners, etc.

[un_ordinateur]

(This could probably be fixed with a soft fork.  If two blocks arrive at nearly the same time, take the one with the more accurate timestamp.  But that's not the current rule.)

It would be more complicated than that: How do you objectively what is the "right" time to compare blocks timestamps to? You would need to define a reference; which would introduce a single point of failure, and a single trusted entity, both of which are against the goals of bitcoin.

The current implementation rejects blocks that are more than a few minutes off according to the miners, and that appear to be "before" the latest block, because even without a central autority "built-in" the protocal, you can be pretty sure that all "good faithed" miners will agree on the current time within a few minutes. Such checks prevents an attack by which a miner would "fake" the timestamp to make the block appear having been far in the future on in the past to trick the difficulty retargetting algorythm to do stupid things, but it is not accurate enough to know if a block is "better" than another.

[anth0ny]

(This could probably be fixed with a soft fork.  If two blocks arrive at nearly the same time, take the one with the more accurate timestamp.  But that's not the current rule.)

It would be more complicated than that: How do you objectively what is the "right" time to compare blocks timestamps to? You would need to define a reference; which would introduce a single point of failure, and a single trusted entity, both of which are against the goals of bitcoin.

As far as how you objectively define the right time in a way which is not controlled by a single entity: https://en.wikipedia.org/wiki/Coordinated_Universal_Time and https://en.wikipedia.org/wiki/International_Atomic_Time

TAI as a time scale is a weighted average of the time kept by over 200 atomic clocks in over 50 national laboratories worldwide.

So, 200 points of failure, and 50 trusted entities.  And I think we'd discover it pretty quickly if someone managed to hack into all the atomic clocks in the world and mess with their clocks.

As far as how you distribute that time, NTP does not have a single point of failure, nor is it controlled by a single trusted entity.

If two blocks arrive within 5 seconds of each other, choose the one with the more accurate time.  Where's the single point of failure?  Where's the single trusted entity?  What's the attack scenario in the first place?  Worst case scenario the fix is imperfect; it doesn't introduce any new vulnerabilities.  If the two blocks don't arrive within 5 seconds of each other, everything goes along as normally.

And yes, NTP isn't perfect.  There are security enhancements from the old days of NTP (including from the time when Satoshi mentioned it in the code as a future improvement), though, and even more that can be made.

When two blocks arrive within 2 seconds of each other, and one is timestamped 2 seconds ago, and the other is timestamped 2 minutes ago, you build on the one with the more accurate timestamp, because it's much less likely that that's the one which is employing "selfish mining" or whatever you want to call it.  It's not a perfect solution, but it's much better than what we have now.

The current implementation rejects blocks that are more than a few minutes off according to the miners, and that appear to be "before" the latest block, because even without a central autority "built-in" the protocal, you can be pretty sure that all "good faithed" miners will agree on the current time within a few minutes. Such checks prevents an attack by which a miner would "fake" the timestamp to make the block appear having been far in the future on in the past to trick the difficulty retargetting algorythm to do stupid things, but it is not accurate enough to know if a block is "better" than another.

That's a start, but NTP accuracy is much better than "a few minutes".  Hell, a clock synced via NTP once per day is almost certainly going to be a whole lot more accurate than "a few minutes".  We can't close the gap completely.  But being able to delay a block by only a few seconds makes an attack a lot less likely to be successful than if you can delay a block by a few minutes.

"Good faithed" miners should be able to agree on the current time within a few seconds.  There's no good excuse for a miner's clock being off by dozens of seconds.

[hephaist0s]

I'll work on namecoin more after I fix the code and while I wait for processing on some of this data...

Thanks, good to hear! I know there's a lot on your plate, and NMC is a small concern by comparison, but after a month it does start to add up for some of us.

Tip sent! Because, you know... bribery.
txid:c784a374deec98f637acf7c7413ba80398befe359dc89e1c1dd5f7c2bc299afc

[un_ordinateur]

(This could probably be fixed with a soft fork.  If two blocks arrive at nearly the same time, take the one with the more accurate timestamp.  But that's not the current rule.)

It would be more complicated than that: How do you objectively what is the "right" time to compare blocks timestamps to? You would need to define a reference; which would introduce a single point of failure, and a single trusted entity, both of which are against the goals of bitcoin.

As far as how you objectively define the right time in a way which is not controlled by a single entity: https://en.wikipedia.org/wiki/Coordinated_Universal_Time and https://en.wikipedia.org/wiki/International_Atomic_Time

TAI as a time scale is a weighted average of the time kept by over 200 atomic clocks in over 50 national laboratories worldwide.

So, 200 points of failure, and 50 trusted entities.  And I think we'd discover it pretty quickly if someone managed to hack into all the atomic clocks in the world and mess with their clocks.

As far as how you distribute that time, NTP does not have a single point of failure, nor is it controlled by a single trusted entity.

If two blocks arrive within 5 seconds of each other, choose the one with the more accurate time.  Where's the single point of failure?  Where's the single trusted entity?  What's the attack scenario in the first place?  Worst case scenario the fix is imperfect; it doesn't introduce any new vulnerabilities.  If the two blocks don't arrive within 5 seconds of each other, everything goes along as normally.

And yes, NTP isn't perfect.  There are security enhancements from the old days of NTP (including from the time when Satoshi mentioned it in the code as a future improvement), though, and even more that can be made.

When two blocks arrive within 2 seconds of each other, and one is timestamped 2 seconds ago, and the other is timestamped 2 minutes ago, you build on the one with the more accurate timestamp, because it's much less likely that that's the one which is employing "selfish mining" or whatever you want to call it.  It's not a perfect solution, but it's much better than what we have now.

The current implementation rejects blocks that are more than a few minutes off according to the miners, and that appear to be "before" the latest block, because even without a central autority "built-in" the protocal, you can be pretty sure that all "good faithed" miners will agree on the current time within a few minutes. Such checks prevents an attack by which a miner would "fake" the timestamp to make the block appear having been far in the future on in the past to trick the difficulty retargetting algorythm to do stupid things, but it is not accurate enough to know if a block is "better" than another.

That's a start, but NTP accuracy is much better than "a few minutes".  Hell, a clock synced via NTP once per day is almost certainly going to be a whole lot more accurate than "a few minutes".  We can't close the gap completely.  But being able to delay a block by only a few seconds makes an attack a lot less likely to be successful than if you can delay a block by a few minutes.

"Good faithed" miners should be able to agree on the current time within a few seconds.  There's no good excuse for a miner's clock being off by dozens of seconds.

I get your point. Still, it would be relying on data external to the blockchain; and I believe it would be difficult to convince the devs of that.

Also, there is a whole problem of it being "unveriefiable"; that is, in case of a blockchain reorg, nodes would have to accept new "old" blocks, and there is no way to prove that their timestamp is true. However, that is a minor problem, because what we want is a fix for otherwise equally valid topmost block.

Also, the current rules is essentially "undefined behavior"; it says to miners to mine on the first they recieved. However, miners may very well choose to accept the most accurate block, and it would not fork the chain, so they are totally free to choose what they want.

[anth0ny]

I get your point. Still, it would be relying on data external to the blockchain; and I believe it would be difficult to convince the devs of that.

We could always make our own NTP network.

At this point there's already a rudimentary clock synchronization protocol which is being used.  It just isn't a very good one.

Also, there is a whole problem of it being "unveriefiable"; that is, in case of a blockchain reorg, nodes would have to accept new "old" blocks, and there is no way to prove that their timestamp is true. However, that is a minor problem, because what we want is a fix for otherwise equally valid topmost block.

Also, the current rules is essentially "undefined behavior"; it says to miners to mine on the first they recieved. However, miners may very well choose to accept the most accurate block, and it would not fork the chain, so they are totally free to choose what they want.

Yes to both. Any part of the network could implement this, and would remain compatible with the rest. Once 50% of the network implemented it it'd be in the best interest of the rest to do so as well, but the only harm in not implementing it is that you'd be more likely to be on "the wrong side of the fork" in the case where two blocks are released near-simultaneously (which should be infrequent when the network is not under attack).  If two or three of the top pools got together, this could easily be reached.

[roy7]

Also, the current rules is essentially "undefined behavior"; it says to miners to mine on the first they recieved. However, miners may very well choose to accept the most accurate block, and it would not fork the chain, so they are totally free to choose what they want.

I never realized that. Thank you. I guess I assumed it was the block with the highest value (transactions) or some other tiebreak. So a miner may collect 2-3 blocks found at the same time, but will keep working on the one they heard about first. As soon as someone finds a 2nd block, the one they were working on becomes the "real" block since they have a longer chain and the other blocks are now orphaned.

If two miners working on different blocks also find 2nd blocks at the same time, they keep mining separate chains until someone first finds a 3rd block for one of those two chains?

Thanks for the education.

[wizkid057]

Looks like this thread has turned into a lot of non-Eligius specific speculation... wonder if a mod could split some of this off.

[un_ordinateur]

Also, the current rules is essentially "undefined behavior"; it says to miners to mine on the first they recieved. However, miners may very well choose to accept the most accurate block, and it would not fork the chain, so they are totally free to choose what they want.

I never realized that. Thank you. I guess I assumed it was the block with the highest value (transactions) or some other tiebreak. So a miner may collect 2-3 blocks found at the same time, but will keep working on the one they heard about first. As soon as someone finds a 2nd block, the one they were working on becomes the "real" block since they have a longer chain and the other blocks are now orphaned.

If two miners working on different blocks also find 2nd blocks at the same time, they keep mining separate chains until someone first finds a 3rd block for one of those two chains?

Thanks for the education.

No, the current rule is really "You mine on the first topmost valid block you recieved", which means three things can happen:
a) You find another block, you broadcast it to the network; it becomes the longest chain.
b) Somebody else finds another block after the block you were working on, it becomes the longest chain and you start mining on that block.
c) Somebody else finds another block on top of another block as equally valid as the one you were working on, you discard your block and accept that chain as the new longest, and mine on top of it.

And yes, in the unlikely case another block was found simultaneously on both chains, both of them would continue to coexist.

But it must be noted that "simulteneaously" is relative here. Two blocks cannot be found at the exact same time. However, accounting network latency, it takes about 1 min for all the nodes to be aware of a new block, in that timeframe, if another block is found, some part of the network may hear about that other block first.

Finally, it must be be noted that work spent on those "alternate" chain is completely lost. Once a block is orphaned, nobody can claim it's reward. And since a potentially large fraction of the network spent time mining on blocks that were, ultimately, discarded, the apparent hashrate of the longest chain is diminished, which means, slower confirmations, and difficulty decrease.

[un_ordinateur]

Looks like this thread has turned into a lot of non-Eligius specific speculation... wonder if a mod could split some of this off.

Oh sorry. I'll try to stay on topic.

[roy7]

Looks like this thread has turned into a lot of non-Eligius specific speculation... wonder if a mod could split some of this off.

My apologies for contributing to that. I hate it when it happens on other threads.

[un_ordinateur]

And to be back on the eligius topic... Seems the pool has finally caught up, we are out of failsafe!

[georgem]

finally.

[wizkid057]

Failsafe is mostly over.  I'm going to make some more tweaks now that everything is caught up and verified which may cause a few minutes of failsafe here and there... but overall should be good to go.

I'll do my best to get a manual catch up done soon, also.

[blubberli]

So, NMC payouts would be next?

SCNR 

[wizkid057]

So, NMC payouts would be next?

SCNR 

Decided NMC would be better spent on more unicorn blood...

[/troll]

[blubberli]

Decided NMC would be better spent on more unicorn blood...
[/troll]

Meh, use chicken blood, much cheaper and works, too ^^

[georgem]

So, NMC payouts would be next?

SCNR  

Decided NMC would be better spent on more unicorn blood...

[/troll]

thanks for your efforts wizkid, now I can relax and watch the first part of season 4 game of thrones...
not quite "unicorn blood" but bloody nonetheless. :-)

Looking forward to NMC

[wizkid057]

Decided NMC would be better spent on more unicorn blood...
[/troll]

Meh, use chicken blood, much cheaper and works, too ^^

But a guy on IRC was selling it super cheap... 10000 NMC per liter.