Δεν υπαρχει επιτακτικο προβλημα. Τα transactions που γινονται αυτη τη στιγμη, ενα μεγαλο ποσοστο ειναι spam και dust. Το απογευμα εκανα για πλακα ενα dust tx με fee 200 satoshi και περασε και εγινε confirm σε 1 μπλοκ μεσα (!). Πραγματικα ντρεπομαι που εγινε και περασε με τοσο λιγο κοστος και σπαμαρω τσαμπα το blockchain. Και confirm σε 1 μπλοκ (!!!).

Τωρα νομιζω το avg block size ειναι κοντα στα 400kbyte, αμα βγαλεις και τα dust, ειναι ουτε 300. Εχει πολυ ψωμι ακομα για να λεμε οτι θα πεθανει το bitcoin επειδη βγαινουν κατι εταιριες και κανουν δηθεν στρες τεστς για να φαινεται πλασματικο προβλημα στο scaling - τη δεδομενη παντα στιγμη.

Και 8mb να παει το μπλοκ, αν μια εταιρια θελει να κανει στρες τεστ και να δωσει τα καταλληλα BTC, παλι θα το γεμισει και θα πει "να, βλεπετε? Δε τσουλαει το 8μβ... καντε το 50mb". Οτι θελουν λενε.

Το core team response για να υπολογιζει καταλληλα το fee και το confirmation αναλογα το φορτο, ηταν μια χαρα.

Τωρα για το μελλον το προτιμοτερο ειναι, κατ'εμε, να βρεθει μια λυση που να μειωνει το μεγεθος των transactions. Αυτο ειναι πιο σημαντικο απ'το να κανουμε tradeoffs με το block size - το οποιο πρεπει να αυξηθει αλλα αργοτερα.

Εντωμεταξυ εκανα ενα πειραμα στο δισκο

134137503 Aug 20 20:43 blk00321.dat (αρχειο του database που κραταει το bitcoin-qt)
107511735 Aug 21 20:18 blk00321.dat.zip (το εκανα .zip με default) - 80.1% του αρχικου αρχειου
109521539 Aug 21 20:21 blk00321.dat1.gz (το εκανα gzip με -1 / δλδ fastest compression) - 81.64% του αρχικου αρχειου
107383880 Aug 21 20:21 blk00321.dat9.gz (το εκανα gzip με -9 / δλδ best compression) - 80% του αρχικου αρχειου

Οποτε με ταχυτερες cpu (γιατι το on the fly compression / decompression ειναι cpu-related), ενα 20% του τωρινου μεγεθους μπορει να εξαλειφθει με ενα απλο zipαρισμα.

Δεν ειμαι πεπεισμενος οτι εχει γινει οτι πρεπει να γινει, σε επιπεδο κωδικα του btc, για να κανει scale οσο πρεπει και να μην αφηνει το footprint που αφηνει αυτη τη στιγμη. Θεωρητικα πρεπει να παιρνει βελτιωσεις.