I'm fighting with priorities on a daily basis, but I'll take a look at it soon.

You talking about both the AMD and NVidia version here?
They were created by different people as far as I know.

One of these days, I'll need to dive into GPU/ OpenCL programming too... it giggity-geeks the hell out of me already, lol!  

Well, I don't think the current algorithm needs to be changed at the core,
except to get rid of inefficiencies or to make the "pool-prevention"-mechanism stronger (which is certainly necessary).

If you have any ideas, let us know!

well, if - as you say - it causes a horrible inefficiency, then it's a bug in my book.

Hey thanks, that you take your time to look into this BTW.

I meant to say "bug", not error, ofcourse.

EDIT: BTW There is something peculiar in the in-wallet-miner where we are only applying the PoK-mechanism every 64 nonces:

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

does it work the same in the openCL version?

ok, I'm only looking at the in-wallet CPU miner code, probably it's just an error in the OpenCL version?

Can you point me to the line in the sourcecode of the OpenCL version please.

Yes, but wait, let's first further analyze this.

So you are saying we have about 3000 unnecessary SHA256 calculations per second, right?

On what GPU with what settings are you getting those values?

I'm currently occupied with servicenode development, and I was going to look into mining optimization only after that.
But if you want to give it a try and optimize the mining code, you are highly welcomed, and I'm sure the community is going to reward your efforts.

BTW, nobody doubts that mr. spread's code can be optimized. He left us in freaking mid-air.

I'm not sure about that either.

Mr. Spread uses the hashPrevBlock (which is known and stays the same while we hash) to fill up the padding he's using to construct a complete MAX SIZE block which is then run thru doubleSHA256 to create the hashWholeBlock value.
So you probably assume that it would be enough if we derived the hashWholeBlock just once after a miner has found a solution (since hashWholeBlock is not part of the actual POW).

But I'm not sure if we are not missing something important here.

I wouldn't mind if a mining specialist like you takes a close look at it.  

Yeah, I'm sure mr.spread's mining algo can be optimized.
The reason we use a little SHA256 in our algo is because the miner has to provide a hashWholeBlock value (to prove he himself had first knowledge about the block content, called POK "Proof Of Knowledge" in the sourcecode https://github.com/spreadcoin/spreadcoin/blob/master/src/main.cpp#L1529 ),
which ofcourse is derived thru a common double SHA256, and which has to be recalculated whenever ANYTHING in the block changes (timestamp, nonce (but only every 64 nonces), txs, etc...)

It's explained in mr. spread's whitepaper : http://www.spreadcoin.info/downloads/SpreadCoin-WhitePaper.pdf
(which admittedly is a little bit cryptic and not using the "clearest" english... I'm working on a more readable whitepaper version when servicenodes have progressed a little bit)

hm, quite curious,

if you use the duckduckgo search engine, you get all the right results for spreadcoin, including recent price, etc:



While when you use google, the results are pretty lame:



we only come in at rank 4, and there is no price mentioned.

I continue to dislike google more and more with every passing day... lol 

well, last months don't really count, since I didn't have much time to work on anything.

Since beginning of november I can concentrate much more on spreadcoin.

So... Stay tuned!

 

If I were forced to estimate I would say approximately 35%

Working on them on a daily basis!

I finally found someone that sells blockchains online... do you want one?









 

Well, naysayers gonna naysay!  

Enjoy low prices as long as you can.

Yep, nothing has changed!

Small update.

I made some major steps in the blockexplorer, will not take much longer

Teaser:



also, while exploring the code, I did have an idea...
maybe we can use this as a feature for an upcoming version.

Currently all cryptocoins use automatically generated change addresses for all their transactions.

This often confuses the shit out of people, and can have quite unforseen consequences.


I want to explore what happens when people have more freedom/control and can decide to tell the wallet that it should send the change back to the same address (or one of the inputs)...
so that no change addresses are generated.

There are some interesting remarks in the posts and comments here:

http://bitcoin.stackexchange.com/questions/736/how-does-change-work-in-a-bitcoin-transaction

http://bitcoin.stackexchange.com/questions/1629/why-does-bitcoin-send-the-change-to-a-different-address

http://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses/

It's scary how many people have already lost money because of those auto-change addresses...

I think sometime in the near future I'll create a patch that gives the user the power to decide:

Do I want to use automatically generated change addresses or not?

(People will be able to switch auto-generated change addresses on and off, as they see fit.)

This will also allow people to use their paperwallet for a quick payment, without having to fear where the change goes.

but that's just an idea to explore, something that would give people more control about what actually happens during the transaction.

Stay tuned, we'll create a testnet version for this soon ... (not gonna experiment with real SPR here obviously)

Thanks.

Still exploring it, you can expect an updated more in-depth whitepaper soon.

Blockexplorer is underway.

We can increase it with the next fork!
Maybe by 10x