Conversation
|
Travis failures likely due to ElementsProject/libwally-core#203 |
|
Rebased on top of |
cdecker
left a comment
cdecker
left a comment
There was a problem hiding this comment.
Quite a nice change, making the internal wallet a lot more like bitcoind's. Can we deprecate txprepare and build on this instead?
| tal_hex(tmpctx, msg)); | ||
|
|
||
| response = json_stream_success(cmd); | ||
| json_add_psbt(response, "signed_psbt", signed_psbt); |
There was a problem hiding this comment.
Maybe add abool indiciating if it's ready for sendpsbt? (i.e. finalizable)
|
Ack, but needs rebase:
But some of this may be GH weirdness... |
We should do that once we have dual funding, because I'd rather not change interfaces twice... |
Unused here, but we'll use it in the next commit so that we can always pass back the effective / used feerate to the caller of `reserveinputs` This makes opening a channel much easier if we've internally determined the feerate
Reserve and unreserve wallet UTXOs using a PSBT which includes those inputs. Note that currently we unreserve inputs everytime the node restarts. This will be addressed in a future commit. Changelog-Added: JSON-RPC: Adds two new rpc methods, `reserveinputs` and `unreserveinputs`, which allow for reserving or unreserving wallet UTXOs
the bitcoin_tx version is basically a wrapper for the wally_tx script extraction -- here we pull it apart so we can easily get a tal'd script for a wally_tx_output
With the incursion of PSBTs, we're moving away from bitcoin_tx
Changelog-Added: JSON-RPC: new call `signpsbt` which will add the wallet's signatures to a provided psbt Changelog-Added: JSON-RPC: new call `sendpsbt` which will finalize and send a signed PSBT
when attempting to calculate the fees for a tx where we don't own all of the outputs, we can overshoot the feerate
Our existing coin_moves tracking logic assumed that any tx we had an input in belonged to *all* of our wallet (not a bad assumption as long as there was no way to update a tx that spends our wallets) Now that we've got `signpsbt` implemented, however, we need to be careful about how we account for withdrawals. For now we do a best guess at what the feerate is, and lump all of our spent outputs as a 'withdrawal' when it's impossible to disambiguate
Ok, updated requested changes and removed/fixed the two commit weirdness that happened due to master rebase. (one removed, the other folded into the appropriate commit). |
|
Looks like all the requested changes were implemented, except the cosmetic change to add fully signed flag in the ACK e101bc8 |
3 participants
These are the base RPC calls that we'll need for constructing a transaction iteratively.
As a PR, this is built ontop of #3762. New commits start at 569efe8Added RPC methods: