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

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? 

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

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.

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

Nice job!

I sent you a tip.

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.

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.

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.

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

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? 

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

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.

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

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.

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

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.

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

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.

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.

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.

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