Topic: [OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 # - page 145. (Read 458370 times)

Luke is guessing it is SatoshiDice, it might just be a run of bad luck.

Or it might be a side effect of Eligius accepting non-standard transactions.

Does Eligius include transactions that have not been transmitted/relayed to the rest of the network?  If so, it might be a side effect of that (and if that isn't a side effect now, it might be in the future if Eligius blocks take longer to verify as other nodes need to fetch transaction inputs from disk, instead of already having them in cache memory like transactions that ARE transmitted/relayed).

So it was SatoshiDice. I was wondering what had changed to make mining profits so noticeably worse despite difficulty being in previously experienced ranges.

You can always check if the block was orphaned by using your block's hash information.

No, it hasn't shown orphans at all for a while. I'm not sure a good way to see this info, considering most orphans are never seen by most of the network at all...

Great idea.

Eligius' block history is at: http://eligius.st/~artefact2/blocks/

The 'Status' column shows whether or not a block was orphaned. See if there's been an increase here, then check other pools, and let us know

Before starting to cry, I would actually prefer to see some numbers - i.e. what was the percentage of orphaned blocks 3 months ago, comparing to what it has been for the last few weeks.

Yes makes sense. Our own mined blocks are slow too and someone may jump us.

The bad news, this looks to be a global scalability problem. Maybe we need smaller and more blocks, but that's very unlikely to change, and has its own problems. Or a tiered network with small nodes not verifying everything -- again with problems.

Oh ok - now it does make sense.

The block itself contains the full data for each transaction. So if we fill the block to the max, that's a 1 MB block that each node needs to download (from another node, likely not a server with a big fat upload pipe) before it even starts validating it. Then once it's downloaded, it's up to 20,000 ECDSA cryptographic signature verifications before it decides the block is valid and begins relaying/uploading it to other nodes.

But it wouldn't make any sense.
It would mean that if I restart my client after one week being offline it executes getdata not only for the thousand of blocks, but also (in parallel) for every tx that is inside these blocks...
I don't believe bitcoin devs would program it like this - bitcoin is not such a bad piece of code.

I believe that is true and considering the size of deepbit its likely why he also decided to limit his block TX long ago and why they never suffered performance issues.

If I understand Luke, he said that when a pool mines a new block and announces it to the network, the block does't get relayed by any node until the node receives all the transactions that are listed inside the block.
Is this really true?
I would have thought that for my node receiving a transaction inside a block is the same as receiving it outside a block. Moreover, if there is a tx inside a block there shouldn't be anything pending for it - so why would it wait?

I am not sure I can follow. I understand how large blocks propagate slower through the network, and how this causes higher orphan rate. But how does not accepting *TXs* into your own to be mined blocks improve this scenario, as long as other pools still mine them?

-coinft

Thats exactly the counter problem that will start to happen unless this gets solved somehow.

If every pool start to limit their TX's, eventually the whole network will start to simply crawl and take ages to process transactions.

Sadly I do understand why you need to do this, this is seriously fking over the network and its getting worse every day starting slowly a month ago.

They propagate the network much slower. First, because the larger amount of data takes longer to upload. Then more, because Bitcoin nodes don't relay it until they've verified every transaction in the block.

Is there any specific reason that a large number of transactions would specifically cause orphans? Is it just because they are slower to be propagated to the network, or is it just too taxing to current pool softwares and algorithms to deal with?

FWIW, all pools have been experiencing higher stales and orphaned blocks due to the excessive transaction volume lately resulting from SatoshiDice abusing the blockchain (there are much cleaner ways to do the same thing). After our second set of 3 orphans in a row, I'm a bit on the annoyed end. For now, I am blocking transactions to 1dice* addresses and limiting our blocks to 32 transactions until we've caught up on the extra credit or at least have a viable alternative solution. I really hate to do this, as Eligius has traditionally been one of the most accepting mining pools, so any suggestions on other possibilities would be most welcome.

While SatoshiDice does force its users/victims to pay a transaction fee, those fees despite their high volume still don't add up to anywhere near the 300+ BTC we've lost by mining their transactions - so it's not like we can just "make up for" the orphans by throwing transaction fees into the pot.

Note that this is really a global Bitcoin scalability problem, but wasn't an immediate issue because up until recently the transaction volume growth was accompanied by an equivalent influx of more people using Bitcoin. SatoshiDice's abuse breaks that balance, so the developer and mining communities need to find a solution faster than previously anticipated.

I didn't experience any issues on this side.

FWIW, Eligius was just hit with 6gbit/sec DDoS for about 15 minutes before they gave up and moved on. No services were affected at any point as far as I can tell.

Hey,

first of all, I want to thank you for the good work and quick temporary solution that worked. Thanks!

Next thing is: the stats are broken. I can see some blocks were mined (the graph says so and my reward added from estimate to unpaid several times during the night), but they're not visible in Artefact2's block stats -- it still says we're mining one huge 65hr block...

The hash rate and estimate/unpaid reward seems fine. List of contributors seems fine. That leaves only the block stats.

Keep the good work!