< 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
< 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.
< 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
< 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
< 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
< 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