Pages:
Author

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

newbie
Activity: 14
Merit: 0
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?  Roll Eyes
newbie
Activity: 30
Merit: 0
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).

newbie
Activity: 14
Merit: 0
Exactly - you have to learn how to make it, break it, and put it all back together - then move forward.  Grin

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.
legendary
Activity: 1504
Merit: 1002
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?  Huh
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.  Grin
legendary
Activity: 1484
Merit: 1007
spreadcoin.info
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.
legendary
Activity: 2296
Merit: 1170
Advertise Here - PM for more info!
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?  Huh
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.
full member
Activity: 202
Merit: 100
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?  Huh
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.
sr. member
Activity: 272
Merit: 250
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?  Huh

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.

hero member
Activity: 728
Merit: 500
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?  Huh

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...; )
full member
Activity: 198
Merit: 100
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?  Huh
hero member
Activity: 728
Merit: 500
As an aside, his post ban is up in five days...

full member
Activity: 182
Merit: 100
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.
legendary
Activity: 1484
Merit: 1005
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.
legendary
Activity: 1484
Merit: 1005
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).
sr. member
Activity: 380
Merit: 250
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.
sr. member
Activity: 1036
Merit: 275
Cryptsy will add this coin as it has lot of support.
legendary
Activity: 1484
Merit: 1005
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.
legendary
Activity: 1484
Merit: 1005
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.
legendary
Activity: 2296
Merit: 1170
Advertise Here - PM for more info!
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.
legendary
Activity: 2296
Merit: 1170
Advertise Here - PM for more info!
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
Pages:
Jump to: