"Cambiar dirección" es la notación de la dirección del script de esta salida, pero técnicamente es el scriptPubKey y el nuevo UTXO, no el saldo de la cuenta. Con la suma de los insumos I, los resultados para los receptores R y la tarifa F, C = I − R − F es cierto. En el caso de un retiro exacto o de un resto no económico, es posible que la billetera no genere ningún cambio.
Bitcoin gasta todos los UTXO; sólo una parte no se puede restar de una entrada. Si la billetera elige entradas de 120.000 sats para un pago de 100.000 sats y una tarifa de 2.000 sats, debe colocar los 18.000 sats restantes en la siguiente salida o conservarlos como tarifa. La salida del destinatario y el cambio tienen la misma posición en la serialización y el orden no tiene significado de consenso. Una vez confirmado, el cambio es un nuevo UTXO con su propio punto de salida, confirmación y precio de gasto futuro. [Guía para desarrolladores de Bitcoin: transacciones]
La selección de monedas selecciona entradas, tarifas y posibles cambios juntos. La combinación exacta no producirá el resultado; de lo contrario, la billetera compara el saldo con el costo de crearlo y gastarlo más tarde. La financiación de RPC Bitcoin Core puede completar como máximo una salida de cambio y devolver su posición, mientras que enviar todo no tiene ninguna. El control de monedas cambia las entradas utilizadas, por lo tanto cambian, pero cada entrada seleccionada manualmente se consume en su totalidad. Consulta entradas finales, importes de beneficiarios, tarifa y cambio. [Bitcoin Core - Implementación de selección de monedas] [Bitcoin Core RPC - transacción de recaudación de fondos] [Bitcoin Optech - Selección de monedas]
Las billeteras HD generalmente derivan scripts de aceptación en la rama externa y cambios en la rama interna. BIP44 marca el cambio=0 como externo y el cambio=1 como interno: por ejemplo m/84'/0'/0'/0/i y m/84'/0'/0'/1/i para una cuenta SegWit nativa. Ésta es una convención de aplicación, no un consenso; La billetera descriptiva puede tener una política diferente. La nueva dirección interna restringe la reutilización de la dirección, mientras que regresar a la dirección original es válido pero vincula el historial. [BIP 32 — Carteras deterministas jerárquicas] [BIP 44 — Jerarquía de cuentas múltiples]
El descriptor de salida combina el tipo de script, las claves, los orígenes y un comodín de derivación que especifica la propiedad. El par wpkh([fingerprint/84h/0h/0h]xpub…/0/*) y…/1/* describe recibir un cambio; BIP389 permite la escritura multiruta. La bandera interna selecciona el descriptor para cambiar, no cambia el script en sí. Una semilla sin información de cuenta, tipo de script y política de derivación puede dejar invisibles los cambios válidos después de una actualización, aunque las claves existan. [BIP 380 — Descriptores de secuencias de comandos de salida] [BIP 389 — Expresiones clave de descriptores de rutas múltiples] [Bitcoin Core — Descriptores de salida]
El bloque contiene valores y scriptPubKeys, no etiquetas de pagador, beneficiario o cambio. La billetera reconoce su propio cambio a partir de registros derivados, el explorador simplemente adivina. El orden de salida o la regla de la "segunda salida" no es confiable. Una transacción no puede tener ningún cambio, una, múltiples salidas autocontroladas o salidas de varios participantes. Por lo tanto, el cambio es una clasificación relativa a la billetera, no una propiedad escrita por el protocolo. [Guía para desarrolladores de Bitcoin: transacciones]
Las heurísticas comunes designan como cambio una salida del mismo tipo de script que las entradas, una cantidad redondeada poco favorecedora, una nueva dirección o un valor correspondiente a la aritmética de las entradas. A menudo trabajan por un pago ordinario con dos salidas, pero cada una tiene contraejemplos. BIP78 Payjoin rompe intencionalmente las heurísticas tanto de entrada común como de tipo script y de cantidad redonda; CoinJoin, procesamiento por lotes y autotransferencia añaden más ambigüedad. Se pretende que el resultado tenga un grado de certeza y respaldo, no un estado de prueba de protocolo. [BIP 78 — Payjoin] [Meiklejohn et al. - Un puñado de Bitcoins]
El polvo es la política de retransmisión del nodo calculada a partir del tipo de producción, el tamaño estimado de su gasto futuro y la tarifa de retransmisión de polvo ajustable; No es un recuento universal de satoshi ni una prohibición por consenso. Una billetera puede rechazar el cambio muy por encima del polvo cuando la creación y el gasto posterior cuestan más que su valor. El límite económico depende de la tarifa actual y a largo plazo y del tamaño del guión. Suprimir el cambio aumentará la tarifa actual; muy poco cambio puede atascarse. [Bitcoin Core - Política de retransmisión de transacciones]
En PSBT, las derivaciones de salida BIP32 permiten que un firmante de hardware o fuera de línea derive la salida propuesta y verifique el retorno a la misma política de billetera. BIP174 describe la detección tanto para clave única como para firma múltiple; para multifirma, hacer coincidir una única clave local no es suficiente. Un coordinador malicioso puede reemplazar el cambio con su propio resultado u ocultar el resto pagando una tarifa exorbitante. El firmante debe verificar el destinatario, la tarifa total y cada cambio declarado en la pantalla confiable. [BIP 174 - Formato de transacción Bitcoin parcialmente firmado]
El reemplazo por tarifa cambia la economía de la transacción no confirmada. La tarifa adicional en Bitcoin Core puede pagar una tarifa más alta al reducir el cambio, agregar entradas o crear cambios; después de caer por debajo del cambio de política o economía, desaparece. Gastar cambios no confirmados crea un descendiente que depende del reemplazo de los padres, y CPFP utiliza resultados controlados por billetera para aumentar la tarifa del paquete. No considere un txid/outpoint final no confirmado antes de que se resuelvan los reemplazos. [Bitcoin Core RPC - tarifa adicional]
La recuperación completa requiere claves iniciales o de firma, así como descriptores internos/de recepción, orígenes de claves, cuenta, red, política de script, rangos de derivación y un inicio de escaneo suficientemente antiguo. Un /1/* que falta normalmente trunca el saldo porque no se encuentra el cambio. Para multifirma, mantenga todos los xpubs, umbrales y pedidos del cofirmante en ambas ramas. Pruebe la recuperación haciendo coincidir los scripts de recepción/cambio conocidos, reconstruyendo el UTXO, creando un PSBT y verificando el cambio en cada firmante. [BIP 32: Carteras deterministas jerárquicas] [BIP 380: Descriptores de secuencias de comandos de salida] [BIP 389: Expresiones clave de descriptores de rutas múltiples]
Para obtener la imagen más completa, lee esta entrada junto con Dirección de Bitcoin, UTXO, Coin Control, Cartera, Coin Selection, HD Wallet. También enlazan con esta entrada Dirección de Bitcoin, Coin Control, Privacidad en Bitcoin, Seudonimidad.