pr-34872

wallet: fix mixed-input transaction accounting in history RPCs

Ver Pull Request en GitHub ↗

  1. Introducción
  2. Pregunta 1
    ¿Qué problemas tiene la manera actual en que las wallets contabilizan transacciones cuyos inputs no son todos de la wallet? ¿Qué puede saber la wallet con certeza y qué problemas puede tener al calcular la fee?
  3. Pregunta 2
    En el primer commit se introduce el enum WalletTxInputOwnership (NONE, PARTIAL, ALL) junto con el caché m_cached_input_ownership en CWalletTx. ¿Por qué el enum necesita tres estados en lugar de reutilizar el bool existente AllInputsMine()? ¿Por qué la clasificación se guarda en caché y se invalida con MarkDirty()?
  4. Pregunta 3
    En el segundo commit se crea el struct WalletTxHistoryAccounting y la función CachedTxGetHistoryAccounting(). ¿Qué información agrupa esta función y por qué, de momento, la fee solo tiene valor cuando input_ownership == ALL? ¿Por qué la fee pasa a ser std::optional?
  5. Pregunta 4
    En el tercer commit se añade CWallet::MarkOutputsDirty() y se invoca al insertar una transacción nueva en AddToWallet() y LoadToWallet(). ¿Qué ayuda a solucionar esta función? (Piensa en qué pasaría si el padre de una transacción que ya está en la wallet se importa después).
  6. Pregunta 5
    En el quinto commit, en CachedTxGetAmounts(), la condición nDebit > 0 para reportar salidas como “sent” se sustituye por all_inputs_mine, y la fee solo se rellena si accounting.fee tiene valor. ¿Qué cambio de comportamiento introduce esto para una transacción con inputs mixtos?
  7. Pregunta 6
    En el septimo commit se añade AllForeignInputsKnownZeroValue() con su caché m_cached_foreign_inputs_zero_value. ¿Qué condición exacta debe cumplir cada input que no es de la wallet para considerarse de valor cero conocido? ¿Por qué se devuelve false si el prevout apunta a una transacción que la wallet no conoce?
  8. Pregunta 7
    En el octavo commit, la condición para atribuir salidas enviadas pasa de all_inputs_mine a can_attribute_sent_outputs. ¿Qué nuevo comportamiento habilita esto para transacciones con inputs extranjeros de valor cero? ¿Por qué, cuando tenemos un input extranjero de valor distinto de cero, aunque sea conocido porque su transacción padre está en la wallet, no calculamos la fee?
  9. Pregunta 8
    En el decimo segundo commit, el test test_zero_value_wallet_input de Alice construye una transacción mixta en la que el input propiedad de la wallet gasta un output de valor cero, mientras que el input que no es suyo (de la wallet de Bob) tiene un valor superior a cero y es desconocido por Alice. El test verifica que la transacción sigue reportándose con la vista de transacción mixta: involves_mixed_inputs: true, una entrada send agregada con wallet_debit = 0 y la fee ausente. ¿Por qué la wallet trata esta transacción como mixta en lugar de tratarla como una recepción pura, dado que Alice no aporta ningún valor?