12016-08-25T00:00:16 *** harrymm has joined #bitcoin-core-dev
22016-08-25T00:00:49 *** justanotheruser has joined #bitcoin-core-dev
32016-08-25T00:04:14 *** pedrobranco has quit IRC
42016-08-25T00:04:46 *** pedrobranco has joined #bitcoin-core-dev
52016-08-25T00:08:56 *** pedrobranco has quit IRC
62016-08-25T00:26:46 *** achow101 has quit IRC
72016-08-25T00:40:22 *** btcdrak has quit IRC
82016-08-25T00:44:58 *** harrymm has quit IRC
92016-08-25T00:45:15 *** harrymm has joined #bitcoin-core-dev
102016-08-25T00:53:45 *** PRab has quit IRC
112016-08-25T01:00:06 *** fengling has quit IRC
122016-08-25T01:12:35 *** PRab has joined #bitcoin-core-dev
132016-08-25T01:19:16 *** fengling has joined #bitcoin-core-dev
142016-08-25T01:44:24 *** Giszmo has quit IRC
152016-08-25T01:44:40 *** justanotheruser has quit IRC
162016-08-25T01:45:10 *** justanotheruser has joined #bitcoin-core-dev
172016-08-25T01:57:06 *** fengling has quit IRC
182016-08-25T02:05:53 *** Ylbam has quit IRC
192016-08-25T02:13:06 *** slackircbridge has quit IRC
202016-08-25T02:13:23 *** slackircbridge has joined #bitcoin-core-dev
212016-08-25T02:23:12 *** Chris_Stewart_5 has quit IRC
222016-08-25T02:24:41 <GitHub109> [bitcoin] rebroad opened pull request #8583: Show XTHIN in GUI (master...ShowXTHINinGUI) https://github.com/bitcoin/bitcoin/pull/8583
232016-08-25T02:34:24 *** tom3 has joined #bitcoin-core-dev
242016-08-25T02:36:11 *** Alopex has quit IRC
252016-08-25T02:36:13 *** achow101 has joined #bitcoin-core-dev
262016-08-25T02:37:16 *** Alopex has joined #bitcoin-core-dev
272016-08-25T02:37:46 <achow101> There appears to be a problem with verifying the email that wladimir sent for announcing the release key. See https://bitcointalk.org/index.php?topic=1596294.msg16030908#msg16030908
282016-08-25T02:39:50 <phantomcircuit> indeed the signature is bad when you copy/paste from the website thing
292016-08-25T02:40:20 <phantomcircuit> the actual email is correct though
302016-08-25T02:40:26 *** Samdney has left #bitcoin-core-dev
312016-08-25T03:08:22 *** Alopex has quit IRC
322016-08-25T03:09:27 *** Alopex has joined #bitcoin-core-dev
332016-08-25T03:27:47 *** fengling has joined #bitcoin-core-dev
342016-08-25T03:30:13 *** btcdrak has joined #bitcoin-core-dev
352016-08-25T03:30:51 *** harrymm has quit IRC
362016-08-25T03:46:43 *** harrymm has joined #bitcoin-core-dev
372016-08-25T03:59:27 *** achow101 has quit IRC
382016-08-25T04:08:02 <GitHub124> [bitcoin] pstratem opened pull request #8585: Remove last caller of IncOrderPosNext (master...2016-08-24-cwallet-incorderposnext) https://github.com/bitcoin/bitcoin/pull/8585
392016-08-25T04:08:31 *** tom3 has quit IRC
402016-08-25T04:09:48 *** LeMiner has quit IRC
412016-08-25T04:10:34 *** LeMiner has joined #bitcoin-core-dev
422016-08-25T04:14:16 <phantomcircuit> can someone cancel all those travis jobs
432016-08-25T04:14:18 <phantomcircuit> sipa: ^
442016-08-25T04:33:06 *** Alopex has quit IRC
452016-08-25T04:34:12 *** Alopex has joined #bitcoin-core-dev
462016-08-25T04:39:09 <jl2012> wumpus: please do not include any email address within a PGP signed message. The signature is invalid because the "@" is replaced by "at": https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009045.html
472016-08-25T04:40:16 <jl2012> achow101, phantomcircuit: s/ at /@/ and you will have a good signature
482016-08-25T04:45:40 *** kadoban has quit IRC
492016-08-25T05:10:01 *** Alopex has quit IRC
502016-08-25T05:11:06 *** Alopex has joined #bitcoin-core-dev
512016-08-25T05:15:46 *** fengling has quit IRC
522016-08-25T05:48:58 *** fengling has joined #bitcoin-core-dev
532016-08-25T05:50:32 <luke-jr> sigh, can't we just flip a switch so the ML sw doesn't edit it? :/
542016-08-25T05:55:22 <kanzure> perhaps that's a "feature" enforced by linuxfoundation (which also doesn't make sense-- are they not signing email?)
552016-08-25T05:59:01 <wumpus> I don't think I'm gonig to send asignedmessage with release announcement again, too many snags
562016-08-25T05:59:43 <wumpus> the annouunce mailing list mutillated initial spaces converted to non-breaking spaces, \# converted to #
572016-08-25T05:59:58 <wumpus> the -dev mailing list malformed the message in digest mode (which can't be disabled)
582016-08-25T06:00:10 <wumpus> and now @'s are verboten too?
592016-08-25T06:00:13 <wumpus> meh :-)
602016-08-25T06:02:32 <wumpus> as if using GPG itsels isn't enough of a monster to get right (what, your key is only 2048 bits!)
612016-08-25T06:03:42 <wumpus> sending a link to a .asc on a server may work
622016-08-25T06:05:14 * wumpus first creates a gpg release mail signing key of 65537 bits
632016-08-25T06:05:26 <wumpus> or maybe a bunch of sed scripts with transformations before validation
642016-08-25T06:06:39 <paveljanik> I think we should abandon GPG and Bitcoin sign everything...
652016-08-25T06:06:55 <wumpus> if only it was all GPG's fault
662016-08-25T06:07:06 <paveljanik> and mailing lists ;-) Of course :-)
672016-08-25T06:07:10 <wumpus> hehe
682016-08-25T06:07:18 <paveljanik> sending announcements via OP_RETURN 8)
692016-08-25T06:07:35 <paveljanik> think a bit of it...
702016-08-25T06:08:05 * luke-jr glares.
712016-08-25T06:08:50 <Lightsword> we could just upload the release itself using OP_RETURNâs :P
722016-08-25T06:09:03 * Lightsword hides
732016-08-25T06:09:28 <wumpus> in any case the release announcement doesn't need to be signed, people should verify the SHA256SUMS.asc tha tcomes *wth* the rekease
742016-08-25T06:09:50 <wumpus> I tend to sign important mails to the mailing list, but this just created a diversion
752016-08-25T06:10:36 <wumpus> verifying the release email itself does nothing, it provides no security, the binaries *at* the link may still be tampered with
762016-08-25T06:11:25 <luke-jr> hm, that's a good point. this doesn't just screw up release mail, it screws up even when we want to sign discussion messages
772016-08-25T06:15:40 <wumpus> would be nice if the archive had a 'RAW' button like github
782016-08-25T06:15:55 <wumpus> that gives you the original text of the message, to paste into gpg
792016-08-25T06:16:39 <wumpus> then again, the anti-@ 'feature' mentioned by jl2012 is probably against spam, so I doubht they'll disable that transformation. They may disable all others though.
802016-08-25T06:18:17 <jl2012> or you may just use an attachment
812016-08-25T06:21:11 <wumpus> put the text in an attachment? fullsigning the mail and putting the signature in the attachment would work worse because any footers added will invalidate it too
822016-08-25T06:26:45 <gmaxwell> wumpus: just send the whole thing ascii armored.
832016-08-25T06:27:05 <wumpus> gmaxwell: that'd work!
842016-08-25T06:27:34 <wumpus> can't find any problems with that, it's what ASCII armoring is supposed to protect against. I guess it will generate no @, no # and doesn't depend on spaces
852016-08-25T06:28:15 <wumpus> people without GPG can't read it anymore, but who cares, they don't take security seriously so shouldn't be using bitcoin in the first place right :)
862016-08-25T06:31:46 * wumpus still remembers uuencode
872016-08-25T06:34:46 <wumpus> GPG base64 characters are A-Za-z0-9+/=
882016-08-25T06:42:59 *** BashCo has quit IRC
892016-08-25T06:44:54 *** Squidicc has joined #bitcoin-core-dev
902016-08-25T06:48:31 *** Squidicuz has quit IRC
912016-08-25T06:57:39 *** jannes has joined #bitcoin-core-dev
922016-08-25T07:11:06 *** Alopex has quit IRC
932016-08-25T07:12:11 *** Alopex has joined #bitcoin-core-dev
942016-08-25T07:14:24 *** BashCo has joined #bitcoin-core-dev
952016-08-25T07:21:21 *** Ylbam has joined #bitcoin-core-dev
962016-08-25T07:23:15 *** BashCo_ has joined #bitcoin-core-dev
972016-08-25T07:25:52 *** rubensayshi has joined #bitcoin-core-dev
982016-08-25T07:26:58 *** BashCo has quit IRC
992016-08-25T07:34:01 *** Alopex has quit IRC
1002016-08-25T07:35:07 *** Alopex has joined #bitcoin-core-dev
1012016-08-25T07:42:32 <wumpus> does anyone happen to have the digest mail from bitcoin-dev or core-dev containing the 0.13.0 announcement?
1022016-08-25T07:42:52 <wumpus> I'd like to see how the text is mangled there
1032016-08-25T07:48:16 <gmaxwell> "okay, so, if we write our release notes in pig latin and make sure any numbers we use are prime..."
1042016-08-25T07:49:40 <wumpus> yes it reminds me of the often crazy requirements for passwords "needs at least one $, but no #, must be longer than 666 characters but shorter than 7" etc
1052016-08-25T07:50:05 <gmaxwell> jonasschnelli: re, service bit comment, that was my thinking too but I didn't make that argument because I didn't want to encourage another bitcoin classic like sybil attack. :)
1062016-08-25T07:50:34 <wumpus> cfields_: sorry for needing another non-trivial rebase for #8085, after the next one you should harry me until it is merged
1072016-08-25T07:50:53 <sipa> "Your password needs to contain at least an uppercase character, a digit, punctuation, a hieroglyph, and an extinct mammal"
1082016-08-25T07:51:03 <wumpus> yes, that
1092016-08-25T07:51:15 <gmaxwell> sipa: is there a configuration for gentropy for that?
1102016-08-25T07:51:35 <sipa> gmaxwell: not yet :)
1112016-08-25T07:51:57 <sipa> yes, the network refactors should be priority now
1122016-08-25T07:52:03 <gmaxwell> where is the gentropy webpage again?
1132016-08-25T07:52:13 <sipa> can we also merge feeler connections?
1142016-08-25T07:52:21 <gmaxwell> feeler++
1152016-08-25T07:52:39 <sipa> gmaxwell: https://github.com/sipa/gentropy/tree/master/gramtropy
1162016-08-25T07:52:42 <gmaxwell> feelers should be considered for backport
1172016-08-25T07:52:57 <gmaxwell> sipa: I mean the enscriptem version
1182016-08-25T07:53:16 <sipa> ah, http://wps.sipa.be/gramtropy/gramtropy.html
1192016-08-25T07:53:24 <gmaxwell> (the backport comment, because of the problems we see in testnet with it taking a while to find many witness peers.)
1202016-08-25T07:54:05 <wumpus> jl2012: huh, there isn't even a @ in the release notes
1212016-08-25T07:54:06 <sipa> feeler is #8282
1222016-08-25T07:54:25 <gmaxwell> his shale kales fail thus nails fail yet ailments bewail but derailing bales assail
1232016-08-25T07:55:10 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8282
1242016-08-25T07:56:55 <GitHub188> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/f2306fbe01426ce11c4df6a5c1b837106bc2c702
1252016-08-25T07:56:55 <GitHub188> bitcoin/0.13 f2306fb Wladimir J. van der Laan: doc: Clean out release notes after 0.13.0 release
1262016-08-25T07:59:38 <paveljanik> and Wshadow changes please...
1272016-08-25T08:00:12 <GitHub120> [bitcoin] rebroad opened pull request #8587: Provide bloom services to whitelisted nodes. (master...WhitelistedBloom) https://github.com/bitcoin/bitcoin/pull/8587
1282016-08-25T08:01:38 <wumpus> yes looking at #8282 now
1292016-08-25T08:05:52 <gmaxwell> :-/ more overloading of whitelisted.
1302016-08-25T08:06:46 <sipa> soon we'll need a separate confog file describing various peer's services
1312016-08-25T08:06:50 <wumpus> I think I've joked about this before, but it's starting to seriously look like whitelisting should be split up into a bitfield
1322016-08-25T08:07:11 <sipa> with its own turing-complete configuration language, of course
1332016-08-25T08:07:32 <wumpus> subnet 1.2.3.x { flags allow-bloom allow-hyperspace-travel ... }
1342016-08-25T08:07:35 <wumpus> yes, exactly
1352016-08-25T08:07:55 <gmaxwell> virtually no one uses it. and its changes in behavior (e.g. the forced relaying) have made it less useful (though at least 0.13 lets you turn that off)
1362016-08-25T08:08:39 <wumpus> yeah..
1372016-08-25T08:08:56 <wumpus> in any case if this is going to be more complicated it's going to need a proper design, instead of bolting on things
1382016-08-25T08:09:26 <wumpus> and proper documentation too
1392016-08-25T08:09:36 <gmaxwell> well, also the authentication bip thing is perhaps a better way to hand out access to varrious things.
1402016-08-25T08:10:32 <wumpus> I suppose there's use cases for allowing based on IP ranges as well as authentication
1412016-08-25T08:11:06 <gmaxwell> there are, though it just gets messy when we're peppering the code with permit this and permit that, and then putting them all under one banner.
1422016-08-25T08:11:19 <wumpus> yes, completely agreed, that was my point
1432016-08-25T08:12:06 <wumpus> rebroad is always like 'I need this, so I'll push this change, I don't care about others'
1442016-08-25T08:12:19 <wumpus> ego-commits
1452016-08-25T08:13:01 <gmaxwell> (Also, AFAIK there isn't even a reason to turn off bloom filter support generally...)
1462016-08-25T08:13:27 <sipa> i don't think he needs whitefiltering or bloom filters at all
1472016-08-25T08:14:05 <wumpus> disabling bloom filters reduces CPU and I/O load of a running node
1482016-08-25T08:14:20 <gmaxwell> I just mean at the moment there are no active attacks going on.
1492016-08-25T08:14:25 <gmaxwell> at least none that I'm seeing.
1502016-08-25T08:14:41 <wumpus> sure, but its true even without attacks, though in a lesser amount ofc
1512016-08-25T08:14:58 <gmaxwell> Yes. It's true.
1522016-08-25T08:15:55 <gmaxwell> in any case, for the use case I can think of for that: only provide bloomfiltering to your own mobile wallet, the authentication is exactly what you want: your wallet will move around, and you want the privacy of the encrypted link.
1532016-08-25T08:16:51 <sipa> the original idea behind whitelisting was to use it on an edge router, which your internal network nkdes connect to
1542016-08-25T08:16:55 <wumpus> yes, it makes sense to allow bloom filtering support selectively, no argument there
1552016-08-25T08:17:08 <wumpus> just overloading whitelisting for everything, bleh
1562016-08-25T08:17:13 <sipa> and it needed special configuration so that rebroadcasts would propagate
1572016-08-25T08:17:35 <wumpus> but it'd make sense to document what whitelisting is actually for
1582016-08-25T08:17:44 <wumpus> to prevent people extending it for what they think it is for
1592016-08-25T08:18:25 <wumpus> yes, that was the original idea
1602016-08-25T08:18:34 <sipa> agree
1612016-08-25T08:18:43 <sipa> it is unclear what the goal os at this point
1622016-08-25T08:19:22 <sipa> maybe peer authentication + mempool reconciliation are a good replacement in the future
1632016-08-25T08:21:40 <wumpus> yes
1642016-08-25T08:22:00 <gmaxwell> well partly it was a result of someone having a specific need (armory wanting to be able to trigger a rebroadcast, when the initial broadcast happened before the nodes connections were up, and similar)
1652016-08-25T08:22:11 <gmaxwell> and it got addressed with a more general tool.
1662016-08-25T08:23:00 <gmaxwell> but the armory usage was kind of at odds with other usage, for example elewhere I use whitelist to bypass my bandwidth limits to let local nodes use as much as they want, and to prevent my p2pool daemon from being disconnected.
1672016-08-25T08:23:48 <wumpus> yes, overloading the same option for a ton of different things isn't a good idea, it makes people get into each other's way, and causes unexpected behavior changes between functions that may be exploitable
1682016-08-25T08:24:03 <wumpus> it should be more granular
1692016-08-25T08:24:25 <wumpus> I wouldn't like rebroad to implement that though...
1702016-08-25T08:25:22 <gmaxwell> sort of a challenge, we want to solve specific problems with general tools... but we don't want to overload multiple tools into one feature. It can be hard to tell these things apart.
1712016-08-25T08:25:57 <wumpus> er between versions, not between functions
1722016-08-25T08:26:22 <wumpus> yes, it's always a challenge, it's clear where we don't want to go, not where we do want to go
1732016-08-25T08:27:36 <wumpus> trying to make general tools is a useful goal but only works with a clear view of what the use cases are
1742016-08-25T08:28:27 <wumpus> and that should be the beginning of the design not follow from it
1752016-08-25T08:28:47 <wumpus> the edge-router case is a clear one, for example
1762016-08-25T08:29:52 <wumpus> so is the 'allow BLOOM for LAN or localhost or authenticated peers only' for people using SPV wallets locally to connect to a node, but don't want to expose it to the whole world
1772016-08-25T08:30:14 <gmaxwell> yes, though that means different things for different uses. e.g. the armory one wanted it to bypass all standardness rules, for example. not what you normally want when the purpose of your edge router is to conceal your screwups from the network. :)
1782016-08-25T08:30:25 <wumpus> but these are completely different things and shouldn't be moved under one option
1792016-08-25T08:31:43 <btcdrak> wumpus: the announce list converted the message to HTML that's where the issues came from which we have solved. As for the LF list, the @ conversion is to protect against spam harvesters. For the mailing list does sending attachments work? I think it is important to have the SHA256SUMS sent to several locations. Certainly GPG signing simple messages is not
1802016-08-25T08:31:43 <btcdrak> hazardous. Maybe it it too much to GPG sign the entire release announcement. The part that needs to be signed are the torrent link and the hashes.
1812016-08-25T08:31:46 <wumpus> the thing is, 'whitebind'/'whitelist' *look* like something that would cover both cases. You allow internal connections with more privileges
1822016-08-25T08:31:48 <gmaxwell> The idea of some fancy acl thing (your set subnet 1234 flags space-modulator, example) makes me sad because 0.0001% of users would use it, and half of them would set it wrong. But something like that would be the only way to reasonable accomidate some things.
1832016-08-25T08:32:19 <wumpus> well at least a fancy ACL would be a general tool, that can be used for many different things, that doesm ake me happy
1842016-08-25T08:32:42 <wumpus> (e.g., instead of specific options with slightly different syntax)
1852016-08-25T08:33:29 <wumpus> btcdrak: yes
1862016-08-25T08:34:48 <wumpus> the hashes are already in SHA256SUMS.asc, I think adding them into the release announcement may have confused people to check the signature on that message instead of SHA256SUMS.asc
1872016-08-25T08:35:45 <wumpus> btcdrak: I usually just sign my mails to the development mailing list, doesn't haev much to do with it being a release announcement or not
1882016-08-25T08:38:18 <wumpus> gmaxwell: but I can still remember arguing against having any subnet/ACL matching in bitcoind because of similar reasons, so I understand your point, it's just that now we've crossed this threshold anyway we should try to do it in a consistent way
1892016-08-25T08:38:49 <wumpus> 'bitcoind is not a firewall tool!'
1902016-08-25T08:39:21 <gmaxwell> I think the authentication will make it more justifyable in fact... just because there will be more cases to use it.
1912016-08-25T08:39:25 <wumpus> maybe we could allow specifying a BPF filter *ducks*
1922016-08-25T08:39:57 <gmaxwell> wumpus: bitcoin script
1932016-08-25T08:39:58 <wumpus> right, with authentication you virtually *need* a system like that
1942016-08-25T08:49:11 <GitHub189> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/62a5a8a01866...026c6edac947
1952016-08-25T08:49:11 <GitHub189> bitcoin/master dbb1f64 Ethan Heilman: Added feeler connections increasing good addrs in the tried table....
1962016-08-25T08:49:12 <GitHub189> bitcoin/master 026c6ed Wladimir J. van der Laan: Merge #8282: net: Feeler connections to increase online addrs in the tried table....
1972016-08-25T08:49:16 <GitHub71> [bitcoin] laanwj closed pull request #8282: net: Feeler connections to increase online addrs in the tried table. (master...feelers3) https://github.com/bitcoin/bitcoin/pull/8282
1982016-08-25T08:49:46 <GitHub197> [bitcoin] laanwj closed pull request #8459: [0.13] release-notes: Do not encourage changing blockmaxsize to blockmaxweight (0.13...0.13_relnotes_remove_bad_advice) https://github.com/bitcoin/bitcoin/pull/8459
1992016-08-25T08:50:20 *** mn3monic_ is now known as mn3monic
2002016-08-25T08:50:35 *** mn3monic has joined #bitcoin-core-dev
2012016-08-25T08:54:05 <wumpus> I'm not sure what to do with "leveldb: generate lib independent of locale sort" https://github.com/bitcoin/bitcoin/pull/8575 it's a change to leveldb,and we no longer need it since 0.13.0, and we likely won't do a leveldb subtree update anymore for 0.12.x.
2022016-08-25T08:55:32 <sipa> right
2032016-08-25T09:01:00 <GitHub185> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/026c6edac947...95a983d56dbd
2042016-08-25T09:01:00 <GitHub185> bitcoin/master fa1cf9e MarcoFalke: [test] Remove unused code
2052016-08-25T09:01:01 <GitHub185> bitcoin/master 95a983d MarcoFalke: Merge #8578: [test] Remove unused code...
2062016-08-25T09:01:10 <GitHub76> [bitcoin] MarcoFalke closed pull request #8578: [test] Remove unused code (master...Mf1608-qaUnused) https://github.com/bitcoin/bitcoin/pull/8578
2072016-08-25T09:15:28 <luke-jr> https://github.com/bitcoin/bitcoin/issues/8586 should probably be reopened.
2082016-08-25T09:16:00 *** hybridsole has quit IRC
2092016-08-25T09:16:33 *** hybridsole has joined #bitcoin-core-dev
2102016-08-25T09:20:48 <wumpus> luke-jr: are you going to troubleshoot/fix it?
2112016-08-25T09:20:55 <wumpus> if so, I don't mind reopening it
2122016-08-25T09:21:58 <wumpus> I tend to agree with MarcoFalke "However, if things are know to be broken and no one maintains/tests them, it would be better to disable qt4 right now.", but if we have someone that tests/fixes/maintains qt4 support we could keep doing that
2132016-08-25T09:22:26 <wumpus> I wonder how long this has been broken and gone unnoticed, not being able to switch tabs is quite serious
2142016-08-25T09:22:39 <btcdrak> is there any point in continuing with Qt4?
2152016-08-25T09:22:45 * luke-jr takes a look at the problem before deciding.
2162016-08-25T09:22:48 <sipa> arguabl, #8586 is still an issue, as we advertize support for Qt4.
2172016-08-25T09:22:50 <wumpus> btcdrak: see https://github.com/bitcoin/bitcoin/issues/8263
2182016-08-25T09:23:02 <luke-jr> btcdrak: it's currently the only way to get native look/feel on KDE 4
2192016-08-25T09:23:04 <sipa> the solution may be discontinuing qt4, but that's still a cjangr
2202016-08-25T09:23:15 <sipa> *changr
2212016-08-25T09:23:18 <wumpus> I personally don't want to spend one minute of my time hndling qt4 issues, at least
2222016-08-25T09:23:18 <sipa> *change
2232016-08-25T09:23:55 <jonasschnelli> Yes. Neither do I.
2242016-08-25T09:24:08 <wumpus> #8263 was *assuming* things were working on qt4
2252016-08-25T09:24:22 <MarcoFalke> What is the advantage of having a native look/feel if you know that the application is untested and potentially buggy?
2262016-08-25T09:24:22 <wumpus> if they aren't, and people didn't even notice, well that's clear enough
2272016-08-25T09:25:12 <luke-jr> wumpus: well, it's only day 2(?) and people are reporting bugs
2282016-08-25T09:25:26 <jonasschnelli> I think we should not keep Qt4 compatibility only because of KDE 4
2292016-08-25T09:25:28 * luke-jr is happy there's been no problems with C++11 though
2302016-08-25T09:25:30 <wumpus> MarcoFalke: tend to agree
2312016-08-25T09:26:36 <MarcoFalke> luke-jr: The person reporting the bug apparently compiled against qt4 by accident
2322016-08-25T09:26:50 <wumpus> luke-jr: any update on when KDE is going to fix this situation?
2332016-08-25T09:27:21 <luke-jr> wumpus: KDE has moved on. KDE 4 is no longer supported. but KDE 5 is not usable yet. if the past tells anything, it'll be years before it is :/
2342016-08-25T09:27:27 <da2ce7> sipa: creative/good work on #8580, I don't feel qualified to ACK, however enjoyed reading the PR.
2352016-08-25T09:27:29 <wumpus> MarcoFalke: I don't understand how that can happen
2362016-08-25T09:27:33 * luke-jr checks KDE release dates
2372016-08-25T09:27:39 <MarcoFalke> wumpus: Forget to install qt5?
2382016-08-25T09:27:47 <wumpus> we choose qt5 by default now
2392016-08-25T09:27:49 <wumpus> oh, maybe that
2402016-08-25T09:28:04 <wumpus> luke-jr: well okay that is as close to an admission that this will never happen
2412016-08-25T09:28:14 <sipa> regarding c++11, i'd like to share a misconception i've had for a long time: i first read that rvalue references where "values where the receiver was responsible for cleaning up", but that's quite confusing - the destructor is still invoked by the caller. What they really are, is references to values that the receiver is allowed (but not required) to do anything with, including reusing its storage
2422016-08-25T09:28:14 <luke-jr> looks like it took 2 years for KDE 4 to stabilise
2432016-08-25T09:29:05 <sipa> s/receiver/callee/
2442016-08-25T09:29:09 <wumpus> but again, if you are willing to actively support Qt4, I'm fine with keeping support for it. Otherwise the clear decision of all other devs seems to be to remove it.
2452016-08-25T09:29:34 <luke-jr> if it's trivial, I'll just fix it; otherwise, fine with removing it
2462016-08-25T09:30:16 <sipa> luke-jr: well, one question is why haven't we noticed yet?
2472016-08-25T09:30:23 <jonasschnelli> If we support Qt4, someone needs to test and fix at least the RCs.
2482016-08-25T09:30:27 <sipa> seems you are using Qt4, but didn't notice this issue either?
2492016-08-25T09:30:32 <luke-jr> sipa: no devs use Qt4? :P
2502016-08-25T09:30:48 <luke-jr> I've been building against Qt5 for a while
2512016-08-25T09:30:52 <wumpus> jonasschnelli: yes, we need someone to step up to support it then, if no one is willing, then advertising qt4 support is wrong
2522016-08-25T09:31:01 <jonasschnelli> Agree
2532016-08-25T09:31:06 <luke-jr> I can probably switch back, it's no big difference to me
2542016-08-25T09:32:04 <jonasschnelli> luke-jr: your saying that you will continue to actively support Qt4? Which means testing release candidates and fixing stuff? Than I'll stop the PR for disabling Qt4 support.
2552016-08-25T09:32:10 <wumpus> sipa: interesting
2562016-08-25T09:32:29 <wumpus> sipa: yes I haven't really formed a conception around them either yet, more than 'maagic!'
2572016-08-25T09:32:31 <jonasschnelli> Qt4 != Qt4
2582016-08-25T09:32:43 <luke-jr> I can't reproduce the problem. :/
2592016-08-25T09:33:09 <da2ce7> wumpus: on the gpg signing the release announcement: I would recommend including signed gpg armoured copy of the announcement at the bottom of the email; Anyone who wishes to verify the message can do a diff between the two to see if anything important was changed.
2602016-08-25T09:33:24 <sipa> wumpus: it's quite clever... the only "magic" is that passed temporaries are automatically given the rvalue-reference class (which can be automatically converted into a lvalue reference, if the callee doesn't have an overloaded version that takes rvalue references)
2612016-08-25T09:33:52 <luke-jr> everything seems to work with Qt4 for me
2622016-08-25T09:34:03 <wumpus> da2ce7: yes that could work (although the mailing list was already complaining about me sending a 40kb mail...)
2632016-08-25T09:34:29 <sipa> wumpus: something else that was unintuitive to me is that when you have a function with a (type&& x) parameter, x is just an lvalue reference - the rvalue status is just used to determine which overloaded version to use
2642016-08-25T09:34:54 <wumpus> luke-jr: I had this problem with qt5 too, with the out-of-tree changes, btw https://github.com/bitcoin/bitcoin/pull/7911#issuecomment-212413442 But that was fixed. Bu tmay be a similar issue
2652016-08-25T09:34:55 <sipa> and if you want to pass x along to something else without copying, you need to use std::move
2662016-08-25T09:35:53 <sipa> wumpus: rvalue references are huge complication to the language, but they really feel like addressing a very deep problem
2672016-08-25T09:36:50 <luke-jr> wumpus: I wonder if a non-clean build dir (old bitcoin-config.h?) might also cause this
2682016-08-25T09:36:53 <wumpus> sipa: it does add a lot of complication to an already extremely complicated language, but yes I think overall it's worth it
2692016-08-25T09:37:11 <wumpus> sipa: it does allow for doing some things much more efficient in a cleaner way
2702016-08-25T09:37:34 <sipa> yes, it always felt non-C++-ish to me that there were many cases in which you couldn't cleanly avoiding copying
2712016-08-25T09:37:57 <sipa> C++-ish here meaning that you should always have the option to avoid unnecessary code execution
2722016-08-25T09:37:58 <wumpus> yes you had to use some really ugly hacks to avoid copying, if possible at all
2732016-08-25T09:38:22 <wumpus> (like adding a dummy element and swapping, etc)
2742016-08-25T09:39:05 <luke-jr> wumpus: I bet he had to `make clean` for Qt5, but didn't the first time around..
2752016-08-25T09:39:06 <wumpus> right, un-c++ish, it's intended to be an efficient language, if not, there are plenty of other languages to use that are more developer friendly
2762016-08-25T09:39:07 <btcdrak> It's pretty clear supporting Qt4 and doing QA for releases is going to be like pulling teeth.
2772016-08-25T09:39:55 <jonasschnelli> A Qt4-semi-disabling-step would be to disable the auto-detection
2782016-08-25T09:40:02 <wumpus> "and if you want to pass x along to something else without copying, you need to use std::move" I do wonder how std::move is implemented, or is it some compiler-internal magic?
2792016-08-25T09:40:04 <luke-jr> btcdrak: it seems to just work for now
2802016-08-25T09:40:16 <jonasschnelli> If someone really wants to compile against qt4, we could keep --with-gui=qt4 but disable the autodetect
2812016-08-25T09:40:27 <wumpus> jonasschnelli: good idea; you can still force using it if you know what you're doing, but it wil never choose it by default
2822016-08-25T09:40:29 <sipa> wumpus: it simply casts a reference to an rvalue reference
2832016-08-25T09:40:37 <sipa> nope, you can implement it yourself
2842016-08-25T09:40:44 <wumpus> sipa: oh, that's all
2852016-08-25T09:40:50 <luke-jr> jonasschnelli: that sounds reasonable; maybe a message to make noises if they want Qt4 support to stay?
2862016-08-25T09:40:59 <sipa> std::forward is more magic, but still does not require any internals
2872016-08-25T09:41:06 <jonasschnelli> luke-jr: Yes. Okay... lets try that.
2882016-08-25T09:41:59 <sipa> wumpus: you can create a function that takes a template parameter <typename T> (T&& x), in which case x is a universal reference (either an lvalue or an rvalue), and std::forward turns it back into the way it was called
2892016-08-25T09:42:32 <sipa> so you can create a function that takes either an lvalue or an rvalue, and passes it down the stack several times without losing its rvalue status
2902016-08-25T09:43:16 <wumpus> ah the 'perfect forwarding' thing
2912016-08-25T09:43:19 <GitHub187> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/95a983d56dbd...d26234a9e2fa
2922016-08-25T09:43:20 <GitHub187> bitcoin/master 15df3c1 Andrew Chow: Persist the datadir after option reset...
2932016-08-25T09:43:20 <GitHub187> bitcoin/master 57acb82 Andrew Chow: Load choose datadir dialog after options reset
2942016-08-25T09:43:20 <GitHub187> bitcoin/master d26234a Jonas Schnelli: Merge #8487: Persist the datadir after option reset...
2952016-08-25T09:43:29 <GitHub68> [bitcoin] jonasschnelli closed pull request #8487: Persist the datadir after option reset (master...persist-datadir) https://github.com/bitcoin/bitcoin/pull/8487
2962016-08-25T09:44:06 <wumpus> it's kind of clever
2972016-08-25T09:44:57 <sipa> and the reason that std::forward doesn't happen automatically is that of course you're allowed to use x multiple times in the function body, as it is a normal variable
2982016-08-25T09:45:14 <wumpus> yes, makes sense
2992016-08-25T09:45:21 <sipa> so in that case you wouldn't want to auto destruct it on first use
3002016-08-25T09:45:35 <sipa> combining with substructural typing would have been nice :)
3012016-08-25T09:48:26 *** fengling has quit IRC
3022016-08-25T09:54:13 *** Ginnarr has joined #bitcoin-core-dev
3032016-08-25T09:55:53 *** fengling has joined #bitcoin-core-dev
3042016-08-25T09:57:11 *** Ginnarr has quit IRC
3052016-08-25T09:58:01 *** Ginnarr has joined #bitcoin-core-dev
3062016-08-25T09:59:32 <btcdrak> that gitian script by achow101 makes me happy
3072016-08-25T10:03:54 <sipa> ffs can we send rebroad to a programming class
3082016-08-25T10:05:24 <luke-jr> Matt's doing one in NY, right? :p
3092016-08-25T10:27:10 <paveljanik> rebroad looking for a ban 8)
3102016-08-25T10:49:52 *** moli has quit IRC
3112016-08-25T11:04:32 *** pedrobranco has joined #bitcoin-core-dev
3122016-08-25T11:05:00 *** pedrobranco has joined #bitcoin-core-dev
3132016-08-25T11:05:53 *** Ylbam has quit IRC
3142016-08-25T11:07:38 *** pedrobranco has quit IRC
3152016-08-25T11:08:12 *** pedrobranco has joined #bitcoin-core-dev
3162016-08-25T11:13:04 *** pedrobranco has quit IRC
3172016-08-25T11:20:11 *** Samdney has joined #bitcoin-core-dev
3182016-08-25T11:22:00 *** pedrobranco has joined #bitcoin-core-dev
3192016-08-25T11:22:44 *** pedrobranco has quit IRC
3202016-08-25T11:22:50 *** pedrobra_ has joined #bitcoin-core-dev
3212016-08-25T11:31:17 *** cryptapus has joined #bitcoin-core-dev
3222016-08-25T11:31:56 <GitHub152> [bitcoin] sipa opened pull request #8589: Inline CTxInWitness inside CTxIn (on top of #8580) (master...segwitinlinepain) https://github.com/bitcoin/bitcoin/pull/8589
3232016-08-25T11:35:50 *** Ginnarr has quit IRC
3242016-08-25T11:36:11 <btcdrak> sipa: does #8589 replace both #8452 and #8580?
3252016-08-25T11:36:53 <sipa> yes
3262016-08-25T11:37:18 <btcdrak> may be better to close those two?
3272016-08-25T11:37:52 <sipa> well i don't know whether #8451 or #8580 will be accepted
3282016-08-25T11:38:12 <sipa> i guess i could wait with #8589 and #8452 until that choice is made
3292016-08-25T11:39:15 <GitHub70> [bitcoin] sipa closed pull request #8452: Code simplification: inline CTxInWitness inside CTxIn (master...segwitinline) https://github.com/bitcoin/bitcoin/pull/8452
3302016-08-25T12:00:38 *** moli has joined #bitcoin-core-dev
3312016-08-25T12:04:49 <GitHub60> [bitcoin] sipa closed pull request #7984: Optional parameter for rescans to start at a specified height (master...rescan-fromheight) https://github.com/bitcoin/bitcoin/pull/7984
3322016-08-25T12:09:28 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3332016-08-25T12:14:42 *** Chris_Stewart_5 has quit IRC
3342016-08-25T12:15:01 <GitHub54> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d26234a9e2fa...9d0f43b7ca72
3352016-08-25T12:15:02 <GitHub54> bitcoin/master be1d451 Will Binns: contributing.md: Fix formatting...
3362016-08-25T12:15:03 <GitHub54> bitcoin/master 9d0f43b Pieter Wuille: Merge #8226: contributing.md: Fix formatting (line lengths and smart quotes)...
3372016-08-25T12:15:09 <GitHub120> [bitcoin] sipa closed pull request #8226: contributing.md: Fix formatting (line lengths and smart quotes) (master...binns-contributing-formatting) https://github.com/bitcoin/bitcoin/pull/8226
3382016-08-25T12:17:46 *** Squidicuz has joined #bitcoin-core-dev
3392016-08-25T12:18:43 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3402016-08-25T12:19:29 *** cryptapus_ has joined #bitcoin-core-dev
3412016-08-25T12:19:52 *** Squidicc has quit IRC
3422016-08-25T12:20:17 *** cryptapus_afk has quit IRC
3432016-08-25T12:20:47 *** MarcoFalke has quit IRC
3442016-08-25T12:21:04 *** MarcoFalke has joined #bitcoin-core-dev
3452016-08-25T12:23:58 *** Alopex has quit IRC
3462016-08-25T12:24:12 *** murch has joined #bitcoin-core-dev
3472016-08-25T12:29:06 *** Alopex has joined #bitcoin-core-dev
3482016-08-25T12:36:12 *** YOU-JI has joined #bitcoin-core-dev
3492016-08-25T12:36:54 *** aalex_ has joined #bitcoin-core-dev
3502016-08-25T12:37:22 *** aalex has quit IRC
3512016-08-25T12:49:04 *** laurentmt has joined #bitcoin-core-dev
3522016-08-25T12:51:12 *** laurentmt has quit IRC
3532016-08-25T12:54:07 *** laurentmt has joined #bitcoin-core-dev
3542016-08-25T12:55:29 *** laurentmt has quit IRC
3552016-08-25T12:55:44 <GitHub179> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9d0f43b7ca72...0606f95b1ea8
3562016-08-25T12:55:44 <GitHub179> bitcoin/master 2f32c82 Jonas Schnelli: [Qt] show network/chain errors in the GUI
3572016-08-25T12:55:45 <GitHub179> bitcoin/master 0606f95 Jonas Schnelli: Merge #7579: [Qt] show network/chain errors in the GUI...
3582016-08-25T12:55:49 <GitHub28> [bitcoin] jonasschnelli closed pull request #7579: [Qt] show network/chain errors in the GUI (master...2016/02/gui_alert) https://github.com/bitcoin/bitcoin/pull/7579
3592016-08-25T13:06:09 <GitHub83> [bitcoin] MarcoFalke opened pull request #8590: Remove unused variables (master...Mf1608-unusedCode) https://github.com/bitcoin/bitcoin/pull/8590
3602016-08-25T13:11:31 <jonasschnelli> Travis failed on master: https://travis-ci.org/bitcoin/bitcoin/jobs/155043866#L2347
3612016-08-25T13:11:34 <jonasschnelli> compactblock test
3622016-08-25T13:15:36 <GitHub69> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0606f95b1ea8...53f8f226bd1d
3632016-08-25T13:15:36 <GitHub69> bitcoin/master f13c1ba Michael Rotarius: Move AdvertiseLocal debug output to net category
3642016-08-25T13:15:37 <GitHub69> bitcoin/master 53f8f22 Pieter Wuille: Merge #8462: Move AdvertiseLocal debug output to net category...
3652016-08-25T13:15:49 <GitHub172> [bitcoin] sipa closed pull request #8462: Move AdvertiseLocal debug output to net category (master...advertiselocal) https://github.com/bitcoin/bitcoin/pull/8462
3662016-08-25T13:16:30 <sipa> jonasschnelli: ugh
3672016-08-25T13:16:50 <jonasschnelli> probably a random error...
3682016-08-25T13:16:54 <jonasschnelli> (one of these)
3692016-08-25T13:17:03 <sipa> i'm restarting
3702016-08-25T13:17:17 <jonasschnelli> ok
3712016-08-25T13:29:29 *** tom3 has joined #bitcoin-core-dev
3722016-08-25T13:35:51 *** Giszmo has joined #bitcoin-core-dev
3732016-08-25T13:49:19 *** kadoban has joined #bitcoin-core-dev
3742016-08-25T13:49:20 <GitHub181> [bitcoin] rebroad opened pull request #8591: Do not relay or mine excessive sighash transactions (master...NoExcessiveSighashTxs) https://github.com/bitcoin/bitcoin/pull/8591
3752016-08-25T13:50:03 *** isis has quit IRC
3762016-08-25T13:59:28 *** BashCo has joined #bitcoin-core-dev
3772016-08-25T14:01:50 *** BashCo_ has quit IRC
3782016-08-25T14:07:20 *** dirtynewshoes has quit IRC
3792016-08-25T14:08:12 *** Chris_Stewart_5 has quit IRC
3802016-08-25T14:09:20 <GitHub149> [bitcoin] MarcoFalke closed pull request #8579: Performance: Prefer prefix operator for non-primitive types (master...Mf1608-perfIter) https://github.com/bitcoin/bitcoin/pull/8579
3812016-08-25T14:11:51 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3822016-08-25T14:14:52 *** tom3 has quit IRC
3832016-08-25T14:25:26 *** tom3 has joined #bitcoin-core-dev
3842016-08-25T14:27:00 *** pedrobra_ has quit IRC
3852016-08-25T14:27:14 *** pedrobranco has joined #bitcoin-core-dev
3862016-08-25T14:30:28 *** Chris_Stewart_5 has quit IRC
3872016-08-25T14:31:13 *** Samdney has quit IRC
3882016-08-25T14:34:25 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3892016-08-25T14:38:29 *** pedrobranco has quit IRC
3902016-08-25T14:44:46 *** YOU-JI has quit IRC
3912016-08-25T14:48:05 <GitHub76> [bitcoin] sipa closed pull request #8591: Do not relay or mine excessive sighash transactions (master...NoExcessiveSighashTxs) https://github.com/bitcoin/bitcoin/pull/8591
3922016-08-25T14:52:27 *** Ylbam has joined #bitcoin-core-dev
3932016-08-25T14:56:33 <GitHub80> [bitcoin] hejunbok opened pull request #8592: 0.13 (master...0.13) https://github.com/bitcoin/bitcoin/pull/8592
3942016-08-25T14:57:25 <GitHub7> [bitcoin] hejunbok closed pull request #8592: 0.13 (master...0.13) https://github.com/bitcoin/bitcoin/pull/8592
3952016-08-25T15:00:28 *** Megaf has joined #bitcoin-core-dev
3962016-08-25T15:00:43 *** arubi has quit IRC
3972016-08-25T15:03:52 *** rubensayshi has quit IRC
3982016-08-25T15:26:41 *** Chris_Stewart_5 has quit IRC
3992016-08-25T15:38:02 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4002016-08-25T15:43:54 *** Megaf has quit IRC
4012016-08-25T15:44:31 *** Samdney has joined #bitcoin-core-dev
4022016-08-25T15:47:16 *** Chris_Stewart_5 has quit IRC
4032016-08-25T15:48:01 <GitHub39> [bitcoin] jl2012 opened pull request #8593: Verify all incoming txs unless the witness stripped size is >100kB (master...verifyalltx) https://github.com/bitcoin/bitcoin/pull/8593
4042016-08-25T16:03:04 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4052016-08-25T16:50:33 *** BashCo has quit IRC
4062016-08-25T16:59:48 *** BashCo has joined #bitcoin-core-dev
4072016-08-25T17:24:34 <luke-jr> MarcoFalke: https://github.com/bitcoin/bitcoin/pull/6996 my rebase already has the tests taken care of too..
4082016-08-25T17:24:48 *** Chris_Stewart_5 has quit IRC
4092016-08-25T17:25:07 <MarcoFalke> Nice, then ask sipa to force push :)
4102016-08-25T17:25:37 <luke-jr> implicitly did 16 days ago :p
4112016-08-25T17:26:37 <sipa> luke-jr: how does it deal with invalidateblock?
4122016-08-25T17:26:58 <sipa> you could return later to something with a lower chainwork
4132016-08-25T17:27:38 <luke-jr> sipa: dunno, I would assume like any other invalid block declared precious? O.o
4142016-08-25T17:27:59 <sipa> i guess it's such an edge case it doesn't matter
4152016-08-25T17:28:34 <luke-jr> doesn't preciousblock just give a small bias toward the block in question, in best-chainwork selection?
4162016-08-25T17:30:33 <sipa> yes
4172016-08-25T17:30:48 <sipa> right, i guess it doesn't matter even
4182016-08-25T17:31:06 <sipa> thanks, i'll update the branch
4192016-08-25T17:32:29 <Lauda> Is the credit list @release of a version updated frequently/automatically/manually?
4202016-08-25T17:34:46 <luke-jr> Lauda: you mean the list of contributors at the end of the release notes? typically comes from a git log, sometimes with manual adjustments
4212016-08-25T17:34:52 *** BashCo has quit IRC
4222016-08-25T17:35:16 *** BashCo has joined #bitcoin-core-dev
4232016-08-25T17:35:36 <Lauda> Yes, that list. Thanks for the information.
4242016-08-25T17:38:01 <sipa> well it's not automatically updated at all... it is compiled by wumpus at release time
4252016-08-25T17:38:13 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4262016-08-25T17:39:39 <Lauda> Based on what? Seems some people are on the list due to just having a pull request or two that eventually got closed.
4272016-08-25T17:40:06 <sipa> commits
4282016-08-25T17:41:38 <Lauda> One has to have a merged commit to be on that list?
4292016-08-25T17:41:45 <luke-jr> Lauda: git shortlog v0.12.1..v0.13.0 | perl -nle 'm/^(\S.*)\s\(.*$/ && print $1' | sort
4302016-08-25T17:42:06 <MarcoFalke> Is the script wumpus uses public?
4312016-08-25T17:42:37 <sipa> Lauda: yes
4322016-08-25T17:42:51 <sipa> that's the necessary and sufficient condition
4332016-08-25T17:43:01 <MarcoFalke> In some corner cases it does misattribution.
4342016-08-25T17:43:10 <MarcoFalke> E.g. I open a pull but I am not author of the commits
4352016-08-25T17:43:17 <Lauda> I think it did, sec.
4362016-08-25T17:43:38 <MarcoFalke> I reported this once so it might be fixed by now
4372016-08-25T17:43:52 <wumpus> for the credits list I prefer erring on the safe side, e.g. including more than necessary instead of less
4382016-08-25T17:44:02 <wumpus> MarcoFalke: any specific ones?
4392016-08-25T17:44:15 <MarcoFalke> This was in 0.12.x
4402016-08-25T17:44:18 <MarcoFalke> already fixed
4412016-08-25T17:44:22 * luke-jr ponders what wumpus's LC_COLLATE is
4422016-08-25T17:44:49 <wumpus> that script simply looks who submitted the pull, so if you submitted someone elses' pulls then that needs to be manually corrected
4432016-08-25T17:45:01 <wumpus> it's pretty dumb and I end up doing a lot of work myself
4442016-08-25T17:45:05 <MarcoFalke> I wonder if the script could be included in the repo.
4452016-08-25T17:45:15 <MarcoFalke> Maybe people will help you maintain it
4462016-08-25T17:45:17 <wumpus> you should look over the list and correct things that aren't correct
4472016-08-25T17:45:19 <wumpus> oh no way, it's crap
4482016-08-25T17:45:28 <MarcoFalke> ha, I guessed it
4492016-08-25T17:45:33 <MarcoFalke> :)
4502016-08-25T17:45:52 <MarcoFalke> I wouldn't want to share my scripts ...
4512016-08-25T17:46:02 <luke-jr> Lauda: git shortlog --use-mailmap v0.12.1..v0.13.0 | perl -nle 'm/^(\S.*)\s\(.*$/ && print $1' | sort | uniq # just needs LC_COLLATE and a mailmap file :P
4522016-08-25T17:46:15 <Lauda> Just.. :p
4532016-08-25T17:46:35 <wumpus> maybe at some point I get to cleaning it up for release, but I only tend to touch it for releases
4542016-08-25T17:46:51 <luke-jr> Lauda: you should see my scripts for merging translation files.. :P
4552016-08-25T17:47:13 *** MarcoFalke has quit IRC
4562016-08-25T17:48:11 *** MarcoFalke has joined #bitcoin-core-dev
4572016-08-25T17:48:13 <Lauda> It must be 'nice' looking :)
4582016-08-25T17:48:32 *** kadoban has quit IRC
4592016-08-25T17:49:02 <wumpus> luke-jr: I don't even know what LC_COLLATE does
4602016-08-25T17:49:10 <wumpus> let alone having changed it manually :)
4612016-08-25T17:49:31 *** kadoban has joined #bitcoin-core-dev
4622016-08-25T17:49:40 <wumpus> it's not even defined in my env
4632016-08-25T17:49:53 <Lauda> https://www.postgresql.org/docs/8.4/static/sql-createdatabase.html
4642016-08-25T17:50:15 <wumpus> postgresql?
4652016-08-25T17:50:18 <sipa> sort order
4662016-08-25T17:50:24 <Lauda> It has the flag explanation
4672016-08-25T17:50:29 <Lauda> Collation order (LC_COLLATE) to use in the new database. This affects the sort order applied to strings, e.g. in queries with ORDER BY, as well as the order used in indexes on text columns. The default is to use the collation order of the template database. See below for additional restrictions.
4682016-08-25T17:50:33 <luke-jr> wumpus: your sort program does a different order than mine :p
4692016-08-25T17:50:42 <wumpus> my sort program probably sucks...
4702016-08-25T17:50:54 <luke-jr> wumpus: run `locale` and check the output
4712016-08-25T17:51:28 <wumpus> LC_COLLATE="en_US.UTF-8"
4722016-08-25T17:51:39 <luke-jr> hmm
4732016-08-25T17:51:49 <wumpus> maybe I should set it to Chinese
4742016-08-25T17:51:57 <wumpus> or Russian
4752016-08-25T17:51:59 <sipa> wumpus: do you use sleepsort?
4762016-08-25T17:52:26 <luke-jr> wumpus: German was a closer approximation in my trial-and-error experience
4772016-08-25T17:52:38 <wumpus> sipa: yes, the parallelism, it's awesome!
4782016-08-25T17:52:51 <luke-jr> de_DE.utf8 got me the same order for the linguas files.. until 0.13.0
4792016-08-25T17:53:14 <wumpus> I don't know what I should feel about people trying to reverse my environment variable settings :)
4802016-08-25T17:53:19 <luke-jr> lol
4812016-08-25T17:53:41 <Lauda> haha
4822016-08-25T17:54:32 *** kadoban has quit IRC
4832016-08-25T17:54:45 <luke-jr> it's what happens when doc/translation_process.md results in a resorting ;p
4842016-08-25T17:55:35 *** kadoban has joined #bitcoin-core-dev
4852016-08-25T17:55:36 <wumpus> python has locale independent sorting AFAIK, but yes, the list-authors script is a shell script
4862016-08-25T17:55:46 <wumpus> and itindeed calls the sort utility
4872016-08-25T17:56:05 <wumpus> so, so far you're right
4882016-08-25T17:56:59 <wumpus> it's curious how all those utilities leak information
4892016-08-25T18:05:24 <wumpus> luke-jr: good idea on using --use-mailmap, I was doing a manual processing step for that
4902016-08-25T18:06:57 <afk11> bitcoincore.org is behind CloudFlare - following the gitian instructions lead to a 403 if CloudFlare decides it doesn't like you. https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#fetch-and-create-inputs-first-time-or-when-dependency-versions-change
4912016-08-25T18:07:23 <btcdrak> afk11: which step?
4922016-08-25T18:07:41 <afk11> wget anything..
4932016-08-25T18:08:23 <Lightsword> is it hitting a captcha page?
4942016-08-25T18:08:27 <afk11> osslsigncode-Backports-to-1.7.1.patch loaded from cfields directory on bitcoincore.org in this case.
4952016-08-25T18:08:33 <afk11> Lightsword, yep
4962016-08-25T18:08:42 <wumpus> I don't think that's correct
4972016-08-25T18:08:50 <luke-jr> hm, I thought there was a different subdomain for downloads
4982016-08-25T18:09:01 <Lightsword> yeahâ¦thatâs their ddos detection getting triggered, btcdrak maybe you can lower the sensitivity
4992016-08-25T18:09:15 <wumpus> you can download from https://dev.bitcoincore.org/cfields/osslsigncode-Backports-to-1.7.1.patch
5002016-08-25T18:09:30 <wumpus> that's where it redirects, and that one's not behind cloudflare
5012016-08-25T18:10:28 <Lightsword> wumpus, dev.bitcoincore.org is showing behind cloudflare for me
5022016-08-25T18:10:46 <afk11> I'll PR that link instead
5032016-08-25T18:10:48 <afk11> oh
5042016-08-25T18:10:51 <wumpus> ok, i didn't use to be, I give up
5052016-08-25T18:11:34 <wumpus> maybe someone else can host the file somewhere else and give a fallback url...
5062016-08-25T18:11:49 *** kadoban has quit IRC
5072016-08-25T18:12:08 <Lightsword> there should be a way to whitelist urls in cloudflare to turn off the ddos protection
5082016-08-25T18:12:20 <Lightsword> although not sure if thatâs available in the free plan
5092016-08-25T18:12:26 <wumpus> dev. shouldn't be behind cloudflare in the first place
5102016-08-25T18:12:46 *** kadoban has joined #bitcoin-core-dev
5112016-08-25T18:13:01 <luke-jr> http://luke.dashjr.org/tmp/code/osslsigncode-Backports-to-1.7.1.patch
5122016-08-25T18:13:04 <wumpus> it's really eating the internet, isn't it cloudflare
5132016-08-25T18:13:12 <wumpus> thanks luke-jr
5142016-08-25T18:14:17 <gmaxwell> sipa: in the feeler stuff that was just merged, what is the purpose of FEELER_SLEEP_WINDOW, when the timing of the feelers is accomplished via the possion next-send?
5152016-08-25T18:14:45 <wumpus> btcdrak: any idea what is happening there?
5162016-08-25T18:15:07 <sipa> gmaxwell: ethan explained that in a comment
5172016-08-25T18:16:46 <gmaxwell> ah, I see it. that should have ended up as a comment in the code.
5182016-08-25T18:17:37 <gmaxwell> As it stands, if I later reworked that code and didn't know they both went in at once, I might have removed the latter delay.
5192016-08-25T18:18:01 <afk11> thanks luke-jr!
5202016-08-25T18:18:34 <btcdrak> wumpus: this is why I wanted to change fallback URL remember.
5212016-08-25T18:18:49 <btcdrak> afk11: are you running behind Tor?
5222016-08-25T18:18:53 <gmaxwell> sipa: I wonder if their test before evict shouldn't be accomplished by having a seperate table of recently evicted entries which are prioritized for feeler probes.
5232016-08-25T18:19:15 <gmaxwell> rather than having the eviction directly trigger a connection.
5242016-08-25T18:19:38 <btcdrak> afk11: it tends to happen on tor exits. settings are on minimal which basically flags Tor exit nodes.
5252016-08-25T18:21:13 <sipa> gmaxwell: i don't think i ever reviewed test before evict
5262016-08-25T18:21:23 <wumpus> btcdrak: but how did dev.bitcoincore.org end up behind cloudflare?
5272016-08-25T18:21:52 <gmaxwell> sipa: ha, I was asking you because you had a bunch of outdated comments on the PR.
5282016-08-25T18:22:38 <wumpus> I'm surprised that doesn't interacts wth the OSX SDK download which checks based on source IP
5292016-08-25T18:23:38 <sipa> gmaxwell: test-before-evict or feeler?
5302016-08-25T18:24:47 <gmaxwell> oh oh sorry. I was commenting on the comments in feeler about test before evict.
5312016-08-25T18:25:25 <afk11> btcdrak, yeah, it's using tor. might be better to host it elsewhere, people do this on servers after all
5322016-08-25T18:27:39 <wumpus> I'd hope that patch gets merged in upstream at some point so we don't need it anymore at all
5332016-08-25T18:27:41 <btcdrak> wumpus: it's in our PMs iirc with lots of details. firstly the fallback URL points to bitcoincore.org so there is a redirect to dev.bitcoincore.org. so the initial request hits CF, game over. the firewall settings are on min, but you cant disable it on the free plan and it flags some IPs very very occasionally if they are "abusive" tor exits usually. You
5342016-08-25T18:27:42 <btcdrak> didnt want to change the fallback URL in gitian setup, so I had to use a redirect. secondly there isnt a valid SSL cert on dev so it uses the CF one, plus there was the issue of transient hosting (and wanting the least maintenance options).
5352016-08-25T18:28:12 <btcdrak> afk11: you're the first person who has complained, I'm not really sure why a server would be running exclusively behind tor unless it's a dnm :-p
5362016-08-25T18:28:16 <wumpus> btcdrak: I know bitcoincore.org is on cloudflare and that we've set up the redirects on bitcoincore.org
5372016-08-25T18:28:29 <wumpus> btcdrak: what I don't understand is why dev.bitcoincore.org is behind cloudflare
5382016-08-25T18:28:57 <btcdrak> it has to be to get the SSL.
5392016-08-25T18:29:12 <wumpus> dev.bitconcore.org has no SSL of itself? okay
5402016-08-25T18:29:21 <wumpus> yes, I probably forgot
5412016-08-25T18:29:22 <btcdrak> unless you want to buy a certificate. but it doesnt matter, the gitian thing would fail for afk11 anyway because of the redirect
5422016-08-25T18:29:34 <wumpus> well we could easily change that link
5432016-08-25T18:29:35 <Lightsword> btcdrak, just use letsencrypt for SSL on dev
5442016-08-25T18:29:39 <afk11> btcdrak, in this case, it's a qube over tor!
5452016-08-25T18:29:39 <luke-jr> â¦
5462016-08-25T18:30:00 <luke-jr> so you're saying people connect to CloudFlare over SSL, and then it connects to the real server unencrypted?
5472016-08-25T18:30:03 <luke-jr> wtf is the point
5482016-08-25T18:30:11 <btcdrak> letencrypt only issues certs for 3 months.
5492016-08-25T18:30:21 <Lightsword> btcdrak, letsencrypt has autorenew...
5502016-08-25T18:30:22 <btcdrak> luke-jr: no, the server is SSL
5512016-08-25T18:30:28 <afk11> you can set a crontab (certauto is a tool for it I think) to auto-renew
5522016-08-25T18:30:28 <wumpus> this is not about gitian, but some other file mentioned in https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#fetch-and-create-inputs-first-time-or-when-dependency-versions-change
5532016-08-25T18:30:31 <btcdrak> it's just expired
5542016-08-25T18:30:38 <luke-jr> aha, ok
5552016-08-25T18:31:11 <luke-jr> how about StartCom?
5562016-08-25T18:31:15 <Lightsword> btcdrak, expiring for letsencrypt certificates shouldnât ben an issue
5572016-08-25T18:31:15 <wumpus> hosting files is one of our bigger problems
5582016-08-25T18:31:20 <btcdrak> if we were to change the gitian fallback URL we could just point it to github tbf
5592016-08-25T18:31:43 <wumpus> but that's what you get with an almost zero project budget :)
5602016-08-25T18:31:47 <Lightsword> since you normally run an autoupdater on the server that will periodically renew the letsencrypt cert before it expires
5612016-08-25T18:32:09 <btcdrak> Lightsword: no, all those moving parts fail and it's a lot of maintenance in practice.
5622016-08-25T18:32:34 <Lightsword> hmm, I thought they had made it fairly reliable by now
5632016-08-25T18:32:38 <btcdrak> the gitian fallback should be hosted on github releases page and that would solve the issue.
5642016-08-25T18:32:48 <wumpus> is there some cheap https-supporting hosting that is not behind cloudflare?
5652016-08-25T18:32:51 <luke-jr> what happened to bitcoin.org's maintainers (not bitcoin.org itself) offering to host bitcoincore.org also?
5662016-08-25T18:33:05 <btcdrak> luke-jr: their hosting is due to run out soon.
5672016-08-25T18:33:08 <luke-jr> ah
5682016-08-25T18:33:14 <wumpus> they have the same proble
5692016-08-25T18:33:25 <sipa> who is bitcoin.org's maintainers, and who is bitcoin.org itself?
5702016-08-25T18:33:30 <btcdrak> actually, Pindar is getting us a budget for about 5 years infrastructure hosting.
5712016-08-25T18:33:47 <luke-jr> sipa: saivann/harding vs theymos/Cobra/someoneelse
5722016-08-25T18:33:54 <sipa> ah, ok
5732016-08-25T18:33:57 <btcdrak> should have the funding by October/November.
5742016-08-25T18:34:06 <gmaxwell> letsencrypt even sends email if you're going to expire.
5752016-08-25T18:34:54 <Lightsword> https://github.com/GUI/lua-resty-auto-ssl
5762016-08-25T18:34:56 <btcdrak> when wumpus and I spoke, he was quite clear about having a long term solution. also infrastructure hosting is a pita
5772016-08-25T18:34:56 <gmaxwell> Please never again setup pretextual security like that, it's an embarassment.
5782016-08-25T18:34:58 <Lightsword> for nginx should work
5792016-08-25T18:35:21 <btcdrak> gmaxwell: pretextural what?
5802016-08-25T18:35:27 <Lightsword> or certbot
5812016-08-25T18:35:29 <btcdrak> sorry, I mean what is pretextural
5822016-08-25T18:35:47 <wumpus> huh gmaxwell?
5832016-08-25T18:36:26 <gmaxwell> proxying through a third party to 'add SSL' when the connection just leaves cloudflare unencrypted and unauthenticated.
5842016-08-25T18:36:42 <gmaxwell> It appears secure to the user, but it's secure to a third party, and not even secure to the backend.
5852016-08-25T18:36:46 <afk11> certbot works quite well
5862016-08-25T18:36:49 <btcdrak> gmaxwell it's _not_
5872016-08-25T18:36:52 * luke-jr assumed btcdrak meant CloudFlare pinned the expired cert or something
5882016-08-25T18:36:54 <btcdrak> it's SSL to SSL
5892016-08-25T18:36:56 <wumpus> that's not even the case
5902016-08-25T18:37:13 <btcdrak> btw, this is the PR https://github.com/bitcoin/bitcoin/pull/7351
5912016-08-25T18:37:16 <afk11> btcdrak, it's not. it can be (gets you over CN mismatches), but they will proxy to a HTTP server
5922016-08-25T18:37:34 *** arubi has joined #bitcoin-core-dev
5932016-08-25T18:37:40 <btcdrak> afk11: no they wont, because it's set to Full SSL
5942016-08-25T18:37:46 <wumpus> gmaxwell: also dev.bitcoincore.org is *not* used for anything security critical, there are just some fallback files and gitian checks the hash
5952016-08-25T18:38:07 <wumpus> the only reason ssl was necessary there is that browsers frown on redirecting https to http
5962016-08-25T18:38:17 <sipa> i'm confused
5972016-08-25T18:38:29 <btcdrak> afk11: you can also configure the webserver to only accept connections from a certificate signed by CF
5982016-08-25T18:38:30 <gmaxwell> okay I was responding to "why is ... behind cloudflare" "it has to be to get the ssl".
5992016-08-25T18:38:53 <Lightsword> wumpus, bitcoincore.org is HSTS preloaded so http through browser wonât work at all for chrome and firefox
6002016-08-25T18:38:54 <wumpus> no, it's because of a cert issue with dev.bitcoincore.org, which is hopefully temporary
6012016-08-25T18:39:10 <gmaxwell> Okay.
6022016-08-25T18:39:37 <wumpus> Lightsword: right, that too
6032016-08-25T18:39:51 <gmaxwell> I thought this was another instance of "something hosted on github pages, then people complained about it not having ssl because security, so someone layerd cloudflare on top". My apologies.
6042016-08-25T18:40:06 <Lightsword> doesnât github force https?
6052016-08-25T18:40:10 <btcdrak> remember also, bitcoincore.org has HSTS preloading so we cannot use http:// on that domain.
6062016-08-25T18:40:26 <luke-jr> HSTS affects subdomains? :x
6072016-08-25T18:40:32 <wumpus> I'm not sure why we're even having an argument about this, is there an actual problem?
6082016-08-25T18:40:36 <wumpus> luke-jr: you can configure it to
6092016-08-25T18:40:39 <Lightsword> luke-jr, yeah itâs required to be on for HSTS preloading
6102016-08-25T18:40:47 <btcdrak> ^
6112016-08-25T18:40:48 <wumpus> please keep this channel restricted to bitcoin core development
6122016-08-25T18:41:01 <sipa> we need #bitcoin-core-org-dev :)
6132016-08-25T18:41:04 <btcdrak> LOL
6142016-08-25T18:41:13 <luke-jr> almost time for meeting btw
6152016-08-25T18:41:21 <wumpus> all the http and gpg etc talk is getting heavily off topic, yes I know I have been participating too
6162016-08-25T18:41:55 <sipa> wumpus: it looks like you've spent an awful lot of time on administrative stuff with 0.13
6172016-08-25T18:42:02 <gmaxwell> It's helpful to collaborate on things, even if they're offtopic. But not polite to people trying to read the logs. :)
6182016-08-25T18:42:03 <wumpus> sipa: yes :(
6192016-08-25T18:43:17 <btcdrak> more channels!
6202016-08-25T18:43:33 * btcdrak dashes for a tea break before the meeting
6212016-08-25T18:48:20 *** kadoban has quit IRC
6222016-08-25T18:49:26 *** kadoban has joined #bitcoin-core-dev
6232016-08-25T18:58:00 *** laurentmt has joined #bitcoin-core-dev
6242016-08-25T18:59:16 *** achow101 has joined #bitcoin-core-dev
6252016-08-25T18:59:31 *** jcorgan has joined #bitcoin-core-dev
6262016-08-25T18:59:42 *** Chris_Stewart_5 has quit IRC
6272016-08-25T19:00:01 <gmaxwell> #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
6282016-08-25T19:00:06 <instagibbs> here
6292016-08-25T19:00:09 <CodeShark> morning
6302016-08-25T19:00:13 <cfields_> hi, here
6312016-08-25T19:00:15 <kanzure> greetz
6322016-08-25T19:00:19 <murch> evening
6332016-08-25T19:00:32 <jonasschnelli> Meeting?
6342016-08-25T19:00:41 <sipa> pÅÄÈá»Ã±Å¥
6352016-08-25T19:01:00 * luke-jr gives sipa some frogs as a present.
6362016-08-25T19:01:21 <gmaxwell> yum.
6372016-08-25T19:01:43 <paveljanik> topics?
6382016-08-25T19:01:47 <MarcoFalke> no chair?
6392016-08-25T19:02:00 <paveljanik> I'd like to ask for more ACKs on Wshadow PRs
6402016-08-25T19:02:13 <gmaxwell> too bad, we haven't started so you can't ask for that yet.
6412016-08-25T19:02:27 <gmaxwell> :P
6422016-08-25T19:02:29 <kanzure> hehe
6432016-08-25T19:02:37 <wumpus> #startmeeting
6442016-08-25T19:02:37 <lightningbot> Meeting started Thu Aug 25 19:02:37 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
6452016-08-25T19:02:37 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
6462016-08-25T19:02:51 <btcdrak> here
6472016-08-25T19:02:57 <paveljanik> I'd like to ask for more ACKs on Wshadow PRs
6482016-08-25T19:02:59 <paveljanik> ;-)
6492016-08-25T19:03:12 <cfields_> seconded. Will ACK/re-ACK.
6502016-08-25T19:03:18 <gmaxwell> paveljanik: as you wish.
6512016-08-25T19:03:18 *** laurentmt has quit IRC
6522016-08-25T19:03:32 <instagibbs> paveljanik, pr #?
6532016-08-25T19:03:34 <cfields_> (i caught a bug of my own with -Wshadow yesterday)
6542016-08-25T19:03:36 <instagibbs> for those not initiated
6552016-08-25T19:03:37 <MarcoFalke> paveljanik: I ACKed all. Anything I missed?
6562016-08-25T19:03:40 <gmaxwell> Give the PP@.
6572016-08-25T19:03:55 <gmaxwell> gr. PR#
6582016-08-25T19:03:59 <MarcoFalke> https://github.com/bitcoin/bitcoin/pulls/paveljanik
6592016-08-25T19:04:20 <paveljanik> 8449, 8472, 8191, 8163, 8109
6602016-08-25T19:04:43 <paveljanik> but yes, Marco's link is even better
6612016-08-25T19:05:00 <wumpus> anything that really needs to be discussed at the meetng?
6622016-08-25T19:05:26 <CodeShark> no, we've already accomplished everything - there's nothing more to do ever
6632016-08-25T19:05:32 <gmaxwell> woot.
6642016-08-25T19:05:33 <sipa> i'd like to bring up the various proposals for segwit DoS protection
6652016-08-25T19:05:38 <gmaxwell> ^
6662016-08-25T19:05:39 <instagibbs> ack
6672016-08-25T19:05:41 <petertodd> ack
6682016-08-25T19:05:41 <btcdrak> ack
6692016-08-25T19:05:47 <wumpus> well I'm very happy we finally managed to release 0.13.0, congrats everyone!
6702016-08-25T19:05:51 <paveljanik> Do we have any numbers of 0.13.0 nodes?
6712016-08-25T19:05:56 <cfields_> topic suggestion: codesigning update
6722016-08-25T19:05:58 <paveljanik> congrats to wumpus!
6732016-08-25T19:06:05 * jonasschnelli is checking the 0.13 nodes on his seeder
6742016-08-25T19:06:07 <instagibbs> paveljanik, few hundred ones bitnodes has reached
6752016-08-25T19:06:09 <btcdrak> beer for wumpus
6762016-08-25T19:06:12 <sipa> wumpus: congrats to all, and thanks a lot wumpus
6772016-08-25T19:06:13 <wumpus> #topic proposals for segwit DoS protection
6782016-08-25T19:06:21 <gmaxwell> Some of this is more general than segwit. There as some existing minor vulnerablities that have been ignored, which were pointed out in segwit form. Good to resolve those too.
6792016-08-25T19:06:35 <luke-jr> paveljanik: http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
6802016-08-25T19:06:51 <murch> paveljanik: 322 (according to bitnodes)
6812016-08-25T19:06:56 <gmaxwell> Congrats on 0.13. It looks like a great release.
6822016-08-25T19:06:57 <jonasschnelli> cat dnsseed.dump | grep "0.13.0" | grep " 1 " | wc -l ---> 62
6832016-08-25T19:07:01 <sipa> so the main issue is #8279
6842016-08-25T19:07:37 <jonasschnelli> 213 seeds in non-good state (probably just set up)
6852016-08-25T19:07:43 <jonasschnelli> s/seeds/nodes
6862016-08-25T19:08:09 <gmaxwell> there are a lot more parties running it than accepting inbound, as typical.
6872016-08-25T19:08:11 <sipa> and there have been several proposed solutions, including: verify all inputs (even if the transaction is too big or below feerate), not entering failed witness txn into the reject table, making feefilter mandatory, ...
6882016-08-25T19:08:30 <jonasschnelli> https://github.com/bitcoin/bitcoin/issues/8279
6892016-08-25T19:08:51 <gmaxwell> sipa: I think all of these changes are beneficial.
6902016-08-25T19:08:52 <kanzure> this is separate from the malleability confusion someone posted about the other day, ya?
6912016-08-25T19:09:07 <luke-jr> sipa: making feefilter mandatory, or merely always using it?
6922016-08-25T19:09:14 <instagibbs> kanzure, the linked github issue explains it
6932016-08-25T19:09:31 <sipa> luke-jr: you need to be able to rely on it, and be able to ban peers who disregard it
6942016-08-25T19:09:33 <gmaxwell> luke-jr: me means giving it an ack message and punting peers that violate it.
6952016-08-25T19:10:00 <sipa> luke-jr: as you're moving the responsibility for filtering things you won't accept to the sender
6962016-08-25T19:10:22 <luke-jr> ok, so <0.12 nodes wouldn't be kicked
6972016-08-25T19:10:28 <gmaxwell> right.
6982016-08-25T19:10:31 <petertodd> segwit is a good opportunity to make feefilter mandatory, given we're completely changing what nodes we connect too
6992016-08-25T19:10:34 <kanzure> instagibbs: for example; someone was unaware that adding witness data to a non-segwit script was consensus-invalid. but er, your link seems more productive anyway, so nevermind.
7002016-08-25T19:11:05 <btcdrak> petertodd: i think that is the plan
7012016-08-25T19:11:20 <sipa> yes, but it seems hasty to do that along with 0.13.1
7022016-08-25T19:11:47 *** kadoban has quit IRC
7032016-08-25T19:11:58 <gmaxwell> in any case, "verify all inputs" was a proposal from before segwit was even imagined.
7042016-08-25T19:12:00 <petertodd> sipa: sure, but 0.13.1 also "hastily" has to stop fetching stuff from non-segwit nodes
7052016-08-25T19:12:12 *** kadoban has joined #bitcoin-core-dev
7062016-08-25T19:12:19 <sipa> petertodd: by hasty i mean we haven't implemented/tested/... a mandatory feefilter yet
7072016-08-25T19:12:29 <sipa> we have tested the relay behaviour of segwit vs non-segwit peers
7082016-08-25T19:13:21 <gmaxwell> I believe the primary reason we didn't just make the verify all inputs change is that it was proposed before feefilter, during spam attacks, and there was a lot of rejected stuff coming from even cooperative peers. That should be resolving now.
7092016-08-25T19:13:23 <petertodd> sipa: but thats the thing, you can just make it mandatory if the peer is a segwit peer, and leave the current behavior the same otherwise - non-segwit peers can't send us segwit txs at all (other than ones stripped of their witnesses which is easy to detect)
7102016-08-25T19:13:59 <sipa> petertodd: we still need a new network message etc
7112016-08-25T19:14:13 <sipa> otherwise peers can just ignore your feefilter
7122016-08-25T19:14:29 <petertodd> sipa: maybe I'm missing something, but why do we need a new network message?
7132016-08-25T19:14:31 <luke-jr> sipa: I think petertodd is saying "segwit peers MUST NOT ignore feefilter"
7142016-08-25T19:14:48 <gmaxwell> petertodd: because the protocol is async, we don't know if the far end has recieved our feefilter request yet.
7152016-08-25T19:14:50 <sipa> petertodd: you don't know what the last feefilter message you sent is that your peer received
7162016-08-25T19:15:15 <petertodd> sipa: ah right, duh...
7172016-08-25T19:15:26 <gmaxwell> so you send a feefilter, remote sends an inv.. you get the data.. oops failed filter.. Was the far end bad or just too fast?
7182016-08-25T19:15:56 <gmaxwell> so the suggestion there is to add a feefilterack, and punt peers that should send it but don't send it 'fast enough'
7192016-08-25T19:15:59 <petertodd> sipa: I had it in my head that feefilter worked the other way around, and already had a new inv with fee info...
7202016-08-25T19:15:59 <luke-jr> are there any possible nodes where implementing feefilter would be a burden? I think we already need fee info to relay transactions anyway, right?
7212016-08-25T19:16:31 <gmaxwell> luke-jr: yes, thats part of the consideration.
7222016-08-25T19:16:54 <sipa> i expect that most of the problems are solved with just having feefilter
7232016-08-25T19:17:27 <sipa> and we can just do #8525 now
7242016-08-25T19:17:34 <luke-jr> hm, what if we change feerate's definition and want to get rid of the current algo some day?
7252016-08-25T19:17:36 <sipa> (don't store witness txn in the reject cache)
7262016-08-25T19:17:54 <gmaxwell> I think we should be able to always validate now that feefilter is in place. The only argument I recall against always validating is that that a significant fraction of all recieved txn failed the fee check. That should be much less true now.
7272016-08-25T19:17:59 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8525
7282016-08-25T19:18:16 <petertodd> sipa: that could be a problem in the future if we have peers with different non-fee-related acceptance criteria than us
7292016-08-25T19:18:25 <CodeShark> I kinda like the idea of an inv with fee data - slightly larger messages but no need for state
7302016-08-25T19:18:30 <gmaxwell> reject cache was 90% implemented for lack of a fee filter.
7312016-08-25T19:18:43 <sipa> gmaxwell: that would open up many attacks... i don't think those are impossible to fix, but it needs a lot of analysis
7322016-08-25T19:18:54 <gmaxwell> I disagree.
7332016-08-25T19:19:21 <sipa> i like the idea of always validating (as #8593 does), but it feels risky
7342016-08-25T19:19:27 <gmaxwell> An uncached UTXO lookup eclipses the validation costs on most systems by orders of magnitude.
7352016-08-25T19:19:51 <petertodd> gmaxwell: yeah, I don't see how an attacker who can DoS attack by sending specially crafted txs is ever stopped by the other validation rules, and yes, UTXO looking is expensive too
7362016-08-25T19:20:12 <CodeShark> can't we consider extreme cases?
7372016-08-25T19:20:31 <CodeShark> what's the maximum possible validation cost for a single transaction?
7382016-08-25T19:21:01 <sipa> huge... remember we can't have any feerate or size based rejection criteria beforehand
7392016-08-25T19:21:33 <gmaxwell> well you can have a stripped size limit.
7402016-08-25T19:21:54 <sipa> yes, #8593 does that
7412016-08-25T19:21:59 <sipa> but you can't use fee
7422016-08-25T19:22:14 *** skyraider has joined #bitcoin-core-dev
7432016-08-25T19:22:19 <sipa> or at least not actual feerate, only stripped-size-feerate
7442016-08-25T19:22:53 <CodeShark> I'm not sure if this is what petertodd was referring to above - but I was imagining an inv that sends not just transaction hash - it also sends fee amount and tx size
7452016-08-25T19:23:11 <petertodd> sipa: so, an attacker who was trying to DoS attack you would just pay enough fee, with a tx that triggered O(n^2) complexity
7462016-08-25T19:23:31 <petertodd> sipa: so I don't see the value of feerate in preventing DoS attack there anyway
7472016-08-25T19:23:41 <sipa> an attacker can now craft a very expensive valid transaction that has a feerate too low to be acceptable to you, but stripped-size-feerate high enough
7482016-08-25T19:23:50 <sipa> and you'll validate it, but not relay
7492016-08-25T19:24:43 <gmaxwell> CodeShark: improved invs are a fine thing, longer term (though we should be spending our time on reconcillation, IMO) -- but I think the focus of the discussion is on shorter term since we likely need some improvements for 0.13.
7502016-08-25T19:24:47 <petertodd> right, but relaying is worse! we're then attacking others, and there's still no guarantee the tx will get mined, allowing the attacker to doublespend and repeat
7512016-08-25T19:25:03 <sipa> petertodd: well in no case will any of this relay
7522016-08-25T19:25:16 <gmaxwell> An alternative jl2012 suggested to validating all was to randomly validate some percentage. This will allow you to punt a peer sending you garbage, but you only take a fraction of the cost.
7532016-08-25T19:26:11 <CodeShark> gmaxwell: it seems simpler to just create a new static inv structure than to have to manage session states and do feefilteracks and stuff like that
7542016-08-25T19:26:41 <petertodd> sipa: sure, so then why not kick peers that send us DoS attack txs? IsStandard() has been around long enough that we could get away with that
7552016-08-25T19:27:04 <sipa> CodeShark: i think mandatory feefilter is a better solution than adding 10 kB of data to each inv
7562016-08-25T19:27:10 <gmaxwell> CodeShark: not so, right now inv bandwidth is already _greater_ than transaction bandwidth. You can't really escape the need to have people not send you things you're totally disinterested in.
7572016-08-25T19:28:05 <CodeShark> 10kB of data?
7582016-08-25T19:28:26 <CodeShark> the fee is uint64 and the tx size is varint
7592016-08-25T19:28:35 <sipa> CodeShark: txid, wtxid, fee, feerate, stripped feerate, size, sigops, bytes hashed, ... anything else that may affect your policy
7602016-08-25T19:28:48 <CodeShark> ok, fair enough
7612016-08-25T19:28:56 <sipa> inv bandwidth is larger than tx bandwidth by a factor of 5 on my node
7622016-08-25T19:29:05 <luke-jr> sipa: let's make it configurable! /s
7632016-08-25T19:29:25 <sipa> and that's between feefilter nodes
7642016-08-25T19:30:22 <sipa> so... do we think jl2012's approach of validating everything (or a fraction thereof) is the way to go for 0.13.1
7652016-08-25T19:30:25 <sipa> ?
7662016-08-25T19:30:36 <CodeShark> I haven't done the math
7672016-08-25T19:30:36 <sipa> the code is simple at least
7682016-08-25T19:30:48 <sipa> CodeShark: getpeerinfo
7692016-08-25T19:30:54 <sipa> shows bytes per message
7702016-08-25T19:30:56 <gmaxwell> This is why I think we need reconciliation for any inv improvement long term.
7712016-08-25T19:31:04 <sipa> yes
7722016-08-25T19:31:13 <sipa> but the meeting time is half, let's not stray too far
7732016-08-25T19:31:21 <sipa> i'd like to know what we're going to do for 0.13.1
7742016-08-25T19:31:26 <instagibbs> sipa, your guess is as ~~good as~~ better than mine
7752016-08-25T19:31:28 <CodeShark> sipa: I mean, I haven't done the math for validation cost edge cases
7762016-08-25T19:31:35 <gmaxwell> sipa: I jl2012's sampling suggestion is a pretty good idea, coupled with not reject filtering them.
7772016-08-25T19:32:22 <sipa> gmaxwell: right... either fully validate, or don't store in reject
7782016-08-25T19:32:41 <sipa> i like
7792016-08-25T19:32:53 <sipa> ok, other topics?
7802016-08-25T19:32:55 <petertodd> I suspect we'd be better off kicking peers who send us >100KB txs
7812016-08-25T19:33:09 <petertodd> (rather than any kind of probabalistic thing)
7822016-08-25T19:33:28 <afk11> hardware signing BIP?
7832016-08-25T19:33:50 <sipa> there were a few other topic ideas before
7842016-08-25T19:34:18 <wumpus> #topic code signing
7852016-08-25T19:34:19 <petertodd> afk11: that's off-topic to Bitcoin Core development right now
7862016-08-25T19:34:20 <gmaxwell> petertodd: yes, we can do that-- and I think we should--, but I think it's not sufficient.
7872016-08-25T19:34:21 <wumpus> @cfields_
7882016-08-25T19:34:37 <wumpus> petertodd: it's on topic for the future though
7892016-08-25T19:34:39 <petertodd> gmaxwell: well, I mean in combination with fully validating
7902016-08-25T19:34:40 *** cryptapus_ has quit IRC
7912016-08-25T19:34:49 <petertodd> wumpus: sure, why I said "right now" :)
7922016-08-25T19:34:52 <gmaxwell> petertodd: okay. lets talk after meeting.
7932016-08-25T19:35:02 <cfields_> so, i just wanted to bring this up before i finish the work, in case anyone has any suggestions for improvements
7942016-08-25T19:35:04 <cfields_> https://github.com/theuni/osx-codesign
7952016-08-25T19:35:21 <cfields_> I have a working codesigner for osx from linux, so an osx machine is no longer needed for the release process
7962016-08-25T19:35:38 <gmaxwell> \O/
7972016-08-25T19:35:47 <sipa> great
7982016-08-25T19:35:48 <cfields_> but i'm curious to see if anyone has any suggstions for more complicated/distributed signing schemes, before just implementing it as it was before
7992016-08-25T19:35:55 <CodeShark> cfields_: nice
8002016-08-25T19:35:57 <btcdrak> cfields_ except for extracting the MacOS SDK...
8012016-08-25T19:35:58 <jonasschnelli> cfields_: very nice. Lots of devs are looking for something!
8022016-08-25T19:36:01 <jonasschnelli> like that
8032016-08-25T19:36:05 <wumpus> cfields_: nice work!
8042016-08-25T19:36:26 <sipa> cfields_: what cryptography does it use?
8052016-08-25T19:36:28 <cfields_> (as of now it produces valid signed binaries given very specific constraints, it just needs to be tidied up and plugged into gitian)
8062016-08-25T19:36:48 <luke-jr> cfields_: plugged into gitian?
8072016-08-25T19:36:53 <petertodd> cfields_: nice license!
8082016-08-25T19:37:10 <jonasschnelli> GNU AFFERO GENERAL PUBLIC LICENSE,... hell!
8092016-08-25T19:37:25 <gmaxwell> :)
8102016-08-25T19:37:41 * luke-jr agrees it's a good choice of license. âº
8112016-08-25T19:37:41 <cfields_> sipa: there's no choice in that, i haven't even looked into the signature type
8122016-08-25T19:37:54 <gmaxwell> If it is RSA or schnorr we can secret share the key.
8132016-08-25T19:38:14 <cfields_> sipa: it basically collects all of the files to be embedded, creates a custom wonky structure out of them, signs, and embeds the final hash in the binary
8142016-08-25T19:38:21 <petertodd> jonasschnelli: I like AGPL because I'm not stinkin' commie
8152016-08-25T19:38:39 <cfields_> along with a mostly redundant detached xml with the same hashes
8162016-08-25T19:38:45 <gmaxwell> cfields_: how are you signing if you don't know how it's signing? :)
8172016-08-25T19:39:01 <cfields_> sorry, not my license choice. 99% of the code is borrowed from an ios tool
8182016-08-25T19:39:31 <jonasschnelli> I guess you need to update "sudo xcode-select --switch /Applications/Xcode-4.6.3.app"
8192016-08-25T19:39:35 <cfields_> gmaxwell: PKCS7_sign(), openssl does the hard work :)
8202016-08-25T19:39:37 <gmaxwell> nothing wrong with AGPL for a tool like this, licensing is a tool.
8212016-08-25T19:39:38 <jonasschnelli> Hard to download older version of Xcode
8222016-08-25T19:39:47 <gmaxwell> cfields_: how big is the signature? :P
8232016-08-25T19:40:23 <cfields_> gmaxwell: i can dump you some samples after the meeting
8242016-08-25T19:40:44 <gmaxwell> great, in any case, I'd like to talk about integrating multiparty signing into it. it might be easy to accomplish.
8252016-08-25T19:40:47 <cfields_> but back to the point: is anyone interested in coming up with a signing scheme that deviates from what we have now?
8262016-08-25T19:41:11 <cfields_> oh, i suppose that's why you want to know about sig type :)
8272016-08-25T19:41:18 <gmaxwell> Yes.
8282016-08-25T19:41:23 <sipa> yes.
8292016-08-25T19:41:28 <jonasschnelli> gmaxwell: my OSX code signing certs are RSA 2048 Bit
8302016-08-25T19:41:45 <michagogo> cfields_: your signer is missing a README
8312016-08-25T19:41:50 <petertodd> cfields_: I'm already working on codesigning as my first application for dex
8322016-08-25T19:42:01 <sipa> oh, let's just switch bitcoin to use prime factoring as PoW
8332016-08-25T19:42:11 <cfields_> same here, what i'm not sure about is how much you're allowed to change around the sig format
8342016-08-25T19:42:44 <cfields_> (for osx, the signing cert must be signed by apple)
8352016-08-25T19:42:49 <wumpus> yes, IIRC PKCS7 is simply RSA wrapped in ASN.1 mess
8362016-08-25T19:43:12 <cfields_> yes
8372016-08-25T19:43:25 <cfields_> and apple adds a weird little scripting language around 'designated requirements'
8382016-08-25T19:43:35 <wumpus> congrats on cracking that :)
8392016-08-25T19:43:37 <sipa> cfields_: well there could be several signers, and we get a cert for the combined key?
8402016-08-25T19:43:50 <jonasschnelli> The question is, does code-signing really increases the security of bitcoin-core...
8412016-08-25T19:44:05 <cfields_> so you can add other restrictions, but again, i'm not sure how much apple lets you deviate from the default
8422016-08-25T19:44:11 <luke-jr> jonasschnelli: imagine where common gitian builders all sign themselves and combine the sig
8432016-08-25T19:44:12 <gmaxwell> the straightforward way of doing threshold RSA needs a trusted dealer. but at least its multiparty after setup.
8442016-08-25T19:44:19 <petertodd> jonasschnelli: I suspect the code-signature-verification is what increases the security of bitcoin-core :)
8452016-08-25T19:44:34 <jonasschnelli> petertodd: i rather say verifing of gitian signatures...
8462016-08-25T19:44:44 <luke-jr> jonasschnelli: essentially we'd get the OS to verify the gitian builds in this case
8472016-08-25T19:44:45 <cfields_> jonasschnelli: yes and no. the code-signing itself, not really. but code-signing does allow you to force-on the osx sandbox, which is interesting for security
8482016-08-25T19:44:49 <jonasschnelli> OSX code signatures are from "Bitcoin Foundation"... anyone could hold the key
8492016-08-25T19:45:03 <sipa> i'm sure we can get a new cert
8502016-08-25T19:45:08 <petertodd> jonasschnelli: the gitian signatures aren't ever going to be much more secure than the code signatures
8512016-08-25T19:45:11 <jonasschnelli> cfields_: Yes. But thats just a restrriction from apple...
8522016-08-25T19:45:13 <cfields_> jonasschnelli: (we haven't messed with the sandboxing yet, afaik)
8532016-08-25T19:45:18 <jonasschnelli> and sandboxing is impossible for bitcoin core right now
8542016-08-25T19:45:23 <petertodd> jonasschnelli: also, lots of people don't use the gitian builds (I've never personally run one)
8552016-08-25T19:45:26 <gmaxwell> We can get a new cert and we should improve the maintaince of it so no one person needs to hold the key-- it's a good practice.
8562016-08-25T19:45:45 <kanzure> someone should make sure to watch petertodd do a gitian build in milan :)
8572016-08-25T19:45:48 <cfields_> jonasschnelli: ah ok, i've been meaning to look into it. if you already have, i'm very curious to hear your thoughts after the meeting
8582016-08-25T19:45:53 *** Ylbam has quit IRC
8592016-08-25T19:46:28 <jonasschnelli> cfields_: sure. But nice work! Linux based OSX/iOS code signing is highly appriciated by lots of devs.
8602016-08-25T19:46:33 <cfields_> just to reiterate though: osx-codesign is 99% ripped from a tool from Saurek. I just ported to osx and updated.
8612016-08-25T19:46:39 <kanzure> saurik
8622016-08-25T19:46:46 <cfields_> *Saurik. Thanks.
8632016-08-25T19:47:04 <sipa> saurik?
8642016-08-25T19:47:09 <cfields_> jonasschnelli: right, mostly I got tired of having to have my macbook for signing.
8652016-08-25T19:47:16 <kanzure> /whois saurik
8662016-08-25T19:47:23 <cfields_> and it limits the amount of people who can do the signing
8672016-08-25T19:47:36 <jonasschnelli> Indeed
8682016-08-25T19:47:46 <jonasschnelli> though you can run a OSX VM on a Linux machine. :)
8692016-08-25T19:47:57 <cfields_> heh
8702016-08-25T19:47:58 <jonasschnelli> (and violate apples TOC)
8712016-08-25T19:48:02 * luke-jr peers at his common channels with saurik
8722016-08-25T19:48:06 <gmaxwell> cfields_: so I think good job, continue on, and I (and sipa?) will look into threshold signing for 2048 bit RSA and see if we can't get it so that no single party holds that key.
8732016-08-25T19:48:18 <kanzure> sipa: he is known for various ios reverse engineering things
8742016-08-25T19:48:22 <CodeShark> is 4096 overkill?
8752016-08-25T19:48:23 <sipa> ah, cool
8762016-08-25T19:48:25 <cfields_> gmaxwell: perfect, thanks.
8772016-08-25T19:48:31 <gmaxwell> (as an aside, this could also be done with wumpus' release key)
8782016-08-25T19:48:37 <jeremyrubin> 4096 not overkill
8792016-08-25T19:48:38 <kanzure> sipa: (pm)
8802016-08-25T19:48:41 *** cryptapus_ has joined #bitcoin-core-dev
8812016-08-25T19:48:42 *** cryptapus_ is now known as cryptapus_afk
8822016-08-25T19:49:03 <sipa> CodeShark: 3000 bits RSA is approximately equivalent with 256 bit EC
8832016-08-25T19:49:05 <jonasschnelli> CodeShark: 2048 gives use 118bit of security.. ECDSA 128 I guess... enought?
8842016-08-25T19:49:09 <gmaxwell> CodeShark: I believe we don't get to choose the parameters of this key.
8852016-08-25T19:49:18 <jonasschnelli> Yes. Apples does it.
8862016-08-25T19:49:22 <CodeShark> oh, right
8872016-08-25T19:49:29 <gmaxwell> Otherwise it would be 4096 bit. because duh.
8882016-08-25T19:49:37 <cfields_> gmaxwell: i'll try to find out if other signature types are possible.
8892016-08-25T19:49:45 * jonasschnelli is trying a 4096 key
8902016-08-25T19:49:48 <gmaxwell> (the size and performance are basically irrelevant)
8912016-08-25T19:51:00 <jeremyrubin> unrelated question while everyone is in meeting: having a lot of trouble getting my code to pass travis, but can pass locally on a few diff machines. If anyone has any ideas, ping me after meeting.
8922016-08-25T19:51:21 <jonasschnelli> To shortly come back to afk11 topic: there has been a proposal for detached signing: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013008.html
8932016-08-25T19:51:25 <kanzure> jeremyrubin: got the core dumps yet?
8942016-08-25T19:51:34 <jonasschnelli> Which would allow decoupling the keys from the wallet(system)
8952016-08-25T19:51:50 <jeremyrubin> kanzure: nope; i tried changing the travis script to dump them but couldn't see anything.
8962016-08-25T19:52:19 <kanzure> you can probably call gdb bt from inside the after_failure segment
8972016-08-25T19:52:21 <jonasschnelli> to end the wild-west APIs/interfaces that are currently been implemented by wallets and hardware-wallet vendors
8982016-08-25T19:52:26 <wumpus> I very much like the idea of standardizing detached signing
8992016-08-25T19:52:32 <wumpus> yes, exactly
9002016-08-25T19:52:54 <jonasschnelli> One of the main problems users have and will have with wallets is to keep private keys private.
9012016-08-25T19:53:29 <wumpus> it makes no sense to try to support detached signing in bitcoin core until there is some kind of standard, if every hw vendor is going to hook in their own code in their own way it isgoing to be a mess
9022016-08-25T19:53:42 <btcdrak> jonasschnelli: well you'd hope hardware signing devices will become more commonplace
9032016-08-25T19:53:53 <CodeShark> they will
9042016-08-25T19:54:04 <instagibbs> 7 minutes, any more topics?
9052016-08-25T19:54:08 <CodeShark> it's not something we should hope for - it's something we should make happen
9062016-08-25T19:54:08 <wumpus> no doubt about that, though it's two-sided, software also needs to support them
9072016-08-25T19:54:09 <jonasschnelli> Yes. I proposed the URLScheme standard... even, I don't like it in the first place.. but its probably the only choice if we'd like to address all systems and platforms.
9082016-08-25T19:54:21 <wumpus> CodeShark: jonasschnelli is helping make it happen
9092016-08-25T19:54:28 <sipa> the topic is still codesigning :)
9102016-08-25T19:54:45 <petertodd> btcdrak: also note that in systems like Qubes, detached signing in another VM is a significant security improvement even w/o special hardware
9112016-08-25T19:54:47 <btcdrak> yes. detached signing is more for the bitcoin-dev ML
9122016-08-25T19:54:58 <petertodd> btcdrak: Qubes does this for GPG already
9132016-08-25T19:55:04 <gmaxwell> jonasschnelli: I think at this point the discussion should stop and some prototypes should be tried. You've seen there is some support and some opposition, and thats fine.
9142016-08-25T19:55:04 <wumpus> do we still have anything to say about codesigning?
9152016-08-25T19:55:07 <btcdrak> petertodd: interesting
9162016-08-25T19:55:24 <jonasschnelli> gmaxwell: Yes. I'm working on a PoC with static data between Core and iOS.
9172016-08-25T19:55:40 <sipa> wumpus: i believe not, i was only casually complaining about the random switch of topic :)
9182016-08-25T19:55:58 <jonasschnelli> my fault. sry.
9192016-08-25T19:56:10 <gmaxwell> jonasschnelli: okay, even simpler-- I think we should change our standard operation to have walletpassphrase and decrypt and sign done by a seperate mlocked process.
9202016-08-25T19:56:22 <wumpus> petertodd: yes, it should be general enough to support that scenario as well, but I think that's handled if it works for hw signing, just expose a 'virtual' hw device
9212016-08-25T19:56:31 <wumpus> sipa: agreed, it's a bit of a sudden switch
9222016-08-25T19:56:54 <wumpus> time to end the meeting maybe
9232016-08-25T19:57:10 <wumpus> #endmeeting
9242016-08-25T19:57:10 <lightningbot> Meeting ended Thu Aug 25 19:57:10 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
9252016-08-25T19:57:10 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-25-19.02.html
9262016-08-25T19:57:10 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-25-19.02.txt
9272016-08-25T19:57:10 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-25-19.02.log.html
9282016-08-25T19:57:13 <murch> sipa: average UTXO set size did turn out to be a very valuable evaluation criteria by the way.
9292016-08-25T19:57:25 <jonasschnelli> gmaxwell: I think it should be split into two applications
9302016-08-25T19:57:28 <sipa> murch: cool
9312016-08-25T19:57:46 <gmaxwell> jonasschnelli: How so?
9322016-08-25T19:58:12 <jonasschnelli> wallet does only hold pubkeys,... it can retrieve new keys or signatures over the sign:// URL scheme
9332016-08-25T19:58:12 *** cryptapus has quit IRC
9342016-08-25T19:58:20 <jonasschnelli> sign://getkeys?amount=10
9352016-08-25T19:58:31 <jonasschnelli> sign://sign?type=bitcointx&somedata=xyz
9362016-08-25T19:58:37 <CodeShark> wallet stuff really needs to be a separate project - bitcoin-core-dev should focus on consensus and p2p stuff :p
9372016-08-25T19:58:45 <gmaxwell> CodeShark: I disagree.
9382016-08-25T19:58:48 *** achow101 has quit IRC
9392016-08-25T19:59:32 <jonasschnelli> If we scale and all uses that jump on the nicely scaled bitcoin bus and use webbased or heavy centarlized insecure walltes... we can stop focus on consensus and p2p
9402016-08-25T19:59:37 <jonasschnelli> *users
9412016-08-25T19:59:42 <gmaxwell> jonasschnelli: now thats batching things into having 'multiple wallet' data stores.
9422016-08-25T20:00:09 <jonasschnelli> No really. Just separating private-key from the wallet
9432016-08-25T20:00:17 <jonasschnelli> *keys
9442016-08-25T20:00:18 <gmaxwell> you mean seperating the wallet from the wallet.
9452016-08-25T20:00:30 <CodeShark> the thing that needs to be separated is the signer
9462016-08-25T20:00:37 <jonasschnelli> No.. the wallet is much more then the private-keys...
9472016-08-25T20:00:39 <CodeShark> along with all private key data
9482016-08-25T20:00:55 <jonasschnelli> private-keys do only sign data... 90% is wallet logic.
9492016-08-25T20:00:57 <CodeShark> and the signing request protocol can be defined abstractly
9502016-08-25T20:01:03 <gmaxwell> jonasschnelli: Yes it is, but the thing 99% of the care goes into is the keying material.
9512016-08-25T20:01:32 <gmaxwell> jonasschnelli: in any case, all I am suggesting there is that the wallet be able to store a blob on behalf of the signer, and be able to return that blob to the signer when asking it to sign.
9522016-08-25T20:01:37 <CodeShark> the signing device doesn't need to store history and perhaps only very little state
9532016-08-25T20:01:57 <sipa> CodeShark: i think jonasschnelli is well aware of that
9542016-08-25T20:02:19 <CodeShark> I was replying to gmaxwell's "separate the wallet from the wallet" comment
9552016-08-25T20:02:24 <jonasschnelli> CodeShark: yes. It just needs the data that needed to verify the data-to-sign
9562016-08-25T20:02:36 <gmaxwell> jonasschnelli: and then my example of having a seperate interface to collect the passphrase and sign, works fine-- the signer would ask the wallet to store its encrypted key data. Then the signer needs no filesystem access.
9572016-08-25T20:02:37 <jonasschnelli> If you sign a PDF, you need the PDF along with the sha256(PDF)
9582016-08-25T20:02:54 <gmaxwell> (for that case)
9592016-08-25T20:03:30 <jonasschnelli> gmaxwell: what would be in the blob stored on behalf of the signer?
9602016-08-25T20:03:46 <jonasschnelli> Some king of authentication?
9612016-08-25T20:03:50 <sipa> jonasschnelli: encrypted keys in gmaxwell's examplr
9622016-08-25T20:03:50 <jonasschnelli> kind
9632016-08-25T20:04:00 <sipa> jonasschnelli: but you shouldn't care about what it is
9642016-08-25T20:04:15 <gmaxwell> jonasschnelli: in the case of the detatched signer which I think we should use in the GUI by default, it would be the encrypted master key. But bitcoin-core wouldn't really know or care what it is.
9652016-08-25T20:04:15 <michagogo> If anyone here has an iOS device and hasn't heard yet: update to iOS 9.3.5 ASAP.
9662016-08-25T20:04:17 <da2ce7> gmaxwell: I agree making the Hardware wallet storage-less other than securely holding a decryption key is a very attractive route.
9672016-08-25T20:04:42 <michagogo> A trio of critical security holes was just patched. And in the meantime stay away from untrusted links.
9682016-08-25T20:05:02 <CodeShark> the requestor sends a blob + metadata, signer displays metadata to user and asks for authorization, user authorizes, signer returns signed blob
9692016-08-25T20:05:11 <sipa> da2ce7: i think you misunderstand
9702016-08-25T20:05:29 <sipa> da2ce7: an actual hardware wallet would have its own state, of course
9712016-08-25T20:05:45 <gmaxwell> or maybe it wouldn't that would be up to its design.
9722016-08-25T20:05:46 <CodeShark> the interface could even provide for abstract sighash type
9732016-08-25T20:06:01 <jonasschnelli> sipa, gmaxwell: thanks... need to think about it. need to go afk.
9742016-08-25T20:06:35 <sipa> da2ce7: gmaxwell is just suggesting that if thr protocol allows the signer to ask the wallet to store data, it could replace our current wallet encryption scheme as well, by moving the signing part to a separare process
9752016-08-25T20:11:08 <kanzure> is the hardware wallet BIP thread the right place to pimp "libconsensus in HSM" stuff?
9762016-08-25T20:11:13 <gmaxwell> NO
9772016-08-25T20:11:25 <gmaxwell> actually I think that thread should be dropped for now.
9782016-08-25T20:12:25 <gmaxwell> I think too many speculative things are going for "BIP" now, this isn't really what the bip process is intended for. BIPs shouldn't be for speculative ideas. They should be so that implementations are documented and can interoperate.
9792016-08-25T20:12:59 <gmaxwell> There are many discussions that are being phrased as "lets have a BIP about X" when they should be "I think it would be useful for me to do X"
9802016-08-25T20:13:24 <gmaxwell> only after establishing that X is something that people might want to actually do, should it move onto "now we should have a standard for doing X"
9812016-08-25T20:14:37 *** BashCo has quit IRC
9822016-08-25T20:15:48 <gmaxwell> talking about it in the context of standards first seems to be having bad effects where people oppose ideas seemingly because they don't want to implement more things.
9832016-08-25T20:16:28 <MarcoFalke> jeremyrubin: You need to solve the merge conflict for travis to pick it up
9842016-08-25T20:16:39 <MarcoFalke> I will try to reproduce locally
9852016-08-25T20:17:36 <jeremyrubin> MarcoFalke: ah; will do. It's picked up on my fork
9862016-08-25T20:17:46 <jeremyrubin> https://travis-ci.org/JeremyRubin/bitcoin/builds/154016406
9872016-08-25T20:17:54 <MarcoFalke> ok
9882016-08-25T20:18:05 <jeremyrubin> I just added something to print out the test-suite.log after_failure
9892016-08-25T20:18:12 <jeremyrubin> so that's the newer build
9902016-08-25T20:22:58 *** cryptapus_afk has quit IRC
9912016-08-25T20:35:28 <jonasschnelli> gmaxwell: the hardware wallet signing thing is not really a BIP now. It's just something to think about I have sent to the ML...
9922016-08-25T20:36:06 <jonasschnelli> But I think a BIP would be the right think for a hardware wallet interface standard..
9932016-08-25T20:36:24 <jonasschnelli> *Thing
9942016-08-25T20:37:28 <sipa> sure, eventually
9952016-08-25T20:41:59 * jonasschnelli sometimes thinks that a wallet with privet-keys is like a home door with the key under the doormat
9962016-08-25T20:44:08 <instagibbs> jonasschnelli, you can start a SIP ;)
9972016-08-25T20:44:12 * instagibbs ducks
9982016-08-25T20:45:54 <gmaxwell> jonasschnelli: that is going a bit far, ultimately if your computere is totally compromised you probably can't use bitcoin correctly no matter having a hardware wallet or offline signing or what not.. at most you can slow the bleeding.
9992016-08-25T20:46:11 <gmaxwell> because your compromised computer will substitute any addresses you attempt to pay to.
10002016-08-25T20:46:29 <gmaxwell> and it will tell you that you've been paid, when you haven't been.
10012016-08-25T20:46:34 <jeremyrubin> MarcoFalke: I rebased onto master fyi so you'll want to -D your local if you pulled it
10022016-08-25T20:46:38 <jonasschnelli> Yeah. Agree. But...
10032016-08-25T20:47:12 <jonasschnelli> A hardware wallet or let say, a detached signer (assume a smartphone) can verify the data(tx) independently.
10042016-08-25T20:47:52 <jonasschnelli> Even if you computer is totally compromised, your signer would reveal that.
10052016-08-25T20:47:56 <sipa> jonasschnelli: how does the hw device verify it's sending to the right address
10062016-08-25T20:48:15 <sipa> it can show you, sure
10072016-08-25T20:48:24 <jonasschnelli> It would show it on a display?
10082016-08-25T20:48:34 <sipa> but how do you know the right address if your computer is hacked?
10092016-08-25T20:48:39 <jonasschnelli> Fees are a bit tricky
10102016-08-25T20:49:12 <jonasschnelli> That right... Your browser window where the address listed could be already compromised.
10112016-08-25T20:49:45 <jonasschnelli> In the world of "addresses", we have to assume it has been transmitted untempered
10122016-08-25T20:50:40 <gmaxwell> jonasschnelli: thats what I mean, if your computer is compromised it doesn't really matter what it displays, at least right now.
10132016-08-25T20:50:41 <jonasschnelli> At least the signer can identify if a receiving address is owned by the signer and also if a change address is
10142016-08-25T20:51:15 <jonasschnelli> But you might scan in a QRcode address...
10152016-08-25T20:53:27 <jonasschnelli> The receiving part can be made relatively secure. But I agree, the pay-to part - in case the pay-to addresses origin for you is your computer - cannot be made much more more secure through a signing device.
10162016-08-25T20:54:19 <gmaxwell> and similarly, there are two ways you can be robbed, by sending where you don't intend, or by thinking you were paid when you weren't. Existing hardware wallets do nothing about the latter.
10172016-08-25T20:54:25 <jonasschnelli> Malware targeting only you wallet software would be identified. A clever forged multi-app attack not.
10182016-08-25T20:55:12 *** Chris_Stewart_5 has joined #bitcoin-core-dev
10192016-08-25T20:55:32 *** aalex_ is now known as aalex
10202016-08-25T20:55:37 <MarcoFalke> jeremyrubin: This also fails locally on my 14.04vm
10212016-08-25T20:55:43 <MarcoFalke> Might be easier to debug
10222016-08-25T20:56:07 <jonasschnelli> gmaxwell: how can the later be exploited? You mean by displaying an attackers address instead of the owner ones?
10232016-08-25T20:56:59 <jeremyrubin> MarcoFalke: Awesome; maybe it's a virtualization thing
10242016-08-25T20:57:32 <jeremyrubin> Are you just using a vanilla 14.04?
10252016-08-25T20:58:00 <gmaxwell> the latter is that the attacker 'pays you' but never authors a transaction and your compromised host displays the transaction as confirmed.
10262016-08-25T20:58:41 <MarcoFalke> jup, I don't recall any specifics I changed
10272016-08-25T21:00:00 <jonasschnelli> Ah. I see. Yes. Hard to detect on the host even with a signing device... You would need access to a trusted offline in-sync air gapped node :-)
10282016-08-25T21:01:54 <gmaxwell> well it's not really that wild, you'd just need your wallet to hand all the payments to the hardware wallet with spv proofs and then it could display your balance and lists of transactions.
10292016-08-25T21:02:09 <gmaxwell> so at least that could be done.
10302016-08-25T21:02:41 <jeremyrubin> cool -- do you see anything interesting in the dump? (spinning one up now)
10312016-08-25T21:03:14 <gmaxwell> but the address substituion attacks don't have as easy a fix.. you need a PKI and send signed payment requests to the wallet. ;(
10322016-08-25T21:15:01 <luke-jr> instagibbs: SIPs are for altcoin stuffs ;)
10332016-08-25T21:39:52 *** MarcoFalke has left #bitcoin-core-dev
10342016-08-25T21:44:51 *** BashCo has joined #bitcoin-core-dev
10352016-08-25T21:54:08 *** belcher has joined #bitcoin-core-dev
10362016-08-25T21:55:53 *** Megaf has joined #bitcoin-core-dev
10372016-08-25T22:13:24 *** Megaf has quit IRC
10382016-08-25T22:28:50 *** cryptapus has joined #bitcoin-core-dev
10392016-08-25T22:28:50 *** cryptapus has joined #bitcoin-core-dev
10402016-08-25T22:29:12 *** cryptapus is now known as cryptapus_afk
10412016-08-25T22:32:15 *** Ylbam has joined #bitcoin-core-dev
10422016-08-25T22:34:33 *** spudowiar has joined #bitcoin-core-dev
10432016-08-25T22:36:05 *** murch has quit IRC
10442016-08-25T22:42:01 *** paracyst has joined #bitcoin-core-dev
10452016-08-25T22:51:44 *** JackH has quit IRC
10462016-08-25T23:03:02 <btcdrak> cfields_: I have successfully extracted the MacOS SDK from Xcode DMG directly linux :)
10472016-08-25T23:06:09 <luke-jr> btcdrak: how?
10482016-08-25T23:06:19 <btcdrak> black magic :)
10492016-08-25T23:07:26 <btcdrak> luke-jr: cfields: https://gist.github.com/btcdrak/6e67c84ed8375c9a9d506c2038622fc4
10502016-08-25T23:12:32 *** skyraider has quit IRC
10512016-08-25T23:13:39 <GreenIsMyPepper> ooo that's awesome ^_^
10522016-08-25T23:18:17 <btcdrak> GreenIsMyPepper: I think I have been cheated! the archive size doesnt match sigh
10532016-08-25T23:18:25 <luke-jr> âº
10542016-08-25T23:18:41 <luke-jr> btcdrak: the files are all empty
10552016-08-25T23:19:26 <btcdrak> =) oh well
10562016-08-25T23:23:12 *** achow101 has joined #bitcoin-core-dev
10572016-08-25T23:23:32 *** spudowiar has quit IRC
10582016-08-25T23:23:33 <cfields_> btcdrak: woohoo!
10592016-08-25T23:23:48 <cfields_> oh, heh
10602016-08-25T23:23:55 <btcdrak> cfields: :/
10612016-08-25T23:24:04 <cfields_> yes, hfsmount hasn't been touched in ages afaik
10622016-08-25T23:24:09 <cfields_> iirc there are files missing too
10632016-08-25T23:25:04 <btcdrak> I assume the extraction of the partition by 7z is fine, just the hfsmount is incompatible?
10642016-08-25T23:26:03 <gmaxwell> so I have a suggestion. We have the data, right? uncompress the download, and the take as side information a list of offsets to extract bytes from.
10652016-08-25T23:26:14 <gmaxwell> We can have side information as part of the process.
10662016-08-25T23:29:45 *** spudowiar has joined #bitcoin-core-dev
10672016-08-25T23:50:16 *** Cheeseo has quit IRC
10682016-08-25T23:53:15 <GitHub34> [bitcoin] gmaxwell opened pull request #8594: Do not add random inbound peers to addrman. (master...no_inbound_addr) https://github.com/bitcoin/bitcoin/pull/8594
10692016-08-25T23:54:23 *** Cheeseo has joined #bitcoin-core-dev
10702016-08-25T23:54:24 *** Cheeseo has joined #bitcoin-core-dev