This allows wallets to import funds without a rescan. It required an address or private key to exist in the wallet before calling. Primarily to be used to import funds to a pruned wallet, but could be used in conjunction with importaddress/privkey without rescan on an archival node.
A companion RPC call "removeprunedfunds" is added to allow the user to delete erroneous imported funds.
Concept ACK.
What happens if I import a fully spent transaction but fail to import the transaction(s) spending it's outputs?
What happens if I import a fully spent transaction but fail to import the transaction(s) spending it's outputs?
You are eaten by a grue.
One could avoid the grue eating by using a lantern, I mean, checking if the output is still spendable and setting a flag... perhaps?
The build fails with this on some systems:
/bin/sh: 1: /home/travis/build/bitcoin/bitcoin/bitcoin-i686-pc-linux-gnu/qa/rpc-tests/importprunedfunds.py: Permission denied
Concept ACK, +1 for the grue
253 | + if (fHelp || params.size() < 2 || params.size() > 3) 254 | + throw runtime_error( 255 | + "importprunedfunds\n" 256 | + "\nImports funds without rescan. Corresponding address or script must previously be included in wallet. Aimed towards pruned wallets.\n" 257 | + "\nArguments:\n" 258 | + "1. \"rawtransaction\" (string, hex, required) A raw transaction funding an already-existing address in wallet\n"
nit: (string, required) would be the pattern that matches with other rpc commands help. Hex as string type is mostly mentioned in the parameters description.
Nice and clean PR. Concept ACK.
And @paveljanik is right: importprunedfunds.py needs a -rwxr-xr-x file permissions mode.
Alternatively, when computing available funds we can check if each output is available directly in the utxo set, rather than (just?) looking at wallet transactions.
I don't know the internals well enough to know which is best, or if these are both terrible ideas. Especially in the presence of reorgs.
Marking outputs as spent is very complicated, as spendability depends on whether other transactions exist that spend them, which themselves may be in conflict with the blockchain.
We can check the UTXO set for spendability in theory, but that introduces yet another dependency between the wallet and the node, and is something that fundamentally requires a trusted full node.
IMHO, if you're manually importing transactions, you're bypassing the entire sync mechanism, it's your responsibility to also import whatever other transactions that may be relevant.
That was my feeling after digging around and thinking about it. On Feb 19, 2016 12:33 PM, "Pieter Wuille" notifications@github.com wrote:
Marking outputs as spent is very complicated, as spendability depends on whether other transactions exist that spend them, which themselves may be in conflict with the blockchain.
We can check the UTXO set for spendability in theory, but that introduces yet another dependency between the wallet and the node, and is something that fundamentally requires a trusted full node.
IMHO, if you're manually importing transactions, you're bypassing the entire sync mechanism, it's your responsibility to also import whatever other transactions that may be relevant.
— Reply to this email directly or view it on GitHub #7558 (comment).
Added a companion RPC call to allow removal of imported transactions.
Added a companion RPC call to allow removal of imported transactions.
Nice!
Fixed the undefined behavior that was causing the test to throw an error.
Squashed.
rebased
utACK 7eb7029