<@wumpus>
why... create a PR like that without any motivation whatsoever
< Randolf>
Looks like a bit of debug output added, plus changing use from a constant to a variable. Using the constant seems to be a better choice to me because with the constant it's more clear what the compression mode is.
< Randolf>
Oh, hang on, it's not debug output. It's getting rid of a warning. This PR seems pointless indeed.
< ossifrage>
Bloody fios had an outage and I lost my IP again, so much for having a well connected node :-(
< gmaxwell>
he's saying the der format private key always wrote the embedded pubkey in compressed form.
< gmaxwell>
I think.
< gmaxwell>
Though considering thats just used inside the wallet and the compressed form is smaller, I think that the current behavior is desirable.
< gmaxwell>
but perhaps he knows some reason why it isn't.
<@wumpus>
let's hope they manage to explain
< * wumpus>
feels like killing account system today, let's get some reviews on #13825
< wumpus>
that PR is pretty much dead code removal (the actual functionality was already removed in an earlier PR) so it should be a more or less easy review
< wumpus>
I still hold to my original belief at the beginning of that PR that -X=0 for *non-boolean* options is ambigious, and we should encourage -noX, but it seems the code base is moving in the other direction
< wumpus>
does
< wumpus>
"nodebuglogfile" work at all in bitcoin.conf?
< wumpus>
(no, doesn't seem to work)
< wumpus>
oh it does if you specify nodebuglogfile=1
< ken2812221_>
I am trying to switch from msvc to autotool on appveyor, hope that it won't fail with weird reason again.
< ken2812221_>
But this would drop CI for MSVC.
< ken2812221_>
I'm not sure if it is a good idea.
< wumpus>
it's just, from a maintenance perspective, that two CI testing systems that can fail for seemingly random reasons is even more frustrating then one
< wumpus>
theoretically I agree testing with MSVC good, but in practice, I end up ignoring it because most of the time the failures make no sense
< wumpus>
and it is another huge log file to scroll through :-(
< wumpus>
...slowly and sometimes crashing the browser
< wumpus>
wish that CI tools were smart enough to simply report what the problem was
< ken2812221_>
I believe we just have to clear the build cache. It will work again as well.
< ken2812221_>
I clear the cache on my appveyor project, the build result turns out green.
< ken2812221_>
Actually, we could add build matrix to both test mingw and msvc binaries. But it would be really slow.
< wumpus>
we already test mingw in travis
< wumpus>
I don't think it's necessary to do this in appveyor too
< ken2812221_>
But no functional test.
< wumpus>
that's simply because they don't pass at the moment
< wumpus>
they were enabled at some point in the past
< wumpus>
but they're flaky
< ken2812221_>
I'm trying to solve this problem on #14007
< wumpus>
if a commit does exactly the same as a previous commit and is anchored at a point before the change was done, I don't think you get a merge conflict
< wumpus>
it's still useless to do of course :)
< bitcoin-git>
[bitcoin] practicalswift opened pull request #14108: tests: Add missing locking annotations and locks (master...mapOrphanTransactions-is-guarded-by-g_cs_orphans) https://github.com/bitcoin/bitcoin/pull/14108
< hebasto>
luke-jr: regarding PR#14037: I've received your review by email but can't see it on GitHub.
< diz23>
A fascinating blog where freenode staff member Matthew mst Trout recounts his experiences of eye-raping young children https://MattSTrout.com/
< diz23>
I thought you guys might be interested in this blog by freenode staff member Bryan kloeri Ostergaard https://bryanostergaard.com/
< diz23>
With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
< sipa>
but as a topic, perhaps someone should go through the list of merged PRs in 0.17 to see if any are missing release notes
< gmaxwell>
I was going to come up with a commandline people could run which would curl the list of merged PRs and run it through shuf and head and ask everyone to look at the top bunch to see if the need release notes, but the list of merged PRs isn't up yet.
< gmaxwell>
here is an approximation: git log --since=2018-02-01 --merges | grep 'Merge #' | shuf | head
< gmaxwell>
maybe we could ask everyone in the meeting to run that and check the results against the current release notes draft and see if they get anything they think needs notes. :)
< echeveria>
/query *otr
< echeveria>
ffs.
< wumpus>
there's still a few things in #12391 too that need release notes
< kanzure>
topic: i am collecting topics for coredevtech tokyo; please submit topic suggestions to me, things that you would like to speak about, or things that you would prefer others to speak about, could be anything from source code things to BIPs to mailing list stuff, or complaints about twitter.
< wumpus>
looks like the most serious one is a possible incompatibility when going back to 0.16.2
< wumpus>
one topic I'd like to discuss is where to move tinyformat in the source tree, if we're going to do that at all, I hate it when there's two competing PRs open for something
< wumpus>
was looking at the wrong caller function
< wumpus>
the argument to RegisterListenSocket is a ListenSocket structure, which has a SOCKET and a whiltelisting flag
< promag>
me too, but then I say the line..
< promag>
*saw
< wumpus>
I only noticed it when I replaced the argument with a copy of the structure, then noticed the variable name in the compiler error didn't change
< wumpus>
phantomcircuit: so on the line below it, 2189, a ListenSocket is actually constructed with ListenSocket(hListenSocket, fWhitelisted)
< wumpus>
though I'm not sure you need to call it there at all, as RegisterListenSocket will already be called with everything in that vector it is added to
< luke-jr>
sorry I missed the meeting
< luke-jr>
would be nice if people look at and decide between the two ARM/RISC-V symbol check things - either one is a fine starting point IMO
< luke-jr>
hebasto: I deleted it because I noticed it was the binary tarball, not sources
< wumpus>
luke-jr: my vote would be little-endian only
< wumpus>
luke-jr: oh, that's not what you mean
< hebasto>
luke-jr: Thank you for clarification.
< wumpus>
yes the symbol check thing is another thing with competing PRs
< wumpus>
tbh for such scripts I care very little as long as they do what they should do
< luke-jr>
wumpus: I'm inclined to just close mine and rebase on the other one
< luke-jr>
maybe clean it up slightly (grouping the arch configurations together)
< wumpus>
yes, rebasing one on top of the other would be great and make it much easier to go ahead
< wumpus>
promag: good question...
< wumpus>
promag: I've unsubscribed from it, was kind of annoyed by the author
< phantomcircuit>
wumpus, oh snap yeah i see what it is
< wumpus>
didn't want to close it in case anyone else wanted to guide them toward getting the PR to a mergable state, as the functionality looks useful, but if it's a lost cause we probably should
< phantomcircuit>
promag, ty
< luke-jr>
I suspect a language barrier in that one
< phantomcircuit>
gmaxwell, derp
< phantomcircuit>
was the answer of course
< luke-jr>
he thought I was trying to make a joke when I said to not touch unrelated whitespace O.o
< wumpus>
yes he seems like an impossible person
< wumpus>
goes to argue against all review comments
< promag>
I guess I'll open a new one with the winextra
< luke-jr>
:x
< promag>
don't care? :D
< wumpus>
looks like either a language barrier or at the least a strong misunderstanding how contributing to open source works, that was clear from the first post
< luke-jr>
I would prefer fixing the communications and teaching him to do it right, so he doesn't think we're just a clique
< luke-jr>
(and hopefully contributes more in the future)
< wumpus>
yes, if you think there's any hope of that, that'd be preferable
< promag>
ok then, my suggestion is there
< phantomcircuit>
if select() fails we're currently setting every fd in fdsetRecv so that the loop immediately after will call recv for every node
< phantomcircuit>
that doesn't seem to make much sense
< phantomcircuit>
this logic goes back to satoshi also so ?
< wumpus>
yes, that doesn't sound very sensible to me either...
< phantomcircuit>
seems like if select() fails we should sleep for a bit and continue the loop?
< phantomcircuit>
actually it seems like every way this can fail except EINTR is basically catastrophic
< instagibbs>
I gave some technical feeback over hte last week; pretty cool to see it live :)
< grubles_>
cool stuff
< echeveria>
gmaxwell: I can see people doing this really badly.
< echeveria>
gmaxwell: it also requires that the sender can process the transaction before the HTTP request times out.
< echeveria>
gmaxwell: you can also hammer the remote to enumerate their outputs, but never submit a result.
< gmaxwell>
echeveria: hm? No. you can only learn one output from the remote per output you spend.
< gmaxwell>
You connect to the merchant and give him a valid txn ready for broadcast. He responds with an updated version that includes his output. If you don't reply, he sends the original to the network.
< echeveria>
"Doing so will invalidate the "template transaction"'s original input signatures, so the sender needs to return this "partial transaction" back to the receiver to sign. This is returned as a hex-encoded raw transaction a response to the original HTTP POST request."
< echeveria>
"The receiver is responsible in making sure the "partial transaction" returned by the sender was changed correctly (it should assume the connection has been MITM'd and act accordingly), resign its original inputs and propagates this transaction over the bitcoin network. The client must be aware that the server can reorder inputs and outputs."
< echeveria>
oh.
< echeveria>
uh. I guess so.
< phantomcircuit>
wumpus, seems like select can fail if a socket is closed or in some way broken
< phantomcircuit>
so im guessing calling recv() on every socket was some attempt to handle that?