< bitcoin-git> [bitcoin] merehap opened pull request #11748: [Tests] Adding unit tests for GetDifficulty in blockchain.cpp. (master...blockchain_unittests) https://github.com/bitcoin/bitcoin/pull/11748
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d4267a3ab271...5ea932a51083
< bitcoin-git> bitcoin/master d2ea2bc practicalswift: trivial: Fix unsuccessful typo
< bitcoin-git> bitcoin/master 5ea932a Pieter Wuille: Merge #11746: trivial: Fix unsuccessful typo...
< bitcoin-git> [bitcoin] sipa closed pull request #11746: trivial: Fix unsuccessful typo (master...unsuccesful) https://github.com/bitcoin/bitcoin/pull/11746
< ForAll> wrapping my head around things first by observation
< meshcollider> sipa: are you here at the moment?
< sipa> that depends onyour definition of 'here'
< meshcollider> lol :) Just a quick question re #11708, if I make redeemScript also accept an array of scripts, do you think listunspent should also return the witnessScript inside a list of redeemScript's or as a separate entry for clarity, because otherwise the output of listunspent can't be directly passed into signrawtransaction
< gribble> https://github.com/bitcoin/bitcoin/issues/11708 | Add P2SH-P2WSH support to signrawtransaction and listunspent RPC by MeshCollider · Pull Request #11708 · bitcoin/bitcoin · GitHub
< sipa> meshcollider: hmm, nnoying
< meshcollider> sipa: yeah :/ I think it would be best to make listunspent return an array of redeemScripts too in this case, there will only be two for P2SH-P2WSH so it should always be easy to work out which is which, but that would be a breaking change
< sipa> meshcollider: but that's technically an API break for listunspent for P2SH-P2WPKH
< meshcollider> sipa: I can think of two cases, either listunspent returns a string or an array when needed (which only breaks P2SH-P2WSH but is uglier code), or listunspent always returns an array even if it only has one element (which breaks P2SH, P2SH-P2WPKH, and P2SH-P2WSH but is cleaner long term)
< meshcollider> is the first case acceptable?
< sipa> i wouldn't even call the second obviously acceptable
< sipa> usually we don't break the api
< meshcollider> yeah
< meshcollider> so listunspent must return a string if there is only one element
< meshcollider> So that will only break P2SH-P2WSH but currently doesn't even work in that case so that's fine right
< sipa> yes, that's why it is maybe ok :)
< jonasschnelli> Would adding block size(s) and weight to the block index be completely wrong? https://github.com/bitcoin/bitcoin/compare/master...jonasschnelli:2017/11/blockindex_size?expand=1
< jonasschnelli> I think only stats stuff could use it. So I'm unsure if the >8MB more ram consumption is worth it.
< jonasschnelli> For things like #5896 or #9849 it would probably required...
< gribble> https://github.com/bitcoin/bitcoin/issues/5896 | [Qt][PoC] introduce "core-pulse" by jonasschnelli · Pull Request #5896 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/9849 | Qt: Network Watch tool by luke-jr · Pull Request #9849 · bitcoin/bitcoin · GitHub
< jonasschnelli> You don't want to load a block from the disk just to get some block size charts.
< bitcoin-git> [bitcoin] practicalswift opened pull request #11749: Set m_last_block_processed to nullptr in SetNull() (master...m_last_block_processed) https://github.com/bitcoin/bitcoin/pull/11749
< nani> hello
< dcousens> jonasschnelli so many things would be great to add... it probably shouldn't be in `bitcoind` though
< Varunram> Hey guys, I'm getting an error while compiling master `Assertion failed: ((pindexFirstNeverProcessed != nullptr) == (pindex->nChainTx == 0)), function CheckBlockIndex, file validation.cpp, line 4203.` What's the problem on my side?
< luke-jr> jonasschnelli: 9849 works fine without it already\
< jeffrade> I posted a question yesterday on https://github.com/bitcoin/bitcoin/issues/3172 I need some clarification.
< jeffrade> I assume it is still relevant since not closed
< promag> jeffrade: I don't think the idea is to add new flags
< jeffrade> so should these "ping pong" transactions as they were called happen for any node that has the -testnet flag enabled?
< jeffrade> or is this just an isolated node hosted by an individual that will send these ping pong tx to the testnet network?
< promag> > hosted by an individual that will send these ping pong tx to the testnet network?
< promag> jeffrade: I think the idea is to have some cron script to do that for instance
< promag> IMHO that issue could be closed.
< jeffrade> promag: So this is nothing that will live in the repo, e.g. bitcoin/test/functional/ ?
< promag> jeffrade: no I don't think it should, but it could :D
< jeffrade> promag: Should I tag someone specific on the github issue? Sounds like it should be closed or some new requirements
< promag> I've made a comment
< jeffrade> promag: Awesome, thank you so much! Will keep and eye on it and look for something else :)
< instagibbs> uh, is abortrescan not supposed to work on a general -rescan argument, rather than importprivkey?
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11743: qa: Add multiwallet prefix test (master...Mf1711-qaMultiwallet) https://github.com/bitcoin/bitcoin/pull/11743
< bitcoin-git> [bitcoin] jamesob closed pull request #11751: Use override in CCoinsView* subclasses (master...add-override-coins) https://github.com/bitcoin/bitcoin/pull/11751
< sipa> instagibbs: -rescan is processed when loading a wallet, i don't think RPC is active then
< instagibbs> sad! ok
< bitcoin-git> [bitcoin] instagibbs opened pull request #11753: clarify abortrescan rpc use (master...abortrescanclarity) https://github.com/bitcoin/bitcoin/pull/11753
< bitcoin-git> [bitcoin] practicalswift closed pull request #11749: wallet: Set m_last_block_processed to nullptr in SetNull() (master...m_last_block_processed) https://github.com/bitcoin/bitcoin/pull/11749
< bitcoin-git> [bitcoin] practicalswift closed pull request #11749: wallet: Set m_last_block_processed to nullptr in SetNull() (master...m_last_block_processed) https://github.com/bitcoin/bitcoin/pull/11749
< bitcoin-git> [bitcoin] practicalswift opened pull request #11754: Add missing cs_wallet locks when accessing m_last_block_processed (master...missing-m_last_block_processed-locks) https://github.com/bitcoin/bitcoin/pull/11754
< cluelessperson> Can someone link me to the node protocol used?
< cluelessperson> I'm trying to figure how the communication is built?
< sipa> cluelessperson: bitcoin.org developer documentation is pretty good
< jonasschnelli> cluelessperson: this is also a handy resource (seems up to date): https://en.bitcoin.it/wiki/Protocol_documentation
< sipa> otherwise, several implementations exist, and several BIPs describe protocol changes (but they don't fully specify it), including 14, 31, 35, 37, 61, 111, 130, 133, 144
< Antarctica> Everyone's wallet. ECDSA Public Key: 1Fjh9tUjTWYz5cuCqixUa9o7NaQQDz7twd ECDSA Private Key: 5KEnS3QYkja72J7JBz1cUdLvkVsJqVV7pQTdMF5dF5xjEorkB4i
< Antarctica> They are already priceless
< cluelessperson> ?