Estoy ejecutando Bitcoin Core v0.11.0.0-gd26f951 (64-bit)
Ubuntu en casa y lo he instalado Bitcoin Wallet for Android
en mi teléfono. Envié dos transacciones desde casa a mi teléfono: Primero , Segundo . Uno tenía una tarifa muy baja y tardó días, así que envié otro con una tarifa un poco más alta que tardó solo unos minutos. Sin embargo, ambos llegaron, ya tienen casi dos mil confirmaciones y se muestran en verde en la aplicación.
La aplicación Bitcoin ahora (lo noté por primera vez hoy y no creo que lo haya dicho inicialmente) dice
This payment was delayed because the sender used an insecure transaction type.
debajo de ambas transacciones. ¿Qué significa eso?
Busqué en Google la frase y obtuve exactamente un resultado, en un paquete de recursos que es parte del código para el proyecto de billetera bitcoin en github , que parece ser la aplicación de Android. La clave correspondiente es transaction_row_message_received_rbf
, que no generó ningún resultado.
¿Alguien puede decirme qué podría ser este "tipo de transacción insegura" y por qué Bitcoin-Qt lo usaría? ¿Debo prevenirlo, y si es así, cómo lo hago?
Parece que las transacciones Bitcoin Wallet for Android
se etiquetan incorrectamente como debidas a un error en . El problema ha sido informado . No necesitas hacer nada.nLockTime
OptInRBF
bitcoinj
Aparentemente, Bitcoin Wallet para Android reconoció su transacción como OptInRBF
(como lo indica el código que encontró). La advertencia que está viendo se agregó a la aplicación recién el 10 de marzo de 2016 .
OptInRBF
es la abreviatura de "Opt-in replace-by-fee", que se agregó a Bitcoin Core en 0.12.0. La nueva versión permite que Bitcoin Core reciba y trate correctamente las transacciones de reemplazo por tarifa. Sin embargo, Bitcoin Core no puede crear transacciones rbf todavía. Las billeteras tienen que "suscribirse" para enviarlas.
Reemplazar por tarifa es un indicador que se puede configurar en las transacciones para comunicar que es posible que desee cambiar la transacción antes de que se incluya en un bloque . Por lo tanto, tales transacciones no deben considerarse confiables hasta que obtengan su primera confirmación. Una vez incluidos en un bloque, son tan seguros como cualquier otra transacción.
Los grupos de minería que admiten rbf permitirán que una versión más nueva de la transacción reemplace a la anterior, especialmente si la transacción más nueva paga una tarifa más alta. Esto es útil, por ejemplo, para aumentar la tarifa de una transacción cuando está atascada, o para combinar varias transacciones en una sola cuando decide enviar otra transacción antes de que se confirme una anterior.
Mirando los datos sin procesar de la primera transacción , resulta que el sequence
número de la transacción está por debajo del valor máximo: muestra 0xFEFFFFFF
mientras que el máximo sería 0xFFFFFFFF
. La secuencia con un E
en segundo lugar es un little endian sin signo largo para "uno por debajo del máximo". Esta es la secuencia de una nLockTime
transacción .
OptInRBF
tienen secuencias que son más pequeñas que la nLockTime
secuencia, es decir, sequence < MAX - 1
. Por lo tanto, parece que bitcoinj
o Bitcoin Wallet for Android
clasifica erróneamente nLockTime
las transacciones como OptInRBF
. El problema es que desde Bitcoin Core 0.11 todas las transacciones tienen una nLockTime
secuencia.
A primera vista, el bitcoinj
código que verifica si una transacción está OptInRBF
bien:
public boolean isOptInFullRBF() {
return sequence < NO_SEQUENCE - 1;
}
Sin embargo, Java usa de forma nativa el formato big endian en lugar del formato little endian.
<especulación>Por lo tanto, puede haber un problema con NO_SEQUENCE - 1
el que podría resolverse 0xFFFFFFFE
y la nLockTime
secuencia 0xFEFFFFFF
leída como big endian parecería mucho más pequeña que eso y, por lo tanto, podría etiquetarse como OptInRBF
.</especulación> 1
He informado del problema y estoy tratando de crear una corrección de errores .
1 Resulta que mi especulación era incorrecta. BitcoinJ
y Bitcoin Wallet for Android
maneje las transacciones con la nLockTime
secuencia fina, y analícela usando el formato little endian según sea necesario. Hasta ahora, el mantenedor no pudo reproducir el problema descrito con las transacciones proporcionadas (en su lugar, se mostraron correctamente sin previo aviso). Por lo tanto, aún se desconoce el motivo de la aparición de la advertencia.
Gracias a Pepijn Schmitz, Gregory Sanders, Andreas Schildbach y Wladimir van der Laan por su ayuda para resolver esto.
muro
muro
Pepijn Schmitz
muro
Pepijn Schmitz
muro
andreas
Pepijn Schmitz
andreas
Pepijn Schmitz
andreas
Pepijn Schmitz
andreas
Pepijn Schmitz