< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6d37ed888e34...29082e8f40c3
< 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?
< luke-jr> their own only
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/29082e8f40c3...8f9725c83f1d
< bitcoin-git> bitcoin/master 1a62425 João Barbosa: qa: Add --filter option to test_runner.py
< bitcoin-git> bitcoin/master 8f9725c MarcoFalke: Merge #16390: qa: Add --filter option to test_runner.py
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16390: qa: Add --filter option to test_runner.py (master...2019-07-testrunner-filter) https://github.com/bitcoin/bitcoin/pull/16390
< promag> stevenroose: /wallet/
< promag> default wallet is ""
< 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> stevenroose: if you prefer you can pm
< promag> stevenroose: there's spendable:false in the 500 utxo
< stevenroose> promag: it's imported by address
< stevenroose> bool spendable = ((mine & ISMINE_SPENDABLE) != ISMINE_NO) || (((mine & ISMINE_WATCH_ONLY) != ISMINE_NO) && (coinControl && coinControl->fAllowWatchOnly && solvable));
< 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 closed pull request #13804: WIP: Transaction Pool Layer (master...Mf1807-txpoolStacked) https://github.com/bitcoin/bitcoin/pull/13804
< 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
< sipa> yeah
< bitcoin-git> [bitcoin] laanwj pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/8f9725c83f1d...8f604361ebaa
< bitcoin-git> bitcoin/master 613c46f James O'Beirne: refactoring: move block metadata structures into BlockManager
< bitcoin-git> bitcoin/master 4ed55df James O'Beirne: refactoring: add block_index_candidates arg to LoadBlockIndex
< bitcoin-git> bitcoin/master 55d525a James O'Beirne: refactoring: make pindexBestInvalid internal to validation.cpp
< promag> stevenroose: don't forget to unlock if you end up not using them
< bitcoin-git> [bitcoin] laanwj merged pull request #16194: refactor: share blockmetadata with BlockManager (master...2019-06-au-blockman) https://github.com/bitcoin/bitcoin/pull/16194
< bitcoin-git> [bitcoin] fjahr opened pull request #16399: wallet: Improve wallet creation (master...followup-16244) https://github.com/bitcoin/bitcoin/pull/16399
< 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 pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/8f604361ebaa...24dbcf380844
< bitcoin-git> bitcoin/master fa613ca MarcoFalke: chainparams: Remove unused fMineBlocksOnDemand
< bitcoin-git> bitcoin/master fa9b419 MarcoFalke: test: Add test that mainnet requires standard txs
< bitcoin-git> bitcoin/master fa89bad MarcoFalke: test: Require standard txs in regtest
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15891: test: Require standard txs in regtest by default (master...1904-testRequireStandard) https://github.com/bitcoin/bitcoin/pull/15891
< bitcoin-git> [bitcoin] sdaftuar opened pull request #16400: [refactor] Rewrite AcceptToMemoryPoolWorker() using smaller parts (master...2019-07-refactor-atmp) https://github.com/bitcoin/bitcoin/pull/16400
< bitcoin-git> [bitcoin] sdaftuar opened pull request #16401: Package relay (master...2019-07-package-relay) https://github.com/bitcoin/bitcoin/pull/16401
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/16296 | gui: crash with loadwallet & QT_FATAL_WARNINGS · Issue #16296 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/16306 | gui: crash in Console after loading & unloading wallet · Issue #16306 · bitcoin/bitcoin · GitHub
< fanquake> promag: can have a go at reproducing today. They are somewhat sporadic.