¿Nueve transacciones de 1 MB podrían crear estragos en la red BitcoinCash?

Parece que la cadena BitcoinCash todavía está en su cadena principal BCH original, y las minas/intercambios/carteras no actualizadas aún pueden realizar transacciones allí.
Entonces, ¿qué pasaría si se crearan nueve (o más) transacciones de 1 MB rellenando los comentarios para que cada transacción tuviera poco menos de 1 MB? Suponiendo que todas estas transacciones, ninguna o más, tuvieran atractivos Satoshi por byte, ¿es posible el siguiente escenario? ¿Si no, porque no?

  • Las minas mejoradas intentarían llenar un bloque nuevo con nueve (o más) transacciones de 1 MB, mientras que los nodos no actualizados intentarían llenar un bloque nuevo con exactamente ocho de ellas.
  • Si una mina mejorada ganó el siguiente bloque, crearía una bifurcación de regla de consenso física de 32 MB con un bloque inicial de 9 MB fuera de la cadena principal, y podríamos ver este bloque de > 8 MB en un explorador de bloques de BitcoinCash (al menos para Un rato).
  • Los bloques subsiguientes extraídos por nodos no actualizados extenderían la cadena principal original no actualizada de 8 MB, mientras que los bloques subsiguientes extraídos por nodos actualizados extenderían la cadena de bifurcación dura ahora actualizada.
  • Mientras tanto, los intercambios/carteras que no se han actualizado (posiblemente algunos jugadores importantes debido a la naturaleza de no búsqueda de consenso de este lanzamiento) operarían solo en la cadena principal original, mientras que aquellos que se han actualizado operarían en la cadena actualizada, suponiendo que sea más larga. .
  • Periódicamente, la cadena con el mayor trabajo acumulativo haría que las transacciones en la otra cadena se enviaran de vuelta al mempool, lo que podría permitir que este proceso se repita, suponiendo que la nueva cadena actualizada tuviera menos trabajo acumulativo y que la nueva cadena actualizada ganara nuevamente la siguiente block race y escribió un nuevo bloque de bifurcación dura de 9 MB.
  • Si esto funciona, el efecto general de esto podría ser equivalente a un ataque temporal de denegación de servicio en la red BitcoinCash.
Por "ninguno o más" en la cuarta línea, quise decir "nueve o más", disculpas por el error tipográfico, gracias ...

Respuestas (1)

No, la bifurcación dura también trajo nuevos códigos de operación. Ya se han realizado transacciones utilizando esos nuevos códigos de operación, lo que provocó que las cadenas se separaran. Si el único cambio fuera un aumento del límite de tamaño de bloque, los desarrolladores (?) pondrían una regla de consenso que dice "El tamaño del primer bloque después de la bifurcación debe ser mayor a 8 MB", similar al primer bloque de Bitcoin Cash, después bifurcando la cadena de bloques de Bitcoin. "... debe tener más de 1 MB..."

Trivia: Rawpool continuó extrayendo la antigua cadena de bloques durante un día. Más información

Soy consciente de los códigos de operación "nuevos" (realmente recién restablecidos). Para este argumento, sigo recurriendo al punto de que puede poner cualquier cosa en el script (incluidos los códigos de operación que no son reconocidos por los nodos no actualizados), pero buena suerte canjeando/desbloqueando fondos, especialmente en nodos no actualizados. Suponiendo que su argumento imparcial (?) sea válido, entonces también puedo preguntar
(1) ¿Un bloque de >8 MB en la cadena principal no causaría la interrupción real que estoy provocando aquí, que es que los intercambios/carteras no actualizados ya no podrían realizar transacciones en esa cadena? y (2) Si la creación de un bloque de más de 8 MB no fuera un problema, ¿por qué entonces los maximalistas de BitcoinCash no crearían dicho bloque (posiblemente como se describió anteriormente) para demostrar de una vez por todas a los posibles adoptantes que su cadena realmente escala? ?
(1) Sí. Es por eso que se oponen las bifurcaciones duras. (2) No hay obstáculos. Un minero puede llenar su bloque por completo si lo desea, de forma gratuita. Sin embargo, los bloques grandes aumentan el riesgo de quedarse huérfano, lo que significa que solo parece "gratis" y tiene un precio oculto. Dicho bloque sería diferente a un bloque de 30 MB lleno de transacciones reales. En ese caso, dado que las transacciones se habrían transmitido, Xthin/Compact Blocks/Graphene puede reducir significativamente la probabilidad de un bloque huérfano. Entonces, un minero tiene que transmitir sus transacciones para reducir la probabilidad de orf. (perder dinero por comisiones) o negociar
con huérfano @jimhash
Un cambio en el tamaño del bloque (actualización del 15 de mayo) es una bifurcación dura por definición, por lo que parece que mi (1) es válido; la creación de tal bloque sería disruptiva. Para mi (2) estoy dispuesto a "muéstrame un bloque> 8 MB". Siento que nos estamos desviando un poco del tema en "agitar el brazo" sesgado (?) En este punto, nunca mencioné nada de un bloque de 30 MB. Espero que BitcoinCash o Bitcoin Maximalists comprometidos financien/investiguen esto desde su lado. El primero para demostrar que su actualización funciona, el segundo para demostrar que no. Mientras tanto, aconsejo a los grandes mineros que vuelvan a la versión previa a la actualización, suponiendo que se hayan actualizado.