No, no he dicho eso. Digo claramente que es la que más se acerca a la que yo considero la solución ideal. BIP100 no la considero una solución ideal, tan solo un parche para comprar algo más tiempo mientras se investiga la solución definitiva.
El punto 1 sería la supuesta solución ideal en la que el tamaño de bloque se decide según mercado.
El punto 2, el parche BIP100 que va ligeramente encaminado en el sentido del punto 1.
En ningún momento he aportado nada que diga mi opinión al respecto. Tan solo he dado mi opinión sobre entre las opciones que se comentaban en el hilo y aportando una opción más (que ni siquiera sé si alguien está investigando al respecto). Esta pregunta daría para un hilo de discusión nuevo.
“The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of blocks in between doublings will increase linearly based on the block’s timestamp. The maximum size of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.”
Yo lo veo de este modo: la comisión por transacción se puede considerar como un pago por una porción de espacio en el siguiente bloque para que tu transacción sea incluida.
Por simplificar, pujas por espacio en el siguiente bloque. Los mineros son los que venden ese espacio y pueden decidir cuánto espacio hay en función de la demanda que se vaya desarrollando según el número de transacciones pendientes. Ley de oferta y demanda. MERCADO decide el tamaño de bloque, creo que es bastante acertado llamarlo así.
Si le sumas que ahora también tendrán competencia directa proveniente de las cadenas laterales, el resultado podría ser que tengan que ser lo más eficientes y económicos posible para mantener la máxima rentabilidad posible. Esto podría traducirse en que no necesariamente tengamos que pagar comisiones por transacción cada vez más altas.
¿Prefieres el bloque a 2MB? Pues si hubiéseis modificado simplemente el
parámetro en el código (tal y como muchos ceporros repetían como
papagayos) tendríais ya todos los nodos quemados. Ya os puse el link el
otro día en el que se explica el vector de ataque para hundir el
sistema.Y si lo incrementáis a 2MB añadiendo la limitación de 100kB
máximo por transacción para evitar freir los nodos, pues estaríais
también desvistiendo un santo para vestir a otro porque todos los
usuarios de menor poder adquisitivo también suele coincidir que son
usuarios que tienen muy dispersos sus bitcoins, en numerosos outputs con
cantidades ínfimas provinientes de faucets, microdonaciones, etc y ese
límite de 100kB los expulsaría también de vuestro sistema.
No existen los milagros.
Y voy a decirte algo más. Gavin y la CIA hacen palmas con las
orejas con la versión de Bitcoin Classic que limita el tamaño máximo de
transacción porque así se impide que se puedan construir transacciones
con muchos inputs, muchos outputs o ambos, cosa que es justo lo que se
hace mediante CoinJoin para mejorar el anonimato y la fungibilidad de
Bitcoin.
Mataban dos pájaros de un tiro. Por un lado disminuirían la
descentralización de la red al poder mantener menos nodos una cadena de
bloques tan pesada, y por el otro reducían el anonimato y la
fungibilidad al añadir un límite en el tamaño máximo de las
transacciones.
