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

[tacotime]

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.

At 20% of the hashrate, I believe the likelihood of getting all 120 blocks in a row would be (1/5)^120, or not very likely.  Basically the math that makes 6 confirmations in the Bitcoin blockchain unlikely to be overwritten also makes it extremely unlikely that any single small pool miner will ever get 100% of the blocks after finding a block.

The probability that the 20% miner will get approximately 24 blocks in that time period is relatively high; but I mean, why pool if you have 20% of the network? Assuming most miners have <= 1% network hash rate, it's unlikely that any small miner could take advantage of this to the full extent.

And, okay, let's say worst case, someone does run off with a little money from the pool. The pool would then just raise fees to pay for the loss and set their deposit higher. This is more of a matter of actuarial science, but I think it's clear that the risks shouldn't be huge to running a pool.

And finally, to further reassure the pool that the money will get to them, the miner can create the tx paying the pool from their coinbase immediately after the block is mined. The tx will then get mined into a block in CoinbaseMaturity many blocks unless the miner either (a) mines a block with a competing transaction or (b) create a doublespend tx with a significantly large fee that can instead be incorporated at a further loss to themselves. (a) is very unlikely given a small hash rate, (b) is possible but causes further loss to the miner and causes him to be banned from the pool immediately upon the doublespend at height CoinbaseMaturity.

[tacotime]

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).

The pool wouldn't have access to the funds, only the miner would. Well, unless you make the miner give his private key to the pool as well, but you don't even have to.

[Youghoor]

Cryptsy will add this coin as it has lot of support.

[LiteMine]

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.

At 20% of the hashrate, I believe the likelihood of getting all 120 blocks in a row would be (1/5)^120, or not very likely.  Basically the math that makes 6 confirmations in the Bitcoin blockchain unlikely to be overwritten also makes it extremely unlikely that any single small pool miner will ever get 100% of the blocks after finding a block.

The probability that the 20% miner will get approximately 24 blocks in that time period is relatively high; but I mean, why pool if you have 20% of the network? Assuming most miners have <= 1% network hash rate, it's unlikely that any small miner could take advantage of this to the full extent.

And, okay, let's say worst case, someone does run off with a little money from the pool. The pool would then just raise fees to pay for the loss and set their deposit higher. This is more of a matter of actuarial science, but I think it's clear that the risks shouldn't be huge to running a pool.

And finally, to further reassure the pool that the money will get to them, the miner can create the tx paying the pool from their coinbase immediately after the block is mined. The tx will then get mined into a block in CoinbaseMaturity many blocks unless the miner either (a) mines a block with a competing transaction or (b) create a doublespend tx with a significantly large fee that can instead be incorporated at a further loss to themselves. (a) is very unlikely given a small hash rate, (b) is possible but causes further loss to the miner and causes him to be banned from the pool immediately upon the doublespend at height CoinbaseMaturity.

First of all, lots of respect for you tacotime!

So roughly the method would be to have everyone send in their (solo) mined coins and then divide them up based on hashrate? And it sounds you would have a list of pubkeys to verify how much everyone mined.

But how would you know how much hash any given miner is supplying? Maybe some kind of custom software to monitor a miner's rigs? I'm somewhat ignorant on the specifics of pool mining and am just trying to wrap my head around this.

[tacotime]

First of all, lots of respect for you tacotime!

So roughly the method would be to have everyone send in their (solo) mined coins and then divide them up based on hashrate? And it sounds you would have a list of pubkeys to verify how much everyone mined.

But how would you know how much hash any given miner is supplying? Maybe some kind of custom software to monitor a miner's rigs? I'm somewhat ignorant on the specifics of pool mining and am just trying to wrap my head around this.

Yes, and yes.

Have them submit their partial solutions, which are blocks that are below target and register that as a share. As mentioned before, you should be able to compress padded blocks that use the recursive padding described in the paper, then after they're piped to the pool decompress them. If you're using some kind of naive solution that doesn't compress blocks, you would use adaptive difficulty and set target share rate to something like one share every 5 minutes so your pool and miner bandwidth isn't crazy.

One neat thing about this is that it does let whichever miner who wins the block pick the transactions in the block, instead of the pool itself. However, miners may wish to keep bandwidth usage low, which would encourage as small of blocks as possible (in the event that someone is able to get padding compression working).

[tacotime]

For anyone wishing to do the share compression, look here in the source code:

https://github.com/spreadcoin-project/spreadcoin/blob/b05777db815d633a76aba5ef55ecb85390a4df7e/src/main.cpp#L1528-L1533

Code:

    // Start with nonce, time and miner signature as these are values changed during mining.
    BlockData << (nNonce & ~NONCE_MASK); // ignore lowest 6 bits in nonce to allow enumeration of 64 hashes without recomputing whole block hash
    BlockData << nTime;
    BlockData << MinerSignature;
    BlockData << nVersion;
    BlockData << hashPrevBlock;
    BlockData << hashMerkleRoot;
    BlockData << nBits;
    BlockData << nHeight;
    // Skip hashWholeBlock because it is what we are computing right now.
    BlockData << vtx;

    while (BlockData.size() % 4 != 0)
        BlockData << uint8_t(7);

    // Fill rest of the buffer to ensure that there is no incentive to mine small blocks without transactions.
    uint32_t *pFillBegin = (uint32_t*)&BlockData[BlockData.size()];
    uint32_t *pFillEnd = (uint32_t*)&BlockData[MAX_BLOCK_SIZE];
    uint32_t *pFillFooter = std::max(pFillBegin, pFillEnd - 8);

    memcpy(pFillFooter, &hashPrevBlock, (pFillEnd - pFillFooter)*4);
    for (uint32_t *pI = pFillFooter; pI < pFillEnd; pI++)
        *pI |= 1;

    for (uint32_t *pI = pFillFooter - 1; pI >= pFillBegin; pI--)
        pI[0] = pI[3]*pI[7];

    BlockData.forsed_resize(MAX_BLOCK_SIZE);

Nothing too crazy going on here from what I can tell, you start with the block header data/tx list and fill the block with crap going forward with *pI |= 1; (bitwise or operation), then iterate backwards through it multiplying with pI[0] = pI[3]*pI[7];.  You should be able to regenerate this all by simply starting from the initial header state and list of transactions.

[tminer]

It would be very interesting to see Mr.Spread's reply to these discussion going here. Can any one notify him to make a comment on this.

[MemoryShock]

As an aside, his post ban is up in five days...

[Hatch]

Please forgive for being the last to catch on...

But if we all appreciate the fact that the "no pools" aspect has served this coin well so far with decentralized mining and expulsion rate, can someone please tell me why we would bother trying to figure out how to pool mine it? 

[MemoryShock]

Please forgive for being the last to catch on...

But if we all appreciate the fact that the "no pools" aspect has served this coin well so far with decentralized mining and expulsion rate, can someone please tell me why we would bother trying to figure out how to pool mine it? 

Theory.  Interesting thought experiment.  Prove fud wrong/right (which neutralizes the inane posts).

It's a great discussion and I have nothing to add to it in that context but I appreciate reading it.

It is a 'side note point' though...easy to set up MN's is a huge selling point and one that doesn't get enough play...though once testing is done we should here more about it...; )

[devlin]

Please forgive for being the last to catch on...

But if we all appreciate the fact that the "no pools" aspect has served this coin well so far with decentralized mining and expulsion rate, can someone please tell me why we would bother trying to figure out how to pool mine it? 

Good point. Until now SPR is "no pool", if someone will make a public pool then perhaps SPR will find a way to avoid this.

[duboisi]

Please forgive for being the last to catch on...

But if we all appreciate the fact that the "no pools" aspect has served this coin well so far with decentralized mining and expulsion rate, can someone please tell me why we would bother trying to figure out how to pool mine it? 

Good point. Until now SPR is "no pool", if someone will make a public pool then perhaps SPR will find a way to avoid this.

Precisely, there is no sign that SPR's decentralization is under threat yet. The world is moving forward everyday and there are so many more new things that can be implemented. It is best to leave "pool" issue as side note for the moment. Let Mr. Spread concentrate on implementing his version of MN and Instant Tx. Can't wait to participate in the next test.

[girino]

Please forgive for being the last to catch on...

But if we all appreciate the fact that the "no pools" aspect has served this coin well so far with decentralized mining and expulsion rate, can someone please tell me why we would bother trying to figure out how to pool mine it? 

Good point. Until now SPR is "no pool", if someone will make a public pool then perhaps SPR will find a way to avoid this.

Precisely, there is no sign that SPR's decentralization is under threat yet. The world is moving forward everyday and there are so many more new things that can be implemented. It is best to leave "pool" issue as side note for the moment. Let Mr. Spread concentrate on implementing his version of MN and Instant Tx. Can't wait to participate in the next test.

Well, i still think that no pools is much more important than masternodes, and that we need to think in advance in order to protect this feature, so trying to break it will tell us its weaknesses and allow us to improve on it and make it less likely to be broken. Constantly discussing it and thinking of ways someone might use to circumvent it and fixing it in advance (or at least having the solution figured out before the circumvention really happens, so it can be implemented and deployed quickly) is the best way to keep it secure.

[georgem]

Started the first  round of the tweet @Cryptsy to add spreadcoin to their exchange on twitter with my followers. I Will be personally messaging my followers to tweet them all week until there mentions are filled with nothing but Spreadcoin. haha Working to get us added to One exchange at a time. If you have a twitter account. Tweet @Cryptsy to add #Spreadcoin join the fun. Also follow me twitter.com/mrcashking

Nice job!

I sent you a tip.

[pokeytex]

Please forgive for being the last to catch on...

But if we all appreciate the fact that the "no pools" aspect has served this coin well so far with decentralized mining and expulsion rate, can someone please tell me why we would bother trying to figure out how to pool mine it? 

Good point. Until now SPR is "no pool", if someone will make a public pool then perhaps SPR will find a way to avoid this.

Precisely, there is no sign that SPR's decentralization is under threat yet. The world is moving forward everyday and there are so many more new things that can be implemented. It is best to leave "pool" issue as side note for the moment. Let Mr. Spread concentrate on implementing his version of MN and Instant Tx. Can't wait to participate in the next test.

Well, i still think that no pools is much more important than masternodes, and that we need to think in advance in order to protect this feature, so trying to break it will tell us its weaknesses and allow us to improve on it and make it less likely to be broken. Constantly discussing it and thinking of ways someone might use to circumvent it and fixing it in advance (or at least having the solution figured out before the circumvention really happens, so it can be implemented and deployed quickly) is the best way to keep it secure.

Exactly - you have to learn how to make it, break it, and put it all back together - then move forward. 

[Spreadcoin_]

Exactly - you have to learn how to make it, break it, and put it all back together - then move forward. 

Yes, true science is all based around trying to falsify and break your own theory and hypothesis. If it withstands this, it must be working.

I welcome this.

[LeongTap]

I really apologize for my actions yesterday or was it the day before ? (it was embarrassingly stupid when i think and look back at it, my lame excuse for it was that i was having a really really REALLY bad day).

Anyhow i'm just posting here to say that i haven't forgotten about my contribution (of 500 SPR) to the bounty if public pools appear. And i will continue to support spread to the end. Like i said, we are in this for the long term.

Its nice too see the discussion returning to a more informative and formal one, and not like MMORPG Flame wars (that i have retired from since long ago).

[Spreadcoin_]

I really apologize for my actions yesterday or was it the day before ? (it was embarrassingly stupid when i think and look back at it, my lame excuse for it was that i was having a really really REALLY bad day).

Anyhow i'm just posting here to say that i haven't forgotten about my contribution (of 500 SPR) to the bounty if public pools appear. And i will continue to support spread to the end. Like i said, we are in this for the long term.

Its nice too see the discussion returning to a more informative and formal one, and not like MMORPG Flame wars (that i have retired from since long ago).

You have done nothing you need to apologize for.
Contrary to all the trolls who created all the chaos and damage.

How come the innocent always want to apologize, but the guilty ones don't give a shit? 

[duboisi]

There is a bounty of 3500SPR to break the no pool. Whoever has solid idea of how it can be done should try it out. Is a cycle that things are being built, being broken and then being built again. The MN codes that Mr. Spread is building is from scratch and not clone. Let him focus on that and someone else can try to break the no pool.

[Hatch]

Please forgive for being the last to catch on...

But if we all appreciate the fact that the "no pools" aspect has served this coin well so far with decentralized mining and expulsion rate, can someone please tell me why we would bother trying to figure out how to pool mine it?  

Good point. Until now SPR is "no pool", if someone will make a public pool then perhaps SPR will find a way to avoid this.

Precisely, there is no sign that SPR's decentralization is under threat yet. The world is moving forward everyday and there are so many more new things that can be implemented. It is best to leave "pool" issue as side note for the moment. Let Mr. Spread concentrate on implementing his version of MN and Instant Tx. Can't wait to participate in the next test.

Well, i still think that no pools is much more important than masternodes, and that we need to think in advance in order to protect this feature, so trying to break it will tell us its weaknesses and allow us to improve on it and make it less likely to be broken. Constantly discussing it and thinking of ways someone might use to circumvent it and fixing it in advance (or at least having the solution figured out before the circumvention really happens, so it can be implemented and deployed quickly) is the best way to keep it secure.

Exactly - you have to learn how to make it, break it, and put it all back together - then move forward.  

Thanks. Was kinda thinking along those lines. Just dont want to get too distracted from other things like the MN's, IX, and other things that can help utility and adoption. S'all good!