Pages:
Author

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

legendary
Activity: 1484
Merit: 1007
spreadcoin.info

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

sr. member
Activity: 272
Merit: 250

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

legendary
Activity: 1484
Merit: 1007
spreadcoin.info
I can't wait for Mr. Spread to finish the next testnet version.

I miss the good times we had in round 1.  Smiley
legendary
Activity: 1105
Merit: 1000
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).
legendary
Activity: 966
Merit: 1000
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. Grin
legendary
Activity: 1105
Merit: 1000
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.
sr. member
Activity: 406
Merit: 250
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.
hero member
Activity: 854
Merit: 1000
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.
legendary
Activity: 1484
Merit: 1005
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.
hero member
Activity: 525
Merit: 529
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?
legendary
Activity: 1484
Merit: 1005
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.
full member
Activity: 149
Merit: 100
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.  Wink
legendary
Activity: 1526
Merit: 1001
Crypto since 2014
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.
sr. member
Activity: 406
Merit: 250

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?
legendary
Activity: 1105
Merit: 1000
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?
legendary
Activity: 1105
Merit: 1000

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.
legendary
Activity: 1484
Merit: 1005
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.
sr. member
Activity: 406
Merit: 250

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!
legendary
Activity: 1105
Merit: 1000
The collateral pool idea is not new:

Hey guys, would it be possible to create a pool like this;


Each miner mines to a separate address. The pool (and the miner obviously) knows the private key.
The pool has insurance of lets say, 15 spr in a separate address for each miner. The insurance needs to be paid by the miner before he starts mining.

The miner submits shares and once he finds a block he publishes it to the network.

If the miner steals coins from his address then he gets banned from the pool and the pools uses his insurance to pay the other miners.


Could this work? Or is it not possible because it isn't how mining works for spreadcoin?
The problem here is that if you will find a block and will not try to steal its reward pool can still claim that you are trying to steal it and use both your funds and block reward. For external observer it is not possible to distinguish between situations when you are trying to steal money and when pool operators are just lying about this. Even if pool is operated by some legally registered entity with non anonymous owners they can steal your money and you wouldn't be able to prove anything.

If you cannot find blocks consistently but are still mining that means that even one block's reward worth something for you.

I don't see this problem as very different from the "pool got hacked, all coins are gone; sorry guys" problem. That is, I don't think it'll stop pools from being set up and having people mining at them.

I think established pools reputation is meaningful enough that doing what's described above would result in the death of the pool. A few reports of the pool taking miners deposits and they'd be mining somewhere else.

Edit: and this:

I don't think his argument is valid, because
(1) The pool and other users know the pubkeyhashes that are mining.
(2) If the miner pubkeyhash finds a block and then refuses to give the funds back to the pool within say, 60 blocks, it's totally clear to everyone mining on the pool that this has happened aside from just the pool itself.
(3) Miners can mine to another pubkeyhash, but that's the exact same as solo mining.
legendary
Activity: 1526
Merit: 1001
Crypto since 2014

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?
Pages:
Jump to: