Yes, this makes sense alright.
I haven't done any GPU mining yet, so I have only secondary opinions from other people about what can be achieved with what GPU model.

No, most people are still mining with the GPU miners created by Mr. Spread / girino and tsiv.

Can you provide us with a getinfo of the wallet you used for mining?

BTW mining 100 coins with 3 cards in 1 day seems unbelievable... what's going on here? Could it be that you started the wallet in testnet mode?

Yes, a few people are sponsoring further development.
It's just a matter of time for servicenodes to reach testnet.

Stay tuned.

You've done enough. Thanks for your assessment.
I will take over from here.

 

Thanks again for providing this insight.

It doesn't work for mr. spread if she has no "cheek pouches"... thanks but no thanks.  

Interesting,
so SHA256d is THE problem, although SPH is the most obvious thing that can be improved.

I need to look into this CodeXL thing to analyze kernels.

PS: mr. spread asks if you have any NSFW pics of naked hamster girls.  

I understand now, thanks.
This means that the efficiency can probably be increased by a tenfold, I would guess... wow!

You mean the way the whole SPH library has been ported to OpenCL, right?

 

One thing is for sure.
If we keep the algo as it is, and increase the block size to say 2 Megabytes (10x ), this will also make the padding / hashWholeBlock calculation 10x more heavy on your GPU.
 

I wonder if this algo can be reduced in complexity while still maintaining the same results.
(But we can also introduce new complexity if it helps make everything MORE anti pool and pro solo-mining)

After all, a solo-miner is always also a full node. Bingo!

What I want to find out how many times we actually need to calculate those double-SHA256 for the whole 200KBytes.
Maybe we can skip / hold a few iterations.

Yep!
It's a hamster dung powered wooden ASIC alright.
He created it himself, just with the stuff that was lying around... 

I told Mr. Spread about your idea.

He LOL'ed and...



Who is Mr. Spread?

padding is constructed starting with a seed/copy of the 32 bytes of previousHashBlock (or hashPrevBlock as it is called in the code), and then there are a few bitshifts (if necessary) and then tens of thousands of multiplications while we are filling the space (moving backwards thru the block).
But we basically start with just those 32 bytes, and everything is derived from them.

Padding starts here:

https://github.com/spreadcoin/spreadcoin/blob/master/src/main.cpp#L1511


First thing we do is fill up the Block from the left (right after the tx-section) with a few 0x07 bytes (only if necessary), just so that the current size of the blockdata size (header + txs) is exactly divisible by 4.
Maybe size is already divisible modulo 4, so we don't need to add any such bytes.

Then we define pointers pFillBegin, pFillEnd and pFillFooter, and then copy hashPrevBlock to the end (last 32 bytes) of this MAX_BLOCK_SIZE block, and then fill all the empty bytes in between moving backwards, 4 bytes per iteration.

Oh, and before we start we also turning these 32 bytes (or the 8 x 4 byte integers it consists of)  "ODD", by doing this *pI |= 1 operation on them, so that they are not divisible by 2 anymore).
Then we just iterate backwards, in 4 byte steps, always taking pI[3]*pI[7] and writing the multiplication result into pI[0], we do that, until we reach the transaction section (or those 0x07 bytes we created earlier (if they were necessary))...

That's about it.

So this large padding section doesn't have any regularity or repetition if you were expecting that.

It's pretty messy & chaotic data.  

Mr. Spread really wants your GPU to double-SHA256 a 200Kbyte datastructure. All the time.

I can't really judge it (yet), but it's probably badly implemented.

Yes, the idea is that to calculate hashWholeBlock we need to fill a complete MAX_BLOCK_SIZE block with data (that's why we have the "padding") and then Double-SHA256 it.

MAX_BLOCK_SIZE for spreadcoin is 200 Kbyte. https://github.com/spreadcoin/spreadcoin/blob/master/src/main.h#L35

So you have the header (less than 100 bytes) , followed by a few tx (<1 KByte or more), and then a giant padding (199 KBytes) to fill up the rest.

(This large pseudoblock is only existing temporarily in memory BTW, just to create the hashWholeBlock hash.)

From the whitepaper:


So the way I understand this, it means that padding calculations are more numerous the fewer transactions you get into your block.
Vice versa: The bigger the block already is (more txs), the less padding has to be added/calculated.

So in a way, padding is horrible on efficiency since we are mostly having 1 transaction blocks these days.
When this changes, then padding will not carry as much weight as it does now.

But I don't think that the padding calculations are that heavy anyway, but I need to do some benchmarks and look into OpenCL / Cuda.

And yes, we are ALWAYS doing a double SHA256 calculation on a MAX_BLOCK_SIZE block (200 KByte).
This size doesn't change from block to block, it's always the maximum.

Why Mr. Spread did it this way?
I'd have to guess, but probably to deliberately give GPUs a hard time?

Wasn't he playing the "CPU-Only-coin" - card for some time?

Can you be a little bit more specific please?

You said words like: WTF, Insane, Barbaric and Ooops, so now I am not sure anymore I understand the point you are trying to make.

Nobody doubts that the miner's efficiency can be improved, and everybody knows that SpreadX11 is pretty exotic *

So... what gives?

Are you just baffled by it? In a good/bad way?  

*(adds MinerSignature to the blockheader, and constructs MAX SIZE block by padding the previousBlockHash (this means many thousand iterations, depending on how "empty" the block is, but those are just simple multiplications and bit operations, no hashes) so that a hashWholeBlock value can be added to the header, so as to prove that whoever found a block solution was also the same person to sign the coinbase and know about the whole blocks content, before any pool did.).

Mr. Spread first created an AMD gpu miner, around 20th Nov 2014:

https://bitcointalk.org/index.php?topic=715435.msg9606917#msg9606917

And then during the next month it was decided that girino's GPU miner was "the better one" ?

https://github.com/girino/spreadcoinx11-sgminer

Anyway...

Yep, exactly... that's why I had girino in my mind in the first place.

But didn't someone else (girino?) create an "improved" version after that?

hm.... need to check the old thread's history.

I don't remember who put together the AMD miner, I'm not even sure if I was part of spreadcoin community yet back then.

Looks like whoever did this was pretty negligent.