< phantomcircuit> anybody know why we sleep in ThreadSocketHandler when select() fails ?
< phantomcircuit> (it's all the way back to satoshi so cant exactly ask the author)
< gmaxwell> presumably to avoid slamming it when it fails under the assumption that if it fails its not going to stop failing for a bit.
< phantomcircuit> gmaxwell, it seems like basically every way it can fail except EINTR is a catastrophic failure and should just exit
< phantomcircuit> other things are like you gave it an invalid fd which should never happen
< sipa> phantomcircuit: well, is it triggering for you?
< phantomcircuit> sipa, no and i cant remember ever seeing "socket select error" in logs
< phantomcircuit> quick split up and search debug.log's far and wide
< gmaxwell> can we try removing +r again, I just couldn't join for a while because freenode bumped me and nickserv was down
<@sipa> let's see
< leishman> I had a node running 0.16.2 with a txindex. I updated the binary to 0.17rc2 and when starting up bitcoind it seems to hang on "Upgrading txindex database... [0%]"
< leishman> I'm not sure how long this is expected to take, but I've seen no progress displayed after 5-10 minutes
< leishman> I'm assuming this has to do with the changes to the txindex in 0.17
< leishman> ok got 10% progress after 10 minutes
< leishman> perhaps we should warn users that an upgrade for a node with a txindex could end up taking a while
< sipa> leishman_: do the release notes not say anything about that? if so, indeed
< leishman_> I see in jimpos PR here (https://github.com/bitcoin/bitcoin/pull/13033) that it was tested. What kind of migration times did others see?
< warren> leishman_: what kind of hardware?
< leishman_> warren: Intel J1900 Quad Core. 4GB ram, HDD
< leishman_> i'm at 22% through the migration after about 30 minutes.
< bitcoin-git> [bitcoin] osbc opened pull request #14098: Dev (master...dev) https://github.com/bitcoin/bitcoin/pull/14098
< bitcoin-git> [bitcoin] osbc closed pull request #14098: Dev (master...dev) https://github.com/bitcoin/bitcoin/pull/14098
< wumpus> yessss @ bitcoin-git
< bitcoin-git> [bitcoin] osbc opened pull request #14099: Dev (master...dev) https://github.com/bitcoin/bitcoin/pull/14099
< bitcoin-git> [bitcoin] osbc closed pull request #14099: Dev (master...dev) https://github.com/bitcoin/bitcoin/pull/14099
< bitcoin-git> [bitcoin] laanwj opened pull request #14100: doc: Change documentation for =0 for non-boolean options (master...2018_08_nodoc) https://github.com/bitcoin/bitcoin/pull/14100
< wumpus> phantomcircuit: please be really ,really careful about making things a catastrophic failure in network code
< wumpus> there's a huge chance of accidentally creating DoS vectors
< wumpus> (though, looking at the man page of select() I tend to agree; not sure it's the same on non-POSIX platforms though, select on windows is a different beast)
< zura_> Start
< wumpus> !!!
< gribble> Error: "!!" is not a valid command.
< lightningbot> wumpus: Error: "!" is not a valid command.
< zura_> Mulai
< wumpus> STOP
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/13887f41f229...2ddce35abcb8
< bitcoin-git> bitcoin/master 1661a47 Chun Kuan Lee: add unicode compatible file_lock for Windows...
< bitcoin-git> bitcoin/master 2ddce35 Wladimir J. van der Laan: Merge #13862: utils: drop boost::interprocess::file_lock...
< Zura_>
< bitcoin-git> [bitcoin] laanwj closed pull request #13862: utils: drop boost::interprocess::file_lock (master...custom-filelock) https://github.com/bitcoin/bitcoin/pull/13862
< bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/2ddce35abcb8...5924dadc2f2d
< bitcoin-git> bitcoin/master e2ba043 251: Implements ParseNetwork unit test....
< bitcoin-git> bitcoin/master 7a208d9 251: Implements custom tolower and toupper functions....
< bitcoin-git> bitcoin/master b193d5a 251: Removes the Boost case_conv.hpp dependency....
< bitcoin-git> [bitcoin] laanwj closed pull request #13671: Remove the boost/algorithm/string/case_conv.hpp dependency (master...patch/remove_boost_case_conv.hpp) https://github.com/bitcoin/bitcoin/pull/13671
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5924dadc2f2d...b0eb8f7ed43e
< bitcoin-git> bitcoin/master 1d9aa00 Ben Woosley: Explicitly initialize prevector _union
< bitcoin-git> bitcoin/master b0eb8f7 Wladimir J. van der Laan: Merge #14028: Explicitly initialize prevector _union...
< bitcoin-git> [bitcoin] laanwj closed pull request #14028: Explicitly initialize prevector _union (master...prevector-explicit-initialization) https://github.com/bitcoin/bitcoin/pull/14028
<@wumpus> can we please make a decision on what to to with tinyformat? either #13846 or #13845 or leave it as it is and close both
< gribble> https://github.com/bitcoin/bitcoin/issues/13846 | Move src/tinyformat.h to src/tinyformat/tinyformat.h by Empact · Pull Request #13846 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13845 | Include tinyformat as a subtree by Empact · Pull Request #13845 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b0eb8f7ed43e...1361f8babcc1
< bitcoin-git> bitcoin/master 6af6d9b João Barbosa: test: Add tests for RPC help
< bitcoin-git> bitcoin/master 1361f8b MarcoFalke: Merge #14020: Add tests for RPC help...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #14020: Add tests for RPC help (master...2018-08-test-help) https://github.com/bitcoin/bitcoin/pull/14020
< bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/1361f8babcc1...888acefa5ee1
< bitcoin-git> bitcoin/master ddd395f MarcoFalke: Mark CTxMemPoolEntry members that should not be modified const
< bitcoin-git> bitcoin/master fe5c497 MarcoFalke: tx pool: Use the entry's hash instead of the one passed to addUnchecked
< bitcoin-git> bitcoin/master fa58777 MarcoFalke: scripted-diff: Remove unused first argument to addUnchecked...
< bitcoin-git> [bitcoin] laanwj closed pull request #13792: tx pool: Avoid passing redundant hash into addUnchecked (scripted-diff) (master...Mf1808-constTxPoolEntries) https://github.com/bitcoin/bitcoin/pull/13792
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/888acefa5ee1...4e9a6f87b7d2
< bitcoin-git> bitcoin/master fa309dc MarcoFalke: validation: Log FormatStateMessage on ConnectBlock error in ConnectTip
< bitcoin-git> bitcoin/master 4e9a6f8 Wladimir J. van der Laan: Merge #14097: validation: Log FormatStateMessage on ConnectBlock error in ConnectTip...
< bitcoin-git> [bitcoin] laanwj closed pull request #14097: validation: Log FormatStateMessage on ConnectBlock error in ConnectTip (master...Mf1808-validationLogError) https://github.com/bitcoin/bitcoin/pull/14097
< bitcoin-git> [bitcoin] ryanofsky closed pull request #9381: Remove CWalletTx merging logic from AddToWallet (master...pr/atw-nomerge) https://github.com/bitcoin/bitcoin/pull/9381
< leishman> I added an update to the wiki with a note about the txindex db migration: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.17.0-Release-notes#how-to-upgrade
< sipa> leishman: sgtm
< sipa> also, i notice the release notes don't mention scantxoutset yet
< sipa> (or i'm missing it)
< leishman> yeah I don't see that either
< marcinja> is getblockstats also new in 0.17?
< sipa> i think so!
< leishman> marcinja: is your feerate percentile stuff included in that as well?
< marcinja> leishman: yeah I think that change is considered a bug fix for getblockstats
< leishman> dope! Great work on that btw
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #14101: qa: Use named args in validation acceptance tests (master...Mf1808-qaNamedArgsAcceptance) https://github.com/bitcoin/bitcoin/pull/14101
< jonasschnelli> luke-jr: I guess its good to know which peer supports what version of the p2p protocol _before_ you connect (in case of a non-compatible protocol).
< jonasschnelli> luke-jr: but dropping NODE_ENCRYPTED is possible... you can just try to perform the v2 handshake and reconnect (&continue with v1 protocol) if failed.
< sipa> that still requires remembering whether or not encryption succeeded, though
< luke-jr> jonasschnelli: why can't the handshake occur over v1?
< jonasschnelli> luke-jr: we would have to drag the legacy v1 protocol always with us
< jonasschnelli> Assume new software doesn't want to adopt the v1 protocol
< luke-jr> yes, so? we need that anyway
< luke-jr> it could be some minimal subset
< jonasschnelli> Also, the v2 handshake doesn't reveal "bitcoin traffic" (not very DPI resistant though)
< luke-jr> hm
< luke-jr> also, you don't *know* service bits until you connect
< luke-jr> so this seems an issue either way
< jonasschnelli> luke-jr: IMO it doesn't make sense to handshake in v1 then upgrade to v2
< jonasschnelli> luke-jr: yes. Same with NODE_BLOOM, etc.
< jonasschnelli> But NODE_ENCRYPTED is something you lear if its working not from the VERSION message.:)
< jonasschnelli> *learn
< luke-jr> you get a guess at best
< jonasschnelli> Yes. Same witn NODE_NETWORK
< luke-jr> for bloom, that's still useful. not so much for encrpyted IMO
< sipa> luke-jr: you don't want to negotiate in v1 first
< sipa> that would defeat the purpose of not being recognizable as bitcoin traffic
< luke-jr> sipa: okay, but that problem is unrelated to the service bit
< jonasschnelli> What sipa said with the disclaimer, that censorship-resistant is not the goal of BIP151
< sipa> luke-jr: then what do you suggest instead? always first try v2 negotiation, and disconnect/reconnect if it fails?
< sipa> luke-jr: that seems a gratuitous waste of time
< luke-jr> I'm not sure.
< luke-jr> probably not a waste of time long-term, though, considering that 99% of nodes run Core now :/
< sipa> i think this is a pretty good match for a service bit
< sipa> it's a property of the node itself, can be rumoured over the network, and is not a disaster if it's wrong
< sipa>
< jonasschnelli> sipa: for the ChaCha20Poly1305, do you think its sane to remove the second length-encryption key (chacha round) and instead use 4 bytes of the poly1305 key chacha round?
< sipa> jonasschnelli: i'd rather keep the two encryption streams separate, but just treat them as streams
< sipa> rather than reset the iv for every packet
< sipa> oh, i see
< sipa> you're saying instead use the auth's stream for the length encrpyption; hmm
< jonasschnelli> yes
< jonasschnelli> I'm not going to mess with the sequence number as IV
< jonasschnelli> there is currently an extra round for the 4bytes length: https://github.com/bitcoin/bitcoin/pull/14050/files#diff-58a94ae53d4f04a57e9dc33014a679eaR70
< luke-jr> sipa: but there's no reason for nodes to care in general
< sipa> luke-jr: i don't understand why not
< sipa> you need to know whhich protocol to use - otherwise you always have to try both
< echeveria> or bind a different port.
< sipa> plus i guess at some point nodes may start preferring encrypted connections
< echeveria> normal peers don’t use non 8333 ports ever.
< sipa> echeveria: in which case you still need a service flags to indicate that the other port is open
< echeveria> yep
< luke-jr> actually, protocol version might make sense for this?
< sipa> luke-jr: protocop version isn't known before connecting
< luke-jr> if we plan to deprecate the current one
< echeveria> luke-jr: key
< echeveria> kek
< luke-jr> I thought it was with the version messages, no?
< sipa> luke-jr: it's not in addr messages
< luke-jr> oh
< sipa> and the version message is only after setting up the encrypted connection
< luke-jr> well, whatever. I guess we can always "de allocate" it later if the old protocol is abandoned
< luke-jr> and we're not exactly short on service bits
< sipa> exactly
< gmaxwell> sipa: using the auth's stream for the length is apparently something the openssh things author considered but didn't so they could use unmodified library functions for the TLS thing. This seems to be a pretty weak argument for slowing down short messages by 33%.
< luke-jr> I guess I just see service bits more for the make-it-or-break-it type stuff, where you will drop the peer entirely if they don't have it
< gmaxwell> "For more information on output descriptors, see the documentation at TODO
< gmaxwell> "
< sipa> luke-jr: well, it is; if you get it wrong, you need to disconnect (at which point you can choose to start over)
< sipa> gmaxwell: seems i forgot about that, and people didn't review the rpc help text changes...
< gmaxwell> the help text there is actually sufficient to use the function.
< sipa> it doesn't explain all the features, though
< gmaxwell> thats true, but my point was that we can probably just remove that line for now.
< jonasschnelli> gmaxwell: do you have a link to the openssh protocol discussion of that auth-stream thing?
< gmaxwell> I linked sipa to it the other day, uh.. have to go searching since my irc client has been restarted.
< sipa> gmaxwell: I have a PR that adds documentation and changes tge link
< sipa> i thought that's why you rought it up
< sipa> (sorry, phone in car typing)
< jonasschnelli> sipa: I'm not your mother, but that sounds dangerous. :)
< sipa> jonasschnelli: i'm ot driving :D
< sipa> *not
< gmaxwell> sipa: oh no, I brought it up because I was using the rpc. :P
< jonasschnelli> huh*.. glad you don't
< sipa> #14096
< gribble> https://github.com/bitcoin/bitcoin/issues/14096 | Add reference documentation for descriptors language by sipa · Pull Request #14096 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #14083: bench: Fix thread sanitizer issue in AssembleBlock benchmark (master...Mf1808-benchAssembleBlockThread) https://github.com/bitcoin/bitcoin/pull/14083
< reza> Hey everyone.
< reza> I had an idea for a Bitcoin wallet, i’d like to hear your thoughts about it.
< reza> To summarise, this wallet is a P2P-Multi-Sig wallet. Meaning that, Alice and Bob connect to each other and a multi-sig wallet is created between them. Whenever Alice or Bob wants to move the funds from that multi-sig they send each other an invoice which then they can approve or disapprove.
< reza> Thoughts?
< promag> reza: this channel is bitcoin-core specific
< promag> I mean, specific to development of bitcoin-core
< reza> ok cool, thanks anyway