< bitcoin-git>
[bitcoin] theStack opened pull request #19781: test: add parameterized constructor for msg_sendcmpct() (master...20200823-test-extend-msg_sendcmpct_ctor) https://github.com/bitcoin/bitcoin/pull/19781
< jeremyrubin>
re https://github.com/bitcoin/bitcoin/pull/17509, should there be a savepsbt RPC interface which keeps track of psbts submitted? Could be useful to keep track of the idea that we have a pending spend of some outputs.
< jeremyrubin>
I think my prev message dropped
< jeremyrubin>
re https://github.com/bitcoin/bitcoin/pull/17509, should there be a savepsbt RPC interface which keeps track of psbts submitted? Could be useful to keep track of the idea that we have a pending spend of some outputs.
< jeremyrubin>
(sorry if repaste)
< gwillen>
this might be something that walletsignpsbt could (maybe optionally on-by-default?) track, if we sign a spend of wallet coins?
< jeremyrubin>
I want it before then though as well
< gwillen>
I don't know if there's an equivalent on the non-PSBT side, when we sign a raw transaction
< jeremyrubin>
You should be able to store and manage a bunch of PSBTs
< jeremyrubin>
E.g., we could stick them in the wallet with a couple special flags to promise not to mine them till final or something...
< jeremyrubin>
It's useful if you're using Core as a wallet DB e.g. for a protocol. You might want to store a watchonly PSBT txn unsigned
< achow101>
jeremyrubin: there should be an option in walletcreatefundedpsbt to lock utxos after funding
< achow101>
IIRC there's an option in fundrawtransaction to do that, and walletcreatefundedpsbt has the same options
< jeremyrubin>
hm
< jeremyrubin>
But there's not a notion of storing the PSBT for later retrieval?
< achow101>
no
< jeremyrubin>
E.g., "get me the PSBT that is locking X output"
< jeremyrubin>
is there a reason not to add something like this conceptually?
< jeremyrubin>
some kind of psbtindex
< achow101>
it can take up a bunch of space?
< achow101>
would probably also require reworking transaction creation to operate on PSBTs
< jeremyrubin>
Well it's your own txns...
< achow101>
not every transaction funded is signed and broadcast though
< jeremyrubin>
Correct, so it could be optional to store them
< achow101>
although I guess locking the utxos implies that you actually plan on doing something
< jeremyrubin>
I just think it would be generically useful to store PSBTs that I expect to use in the future. Otherwise where should I store a txn waiting for a signature from a vault keu?
< jeremyrubin>
I want to send an witness-stripped PSBT to the vault key, and then finalize it later on my node
< jeremyrubin>
If I store the PSBT I can check what I got back was the same thing
< achow101>
sure
< jeremyrubin>
If they're just locked it would prevent new txs from using them, but doesn't guarantee the right tx uses them
< sipa>
why do you need to store it in the first place?
< sipa>
what you'll get back from the vault will be a fully-signed transaction, no?
< jeremyrubin>
Nope!
< jeremyrubin>
i send it to the vault unsigned by anyone
< jeremyrubin>
and then only sign after the vault has signed
< sipa>
ok
< jeremyrubin>
You can imagine that this is more normally the case when dealing with e.g. 10 vault keys that you want to sign in parallel with
< sipa>
i can see a use for something that keeps track of "in progress" transactions
< sipa>
i'm not sure if the bitcoin core wallet is the right place
< jeremyrubin>
I think it's more that bitcoin core wallet is the de-facto security perimiter for storing/handling the sensitive info and backups
< jeremyrubin>
So anything that you implemented as a diff layer you would want to likely have identical state for consistency
< jeremyrubin>
which leads me to believe the natural place is core wallet
< jeremyrubin>
(The context in which this came up is I have a tool which creates a bitcoin smart contract, and then I create a PSBT for it, locking the outputs I need. I then also have sub-transactions in that smart contract which i want to store somewhere, and they could be partially signed because they're lacking e.g. a vault key or a preimage.
< jeremyrubin>
Otherwise if you lose the specific transactions you would need to re-generate from the smart contract script the binary, which is currently not possible because I'm using Policy language for creating the contract
< sipa>
i've told you that's the problem
< jeremyrubin>
I'm not disagreeing or countering what you've said previously, merely noting. Were I to use a deterministic engine, then the issue would be lesser, but still present for convenience in finalizing txns.
< bitcoin-git>
[bitcoin] hebasto closed pull request #19780: build, qt: Add SVG support, and replace bitcoin PNG image with SVG one (master...200822-svg) https://github.com/bitcoin/bitcoin/pull/19780
< bitcoin-git>
[bitcoin] hebasto opened pull request #19783: build, doc: Correct and complete zlib info and usage (master...200823-zlib) https://github.com/bitcoin/bitcoin/pull/19783