elements
elements copied to clipboard
ElementsProject
rpc/wallet: add simulaterawtransaction RPC
This is an experimental feature for analyzing a given raw transaction, generating a mapping of what the wallet's balances will look like were the transaction to be signed and broadcast.
It uses GetDebit from wallet to determine incoming amounts and the unblinded transaction outputs to determine the outputs.
(Work here is on hold as upstream is progressing.)
Upstream: https://github.com/bitcoin/bitcoin/pull/22751
concept ACK
Have you proposed this for Bitcoin? Curious if you've gotten any feedback there?
This would be of limited use to bitcoin, I think, as it mostly becomes an issue when you are juggling multiple assets. (Maybe I'm too narrow-minded though. If there are actual use cases I would be happy to move upstream.)
Also I don't see how the CI errors are related to this change (e.g. why would feature_taphash_pegins_issuances.py stop working because of a new RPC command that doesn't change anything anywhere?)
@kallewoof how would you feel about rebasing this and changing it to work with PSETs rather than raw transactions?
@apoelstra I'm actually making more progress upstream than I expected. There are two versions, one which is this renamed to simulaterawtransaction in https://github.com/bitcoin/bitcoin/pull/22751 and one where an array of transactions is added to getbalances in https://github.com/bitcoin/bitcoin/pull/22776.
Rewriting this to work with PS?Ts would be a downgrade I believe, as PS?Ts can be turned into raw transactions but raw transactions cannot be turned into PS?Ts.
Rewriting this to work with PS?Ts would be a downgrade I believe, as PS?Ts can be turned into raw transactions but raw transactions cannot be turned into PS?Ts.
You can get a rawtx from a PSBT with finalizepsbt and get a PSBT from a rawtx with converttopsbt. PSBTs have strictly more information.
Ah, I didn't realize that. If you can go both directions it doesn't seem hugely important which one is implemented, though. And since raw transactions are "closer" to what is actually put on chain (e.g. side-stepping bug(s) in PS?T code) raw seems sensible. Is there a specific reason why you prefer the other?
When you go from a PSBT to a raw tranaction then you lose a ton of data: information about the previosu UTXOs needed for signing, BIP32 derivation paths, EC signatures which have not yet been pulled into the actual witness bytes, (in Elements) blinding keys and ECDH keys and explicit data which is hidden in the actual transaction.
The rawtransaction API basically cannot be used for collaborative transaction creation and it is effectively deprecated in favor of PSBT.
The rawtransaction API basically cannot be used for collaborative transaction creation and it is effectively deprecated in favor of PSBT.
I didn't realize this was the sentiment. Perhaps both would be ideal. I haven't done any PSBT stuff yet, but will look into it.
When you go from a PSBT to a raw tranaction then you lose a ton of data: information about the previosu UTXOs needed for signing, BIP32 derivation paths, EC signatures which have not yet been pulled into the actual witness bytes, (in Elements) blinding keys and ECDH keys and explicit data which is hidden in the actual transaction.
The way I envision this to be used is, you get a PSBT thrown at you, you convert it to raw tx, analyze (simulate) it, check that the result is what you expect it to be, then provide a signature for the PSBT in question.
Since you don't throw away that input you don't technically lose any information regardless of whether this is a raw tx command or a psbt command. That said, if people are of the sentiment that we're getting rid of raw tx entirely, then I should rework it for sure.
I doubt we'll ever get rid of the raw transaction API, for backward compatibility and testing purposes. But I expect that users in multi-party transactions (where the ability to analyze transactions is most important) will always use PSET/PSBT rather than rawtxes, so the extraction would be an extra step for them (and the extraction may lose extra data, such as input values, that could be useful for analysis).
I was going to say "there's already an analyzepsbt, maybe the functionality should go there", but then I realized it's non-wallet code. Anyway, thanks for the feedback, I will look into psbt'ifying.