[
UPDATED 10-04-2013]
In response to this thread:
https://bitcointalk.org/index.php?topic=87444.0 (satoshidice spam)
Problem:The bitcoin network basically has what is called O(n) algorithmic performance.
In short this means that if the network grows 100 times, you need pretty much 100 times more powerful nodes and 100 times more bandwidth for EACH node.
While this is possible from a technical perspective it would quickly make the entire BTC network dependent on a few exposed super nodes.
Such nodes would very likely extort huge fees and/or be shut down by the US government.
Pruning or ledger blocks solves the HDD issues, but does nothing to spread out CPU, RAM or bandwidth loads.Solution:Future clients should be swarm clients that do the roles of full nodes, but only on parts of the chain.
The simplest explanation I have is this:
Imagine "cutting the blockchain in two halves". Now you run two clients on two computers that look at each their half of the chain or rather each their half of the addresses in the blockchain.
Now if one client sees a block spending an output already spent it reports it to the other client and they both reject the block. To prove such claims the reporter includes the TX and its minified merkle-branch up to the block header it occurred in - so the reporter cannot fake a report.
To the outsider such two clients would act and behave in every way as a full node - imagine chopping up the blockchain further and you have a system of swarm nodes!I have already pledged 15 BTC to the implementer of this - mark me a scammer if I don't pay up please. Some escrow solution is also possible.
I will also accept less elegant solutions that split up the blockchain just 5 times or more.
Feel free to pledge along with me, it will be worth some of your BTC to secure the value of the rest I think
Nature of my solution+ No fork.
+ No new blockchain standards.
- New communication protocol.
+ Bridge can be made between old and new clients.
Detailed solution: Abbreviations:F-node: Full node.
Could choose to mine independently of a pool, does verification on the whole blockchain and so on.
S-node: Swarm node.
In a swarm acts the same as a network of full nodes, but only does verification on parts of the chain.
L-node: Light node.
Is dependent on super nodes.
B-Node: Bridge node.
Bridges two ways of sharing blocks by "translating" the format of one to the other and broadcasting it.
Only one such node is theoretically needed to prevent forking.
Branches/trees:
See Merkle trees in wikipedia - the existing way Bitcoin stores txs.
The important thing here is that S-nodes send block fragments in the form of merkle trees tied to the block header whereas todays clients send whole blocks.
Subscriber:
A client which has a standing request for updates concerning specific addresses.
W-addrs: Watched addresses.
The Bitcoin addresses a swarm client is watching and storing the full history for. To keep itself updated it will subscribe to information about these addresses with other S-nodes.
S-nodes will relay information and TXs to each other even if
S-node group:
Say half the S-nodes watch addrs ending with an equal hex number and the other half unequal - each half would then be a "group". Members of the same group watch the same addresses, can then more easily share data and will have to connect to fewer relay nodes.
NEW IMPORTANT - Addresses:
The blockchain does in fact not store BTC in addresses, this is an abstraction, but rather allows movement of BTC if a script evaluates to true. With normal Bitcoin addresses this script looks something like this:
1<insert signature> 2<Check it fits with public key:> 3<BTC-address>
However the script could also require multiple signatures or go by IP.
Hence S-nodes will not actually organize by addresses, but by the
scripts - a redeem script will always look the same for the same address and/or the same conditions, hence it can be used as an identifier.
In most normal cases this will mean S-nodes basically use addresses as expected, but a multisig or IP script will just be handled as another address would: it has a balance or it doesn't.
If we imagine the hash or just first 50 bits of a script are between 0-1 then one S-node group could be 0-0.5 and another 0.5-1 and it would not matter at all what kinds of scripts were thought up or used.
<TX ID - Script/Condition hash - Spending TX ID/UnspentCode> would be all an S-node saw.
Miners forming a new block entirely with S-node system:1. Miners in a pool will split themselves up into groups by the addresses their S-clients watch.
2. Each group will handle TXs that send funds from their W-addrs. (If there are multiple input addrs in the TX the first input will determine which S-node group puts the TX in the block, but each relevant group validates their W-addrs inputs.)
2A. Bad TXs inserted by dishonest miners will be rejected/reported by the other miners of the same S-node group.
3. From this they construct branches of the block and transmit these.
4. A pool master collects branch headers and makes a header hash which can be mined - no super node required to validate the whole thing.
5. Header hash is broadcasted and solved by the miner clients.
6. Bridge node gathers all the block strands into one traditional block.
7. Bridge node broadcasts the block to the older clients (or vice versa).
Clients with S-node system1. Single small block branch is received from same S-node group.
2. Client checks all transactions it can and block header is valid.
3. The miners who solved the block send the sections to the various S-node groups on a on-demand basis branch by branch.
Security:Bad TX:
If in step 2 a transaction is invalid due to either a hash error OR insufficient balance this is reported to the network.
1. Report is trustworthy because everyone can check that chain part themselves or that hash operation themselves.
2. The IP that sends the invalid branch/block is automatically added to a client IP-filter.
3. If an balance error report is received that turns out to be
false, then
that IP is blocked automatically.
If your connection is hijacked:
You don't need a web of trust or anything like that, just PKC; each client randomly selects a PK and publishes it.
Each client would then have its own list of Pub.Ks or "client addresses". For instance I might add MtGox, my brother and some others.
This doesn't mean I trust these guys it just means I find it near impossible that they would ALL know what the attacker wanted left out AND either have been hacked or colluding with him.
If I cannot connect to them because the attacker cannot fake them without their Pri.Ks I will know my connection has been hijacked.
NotesAll of this means that no S-client has to process, receive nor store the full blockchain. Or: O(log(n)) -> network grows 100 times you only need say 2 as powerful nodes.
Full trust-less security is maintained.
Even in the case of reports you can either trust the multitude of clients watching a certain address balance or reconstruct the entire chain from branches around the network.
Implementation:It is my understanding that today the client has certain "get block" methods.
While the block standards would remain the same the S clients would basically ignore such calls and replace them with at least:
1. Reporting.
2. Get branch.
3. Subscribe to address/group updates.
By having S-node groups sharing information with themselves we can continue operating with just a couple of peers (many peers overload routers and stuff).
Using a bridge no one would even need know you had S-nodes behind it.
Am I missing anything?EDIT: Changed title to be more informing.
EDIT, Update 10-04-13: Clarified some things and improved solution with my now clearer understanding of the Bitcoin protocol.
Show Posts
