Topic: [ANN] SpreadCoin | True Decentralization (No Pools) | Testing New Masternodes - page 14. (Read 20123 times)

Even if someone had several machines mining to separate wallets it still creates the most decentralized coin in all of existence.

If a miner is reporting a hashrate set above the maximum then there will be a refusal of payout.  They will effectively mine the block but will not receive the reward.

Please do tell how you would implement such a system?

Edit: wow, someone(s) filled MyFarm's wall.

What if we considered a hashrate cap? Even if people organized themselves in pools they could only mine up to a certain point. Perhaps no more than 20 Mh/s per mining operation.

Yes! Alex Millar is who I had in mind when I said "automated escrow".

I saw one of his videos a few months ago, that explained it all very well:

https://www.youtube.com/watch?v=ITRPrGuzqjE

(wait Andrew Miller not the same person as Alex Millar, weird coincidence.lol)

Can this even be automatized?
This all sounds we would need to trust someone to initiate all that, so this will just introduce a single point of failure again, which is what will prevent such pools from appearing in the first place.

It's an active area of research; amiller wrote a paper about it recently that was pretty neat.
https://cs.umd.edu/~amiller/nonoutsourceable.pdf

I don't think multisig would work because I think that (a) coinbase needs to output to a single P2PKH output and (b) you'd have to have all members of the pools receive all blocks from each other and sign them before determining if they met difficulty, which would be super slow. You could maybe send the coinbases to a multisig account after, and have all the pool members sign off on payouts, but that seems overly complicated.

Why involve BTC at all?

I would love to see such a proposed "escrow pool" that uses automated escrow by using multisignature on the SPR blockchain itself.
I wonder if this could work out, and where potential problems will appear.

Anyway, the term "pool prevention" still applies to spreadcoin. And maybe we just need to step the pool prevention up a notch.

Oh, just to make accessibility to the pool easier. Mining a SpreadCoin block solo could be kind of a pain, and otherwise you'd have to buy the coins from an exchange (with BTC). Obviously you can just use SpreadCoins themselves too if you want to keep it 1:1, but more users will probably join a pool than only requires a tiny amount of BTC to join and the amount of risk losing SpreadCoins versus equivalent Bitcoins is probably pretty similar. If SpreadCoins were worth more you might want to use them instead I guess.

As far as say, a block equivalent in BTC: right now that's about $220 USD * 25 = $5,500. But at Bitcoin's current market cap, the vast majority of small miners are being phased out anyway, so maybe a $5,500 entry fee (that you'd eventually get back) isn't such a big deal. It's hard to say. It's difficult to see SpreadCoin getting anywhere near that value in the short term, too.

To make the pool ultra simple too, just make the username the pubkeyhash you're mining to with your coinbase/signing your blocks with.

Given the recursive algorithm used to pad the blocks, I think it should be possible to code an imperative algorithm to pad the blocks and compress the block as well when sending back to the main server, so that bandwidth consumption isn't huge and you don't need to accept super high difficulty shares.

I'd love to hear your reasoning as to why it's not needed.

Thanks

No not at all and that workaround is also not absolutely needed - but a good idea as some kind of extra insurance, I'm just saying that 3500 coins is quite low as a bounty.

So what you're saying is a potential workaround is really hard and costly to implement?

That is quite low... IMHO..

This solves the problem fairly elegantly I believe. It's still not the ease of running a "standard" pool, and there are additional considerations, like: how popular would a BTC pool be if you had to deposit 25 BTC to mine there (even considering that their wouldn't be any other pools where you didn't have to do this)? Edit2: this plays on the "(which isn't much)" above; what if it was a "lot"?

Edit: tacotime, why wouldn't you send the SPR equivalent of one block reward? BTC would be subject (I believe unnecessarily) to exchange rate volatility.

There's a 3500 SPR bounty if anyone is able to make this idea work.

Yeah, that's the idea.

you are talking about something like an "Automated Escrow", right?

Make everyone pay into a pot first, so should they dare to steal, you just keep what they previously payed.
And if they play nice, they can have their collateral back.

So, for a pool, I think what you would do is just have people send the BTC equivalent of one block's reward to the pool (which isn't much), then if the miner's steal the reward, the pool still retains their deposit so net miner gain is 0. You would have the miners themselves mine to their own pubkeyhashes, and you'd submit partial solutions to these blocks to the pool itself. When the miner gets a block, they would be given n many blocks to get the coinbase from their block to the pool to redistribute to the other miners. If they didn't return the reward to the pool, the pool would then just take their deposit and ban them.

So, I don't think there's a big issue with pooling, just a slightly more complicated implementation. There's a small associated cost with joining a pool, but it's not really much.

Yes, also let's motivate people to really pose the hard questions here in this thread. Let's show that we can have a deep discussion without calling anyone a "troll" immediately.
(I remember that in early april I myself was called a troll a few times in the darkcoin thread here... how could that happen???)

Maybe even make it our motto, to NOT call anyone a troll in this thread.
Instead just moderate the obvious saboteurs away, and just keep on talking to the people who don't yet understand spreadcoin.