Quote from: Realpra on February 27, 2013, 05:55:28 PM

Quote from: MoonShadow on February 27, 2013, 07:54:15 AM

Quote from: Realpra on February 27, 2013, 06:34:08 AM

Did any of you guys remember my "swarm client" idea? It would move Bitcoin from being O(n*m) to O(n) and the network would share the load of storage and processing both.

Searching the forum for "swarm client" begets nothing. Link?

https://bitcointalk.org/index.php?topic=87763.0
(Second search link Tongue

)

Quote

I read your proposal, and could find no details about how a swarm client could actually divide up the task of verification of blocks. That or I simply didn't understand it.

The details are a little hairy, but it is actually very simple: It is difficult to validate, BUT easy to show a flaw in a block.

To show a block is invalid just one S-client needs to share with the rest of the network that it has a double spend. This accusation can be proved by sending along the transaction history for the address in question.
This history cannot be faked due to the nature of the blocks tree-data-structure.

Not true. A double spend would occur at nearly the same time. Due to propogation rules that apply to loose transactions, it's very unlikely that any single node (swarm or otherwise) will actually see both transactions. And what if it did? If it could sound an alarm about it, which one is the valid one? The nodes cannot tell. And even responding to an alarm impies some degree of trust in the sender, which open up an attack vecotr if an attacker can spoof nodes and flood the network with false alarms.

Furthermore, a double spend can't eget into a block even if that miner doesn't bother to validatie it first, since that would imply that the miner is participating in an attack on the network himself, since he shouldn't be able to see both competing transactions.

Quote

Even if the S-clients keep a full history of each address they watch and exchange this in cases of accusations the computer power saved should still be substantial despite many addresses being tangled together.

This would serve little purpose, since addresses are created and abandoned at such a rapid rate.

Quote

There was also talk of combining this with a 5-10 year ledger system which would put a cap on the running blockchain size.

Pruning would also put a cap on the running blockchain size, and doesn't require a hard code fork. It's also the purpose of the myrkle tree from the beginning. Satoshi thought about that, too.