Quote from: Forp on October 05, 2011, 06:07:48 PM

Quote from: Meni Rosenfeld on October 05, 2011, 01:39:07 PM

Quote from: Forp on October 05, 2011, 11:53:46 AM

Quote from: Meni Rosenfeld on October 05, 2011, 11:10:11 AM

let's say that in this system a person with a computer finds one block per month. Then four people with a computer each should find a total of 4 blocks per month, right?.

Why?

If it wasn't clear, in this example the intention was that the 4 people aren't all there is, there are 4000 more similar people each finding 1 block per month, for a total of 4000 blocks per month. So again, if 4 people find 1 block per month each, then between them they find 4 blocks per month.

Why?
It is characteristic of non-parallelizable PoWs that they do not scale in the way you describe. I believe we have a misunderstanding here.

This isn't about parallelizable vs. non-parallelizable computations. Performance in serial computations doesn't scale linearly with more computing cores, but this is irrelevant. This is about the process of block finding, which is why I asked if your system diverges fundamentally in the notion that blocks are something found once in a while by people on the network. If not then it's really "if Billy and Sally each have an apple, then that's two apples" math - if in a given scenario (not in distinct scenarios) two people find 1 block each, then both of them together finds 2 blocks. If a network of 4000 people find 4000 blocks per month, each finds on average 1 block per month. This isn't enough data to know the distribution (it's possible one person finds all 4000) but the best scenario is when each finds close to 1.

It also means that if in a given situation 4000 people find 4000 blocks, each finding about 1, then if I join in it would only be fair if I also find about 1 (or, more precisely, that each will now find 4000/4001).

Quote from: Forp on October 05, 2011, 06:07:48 PM

Quote from: Meni Rosenfeld on October 05, 2011, 11:10:11 AM

Because the pool shouldn't be the one deciding what goes in a block. As was explained, a pool is essentially just an agreement to share rewards.

Ok. Forget the pool as part of the argument here but think of parallel computing. The pool is a parallel computer.

The line of reasoning is about parallel computation and scalability of the PoWs.

With parallelizable PoWs, Bill Gates can buy as much computing power as he wants. He then changes a transaction in block 5 to his favour. Thanx to his computing power he easily can redo the entire block chain history since then. If the PoWs are, as I suggest, non-parallelizable, he simply cannot do better buy buying more computers. The only thing he can do is increase the clocking. By this, he can speed up his computation mabe by a factor of 5 or 10 - as opposed to buying more computers, where only money is his limit. So, non-parallelizable PoWs are an effective solution against this kind of attack.

(Yes, I know that the hashes of some 6 or so intermediate blocks are hardcoded in the bitcoin program and hence the attack will not work out exactly the way I described it - but this does not damage the line of reasoning in principle.)

Yes, with parallelizable PoW you can overwhelm the network given enough time and money. My contention is that non-parallelizable makes the problem worse, not better. With fully serial only the fastest one will do anything, so noone else will be incentivized to contribute his resources. So this one person can do the attack, and even if he's honest, it's only his resources that stand against a potential attacker (rather than the resources of many interested parties).

And there's no indication that some hybrid middle ground gives better results - to me it seems like more like a linear utility function where fully parallel is best and it gets worse the closer you make it to fully serial.

Also, I hold the position that security can be significantly improved using some form of proof-of-stake (basically a more methodical version of the hardcoded hashes).

Quote from: Forp on October 05, 2011, 06:07:48 PM

Quote from: Meni Rosenfeld on October 05, 2011, 01:39:07 PM

Variance in block finding times is unwanted, but I think most will agree it pales in comparison to the other issues involved. Especially since there are basically two relevant timescales - "instant" (0 confirmations) and "not instant". The time for 10 confirmations follows Erlang(10) distribution which has less variance.

I do not think that the "variance in block finding times" is the essential advantage, it is rather convergence speed to "longest chain" (I have no hard results on this but am currently simulating this a bit) and better resistence against attacks which involve ~~pools~~ parallel computers.

See above. I think you're going the wrong way.

Quote from: Forp on October 05, 2011, 06:07:48 PM

Quote from: Forp on October 05, 2011, 11:53:46 AM

By all means you should pursue whatever research question interests you, but I expect you'll be disappointed both in finding a solution satisfying your requirements, and in its potential usefulness.

Trying to understand the argument. Do you think there is no PoW matching all the requirements? Care to give a hint why?

I'm still not completely sure what the requirements are, this whole discussion has been confusing to me. But yes, to me it seems that from a "back to basics" viewpoint a serial computation only makes it easier for one entity to dominate the blockchain, making the "better security" requirement impossible. Again, if multiple computers don't give more power over the network, it means the attacker doesn't have to compete against multiple computers, only against one.

Quote from: Forp on October 05, 2011, 06:07:48 PM

As to a potential usefulness: The concept is by now means "finished" but until now the discussion on the board proved very fruitful and helps to improve the system I am working on. This is for a different kind of block-chain application, so I am not expecting an impact for Bitcoin. Bitcoin is widely disseminated so I do not expect significant protocol changes to occur any time soon, especially by suggestions from outside the core team.

You mean an alternative Bitcoin-like currency, or something that doesn't look anything like it? If the former I doubt this will be applicable, if the latter I can only speculate unless you give more details about the application.

The Bitcoin code progresses slowly, probably mostly because of the sophistication of the code, but I trust that all sufficiently good ideas will make it in eventually.