< Tatty> I think I found an outdated version User Agent on Bitcoin Core 64 bit for Windows v0.15.0.1. I enabled 2 tor proxies, both making bidirectional connections. It happened one of the proxies contacted the other, and that's when I saw a wrong version: User Agent /Satoshi:0.14.0/
< sipa> why is that wrong?
< Tatty> I am sure because I recognize the Hidden Service, of the income connection, it is mine
< gmaxwell> Tatty: what reason do you have to believe it wasn't some other node connecting to you.
< sipa> you can't know where an hidden service connection is coming from
< gmaxwell> gives a correct useragent, so either that connection wasn't from you or you're not running what you think you are. :)
< Tatty> it says on top via and then my hidden service
< Tatty> is it possible the user agent is only wrong one one of them when using 2 tor proxies?
< Tatty> and I am sorry for insisting
< sipa> what do you mean by 2 tor proxies?
< sipa> you can only configure oe
< sipa> one
< Tatty> I run 2 different ptor proxies as allowed by Bitcoin Core
< sipa> what's your configuration like?
< Tatty> no, I have 2 configured, running and one connecting to the other as I can only set 1 externalip=
< sipa> i have no idea what you mean by that
< sipa> can you paste your config somewhere?
< Tatty> I try
< Tatty> screenshots
< sipa> that means some Tor peer connected to you via Tor
< sipa> using that ou26n... address (which is *your* onion address, not theirs)
< Tatty> YES!
< sipa> and *they* have user agent 0.14.0
< Tatty> it is my hidden service
< sipa> i know
< sipa> but that address is the onion address they are connecting TO
< sipa> i.e., yours
< Tatty> no, they are conecting to the seconf one, managed by bitcoin-qt
< sipa> that's not what it says
< sipa> all i can see is an external peer connecting to you
< Tatty> right
< Tatty> I know it connected to the 2nd tor proxy
< Tatty> by those phictures you can't know
< sipa> then i can't help you
< sipa> everything you're showing me just says there is some external peer running 0.14 that is connecting to you over tor
< Tatty> do you really want me to post unsafe tor logs?
< sipa> no
< sipa> i want you to explain me why you think my theory is wrong
< Tatty> because I know the hidden service on that picture in unkown to tor proxy #2
< gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
< Tatty> and you see a incoming connection via that hidden service
< sipa> what do you mean by tor proxy 2
< Tatty> ok, someone might be having some fun announcing my hidden service as being theirs, but the simplest solution is that tor proxy 1 contacted tor proxy 2
< sipa> what do you mean by tor proxy 1 and tor proxy 2
< Tatty> check the second picture, the one set for port 9150 instead of 9050
< sipa> are those screenshots from the same client?
< Tatty> https://ibb.co/kX50sm proxy on top = proxy 1, the other is proxy 2
< Tatty> yes they are Ionly have this one
< sipa> those settings are irrelevant
< Tatty> and I never used any version prior to this
< sipa> they're about outgoing connections
< sipa> the peer screenshot is about an incoming connection
< Tatty> correct
< sipa> so i don't understand what the problem is
< sipa> a random other peer on the internet connected to you over tor
< sipa> those two proxy settings are not relevant
< Tatty> incomming to the hidden service created by Bitcoin Core on tor proxy 2
< Tatty> ok, I give up.
< sipa> ok?
< Tatty> sorry for taking your time
< sipa> why is that not possible?
< sipa> your bitcoin client rumours its addresses to other peers, including onion addresses if it knows th
< sipa> some peer saw yours, and connected to you
< Tatty> sipa, I can't make you understand
< Tatty> one of my peers conected to one of my peers with the wrong User Agent
< Tatty> putting it simple that is what happens
< sipa> i see no evidence of that
< Tatty> you keep telling me this setting doesn't work, but it does work
< sipa> no, i'm saying this setting is not relevant
< Tatty> proxy 1 doesn't accept any incoming connection as it doesn't have any hidden service
< Tatty> only the second does and it is Bitcoin Core who creates it
< sipa> ok
< Tatty> now you say that is not possible
< sipa> no, i'm saying that you're seeing an incoming connection
< sipa> the settings you're showing me only affect outgoing connections
< Tatty> proxy= listen=1 bind= proxyrandomize=1 externalip=ou26nyghcyiwrecx.onion
< Tatty> is this what you needed?
< sipa> so, you configured your external address as ou26...
< sipa> your bitcoin node rumoured that address around
< sipa> and someone is connecting to it
< sipa> the proxy setting does not matter, it changes how outgoing connections are made
< Tatty> I see yur point
< Tatty> Iam advertising a hidden service on the wrong tor proxy
< sipa> it is advertized to all your peers, regardless of connection type
< Tatty> You helped me very much
< Tatty> thank you!
< sipa> ok!
< kallewoof> I don't even see the error in that log.
< meshcollider> kallewoof its something to do with that table diff, it runs scripts/buildtable.pl before and after your commit and then runs `if [ -n "$newdiff" ]; then echo "$newdiff"; exit 1;`
< meshcollider> Should you add an entry to README.mediawiki?
< kallewoof> Ohh, that is probably it yeah. Thanks!
< kallewoof> That was it, yep. Thanks again.
< meshcollider> Sweet :)
< eck> if any of you use fedora, I just set up a bitcoin rpm repo based mostly on the existing spec file in the contrib/ directory, feel free to help me test it or give me feedback: https://copr.fedorainfracloud.org/coprs/eklitzke/bitcoin/
< wumpus> meshcollider: nice!
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3bdf242fc68a...4db82b7aab4a
< bitcoin-git> bitcoin/master 5ff01c2 James O'Beirne: [docs] Add instructions for lcov coverage report generation
< bitcoin-git> bitcoin/master 4db82b7 Jonas Schnelli: Merge #11680: [docs] Add instructions for lcov report generation...
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #11680: [docs] Add instructions for lcov report generation (master...lcov-docs) https://github.com/bitcoin/bitcoin/pull/11680
< kallewoof> Man, running a full node with datadir on an external USB drive is really slow. Like, handshakes are timing out kind of slow.
< jonasschnelli> kallewoof: you could do a PR that would allow to keep the block files on a different "datadir"...
< jonasschnelli> That would be handy IMO
< jonasschnelli> Maybe only blocks older then 144+...
< kallewoof> Can't you just ln -s the blocks folder? I was thinking of doing that
< jonasschnelli> You want the UTXO/chainstate internal and the blocks external
< jonasschnelli> kallewoof: you can...
< jonasschnelli> but meh
< kallewoof> I actually think this might be a problem on my end, but not sure. It's way too slow to be normal behavior. I can't even addnode another full node on the same network. It times out.
< kallewoof> After running for awhile, things got faster. I don't know what was going on but it seems to have been temporary.
< jonasschnelli> kallewoof: anyways,.. that datadir split PR is still welcome. :)
< bitcoin-git> [bitcoin] eklitzke opened pull request #11690: [trivial] Fix the StartupWMClass for bitoin-qt, so gnome-shell can recognize it (master...desktop-file) https://github.com/bitcoin/bitcoin/pull/11690
< kallewoof> OK! I'll see what I can do. :) Related: I wanted to make a PR that lets you have a readonly "cache" of the blockchain in a separate folder. You can spin up more than one node very easily without having to copy entire chain if you have access to the filesystem of the first one. Would be helpful for testing things I think.
< meshcollider> You can already move conf file with -conf and #11466 splits walletdir out so soon there'll be nothing left in the datadir itself ;)
< gribble> https://github.com/bitcoin/bitcoin/issues/11466 | Specify custom wallet directory with -walletdir param by MeshCollider · Pull Request #11466 · bitcoin/bitcoin · GitHub
< kallewoof> Huh... 2017-11-15 08:37:57 - Connect 1802 transactions: 156296.66ms (86.735ms/tx, 25.606ms/txin) [270.35s]
< kallewoof> WOuld this benefit from having only blocks on external drive? I am not sure what part of the fs is used for the tx connect stuff. *checking*
< wumpus> where you put chainstate is going to have the most influence there
< jonasschnelli> Yeah.. I guess the lag comes from leveldb internals
< wumpus> the blocks directory has the block data and block index, which are relatively rarely accessed (unless -txindex)
< kallewoof> Okay, testing ln -s solution to see if it helps.
< wumpus> (and unless you're reindexing, at which point it has to go through all blocks twice, but stilll chainstate drive will be much, much more busy)
< kallewoof> I'm not
< kallewoof> Yay! 2017-11-15 08:47:24 - Connect 2033 transactions: 2525.99ms (1.242ms/tx, 0.515ms/txin) [9.74s]
< jonasschnelli> kallewoof: that's with chainstate on internal drive an ln -s of your blocks to your ext drive?
< kallewoof> Yeah
< kallewoof> 4.7GB on internal and the rest on external
< wumpus> nice!
< bitcoin-git> [bitcoin] practicalswift opened pull request #11691: rpc: Add missing lock in getblocktemplate(...). Work around Clang thread safety analysis quirks. (master...rpc-locking) https://github.com/bitcoin/bitcoin/pull/11691
< wumpus> gah, we sould create a separate issue for WFL issues
< Guest27291> hi
< Guest27291> can someone confirm segiwit2x is still execute?
< timothy> Guest27291: OT
< meshcollider> Guest27291: this is not the place, but segwit2x was called off https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html
< Guest27291> thanks.. but i still heard a lot of rumour about segwit2x which is make me confuse
< meshcollider> You should probably discuss it in #bitcoin not this channel
< Guest27291> sorry.. thanks anyway
< meshcollider> No problem :)
< bitcoin-git> [bitcoin] practicalswift opened pull request #11692: Remove unused Boost include. Move Boost include. (master...remove-boost-includes) https://github.com/bitcoin/bitcoin/pull/11692
< promag> meshcollider: hi
< meshcollider> promag: Hey :)
< promag> I'm not familiar with the dumpwallet test
< promag> let me read it
< meshcollider> The dumpwallet test basically counts the number of keys present in the file and makes sure that is the number that were generated in the wallet
< meshcollider> For the scripts part which I added, it relies on the comment to find which scripts correspond to which P2SH address we generated
< meshcollider> and then reimports to make sure the script was valid
< meshcollider> I'm looking into the GetAllReserveKeys() comment you wrote now, I'm unsure on that as I didn't change that part of it
< promag> +1 on the test
< promag> dunno why there is no lock in the RPC
< meshcollider> there is a lock on cs_wallet
< meshcollider> I commented on the PR, its on line 630
< meshcollider> Unless I misunderstood what you're referring to
< promag> f*** sorry!
< meshcollider> Heh all good :)
< promag> Missed one expand in gh
< meshcollider> So do you suggest modifying GetAllReserveKeys or is it ok since it is locked?
< meshcollider> This is the only place in the entire codebase which that function is called iirc
< promag> yes, it is fine the way it is
< meshcollider> Sweet, thanks :)
< meshcollider> promag: lol I like your thumbs_up reaction to that random "O" comment
< promag> hehe
< promag> meshcollider: I think you can remove ::GetCScripts
< promag> why not return a const reference to mapScripts?
< promag> that way you avoid a bunch of copies, set sorts and map lookups?
< meshcollider> mmm yeah true, that function is basically a C+P of CBasicKeyStore::GetKeys()
< meshcollider> Is there any disadvantage to that?
< promag> meshcollider: the only one I can see is that `cs_KeyStore` must be locked
< promag> while using/iterating the mapScripts
< promag> I would wait for someone with deeper knowledge there
< promag> but the idea is the same as GetAllReserveKeys()
< promag> but that one is protected by cs_wallet I think
< meshcollider> Yeah
< meshcollider> Ok maybe just post the idea on the PR so others can weigh in on it when they see it 👍
< bitcoin-git> [bitcoin] practicalswift closed pull request #11692: Remove unused Boost include. Move Boost include. (master...remove-boost-includes) https://github.com/bitcoin/bitcoin/pull/11692
< kgc> Hi! I have a question, sorry for interrupting, is it planned in the foreseeable future to change signrawtransaction rpc method to successfully sign an output that was sent to a P2SH-P2WSH address? I tried doing so resulted in failure.
< wumpus> kgc: hrm, I think that should just work?
< meshcollider> kgc wumpus: yep should just work, tested on
< wumpus> thanks for testing meshcollider
< wumpus> kgc: so you need to be a bit more specific about the steps you followed and the result you get
< kgc> ok, I'll give you a json request I made, give me a sec
< kgc> { "jsonrpc": "1.0", "id": "requestId", "method": "signrawtransaction", "params": [ "0200000001d6b67546a418331a5e3877d103e7c95b2e0c69a2e289ddca75383dcca53128120100000000ffffffff0198929800000000001976a914423ffad905158d1d472f5fcd5fbc6916c2fb031f88ac00000000", [ { "txid": "122831a5cc3d3875cadd89e2a2690c2e5bc9e703d177385e1a3318a44675b6d6", "vout": 1,
< kgc> ok, not the best idea...
< wumpus> better use a pastebi.. yea
< kgc> this is the response from that request
< kgc> are there some undocumented parameters I should be passing in?
< wumpus> no, there are no further parameters. Sounds like the transaction is missing the witness somehow?
< meshcollider> oh hrm
< kgc> well, it's slightly weird because if I create corresponding deposit address and import it inside bitcoin core wallet, I can send to and spend funds without anyproblems
< meshcollider> Yeah that's what I thought you were asking about initially
< wumpus> it looks like the witness was stripped from the transaction
< meshcollider> Does signtrawtransaction need a witness transaction with empty witness?
< meshcollider> Or will it add the witness itself
< kgc> Hmm, are you suggesting that createrawtransaction method somehow cut out the witness part?
< meshcollider> createrawtransaction would not create a witness transaction because it would not know it was a P2WSH address would it
< kgc> yeah, sounds legit, are there any workarounds for this except for realizing serialization myself (which I would much rather avoid)
< meshcollider> Well it shouldn't be hard to make it into a witness transaction right
< meshcollider> `02000000000101d6b67546a418331a5e3877d103e7c95b2e0c69a2e289ddca75383dcca5312812010000002322002016a91e58e02069f95ea6defba7436199658573c34d384c69779779f4500d7cacffffffff0198929800000000001976a914423ffad905158d1d472f5fcd5fbc6916c2fb031f88ac0000000000`
< meshcollider> just added marker, flag and empty witness
< wumpus> it's strange if that is needed though
< meshcollider> indeed
< wumpus> so I think we're missing something
< meshcollider> Ideally signrawtransaction should just convert the raw transaction to a witness transaction itself if the input is a witness input right
< kgc> that would be the desired behavior I guess
< wumpus> send_to_witness and create_witness_tx
< meshcollider> I looked into that, but there are no tests for P2SH-P2WSH it seems
< meshcollider> using signrawtransaction
< meshcollider> because L251-L264 notice that encode_p2sh is False
< meshcollider> Hmm actually how does it know what the redeemscript is for the P2WSH part
< meshcollider> you only pass in the P2SH redeemscript aye
< kgc> these are the parameters I've available: https://pastebin.com/TE1LrR44 should I be passing in as a redeem script something other than: 002016a91e58e02069f95ea6defba7436199658573c34d384c69779779f4500d7cac
< meshcollider> Yeah see you give it `002016a91e58e02069f95ea6defba7436199658573c34d384c69779779f4500d7cac` which is the redeemScript for the P2SH wrapper, but then it must not know what the redeemscript for the internal `16a91e58e02069f95ea6defba7436199658573c34d384c69779779f4500d7cac` is
< meshcollider> which is what hex=...
< meshcollider> but I don't know how to pass that in, no :/
< kgc> I'm confused, then what is it expecting as the redeem script parameter
< meshcollider> I would think what you did was correct, maybe it really isn't supported without importing the script into the wallet... I would wait for someone more experienced than me to say for sure though
< kgc> well the very least I got the address generation part right :D hopefully someone can shed some light on it, because implementing tx serialization/deserialization/signing and maintaining it would be painful for me
< kgc> then I might as well start contributing to bitcoinj project on my spare time (which I don't have)
< aj> MarcoFalke: #11646 was merged, so it shouldn't be labelled up for grabs, should it?
< gribble> https://github.com/bitcoin/bitcoin/issues/11646 | Require a steady clock for bench with at least micro precision by TheBlueMatt · Pull Request #11646 · bitcoin/bitcoin · GitHub
< meshcollider> aj: might be related to the comment
< kgc> should I open an issue on the github so it doesn't get lost?
< meshcollider> kgc: someone like sipa will probably be able to clarify things when he is online :)
< meshcollider> Yes I think an issue is a good idea
< kgc> ok, will do that, thank you for helping out :)
< meshcollider> There should be a way to pass scripts in as well as private keys
< meshcollider> kgc: in the mean time, you could just import the witness redeem script into your wallet I think :)
< wumpus> aj: I see now, it's merged but there was a mistake in it
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4db82b7aab4a...aca77a4d58c6
< bitcoin-git> bitcoin/master 63c2d83 practicalswift: Explicitly state assumption that state.m_chain_sync.m_work_header != nullptr in ConsiderEviction...
< bitcoin-git> bitcoin/master aca77a4 Wladimir J. van der Laan: Merge #11655: net: Assert state.m_chain_sync.m_work_header in ConsiderEviction...
< bitcoin-git> [bitcoin] laanwj closed pull request #11655: net: Assert state.m_chain_sync.m_work_header in ConsiderEviction (master...m_chain_sync.m_work_header) https://github.com/bitcoin/bitcoin/pull/11655
< JackH> how can I dump privkey on segwit addresses? I get an error when doing dumpprivkey
< JackH> from the one topic I read, since it is a p2sh script, there is no address, thus I cannot dump privkey? but how can I otherwise get the privkey for the inputs?
< wumpus> you probably added the witness address using addwitnessaddress?
< wumpus> that won't add a private key
< JackH> so how do I get access to the inputs? basically I am looking to do a child pays for parent for some stuck txs
< JackH> and I wanted to import the privkey into electrum
< JackH> or is there a better way?
< wumpus> I think you need the address you called addwitnessaddress with, and use dumpprivkey with that
< wumpus> that would give you a private key, though importing it in other software is not going to be easy I expect, e.g. just importing the key isn't going to make it recognize the transaction
< was> hello
< was> is someone can help me ?
< wumpus> just ask your question in the channel and if someone can help you they'll answer (or tell you where it's better to ask it)
< was> i have a wallet btc core
< was> i save wallet.dat
< was> for change another pc
< was> now how can getback ?
< was> i have wallet.dat and my password
< was> you know ?
< sipa> try #bitcoin
< promag> Are CBlockTreeDB/CDBWrapper member functions thread safe?
< wumpus> no
< wumpus> though leveldb itself is thread safe
< wumpus> we make use of that only in one place, for the Cursor in GetUTXOStats, to iterate over a snapshot of the database while the rest of the process continues
< wumpus> but none of the caching and buffering we do on top of leveldb is thread-safe
< bitcoin-git> [bitcoin] practicalswift closed pull request #11691: rpc: Add missing lock in getblocktemplate(...). Work around Clang thread safety analysis quirks. (master...rpc-locking) https://github.com/bitcoin/bitcoin/pull/11691
< promag> wumpus: ty
< bitcoin-git> [bitcoin] practicalswift opened pull request #11694: rpc: Add missing cs_main lock in getblocktemplate(...) (master...missing-lock-in-getblocktemplate) https://github.com/bitcoin/bitcoin/pull/11694
< bitcoin-git> [bitcoin] laanwj pushed 13 new commits to master: https://github.com/bitcoin/bitcoin/compare/aca77a4d58c6...927a1d7d088e
< bitcoin-git> bitcoin/master a7d3936 Matt Corallo: Add a CValidationInterface::TransactionRemovedFromMempool...
< bitcoin-git> bitcoin/master 0343676 Matt Corallo: Call TransactionRemovedFromMempool in the CScheduler thread...
< bitcoin-git> bitcoin/master 2b4b345 Matt Corallo: Add ability to assert a lock is not held in DEBUG_LOCKORDER
< bitcoin-git> [bitcoin] laanwj closed pull request #10286: Call wallet notify callbacks in scheduler thread (without cs_main) (master...2017-01-wallet-cache-inmempool-4) https://github.com/bitcoin/bitcoin/pull/10286
< promag> is practicalswift around?
< gustav> hello
< promag> guess not
< gustav> i have one app where users are given 1 bitcoin address A, they deposit btc on A and later on they withdraw on their address B. I'd like to use segwit addresses to cut down expenses on network fees (if im getting this right). now i use getnewaddress, sendmany and rawtransactions functions. would it be possible to use $addr = getnewaddress(); $segwit
< gustav> addr = addwitnessaddress($addr); to "move into segwit addresses usage"? if so would users be able to send to my app segwit address, and will my existing code be able to send payments to user addresses (non segwit and segwit)? thank you very much for all the work. now fees are insane this is why im asking. if wrong irc please tell me where to ask.
< gustav> reading online on stackoverflow and similar leads me to believe it can be done but im not sure about compatibility (user sends from non-segwit to segwit, needs to receive from segwit to non-segwit) and if addwitnessaddress is all i need. again thanks and sorry for wall of texts
< gustav> oopsie, using bitcoin-core latest version on linux (rpc, with php)
< sturles> Yes, this will make an address into a segwit address (P2SH-P2WPKH). There are multiple kinds of segwit addresses. To get the highest nenefit, you can make a P2PKWH address like this: addwitnessaddress($addr,true)
< sturles> The P2PKWH address will begin with bc1... (Bech32 format), and the sending wallet must be segwit aware to use it.
< sturles> You can only convert your own addresses. Do not attempt to convert addresses you get from other people.
< BlueMatt> note to anyone with open wallet-rpc PRs: ##10286 will likely cause a silent conflict - you will need to add calls to BlockUntilSyncedToCurrentChain!
< gribble> https://github.com/bitcoin/bitcoin/issues/10286 | Call wallet notify callbacks in scheduler thread (without cs_main) by TheBlueMatt · Pull Request #10286 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/927a1d7d088e...4ed818060ecf
< bitcoin-git> bitcoin/master 7c4f009 Russell Yanofsky: [trivial] Rename feebumper variables according to project code style...
< bitcoin-git> bitcoin/master 37bdcca Russell Yanofsky: [refactor] Make feebumper namespace...
< bitcoin-git> bitcoin/master aed1d90 Russell Yanofsky: [wallet] Change feebumper from class to functions...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10600: Make feebumper class stateless (master...pr/ipc-bump) https://github.com/bitcoin/bitcoin/pull/10600
< jonasschnelli> Thanks BlueMatt for the info
< luke-jr> BlueMatt: I wonder if there's a good way to make builds fail if they're incompatible
< luke-jr> though I can't think of anything obvious
< BlueMatt> I mean its kinda a manual thing to figure out if a given RPC needs the block
< luke-jr> BlueMatt: right, but we could fail everything until some change is made to indicate one way or the other
< BlueMatt> that seems like overkill? I mean as long as people pay attention when merging wallet rpc changes in the same way that we will need to in the future
< luke-jr> dunno
< luke-jr> incompatible changes breaking stuff is generally a good idea to avoid bug
< BlueMatt> I mean if you want to write one I'd be happy to see it, but I dont think its a huge risk
< BlueMatt> just gotta educate =D
< jonasschnelli> Do you recommend to keep MayHaveUsefulAddressDB() as it is and add the HasAllDesirableServiceFlags() at another place?
< jonasschnelli> IMO NODE_NETWORK_LIMITED should conform to MayHaveUsefulAddressDB()... or why not?
< BlueMatt> hmm?
< BlueMatt> yes, no, I was not objecting to the code changes there
< BlueMatt> at all
< BlueMatt> my complaint was about the commit message and the confusion it implies
< BlueMatt> an easy fix for which would be to change net_processing's addr handling
< BlueMatt> to check MayHaveUsefulAddressDB(services) || HasAllDesirableServiceFlags(services)
< BlueMatt> as the condition for getting an address into *our* addr db
< BlueMatt> (which, as indicated in the comment, would also not be a change in behavior, but it'd make things much clearer)
< jonasschnelli> I see..
< jonasschnelli> BlueMatt: but we should also do feeler to NODE_NETWORK_LIMITED, right?
< jonasschnelli> That's why I have changed MayHaveUsefulAddressDB()
< BlueMatt> correct
< BlueMatt> again, I think the *code* in that commit is right, the changes I was talking about would change no behavior against what you already have
< jonasschnelli> Okay with just rewording the commit message to mention the feeler thing?
< BlueMatt> wait, huh?
< BlueMatt> ohoh, yes
< BlueMatt> so the function is named MayHaveUsefulAddressDB because its primary use is "should i do a feeler to this connection"
< jonasschnelli> Or do you think adding "HasAllDesirableServiceFlags(services)" in net_processing would make the code more readable (not an acctual change)
< BlueMatt> the fact that acceptance into our addr db relies on that function is purely because its a superset of HasAllDesirableServiceFlags
< BlueMatt> my request was that you do both
< jonasschnelli> okay... got it
< jonasschnelli> BlueMatt: wait,... but HasAllDesirableServiceFlags() changes over time. Should we not add NODE_NETWORK_LIMITED to our addr man even during IBD?
< jonasschnelli> A check in net_processing (MayHaveUsefulAddressDB(services) || HasAllDesirableServiceFlags(services)) would lead to not adding NODE_NETWORK_LIMITED during IBD, right? Is that desirable?
< BlueMatt> jonasschnelli: I mean MayHaveUsefulAddressDB will always return true for either NODE_NETWORK{,_LIMITED}
< BlueMatt> jonasschnelli: so it should be fine?
< jonasschnelli> Yes. Your right...
< rabidus> no, that's your left
< rabidus> sry.
< sipa> it's your right to be left on the left
< sipa> sry.
< jonasschnelli> lol
< jonasschnelli> Anyone willing to review https://github.com/bitcoin/bitcoin/pull/11281/files?w=1 ?
< jonasschnelli> #11281
< gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid pemanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
< jonasschnelli> (use ?w=1)
< bitcoin-git> [bitcoin] jnewbery opened pull request #11697: [trivial] remove trailing whitespace in streams.h (master...streams_trailing_whitespace) https://github.com/bitcoin/bitcoin/pull/11697
< meshcollider> wumpus: #11651 is ready to merge I think
< gribble> https://github.com/bitcoin/bitcoin/issues/11651 | refactor: Make all #includes relative to project root (laanwj, MeshCollider, ryanofsky) by MeshCollider · Pull Request #11651 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4ed818060ecf...f0c1f8abb018
< bitcoin-git> bitcoin/master b077fe9 Evan Klitzke: fix the StartupWMClass for bitoin-qt, so gnome-shell can recognize it
< bitcoin-git> bitcoin/master f0c1f8a MarcoFalke: Merge #11690: [trivial] Fix the StartupWMClass for bitoin-qt, so gnome-shell can recognize it...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11690: [trivial] Fix the StartupWMClass for bitoin-qt, so gnome-shell can recognize it (master...desktop-file) https://github.com/bitcoin/bitcoin/pull/11690
< bitcoin-git> [bitcoin] lmlsna opened pull request #11698: [Docs] [Qt] RPC-Console nested commands documentation (master...doc-rpc-console) https://github.com/bitcoin/bitcoin/pull/11698
< go1111111> I'm experiencing a fairly painful UX issue with Core. I'm probably "using it wrong", but I wanted to describe my problem in case it influences development, and also see if there's a workaround:
< go1111111> I have several different wallet files, with different passwords. I rename them 'wallet.dat' as needed. I also recently started pruning my node. These two things don't work together well, as whenever the node is given a wallet with new addresses and it thinks it might be missing info, it wants to re-download the entire blockchain
< go1111111> so, i essentially have to redownload and revalidate the entire blockchain for every wallet (it is possible to be smarter about this by taking snapshots, but it's cumbersome). Is there a workaround to that?
< sipa> are you using multiwallet? you can load all wallets at once
< bitcoin-git> [bitcoin] jnewbery opened pull request #11699: [travis-ci] Only run linters on Pull Requests (master...lint_only_prs) https://github.com/bitcoin/bitcoin/pull/11699
< bitcoin-git> [bitcoin] jnewbery closed pull request #11697: [trivial] remove trailing whitespace in streams.h (master...streams_trailing_whitespace) https://github.com/bitcoin/bitcoin/pull/11697
< go1111111> Oh, wasn't aware of that. I'll look into it -- thanks! My other problem: I'm about 40% of the way through validating the blockchain, but all the inputs I want to spend have already been seen by the node, so I'd like to be able to broadcast a tx even though the node itself doesn't know that inputs are unspent. Is there a better way to do this other than using createrawtransaction?
< go1111111> I'd like to take advantage of the transaction construction of the UI to avoid errors, but also don't want to wait another 6 hours..
< sipa> you can construct a transaction as soon as your node knows about the outputs
< sipa> however, if you would construct a transaction that spends inputs which happen to be already spent in the chain, the result will be invalid (and you'll need to use abandontransaction to fix things)
< go1111111> interesting. that's how I wanted it to work, but when I construct my tx in the UI and click 'send', the UI doesn't respond at all. I expect to be prompted for my pw. Now that I know this is unexpected i'll try some variations to see if I can get it to work. thanks
< sipa> i'm unfamiliar with the GUI, but that does sound like a bug
< sipa> or at least something that requires more accurate information
< go1111111> it seems to relate to coin-control. I get the expected behavior when I don't manually select the inputs
< go1111111> wait no, that's wrong.. I'll be back when/if I have a proper bug report. thanks for the help.
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f0c1f8abb018...54aedc013744
< bitcoin-git> bitcoin/master ea3f363 Matt Corallo: Make ISSUE_TEMPLATE a bit shorter, mention hardware tests
< bitcoin-git> bitcoin/master 54aedc0 MarcoFalke: Merge #11686: Make ISSUE_TEMPLATE a bit shorter, mention hardware tests...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11686: Make ISSUE_TEMPLATE a bit shorter, mention hardware tests (master...2017-11-shorter-default-issue) https://github.com/bitcoin/bitcoin/pull/11686