< 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
< bitcoin-git> [bitcoin] hebasto opened pull request #19785: build: lrelease requires xml if not cross-building (master...200823-xml) https://github.com/bitcoin/bitcoin/pull/19785