Show Posts
Gut bei mir ist genau anders rum 
"Kleine Gruppe" ist doch nicht ernst zunehmend. Hier wird das Bild gemalt von einem "Superrechenzentrum" pro Land und die sind dann miteinander verbunden, was vollkommen an der Realität vorbei geht. Ich rede nicht von "einer kleinen Gruppe" auf der Welt sondern z.B. von Hackerclub X in der Stadt usw.
Nochmal: Nur weil man mehr als 7 tx/s verarbeitet wird man kein NSA-Rechenzentrum als Knoten benötigen. Es wird nur nicht mehr mit dem 486er im Keller und der 2Mbit Leitung funktionieren.
"Kleine Gruppe" ist doch nicht ernst zunehmend. Hier wird das Bild gemalt von einem "Superrechenzentrum" pro Land und die sind dann miteinander verbunden, was vollkommen an der Realität vorbei geht. Ich rede nicht von "einer kleinen Gruppe" auf der Welt sondern z.B. von Hackerclub X in der Stadt usw.
Nochmal: Nur weil man mehr als 7 tx/s verarbeitet wird man kein NSA-Rechenzentrum als Knoten benötigen. Es wird nur nicht mehr mit dem 486er im Keller und der 2Mbit Leitung funktionieren.
Ich gehe davon aus, keiner könnte heute Effektiv angenommene 2k TX/s verarbeiten. Weder die heutigen Knoten, noch die Miner, noch die ganze Light-Clients, noch deren Netzwerkanbindungen. Nur weil ein Einzelaspekt heute schon funktionieren könnte heisst das noch lange nicht, dass das ganze System damit funktionieren würde. Aber warten wir's ab - die meisten Entwickler sind hier ja (zurecht) sehr zurückhaltend. Als erstes wird wohl irgendwann mal Pruning auf der Liste stehen. Und selbst dort wird es effektiv wesentlich komplizierter als "nur mal kurz" die Blockliste aufzuräumen. Da müssen UTXO und Checkpoints durchs Netz bewegt werden, ohne Trusted Nodes vorauszusetzen und einiges mehr. Also braucht es mindestens noch ein paar Protokolländerungen (aber keine Regeländerungen).
Ja, 2000 oder mehr TX pro Sekunde sind wirklich nicht schwer zu realisieren. Selbst für den normalen Rechner der zu Hause läuft:
Quote
CPU
The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.
The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some ECDSA signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.
Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core Intel Core i7-2670QM 2.2Ghz processor. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.
As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2012 the network is handling 0.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.
Network
Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.
That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.
This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.
When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.
The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.
The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some ECDSA signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.
Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core Intel Core i7-2670QM 2.2Ghz processor. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.
As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2012 the network is handling 0.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.
Network
Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.
That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.
This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.
When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.
Was wirklich problematisch ist, ist die ewig wachsende Blockchain. Um das zu lösen ist unbedingt sauberes Pruning notwendig. Deshalb ist es gut, dass der Fokus erst einmal darauf gelegt wird.
Ohne das könnte eine Erhöhung das TX Limits sehr schnell ein Schuss sein, der nach hinten los geht.
