< bitcoin-git>
bitcoin/master fa0d0ff MarcoFalke: Remove unused bits from the service flags enum
< bitcoin-git>
bitcoin/master 29082e8 fanquake: Merge #16380: Remove unused bits from the service flags enum
< bitcoin-git>
[bitcoin] fanquake merged pull request #16380: Remove unused bits from the service flags enum (master...1907-netRemoveUnusedServiceBits) https://github.com/bitcoin/bitcoin/pull/16380
< pinheadmz>
I'm getting a leveldb checksum mismatch error `Fatal LevelDB error: Corruption: block checksum mismatch: /home/pi/.bitcoin/chainstate/2109327.ldb` but only when I shutdown with RPC stop... Since the error is in chainstate, can I try with -reindex ? Or do I need to redownload the chain...?
< sipa>
even -reindex-chainstate should work
< pinheadmz>
tnx
< stevenroose>
What's the name of the default wallet?
< stevenroose>
Like some other process calls `create("myname")` and then uses `/wallet/myname` as endpoint. If I want to use the default wallet, what endpoint do I use?
< stevenroose>
When doing multiwallet stuff, all wallets should notice new incoming transactions, right?
< promag>
what do you mean by "notice new incoming transactions"?
< stevenroose>
promag: that if the wallet is loaded, and then you call fundraw, it should know about the utxos it has
< stevenroose>
promag: I guess my issue is more with fundraw than the wallets
< jnewbery>
fundrawtransaction is a wallet RPC. It needs to be sent to an individual wallet's RPC endpoint
< stevenroose>
I'm running this all inside a program so it's not trivial to get good debugging information (I can print out things, but to investigate deeper I need to change the code and re-run integration test.).
< stevenroose>
So listunspent shows a 500 btc output
< stevenroose>
but fundraw keeps saying "insufficient funds"
< promag>
note that if the wallet was offline then some utxo might not be known. getwalletinfo has the "scanning" response
< stevenroose>
The funds are watchonly, but I have the include_watchonly variable set to true
< stevenroose>
promag: the node doesn't go down.. so the the wallet online as long as it was "createwallet"'d before?
< promag>
stevenroose: I don't know how you have that setup, but wallets can be loaded/unloaded
< promag>
do you specify conf_target in fundraw?
< stevenroose>
promag: don't think so
< stevenroose>
it's regtest
< stevenroose>
I have minrelaytxfee and minblockfee set to 0
< stevenroose>
(While I would like to remove those later, I have them at 0 now.)
< shesek>
stevenroose, did you set includeWatching?
< shesek>
oh sorry, missed your message
< stevenroose>
yeah I did, I'm not 100% sure the client is encoding includeWatching correctly, though, but I suppose if the field is names incorrectly (like include_watching), Core would complain, right? promag
< promag>
stevenroose: some yeah
< promag>
not sure about invalid options in json options
< stevenroose>
(@shesek we have serde(rename_all = "camelCase") so that should work
< promag>
invalid keys I mean
< shesek>
I just looked, FundRawTransactionOptions has serde configured with rename_all = "camelCase", then special case for the ones that aren't
< stevenroose>
shesek: yeah I know, just not 100% confident in it :D
< * luke-jr>
grumbles at tests failing on normal hard drives
< stevenroose>
hmmmm, do you have time, shesek? I could push my current progress, I reverted all the manual tx creation stuff
< shesek>
yes, lets move over to pm?
< stevenroose>
sure
< stevenroose>
thanks, promag, jnewbery I'll keep you posted if we figure it out :)
< promag>
sure
< stevenroose>
promag: can you do multiwallet witn bitcoin-cli without having to change the url in the config file?
< stevenroose>
-h doesn't show a -wallet or something
< promag>
-rpcwallet
< stevenroose>
oh
< stevenroose>
k cool thanks
< stevenroose>
promag: I just tried manually doing the same as what I did and it seems like it also doesn't work. Let me write this up briefly.
< promag>
right, how do you expect it to spend that?
< stevenroose>
I'm calling fundraw with includeWatching: true.. Is that not supposed to work?
< promag>
I could watch your coins and then I could spend them?
< stevenroose>
I'm just trying to use Core for coin selection.
< stevenroose>
promag: well there is includeWatching on fundraw..
< stevenroose>
fundraw doesn't sign, right
< stevenroose>
So it just fills some inputs from the unspent ones in the wallet
< promag>
1sec
< shesek>
the output needs to be `solvable` in order to be used by fundrawtransaction, not necessarily spendable
< shesek>
I think the issue is that the addresses needs to be imported with their matching pubkeys/spks in order to be `solvable`
< stevenroose>
True. But it doesn't really make sense. It's supposed to be for fee calculation because for solvable inputs you know the witness/scriptSig size, but for p2wpkh you should also know that
< sipa>
stevenroose: you're right that this could work in theory, but it's an exception
< sipa>
p2wpkh is only thing where feerates are computable without actually knowing the pubkeys
< sipa>
stevenroose: fee estimation works by trying to sign with a dummy signers which succeeds without knowing private keys
< sipa>
but if your address is not solvable, there isn't even a public key to invoke it on
< promag>
is there any inconvenient in importpubkey 03d2fad0057c658d013153cfab628af5fab3ff78cb6b4d6d5cd194556eedf0f206 ?
< stevenroose>
sipa: I understand now it's for feecalculation reasons. My main confusion is that includeWatching stringly suggests that watched addresses should work.
< stevenroose>
I'll pr a clarification.
< bitcoin-git>
[bitcoin] stevenroose opened pull request #16397: Clarify includeWatching for fundrawtransaction (master...fundraw-includewatching) https://github.com/bitcoin/bitcoin/pull/16397
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16398: rpc: testmempoolaccept for list of transactions (master...Mf1807-txpoolStacked) https://github.com/bitcoin/bitcoin/pull/16398
< stevenroose>
I'm getting this error when I'm using importmulti with "desc": { code: -8, message: "Invalid scriptPubKey" }
< stevenroose>
But the documentation for that field says "Should not be provided if using a descriptor"
< stevenroose>
promag, sipa: someone familiar with importmulti? I have a descriptor `wpkh(xpub..../0)` that I want to import. So that I (1) watch the address, (2) see the balance, (3) use it for coin selection in fundraw.
< stevenroose>
I'm reading: "If using descriptor, do not also provide address/scriptPubKey, scripts, or pubkeys"
< stevenroose>
When I don't provide `scriptPubKey`, I'm getting the "Invalid scriptPubkey" error.
< stevenroose>
When I do provide it (`{"address": "<derived p2wpkh address>"}`), the outputs for it stay `solvable: false`..
< sipa>
stevenroose: what version of bitcoin core?
< stevenroose>
0.17.1
< stevenroose>
sorry, that's probably relevant.
< stevenroose>
but my cites from the docs are from master
< sipa>
given that descriptor imports were only added in 0.18, that is relevant yes :)
< sipa>
if you want to use the pre-descriptor importmulti you'll need to provide the public key explicitly
< sipa>
and do it separately for each address imported
< sipa>
or use importpubkey
< stevenroose>
Oh really is "desc" just silently ignored? Yeah whoops that makes sense for the invalid scriptPubKey :D
< sipa>
yes
< stevenroose>
So now I did {"scriptPubKey":{"address":"bc1.."}, "pubkeys":["<the pubkey>"]} and I'm getting consistency check failed
< sipa>
there were many bugs in importmulti before it was overhauled in 0.18
< stevenroose>
hmm, k so I'll probably go with importpublickey for now then
< sipa>
what is the pubkey you're importing if i can ask?
< stevenroose>
I just don't really like that you can't force only indexing p2wpkh
< stevenroose>
Just a pubkey from the path.
< stevenroose>
We want Core to do coin control for us, while keeping the derivation outside of the node.
< sipa>
stevenroose: yes, that's a huge shortcoming... but we need a pretty big internal change before we can support that
< stevenroose>
So we have the xpriv and whenever a new address is requested, we put the address in Core.
< sipa>
descriptor wallets will do that
< sipa>
even in 0.18 with descriptor importmulti it'll effectively also import other address formats for the same key
< stevenroose>
So with importpublickey instead of importaddress, people can send to the p2pkh scriptpubkey and Core will think it's ours, coin select it and we'll fail signing it
< sipa>
yup
< stevenroose>
I mean we could have logic that checks for that, but Core doesn't have "drop this utxo" logic, so Core will keep selecting the output.
< stevenroose>
Ah we could lock it with lockunspent
< bitcoin-git>
[bitcoin] hebasto closed pull request #16389: Early "-" check for bitcoin-tx using stdin in ParseParameters() (master...20190714-short-parse-tx) https://github.com/bitcoin/bitcoin/pull/16389
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16402: Remove wallet settings from chainparams (master...1907-walletNoChainParams) https://github.com/bitcoin/bitcoin/pull/16402
< enigmisto>
Where is the source code for how the nodes discover the "true" chain with the most proof of work?
< tryphe>
enigmisto, the one with the longest cumulative work has the most work
< tryphe>
longest/biggest
< sipa>
enigmisto: really, it discovers all chains
< sipa>
and then tries to validate the best one
< sipa>
hard to point to exactly the source code for that; it's combination of p2p logic, consensus validation, and headers processing
< enigmisto>
I'm concerned there may be a denial of service vector where a node lies that they have a chain with most cumulative work, and forms the chain in a way that is computationally intensive to prove wrong.
< enigmisto>
For example, make a chain with hundreds of millions of blocks, each with a valid shallow proof of work, lie about the total they'll see when they get to to the end.
< enigmisto>
I assume I'm not the first person to think of that attack, so presumably there's some protection against it, but I'd like to understand it better.
< sipa>
basically that protection is checkpoints (unfortunately)
< sipa>
you can't branch off before the last checkpoints (which is now years old, but still sufficient for this purpose)
< sipa>
which means that every individual block must start with a large number of blocks that each have PoW as was required at the time
< sipa>
there won't be any actual validation however, until you have actually a chain of headers that exceed the known best chain's pow
< sipa>
the blocks won't even be downloaded
< sipa>
but the headers would be, if not for this protection
< enigmisto>
I see. Thanks for the explanation.
< sipa>
yw
< promag>
fanquake: don't forget about #16296 #16306 :D