Mal sehen ob das künftig ein Problem wird. Wäre fraglich wie man das lösen könnte.
Es gibt da schon Ideen. Z.B. durch bloom filter[1], grob gesagt ist die Idee das die meisten Nodes die TX in den Blöcken eh schon kennen. Da reicht es dann zu verbreiten welche TX im Block sind und der vollständige Block muss nur noch in Ausnahmefällen übertragen werden, z.B. wenn ein Node hinterher hängt oder gerade erst online gekommen ist. Dadurch lassen sich Blöcke in fester Zeit (O(1)), also unabhängig von der Blockgröße, übertragen.
Und wir reden über 20MB Blöcke. Na ich frage mich ob das nicht ein Hindernis für die Verbreitung von Bitcoins werden könnte.
*pingel* 20MB beruhen auf einem Rechenfehler, konkret geht es um 4 bzw. 8 MB.
Echt? Gilt das beim aktuellen 1MB auch?
Ne, das 1MB limit ist schon so im code. Softlimit ist zur Zeit 750KByte um das zu ändern muss man halt mal in die config Datei. Blöcke über 1 MB werden nicht akzeptiert. Gavin hat nur bei seinen Berechnungen einen Fehler gemacht und kam daher fälschlicher weise auf 20MB, es müssten aber eher 4 oder 8MB sein.
[1] https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2
*lach* Das ist aber peinlich wenn der Chefcoder einen solchen Fehler macht und gleichzeit laut "Feuer" ruft.
bloom_filter klingt interessant. Gut dass da schon eine Lösung in Planung ist. Auch wenn ich mir das irgendwie schwer machbar vorstelle da der Server doch wissen muss welche Transaktionen letztendlich im Block gelandet sind bevor er prüfen kann ob ein Block, der ihm geschickt wurde, auch valide ist.
Aber so genau habe ich mich jetzt nicht mit der Technik beschäftigt. Kann sein dass ich das falsch sehe.