[ANN] SpreadCoin | True Decentralization (No Pools) | Testing New Masternodes

[njs811]

The payout for finding a block would look at the reported hashrate during the time the block was mined.  If that hashrate exceeds the maximum the payout is refused.

Such a thing doesn't exist.

Not yet. If there was a third party service which held all of the payouts until the hashrate is determined that would solve large pools.

Wait, hold on. You're suggesting a centralized system to "solve" the problem of too much hashpower in too few hands?

Essentially yes. However, i'm not suggesting an escrow service or a website handle this.  What if something like the masternodes program handled it.

The problem remains that it's still effectively unenforceable.

But i'm not entirely understanding why. Even if someone had their machines pointed at several different pools that still keeps pools small and numerous. We can never run into the 51% problem.

Then why don't they solo mine?

EXACTLY! SPREADCOIN!

[tacotime]

I would love to see such a propsed "escrow pool" that uses automated escrow by using multisignature on the SPR blockchain itself.
I wonder if this could work out.

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.

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.

I don't know why you would, seems to make it overly complicated when it doesn't need to be.

[luigi1111]

The payout for finding a block would look at the reported hashrate during the time the block was mined.  If that hashrate exceeds the maximum the payout is refused.

Such a thing doesn't exist.

Not yet. If there was a third party service which held all of the payouts until the hashrate is determined that would solve large pools.

Wait, hold on. You're suggesting a centralized system to "solve" the problem of too much hashpower in too few hands?

Essentially yes. However, i'm not suggesting an escrow service or a website handle this.  What if something like the masternodes program handled it.

The problem remains that it's still effectively unenforceable.

But i'm not entirely understanding why. Even if someone had their machines pointed at several different pools that still keeps pools small and numerous. We can never run into the 51% problem.

Because a pool is not forced to use the same pubkeyhash for each block, and cannot be forced to do so. Therefore, a pool that is approaching whatever limit you set would just add a second pubkeyhash, effectively appearing as a second pool, and solving nothing.

[luigi1111]

I would love to see such a propsed "escrow pool" that uses automated escrow by using multisignature on the SPR blockchain itself.
I wonder if this could work out.

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.

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.

I don't know why you would, seems to make it overly complicated when it doesn't need to be.

Unrelated, but is the gist of that paper that one would need to use ZKP so that pools could not know a "bad" miner is cheating, because they wouldn't know he solved the block in the first place?

[njs811]

The payout for finding a block would look at the reported hashrate during the time the block was mined.  If that hashrate exceeds the maximum the payout is refused.

Such a thing doesn't exist.

Not yet. If there was a third party service which held all of the payouts until the hashrate is determined that would solve large pools.

Wait, hold on. You're suggesting a centralized system to "solve" the problem of too much hashpower in too few hands?

Essentially yes. However, i'm not suggesting an escrow service or a website handle this.  What if something like the masternodes program handled it.

The problem remains that it's still effectively unenforceable.

But i'm not entirely understanding why. Even if someone had their machines pointed at several different pools that still keeps pools small and numerous. We can never run into the 51% problem.

Because a pool is not forced to use the same pubkeyhash for each block, and cannot be forced to do so. Therefore, a pool that is approaching whatever limit you set would just add a second pubkeyhash, effectively appearing as a second pool, and solving nothing.

Are you saying that a pool can appear as two pools while working on the same block?

[e1ghtSpace]

I would love to see such a propsed "escrow pool" that uses automated escrow by using multisignature on the SPR blockchain itself.
I wonder if this could work out.

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.

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.

I don't know why you would, seems to make it overly complicated when it doesn't need to be.

Unrelated, but is the gist of that paper that one would need to use ZKP so that pools could not know a "bad" miner is cheating, because they wouldn't know he solved the block in the first place?

No, each mining account would mine on a different private key.

[nonce-pool]

How much is the bounty for creating a public pool now?

At least 3500.

Terms are,

Pool needs to be active for atleast 30days.

Anything i missed "myfarm"?

Edit, from the FAQ

Q.  Is it possible to create pools?
A.  If a pool is created, any miner can steal all of the blocks.  Theories have been put forth on ways to get around this such as coding in a collateral system, but none have been created.  There is currently a 3500 SPR bounty on the creation of a public pool that successfully runs with no stolen coins for 30 days.

Double that all up front and maybe I'll open it up to the public. 

[tacotime]

Are you saying that a pool can appear as two pools while working on the same block?

Pools won't show up at all, it'll look like solo mining followed by a tx spending all the coinbase to the pool sometime later. The pool could choose to give totally random addresses for a miner to send funds to, making it impossible to see which pool it went to.

[elbandi]

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.

coinbase mature is 120 blocks, pool have to wait that time, before spend the block reward. a big miner can mine more blocks during this time, so every miner sould pay a bigger guarantee (60 spr for 10 blocks, 120spr for 20 block guarantee), do you think they will do this?

[tacotime]

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.

coinbase mature is 120 blocks, pool have to wait that time, before spend the block reward. a big miner can mine more blocks during this time, so every miner sould pay a bigger guarantee (60 spr for 10 blocks, 120spr for 20 block guarantee), do you think they will do this?

Probably, yeah. Considering 100 SPR is only $6 USD and assuming that that majority of miners probably have a cheeseburger worth of funds to spare, it should be fine.

I mean, reward is like 6.66 SPR, *= 120 blocks (worst case, extremely unlikely) is ~800 SPR. But if you have enough to get 100% of the network's blocks, why would you be on a pool? More likely case is that a big miner gets maybe 20% of the network... That's a deposit of ~160 SPR to prevent a large loss.

[MyFarm]

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.

coinbase mature is 120 blocks, pool have to wait that time, before spend the block reward. a big miner can mine more blocks during this time, so every miner sould pay a bigger guarantee (60 spr for 10 blocks, 120spr for 20 block guarantee), do you think they will do this?

Probably, yeah. Considering 100 SPR is only $6 USD and assuming that that majority of miners probably have a cheeseburger worth of funds to spare, it should be fine.

I mean, reward is like 6.66 SPR, *= 120 blocks (worst case, extremely unlikely) is ~800 SPR. But if you have enough to get 100% of the network's blocks, why would you be on a pool? More likely case is that a big miner gets maybe 20% of the network... That's a deposit of ~160 SPR to prevent a large loss.

If new miners are having to buy 100+ SPR to mine SPR, I suspect that 100 SPR won't be $6.00 for long.

[njs811]

Are you saying that a pool can appear as two pools while working on the same block?

Pools won't show up at all, it'll look like solo mining followed by a tx spending all the coinbase to the pool sometime later. The pool could choose to give totally random addresses for a miner to send funds to, making it impossible to see which pool it went to.

But couldn't a program tell the time it took to mine a block and compare it to the minimum time it should take? Only then it would payout.

[luigi1111]

Are you saying that a pool can appear as two pools while working on the same block?

Pools won't show up at all, it'll look like solo mining followed by a tx spending all the coinbase to the pool sometime later. The pool could choose to give totally random addresses for a miner to send funds to, making it impossible to see which pool it went to.

But couldn't a program tell the time it took to mine a block and compare it to the minimum time it should take? Only then it would payout.

No. Variance.

[thelonecrouton]

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.

coinbase mature is 120 blocks, pool have to wait that time, before spend the block reward. a big miner can mine more blocks during this time, so every miner sould pay a bigger guarantee (60 spr for 10 blocks, 120spr for 20 block guarantee), do you think they will do this?

Probably, yeah. Considering 100 SPR is only $6 USD and assuming that that majority of miners probably have a cheeseburger worth of funds to spare, it should be fine.

I mean, reward is like 6.66 SPR, *= 120 blocks (worst case, extremely unlikely) is ~800 SPR. But if you have enough to get 100% of the network's blocks, why would you be on a pool? More likely case is that a big miner gets maybe 20% of the network... That's a deposit of ~160 SPR to prevent a large loss.

Well we could increase the maturation time to 1440 or 2880 blocks. Would also dissuade opportunistic short term profiteers.

[luigi1111]

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.

coinbase mature is 120 blocks, pool have to wait that time, before spend the block reward. a big miner can mine more blocks during this time, so every miner sould pay a bigger guarantee (60 spr for 10 blocks, 120spr for 20 block guarantee), do you think they will do this?

Probably, yeah. Considering 100 SPR is only $6 USD and assuming that that majority of miners probably have a cheeseburger worth of funds to spare, it should be fine.

I mean, reward is like 6.66 SPR, *= 120 blocks (worst case, extremely unlikely) is ~800 SPR. But if you have enough to get 100% of the network's blocks, why would you be on a pool? More likely case is that a big miner gets maybe 20% of the network... That's a deposit of ~160 SPR to prevent a large loss.

This does discourage pools though, particularly if a coin gets more valuable. One could also have the mature time be longer.

The pool could also stop accepting work when x number of blocks in the last 120 have been solved by the same miner (matching collateral), but that would suck from the miner perspective.

In the event a miner started stealing coins, it'd be kinda a funny battle between the miner and pool to get the spending TX in the 121st block before each other for all of the remaining blocks (you would assume the pool would ban the miner at the first block stolen).

Though it seems to me that the pool should be spending the TX in the first block it's allowed regardless, so the miner wouldn't have 100% chance of even stealing the first block (pool possibly has a better connection as well).

[georgem]

I can't wait for Mr. Spread to finish the next testnet version.

I miss the good times we had in round 1. 

[devlin]

Is known what will be new in the next testnet version?

[georgem]

Is known what will be new in the next testnet version?

Yes, most of it you can read here:

http://spreadcointalk.org/index.php?topic=41.0

But it hasn't been updated, and some things have changed.

Best way is if you read the whole thread of the testnet version round 1:

http://spreadcointalk.org/index.php?topic=37.0

[girino]

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.

You need 120 confirmations before spending the money, so your guy can steal 120 private keys in this meantime. Sou you should have a deposito for at least 120 * 6.66 = 799.2 SPR

[girino]

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.

coinbase mature is 120 blocks, pool have to wait that time, before spend the block reward. a big miner can mine more blocks during this time, so every miner sould pay a bigger guarantee (60 spr for 10 blocks, 120spr for 20 block guarantee), do you think they will do this?

Probably, yeah. Considering 100 SPR is only $6 USD and assuming that that majority of miners probably have a cheeseburger worth of funds to spare, it should be fine.

I mean, reward is like 6.66 SPR, *= 120 blocks (worst case, extremely unlikely) is ~800 SPR. But if you have enough to get 100% of the network's blocks, why would you be on a pool? More likely case is that a big miner gets maybe 20% of the network... That's a deposit of ~160 SPR to prevent a large loss.

you have to account for variance. There is a non-zero probability (sorry, i missed that class so i can't say exactly how much) that the miner with 20% of the hashrate gets 120 blocks in a row. If that happens and he steals, then your collateral wont cover it.