< achow101>
so we can rebase all the things on top of it
< luke-jr>
Dizzle: it doesn't, and generally isn't expected to be called with mined blocks
< luke-jr>
Dizzle: note it does not perform the PoW check
< Dizzle_>
luke-jr: if the mined block is proposed to Bitcoin Core via getblock template, it gets called, and I couldn't find an indication that a valid proposal gets submitted by Core.
< Dizzle_>
*getblocktemplate
< Dizzle>
I'm assuming a pool implementing gbt would submit a valid proposal to their p2p and fibre peers?
< luke-jr>
Dizzle: mined blocks aren't supposed to be proposed in that manner, they're supposed to be fed to submitblock
< luke-jr>
a pool could, but clients shouldn't assume they will
< luke-jr>
Dizzle: proposals are for checking that the block is valid BEFORE mining it
< Dizzle>
luke-jr: ahhh, thanks! That was the missing piece of the puzzle for me. I was thinking it was like getwork(data)
< Dizzle>
I did. It didn't really define what a proposal was, just how to construct one
< luke-jr>
hmm
< Dizzle>
Not your fault. I didn't jump into this knowing mining especially well. So proposal is for something like, "If I were to change the coinbase to spend coins to myself, would you accept the mined block when I submit it?"?
< luke-jr>
Dizzle: if the BIP is unclear, it is indeed my fault :P
< luke-jr>
Dizzle: in bitcoind's case, you have to make the coinbase from scratch, but otherwise yes
< Dizzle>
Sweet. Thanks! Heading out for the night.
< gmaxwell>
luke-jr: I guess it wouldn't be bad for it to actually accept it, if it turned out to be valid.
< luke-jr>
no, other than setting up a false expectation
< provoostenator>
Is there (or should there be) a document in the repo or elsewhere to describe best practices for replacing deprecated RPC calls?
< provoostenator>
E.g. someone asked me what to use instead of signrawtransaction (answer: signrawtransactionwithkey or signrawtransactionwithwallet).
< wumpus>
for 'getinfo' we had a special message for a while, if you used the old RPC call, it'd give an error message to use the new ones, I think that would be good practice for other removed RPC calls as well at least for one major release
< instagibbs>
Is there a great cost to just leaving around a disabled message indefinitely? No supporting code infra etc.
< instagibbs>
Doesn't even have to be verbose, just "disabled, see release notes version blah" or something
< instagibbs>
gwillen, any update on psbt signing stuff?
< provoostenator>
For those reading (the logs): ##hwi is a fun place for those interesting in _hardware_ wallet support, and there's some overlap with this effort.
< sipa>
a question i had, how do we progress with things like #14481 ?
< sipa>
because it seems to me that using descriptors instead of lists of keys/redeemscript/witnessnessscript in sign* RPCs will be a much better user experience
< gwillen>
I still owe another PR of PSBT related refactoring, and I have a working demo of offline signing UI if anybody wants to play with it (it's the same one I had around this time last week already)
< provoostenator>
How would listunspent return descriptors?
< sipa>
provoostenator: #14477
< sipa>
already implemented
< meshcollider>
provoostenator: accept, not return
< sipa>
i was thinking about a processpsbtwithdescriptor RPC, and was wondering if it should be integrated with utxoupdatepsbt
< meshcollider>
Ok I have to go now, I'll catch up on the rest later today
< sipa>
as we have all the pieces in place now
< sipa>
or should we keep them separate, where you'd first run utxoupdatepsbt, then processpsbtwithdescriptor to fill in scripts, and then sign (which could be done by any signer, or with processpsbtwithdescriptor at once)
< instagibbs>
sipa, would that be a "stateless" call?
< sipa>
utxoupdatepsbt is not stateless (it looks at the UTXO set), but processpsbtwithdescriptor would be
< instagibbs>
was asking about latter
< instagibbs>
so it would involve passing in xprv-containing descriptors when signing required
< sipa>
i was thinking you could give it either public descriptors, private descriptors, or private keys separately
< achow101>
i think it should stay separate
< sipa>
i have a slight preference for that as well, but it's less convenient
< achow101>
but do you really need a descriptor to process a psbt? what if we just made it a simple signer?
< achow101>
the descriptor is only needed for finalizing
< achow101>
i guess you could also fill in keys from a descriptor
< sipa>
achow101: to fill in witnessscript/redeemscripts/keys
< sipa>
so yes
< provoostenator>
Just a key could be a handy shortcut for some descriptors, but perhaps the base case should be a descriptor.
< sipa>
provoostenator: just a key is for the case where you have an xpub-based descriptor, and a private key separately
< provoostenator>
For the unambiguous case if you have pwpk(blah xpub blah) then if you pass in an xpriv that's clear.
< provoostenator>
Right
< provoostenator>
But that would just be a shortcut for pwpk(blah xpriv blah)
< sipa>
or when the PSBT already has all script fields, and all you have is a private key
< sipa>
i'll add them to the issue i'm opening
< sipa>
anything else we want to discuss?
< provoostenator>
Nope
< sipa>
as decreed by provoostenator:
< sipa>
#endmeeting
< lightningbot>
Meeting ended Fri Nov 16 19:54:56 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< zallarak>
meshcollider: I updated per your feedback, and the build is passing. Any other thoughts / comments welcome. I am thinking about a new way of testing, that is why I worked on this.