Yo mismo investigué un poco, pero descubrí que yo mismo estoy sesgado o que mis propias fuentes están sesgadas. ¿Alguien tiene un análisis objetivo de las diversas propuestas y sus ventajas/desventajas? Primero-visto-seguro, niño-paga-por-padre, RBF completo son los que conozco, pero felizmente leería más propuestas si están disponibles.
Las tres propuestas intentan resolver el mismo problema, el problema de las transacciones atascadas.
Debido al comportamiento de Bitcoin Core con respecto a los gastos dobles (se eliminan silenciosamente y no se retransmiten), es imposible gastar productos que haya utilizado en una transacción existente. Por lo general, esto es algo bueno, pero hay algunos casos en los que un usuario puede haber creado una transacción mal formada (por ejemplo, estableciendo accidentalmente 0 tarifas) que no es aceptable o no se puede extraer por varias razones, y es deseable que ellos ser capaz de volver a emitir una transacción fija.
Esto se ve agravado por el comportamiento indefinido del grupo de memoria de los nodos con respecto al vencimiento de transacciones antiguas y la falta de una regla clara sobre cuándo es seguro intentar otro gasto.
El enfoque Child-Pays-For-Parent permite que las tarifas del elemento secundario de una transacción (la transacción que gasta los resultados de la transacción atascada) también paguen la transacción principal. Esto permite que un comerciante gaste la transacción "rota" que recibió como cualquier otra transacción, y el sistema debería volver a un estado consistente.
El beneficio de Child-Pays-For-Parent es que resuelve el problema de una manera que no cambia fundamentalmente la mecánica de cómo se selecciona y mantiene una transacción (sobre todo, el comportamiento del grupo de memoria visto por primera vez). En mi opinión, esto hace que esta solución sea la más intuitiva.
Sin embargo, la dificultad con Child-Pays-For-Parent está en la implementación. Hay algunos cambios necesarios en la propagación de transacciones que se requieren para que esto funcione correctamente (ya que solo transmitir un hijo válido hará que otros nodos consideren la transacción como huérfana, sin el contexto del padre).
El reemplazo por pago intenta abordar el problema cambiando la regla fundamental para aceptar y mantener transacciones, la regla de "primero visto".
En este sistema, una transacción con tarifas más altas puede gastar entradas ya gastadas (que aún no se han confirmado en un bloque) y reemplazará esa transacción en el grupo de memoria.
El beneficio de este sistema es que cambia la regla fundamental de selección de transacciones pero no requiere cambios en la forma en que se calculan las tarifas.
La desventaja es que esto representa un cambio significativo en términos del comportamiento esperado del grupo de memoria. En mi opinión, esto hace que las transacciones sean menos predecibles; la regla vista por primera vez es directa, predecible y fácil de entender e implementar. Además, rompe cualquier funcionalidad que dependa de la previsibilidad de transacciones no confirmadas al hacer que sea trivial emitir gastos dobles. (El gasto doble en una primera transacción vista requiere una combinación de red moderada y recursos informáticos, algunos conocimientos técnicos decentes y algo de suerte. El gasto doble en un mundo de reemplazo por tarifa no requiere nada de lo anterior).
FSS RBF intenta hacer que RBF sea compatible con las implementaciones de grupos de memoria que se ven por primera vez al exigir que los resultados de la transacción original se mantengan mediante regastos posteriores.
Los beneficios son que, en algunas situaciones, se puede confiar en el comportamiento visto por primera vez. Una transacción que envía x BTC a un comerciante no puede revocar eso.
En la práctica, sin embargo, esta protección es bastante débil. Rompe trivialmente las transacciones que gastan otras transacciones no confirmadas al permitir que se reemplace la primera transacción en la cadena, invalidando salidas futuras. Esto significa que la carga por el doble gasto de una transacción no confirmada se vuelve solo un poco más alta que en el reemplazo por tarifa estándar.
En teoría, permite aceptar una transacción no confirmada que gasta una salida confirmada con protecciones similares a las del comportamiento típico visto por primera vez.
Sin embargo, es imposible hablar de esto sin tocar la política. La razón por la que esto es tan polémico es que implica un cambio político que rompe muchos sistemas que se basan en el comportamiento del grupo de memoria visto por primera vez. Los defensores del cambio creen que, dado que las transacciones no confirmadas no están sujetas a las mismas protecciones criptográficas que las transacciones confirmadas, deben eliminarse del ecosistema y deben adoptarse herramientas que faciliten esto. Las personas que se oponen a este cambio creen que las transacciones no confirmadas representan un riesgo aceptable como con todo en Bitcoin (recuerde, Bitcoin requiere una mayoría de mineros honestos, por ejemplo), y que romper algo en lo que muchas personas confían innecesariamente es un neto negativo.
Respuesta republicada de: ¿Cómo funciona el reemplazo visto por primera vez por tarifa?
En este momento, en su mayor parte, los mineros de Bitcoin siguen una regla First-Seen-Safe: si aparecen 2 transacciones en conflicto en el mempool, el minero se queda con la que vio primero.
Reemplazar por tarifa permitiría a los mineros eliminar transacciones del mempool en función de qué transacción paga la tarifa más alta. Esto es problemático porque permite el fraude. Si le pago a un comerciante y me retiro, puedo transmitir fácilmente una transacción en conflicto que me devuelva el dinero con solo una tarifa ligeramente más alta. Al comerciante no se le paga, pero obtengo los productos por una tarifa de transacción ligeramente mayor.
Con Child-Pays-For-Parent, una transacción no confirmada (padre) puede tener prioridad de minería gastando su producción (hijos). Las tarifas adicionales que vendrían de los niños ofrecen un incentivo para que el minero incluya la transacción principal. CPFP se relaciona con RBF como una forma para que un comerciante luche contra el fraude. Si un comerciante detecta que se ha desviado un pago que esperaba, puede aumentar la prioridad de su transacción preferida mediante CPFP. Esta es una solución polémica para hacer aceptable el RBF.
First-Seen-Safe Replace-By-Fee sigue las reglas de RBF, pero impone algunos requisitos sobre el reemplazo de transacciones en el mempool. Al reemplazar una transacción basada en una tarifa más alta, se deben cumplir todos los montos de todas las salidas de la transacción original. Puede agregar y eliminar entradas, aumentar las cantidades de salida anteriores y agregar nuevas salidas. Puede modificar las transacciones siempre que cumpla o supere las salidas anteriores.
Con FSSRBF puede aceptar con seguridad transacciones que gastan salidas confirmadas, pero no transacciones no confirmadas que gastan salidas de otras transacciones no confirmadas. CPFP es útil más allá de RBF, pero no es necesario para la usabilidad de FSSRBF.
Nick ODell