en el post dice haber estado probando ditintas cadenas de bloques con un tamaño de 20MB cada uno (e incluso 200MB!), lo cual nos permitiría incluír muchísimas más transacciones por bloque y quizás pueda ayudar para volver a aumentar el valor de OP_RETURN el cual había sido reducido de 80 bytes a 40 anteriormente.
El post no dice nada de OP_RETURN. Lo digo por aclarar, ya que tu redacción puede dar lugar a que alguno piense que así es, pero no.
Sí, es cierto, lo edito para que no haya malos entendidos.
Este cambio necesitaría un Hard Fork, el cambio en el código nos obligaría a todos a actualizar nuestro actual sofware (cartera) por una versión nueva configurada para funcionar con estos nuevos bloques más grandes. Según comenta en el post este cambio sería MUY facil, tan solo cambiar tres lineas de código. Pero surgen dos problemas:
Las transacciones con "locktime" [
] y las "coinbase" [
]
Estos problemas se los encontró él durante sus pruebas. No van a darse en el momento de actualizar.
También edito y corrijo tiempos verbales para solventar el fallo

Creo que los que ahora tenemos nodos funcionando con Raspberrys como tengamos que indexar esta nueva cadena podremos echar semanas hasta que acabe.
Esa nueva cadena la creó él durante sus pruebas. De hecho en la primera línea del post dice "he estado ocupado llenando mi disco duro con copias de la cadena de bloques". Nosotros seguiremos usando la misma de siempre!
Corregida también esa mala interpretación, gracias dserrano.
Pido perdón por los desaciertos en la redacción. Creo que quedó arreglado.
Me explico, digamos que un nuevo cliente que se saque, soporte ya dicho protocolo, pero que aún continue soportando el antiguo/actual un par de versiones mas/meses, para dar tiempo a que se actualize el máximo número de usuarios y nodos y que a una fecha, ya no se sincronize y te oblige a actualizarlo sacando un mensaje.
Sin saber tampoco a qué te refieres (¿"protocolo"?), quiero decir que el fork será un proceso de varias semanas o meses, durante l@s cuales la gente se actualiza a una versión nueva que soporte los bloques más grandes y solo cuando determinado porcentaje de la red se haya actualizado, estos bloques podrían realmente empezar a aparecer. Ya hemos pasado por una transición así y no hubo ningún problema.
Edito para añadir: el fork real solo sucederá cuando aparezca el primer bloque de más de 1 Mb de tamaño, y solo sucederá para aquellos usuarios que no se hayan actualizado, que serán minoría. Rechazarán el bloque y probablemente se quedarán atascados en ese punto, puesto que el resto de la red seguirá construyendo la cadena teniendo en cuenta este bloque grande, y todos esos nuevos bloques también serán rechazados por la minoría porque no les encajan en la cadena que tienen. En este punto, se verán forzados a actualizar.
Sí, esto lo comenta Gavin en una de las respuestas de su post:
I'll be proposing what we did for the block.version=1 to block.version=2 soft fork: miners signal that they approve of the new rules by producing less-than-1-MB-blocks with version=3 (the version number is part of the block header of every block).
When 50% of blocks are version=3, old version of the reference implementation start complaining: "Warning: This version is obsolete, upgrade required!"
Whenever... uhh... 80% of blocks produced are version=3, the fork happens: version=2 blocks are rejected, and miners are free to build bigger-than-1-MB version=3 blocks.
The hard fork would happen sometime after that, when a miner actually DOES produce a bigger-than-1-MB block (that is assuming that we don't decide to make some other incompatible hard-forking change that is also tied to block.version=3 blocks becoming a supermajority).
Saludos!