< bitcoin-git> [bitcoin] fingera opened pull request #14102: export der always compressed (master...3-export-der) https://github.com/bitcoin/bitcoin/pull/14102
<@wumpus> huh
<@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
< gribble> https://github.com/bitcoin/bitcoin/issues/13825 | [wallet] Kill accounts by jnewbery · Pull Request #13825 · bitcoin/bitcoin · GitHub
< 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
< jonasschnelli> wumpus: kill it!
< bitcoin-git> [bitcoin] practicalswift opened pull request #14103: Fix broken Doxygen comments (master...doxygen-cleanups) https://github.com/bitcoin/bitcoin/pull/14103
< wumpus> jonasschnelli: ack it please :)
< jonasschnelli> wumpus: I did my utACK (hope that is enought)
< wumpus> jonasschnelli: oh! hadn't seen yet
< jonasschnelli> Greg did also
< wumpus> appveyor is doing its thing again (failing on every PR)
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4e9a6f87b7d2...be301a577776
< bitcoin-git> bitcoin/master 0e534d4 practicalswift: Fix incorrect Doxygen comments
< bitcoin-git> bitcoin/master be301a5 Wladimir J. van der Laan: Merge #14103: docs: Fix broken Doxygen comments...
< bitcoin-git> [bitcoin] laanwj closed pull request #14103: docs: Fix broken Doxygen comments (master...doxygen-cleanups) https://github.com/bitcoin/bitcoin/pull/14103
< wumpus> okay, we should definitely discuss -noX versus -X=0 in the meeting, this is driving me crazy
< wumpus> #14100
< gribble> https://github.com/bitcoin/bitcoin/issues/14100 | doc: Change documentation for =0 for non-boolean options by laanwj · Pull Request #14100 · bitcoin/bitcoin · GitHub
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/14007 | tests: Run functional test on Windows by ken2812221 · Pull Request #14007 · bitcoin/bitcoin · GitHub
< wumpus> okay on travis they ran in wine, instead of windows
< ken2812221_> Yes, we should test it on real Windows.
< wumpus> but yes mingw on windows is really, really slow
< wumpus> (in compile time)
< wumpus> anyhow if clearing the cache works, let's do that
< ken2812221_> https://github.com/krlmlr/r-appveyor/issues/98#issuecomment-395123720 I believe that this is the easiest way to clear cache, appveyor does not have "clear cache" button.
< wumpus> ooh apparently I can log in as drahtbot into appveyor
< wumpus> maybe it means I can do things like clear the cache now
< wumpus> ok thank you
< wumpus> hehe the mozilla javascript console blocks pasting by default, with a warning about scams, makes sense
< wumpus> so in my case this would be https://ci.appveyor.com/api/projects/DrahtBot/bitcoin/buildcache , hope it worked
< ken2812221_> Seems it does not work, maybe it should be done by MarcoFalke
< wumpus> sigh--
< bitcoin-git> [bitcoin] laanwj opened pull request #14105: util: Report parse errors in configuration file (master...2018_08_parse_error_reporting) https://github.com/bitcoin/bitcoin/pull/14105
< bitcoin-git> [bitcoin] mkjekk opened pull request #14106: 0.17 (master...0.17) https://github.com/bitcoin/bitcoin/pull/14106
< bitcoin-git> [bitcoin] laanwj closed pull request #14106: 0.17 (master...0.17) https://github.com/bitcoin/bitcoin/pull/14106
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/be301a577776...6c7cfc8da68a
< bitcoin-git> bitcoin/master db5e9d3 practicalswift: Add missing locks (cs_args)
< bitcoin-git> bitcoin/master d58dc9f practicalswift: Add lock annotations (cs_args)
< bitcoin-git> bitcoin/master 1e29379 practicalswift: Fix potential deadlock
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13126: util: Add Clang thread safety annotations for variables guarded by cs_args (master...guarded-by-cs_args) https://github.com/bitcoin/bitcoin/pull/13126
< ken2812221_> OK, appveyor cache cleared.
< bitcoin-git> [bitcoin] ken2812221 closed pull request #13515: travis: avoid timeout without saving caches, also enable all qt (master...travis_qt) https://github.com/bitcoin/bitcoin/pull/13515
< bitcoin-git> [bitcoin] practicalswift opened pull request #14107: wallet: Remove unused function GetLabelDestination (master...deadc0de) https://github.com/bitcoin/bitcoin/pull/14107
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6c7cfc8da68a...07033a8f9197
< bitcoin-git> bitcoin/master c9c32e6 John Newbery: [wallet] Kill accounts...
< bitcoin-git> bitcoin/master 07033a8 Wladimir J. van der Laan: Merge #13825: [wallet] Kill accounts...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #14107: wallet: Remove unused function GetLabelDestination (master...deadc0de) https://github.com/bitcoin/bitcoin/pull/14107
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13825: [wallet] Kill accounts (master...kill_accounts) https://github.com/bitcoin/bitcoin/pull/13825
< instagibbs> MarcoFalke, sorry for noob but why you close #14107 ? Doesn't say there's a merge conflict?
< gribble> https://github.com/bitcoin/bitcoin/issues/14107 | wallet: Remove unused function GetLabelDestination by practicalswift · Pull Request #14107 · bitcoin/bitcoin · GitHub
< instagibbs> ah ok
< 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.
< gribble> https://github.com/bitcoin/bitcoin/issues/14037 | Add README.md to linux release tarballs by hebasto · Pull Request #14037 · bitcoin/bitcoin · 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/
< diz23> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
< sipa> i won't attend the meeting today
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/12391 | TODO for release notes 0.17.0 · Issue #12391 · bitcoin/bitcoin · GitHub
< midnightmagic> I know I've asked this before, but can anyone tell me if the meta-data in the github instance is being archived somewhere (still)?
< phantomcircuit> while implementing logic for poll() i've run into an interesting issue
< phantomcircuit> with net.cpp:2188:39: error: no matching function for call to ‘CConnman::RegisterListenSocket(SOCKET&)’
< phantomcircuit> but RegisterListenSocket(hListenSocket); hListenSocket is actually a struct ListenSocket
< wumpus> midnightmagic: yes, it is, at git@github.com:zw/bitcoin-gh-meta.git
< echeveria> midnightmagic: wumpus: the whole of github is archived in real time.
< wumpus> echeveria: nice, that could be useful too I guess
< wumpus> the more mirrors the better
< midnightmagic> wumpus: thank you
< midnightmagic> echeveria: thank you
< midnightmagic> heh heh heh!
< wumpus> and yes, I'll add the PR list and author list into the preliminary release notes soon
< promag> meeting?
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Aug 30 19:01:18 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< jonasschnelli> \o
< jonasschnelli> \o
< promag> howdy
< jonasschnelli> o/
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
< kanzure> hi.
< achow101> hi
< meshcollider> hi
< wumpus> so re: 0.17.0 it seems we still have a few issues
< gmaxwell> Hi.
< 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> #14048
< gribble> https://github.com/bitcoin/bitcoin/issues/14048 | 0.16.2 binary gives error after latest compiled client has run · Issue #14048 · bitcoin/bitcoin · GitHub
< instagibbs> hi
< achow101> wasn't there a change to how txindex is handled now?
< gmaxwell> I no longer think #14109 is blocking, it appears to be a measurement artifact. pages in the cache in read only mmaps show up in res.
< gribble> https://github.com/bitcoin/bitcoin/issues/14109 | ibd memory usage up in 0.17 · Issue #14109 · bitcoin/bitcoin · GitHub
< wumpus> there's also possible working memory use increase during IBD ( #14109)
< gribble> https://github.com/bitcoin/bitcoin/issues/14109 | ibd memory usage up in 0.17 · Issue #14109 · bitcoin/bitcoin · GitHub
< achow101> so that's probably what is causing the problem
< wumpus> gmaxwell: good to know!
< jonasschnelli> Also #14104 is eventually something we want to take a look (or at least mention in the RN)
< gribble> https://github.com/bitcoin/bitcoin/issues/14104 | 0.17.2rc issue (standardness change for bare multisig) · Issue #14104 · bitcoin/bitcoin · GitHub
< wumpus> ok tagging that with 0.17.0
< jonasschnelli> sipas script template remove (#13194) caused a tiny isStandard different for bare multisig
< gribble> https://github.com/bitcoin/bitcoin/issues/13194 | Remove template matching and pseudo opcodes by sipa · Pull Request #13194 · bitcoin/bitcoin · GitHub
< wumpus> hadn't seen that one but it looks like it is expected?
< wumpus> ah
< jonasschnelli> Invalid pubkeys with the right size was standard until 0.17
< jonasschnelli> Now, it checks the first byte (compress, uncompressed, etc.). Before it just had to be 33 or 65 bytes.
< gmaxwell> jonasschnelli: what does invalid here mean? the initial byte isn't ne of the right flags?
< gmaxwell> okay.
< wumpus> I'd say the new way is better then?
< gmaxwell> (just making sure we weren't doing the on-the-curve check, since thats slow)
< jonasschnelli> It looks like people have stuffed 33 bytes into a bare multisig for some unknown reason
< jonasschnelli> (probably to make some data public available ala OP_RETURN)
< wumpus> well you can't avoid people stuffing other things in them, but making sure they look like valid keys makes some sense
< gmaxwell> The new way is a reasonable behavior. it will inhibit some kind of non-op-return store-data-in-the-utxo set behavior.
< jonasschnelli> heh. Yes. I think we should just mention that in the release notes
< wumpus> right
< gmaxwell> yes, should be release noted.
< wumpus> posted it in #12391
< gribble> https://github.com/bitcoin/bitcoin/issues/12391 | TODO for release notes 0.17.0 · Issue #12391 · bitcoin/bitcoin · GitHub
< jonasschnelli> For #14048, I think its acceptable to require to create the txindex again when downgrade from 17 to 16...
< gribble> https://github.com/bitcoin/bitcoin/issues/14048 | 0.16.2 binary gives error after latest compiled client has run · Issue #14048 · bitcoin/bitcoin · GitHub
< gmaxwell> jonasschnelli: I agree, but it needs to be release noted.
< wumpus> oh this is because of the txindex update? of course, gah
< wumpus> what is the PR that changed the txindex?
< jonasschnelli> #13033
< gribble> https://github.com/bitcoin/bitcoin/issues/13033 | Build txindex in parallel with validation by jimpo · Pull Request #13033 · bitcoin/bitcoin · GitHub
< jonasschnelli> (i think)
< promag> also related #13243
< gribble> https://github.com/bitcoin/bitcoin/issues/13243 | Make reusable base class for auxiliary indices by jimpo · Pull Request #13243 · bitcoin/bitcoin · GitHub
< willyko_> yaas finally got my gitian build to work
< wumpus> ok added
< wumpus> for the rest there is some documentation confusion which I *try* to clear up in #14100
< gribble> https://github.com/bitcoin/bitcoin/issues/14100 | doc: Change documentation for =0 for non-boolean options by laanwj · Pull Request #14100 · bitcoin/bitcoin · GitHub
< wumpus> at least if I do understand it correctly
< jonasschnelli> Added a new minor issue for 0.17 #14114
< gribble> https://github.com/bitcoin/bitcoin/issues/14114 | scantxoutset help about descriptors refers to TODO document · Issue #14114 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< wumpus> oops
< gmaxwell> pieter opened a PR to fill in the docs.
< gmaxwell> #14096
< gribble> https://github.com/bitcoin/bitcoin/issues/14096 | Add reference documentation for descriptors language by sipa · Pull Request #14096 · bitcoin/bitcoin · GitHub
< wumpus> yes, that is already tagged 0.17.0
< gmaxwell> so it fixes 14114
< wumpus> right
< jonasschnelli> Oh. Wasn't aware
< 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
< * jonasschnelli> is lost in PRs
< wumpus> #topic tinyformat move
< wumpus> e.g.: #13846, #13845, or keep as is
< 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 · GitHubAsset 1Asset 1
< wumpus> I'm ok with all three options but not with leaving those PRs open forever
< jonasschnelli> The subtree looked to me after an overkill,... I would prefer #13846 (no strong opinion)
< gribble> https://github.com/bitcoin/bitcoin/issues/13846 | Move src/tinyformat.h to src/tinyformat/tinyformat.h by Empact · Pull Request #13846 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< wumpus> I guess MarcoFalke is not here?
< wumpus> I think he has the strongest opinion about it
< gmaxwell> would we really do a subtree for a single file?
< wumpus> no.
< wumpus> I think this is pretty much unnecessary, and certainly the subtree one contains lots of changes
< gmaxwell> seems like change for the sake of change to me.
< wumpus> too much of that
< achow101> I'm in favor of keeping it as is
< wumpus> ok, other proposed topics?
< wumpus> I guess we haven't had high prio for review yet
< wumpus> #topic high priority for review
< jonasschnelli> I'd like to add #14046
< wumpus> we made quite a lot of progress there this week
< gribble> https://github.com/bitcoin/bitcoin/issues/14046 | net: Refactor message parsing (CNetMessage), adds flexibility by jonasschnelli · Pull Request #14046 · bitcoin/bitcoin · GitHub
< wumpus> only three left
< wumpus> added
< achow101> can I get #14019 for hi prio?
< gribble> https://github.com/bitcoin/bitcoin/issues/14019 | Import pubkeys when importing p2sh with importmulti by achow101 · Pull Request #14019 · bitcoin/bitcoin · GitHub
< wumpus> achow101: you already have one
< achow101> replace it with that one
< wumpus> ok
< wumpus> done
< ken2812221_> wumpus: I want to replace #13866 with #13878
< gribble> https://github.com/bitcoin/bitcoin/issues/13866 | utils: Use _wfopen and _wfreopen on Windows by ken2812221 · Pull Request #13866 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< gribble> https://github.com/bitcoin/bitcoin/issues/13878 | utils: Add fstream wrapper to allow to pass unicode filename on Windows by ken2812221 · Pull Request #13878 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< wumpus> ken2812221_: you really need to find someone that can review windows stuff :)
< wumpus> anyhow - replaced
< ken2812221_> I am not sure that who knows about Windows thing.
< wumpus> maybe sipsorcery (who contributed the MSVC build)
< wumpus> which reminds me of #14089
< gribble> https://github.com/bitcoin/bitcoin/issues/14089 | CryptGenRandom is deprecated by fingera · Pull Request #14089 · bitcoin/bitcoin · GitHub
< wumpus> I'd, personally, prefer to close that one
< wumpus> or what luke-jr says, add it as extra random source, that can't hurt
< jonasschnelli> deprecated PRNG may have less backdoors. :)
< wumpus> right, good to be very careful here
< ken2812221_> anyway, I don't have a strong opinion.
< gmaxwell> when we finally do move off of openssl as an input, we'll add additional randomness inputs, making that stuff slightly less critical.
< gmaxwell> ken2812221_: what caused you to be aware of the deprecation?
< wumpus> he only concept-ACKed it
< ken2812221_> Well, that is not my PR.
< wumpus> NicolasDorier NACKed it (with rationale)
< wumpus> he's another person that knows things about windows btw, you could maybe ping him in your other PRs ken2812221_ :)
< ken2812221_> Thank you, wumpus
< gmaxwell> ken2812221_: oh sorry, its fingera's PR. my mistake.
< wumpus> ok, any other topics?
< wumpus> ken2812221_: would be nice to get your PRs in for 0.18 and fix the windows unicode issues once and for all
< ken2812221_> I'm not sure if this fix all problems, it needs more and more tests.
< ken2812221_> But we have 6+ months to test it.
< wumpus> yes, better to merge it soon in that regard
< wumpus> so if no other topics I'm going to close the meeting
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Aug 30 19:45:34 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< phantomcircuit> while people are here
< gmaxwell> phantomcircuit has almost finished a patch to switch to poll but is stuck on some C++ confusion.
< promag> wumpus: regarding min qt, shouldn't we just use the current qt lts?
< phantomcircuit> net.cpp:2188:39: error: no matching function for call to ‘CConnman::RegisterListenSocket(SOCKET&)’
< gmaxwell> I looked at it, but must be a blonde day for me...
< promag> too bad if distributions use less than that?
< phantomcircuit> but im pretty clear that im calling RegisterListenSocket(hSocketListen) and hSocketListen is a const ListenSocket&
< phantomcircuit> any ideas?
< wumpus> promag: so that is 5.5?
< promag> 5.9
< wumpus> phantomcircuit: will have a look
< wumpus> phantomcircuit: the branch is 2018-08-29-poll?
< wumpus> I rather check locally instead of on gh
< wumpus> ok this is really strange
< * wumpus> wishes c++ had helpful warnings like rust
< promag> it's not strange
< midnightmagic> I thought clang having helpful warnings was one of the whole reasons for its existence
< promag> there type of hListenSocket is SOCKET
< wumpus> promag: yes!
< 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
< promag> what is going on in #14090? :S
< gribble> https://github.com/bitcoin/bitcoin/issues/14090 | [windows] progress bar in task bar by alexeyneu · Pull Request #14090 · bitcoin/bitcoin · GitHub
< 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
< gmaxwell> Bustapay ftw.
< achow101> cool!
< instagibbs> Dr Maxwell makes his return
< 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?