12016-10-19T00:15:00 <aj> question: re: https://bitcoincore.org/en/2016/01/26/segwit-benefits/#compact-fraud-proofs -- as it turns out, that didn't make it in, right? those will need an additional merkle tree with an additional coinbase commitment with segwit as implemented, just as they would without segwit, yes/no?
22016-10-19T00:15:50 <gmaxwell> aj: right, or get picked up as part of some other addition that needs an additional commitment.
32016-10-19T00:17:22 <gmaxwell> it can be done with 'external commitments' in the same manner as the proposed commited bloom filters... meaning that it's possible to implement the whole software stack, but not get a commitment from the blockchain for it (instead get it from semitrusted servers or what not).. probably a good way to go to work out the design.
42016-10-19T00:19:14 *** achow101 has joined #bitcoin-core-dev
52016-10-19T00:19:41 <gmaxwell> aj: why do you ask?
62016-10-19T00:24:34 <aj> gmaxwell: have been pondering a companion segwit-costs/risks page, and when reviewing the benefits page thought that one seemed mistaken now
72016-10-19T00:26:54 <gmaxwell> yea, it's out of date, when god knows who announced segwit would be done in design and implemenation complete in April it just didn't give any time to finalize a design... and better to have fewer commitments than commitments you regret. :)
82016-10-19T00:27:41 <gmaxwell> they same deployment approach could be used though, so basically a straightforward extension.
92016-10-19T00:30:05 <GitHub75> [bitcoin] rebroad closed pull request #8958: Improve logic for advertising blocks (master...BetterBroadcastLogic) https://github.com/bitcoin/bitcoin/pull/8958
102016-10-19T00:30:10 <GitHub120> [bitcoin] rebroad reopened pull request #8958: Improve logic for advertising blocks (master...BetterBroadcastLogic) https://github.com/bitcoin/bitcoin/pull/8958
112016-10-19T00:31:47 <aj> yeah. i thought i remembered some other feature being mentioned that was implemented but wasn't in that list too. not coming to mind immediately though
122016-10-19T00:32:10 <gmaxwell> I don't think there was anything else.
132016-10-19T00:33:20 <gmaxwell> maybe the fact that pruned nodes could skip downloading stuff they wouldn't vakidate or keep? thats stull true though, commitment structure wise.
142016-10-19T00:33:56 <gmaxwell> maybe you were thinking of the n^2 sighash fix--- for a while that was implemented in the commitment structure but core wasn't making use of it to reduce the hashing, it does now.. however.
152016-10-19T00:45:53 *** Victor_sueca has joined #bitcoin-core-dev
162016-10-19T00:46:16 *** Victorsueca has quit IRC
172016-10-19T00:46:24 *** Victor_sueca is now known as Victorsueca
182016-10-19T00:48:20 *** testnet has joined #bitcoin-core-dev
192016-10-19T00:48:49 <aj> gmaxwell: ah, my irc logs remind me that it was the fix for the "sighash single bug" -- but i'm not entirely sure what that bug is precisely
202016-10-19T00:50:44 <gmaxwell> oh? I don't really consider that much of a bug, it's just a surprising feature. It has some vaguely constructive uses, in theory.
212016-10-19T00:52:05 <aj> gmaxwell: i think it's that "if you use SIGHASH_SINGLE on an input with a higher index in a transaction than the number of outputs, then that signature can be used by anyone to spend any UTXO sent to that address", but post segwit it can only spend that particular coin?
222016-10-19T00:56:31 <gmaxwell> aj: thats not incorrect.
232016-10-19T00:56:53 <aj> haha, high praise
242016-10-19T00:58:07 <gmaxwell> for non SW txn an out of bound single causes to to sign the 32 byte value 1. For SW it just causes you to sign no particular outputs for that input.
252016-10-19T00:58:24 <gmaxwell> but you still sign the prevouts.
262016-10-19T01:04:28 <Victorsueca> gmaxwell: the how is it prevented that somebody changes the outputs?
272016-10-19T01:04:51 <Victorsueca> then*
282016-10-19T01:07:04 *** Ylbam has quit IRC
292016-10-19T01:11:37 * Victorsueca wonders if he just asked the whole point of segwit and should read the docs instead
302016-10-19T01:14:06 <gmaxwell> Victorsueca: it's sighash single-- you're specifically flagging the signature so people can change outputs.
312016-10-19T01:38:41 *** fengling has joined #bitcoin-core-dev
322016-10-19T01:53:01 *** Victorsueca has quit IRC
332016-10-19T02:05:22 *** Victorsueca has joined #bitcoin-core-dev
342016-10-19T02:06:59 *** DigiByteDev has joined #bitcoin-core-dev
352016-10-19T02:10:51 <Victorsueca> OMG
362016-10-19T02:11:08 <Victorsueca> A wild bitcoin-qt.exe appeared
372016-10-19T02:11:25 *** whphhg has quit IRC
382016-10-19T02:11:34 <Victorsueca> it's finally compiled
392016-10-19T02:13:54 *** whphhg has joined #bitcoin-core-dev
402016-10-19T02:14:37 *** DigiByteDev has quit IRC
412016-10-19T02:14:53 *** DigiByteDev has joined #bitcoin-core-dev
422016-10-19T02:16:05 *** justanotheruser has joined #bitcoin-core-dev
432016-10-19T02:36:19 *** ill has joined #bitcoin-core-dev
442016-10-19T02:43:08 *** jtimon has quit IRC
452016-10-19T02:43:20 *** bluerazor has joined #bitcoin-core-dev
462016-10-19T02:43:22 *** Chris_Stewart_5 has quit IRC
472016-10-19T02:50:37 *** alpalp has quit IRC
482016-10-19T02:57:11 *** Alopex has quit IRC
492016-10-19T02:58:12 *** ill has quit IRC
502016-10-19T02:58:17 *** Alopex has joined #bitcoin-core-dev
512016-10-19T02:59:15 *** Victor_sueca has joined #bitcoin-core-dev
522016-10-19T03:01:50 *** Victorsueca has quit IRC
532016-10-19T03:05:22 *** Victorsueca has joined #bitcoin-core-dev
542016-10-19T03:05:55 *** Victor_sueca has quit IRC
552016-10-19T03:32:02 *** Alopex has quit IRC
562016-10-19T03:33:07 *** Alopex has joined #bitcoin-core-dev
572016-10-19T03:44:57 *** testnet has quit IRC
582016-10-19T04:03:26 *** Alopex has quit IRC
592016-10-19T04:04:31 *** Alopex has joined #bitcoin-core-dev
602016-10-19T04:07:12 *** JackH has quit IRC
612016-10-19T04:17:32 *** kadoban has quit IRC
622016-10-19T04:28:12 *** Alopex has quit IRC
632016-10-19T04:28:47 *** Giszmo has quit IRC
642016-10-19T04:29:17 *** Alopex has joined #bitcoin-core-dev
652016-10-19T04:39:02 *** Alopex has quit IRC
662016-10-19T04:40:07 *** Alopex has joined #bitcoin-core-dev
672016-10-19T04:49:55 <tulip> neat, I now have 11 peers with NODE_WITNESS (but all inbound, less than ideal).
682016-10-19T04:54:30 <gmaxwell> 4 on my bog standard host, all inbound.
692016-10-19T04:54:49 <tulip> that was on my bog standard host, too.
702016-10-19T04:55:37 <luke-jr> there's probably significantly fewer peers that they'll be willing to connect to
712016-10-19T04:56:15 <tulip> restarted the patched node and it managed 7/8 outbound peers as segwit, ha.
722016-10-19T04:57:33 <luke-jr> I thought it won't tolerate non-witness outbound peers at all?
732016-10-19T04:58:36 <tulip> in r1 you can end up with no NODE_WITNESS peers.
742016-10-19T04:59:04 <tulip> with #8949 you will continuously search until at least 4 as NODE_WITNESS.
752016-10-19T05:01:53 <gmaxwell> luke-jr: no, it makes 40 requests to addrman, and if it doesn't get any node_witness results, it gives up and uses a non-nodewitness one.
762016-10-19T05:02:02 <luke-jr> hm
772016-10-19T05:02:17 <gmaxwell> it turns out on mainnet there are so many non-nodewitness peers and such.. that it's pretty easy for it to get no node witness outbound peers at all, thus my PR.
782016-10-19T05:05:40 *** bluerazor has quit IRC
792016-10-19T05:06:15 *** bluerazor has joined #bitcoin-core-dev
802016-10-19T05:18:30 <luke-jr> what are things coming to, when we can't even find a witness peer anymore? :<
812016-10-19T05:19:11 <luke-jr> oh wait, that comment was meant for 2026, but this is 2016
822016-10-19T05:20:28 <jl2012> why 0.13.1rc1 binary is not yet released?
832016-10-19T05:21:43 <jl2012> aj: re SIGHASH_SINGLE: yes, BIP143 sort of fixed the bug
842016-10-19T05:22:19 <jl2012> or removed the unintentional "feature" of making a replay-able signature
852016-10-19T05:27:17 <gmaxwell> jl2012: in the past when we've encountered issues that would call for an RC2 before we shipped the RC1 binary we've sometimes just skipped it. I'm not sure if wumpus is planning on doing that.
862016-10-19T05:35:04 <btcdrak> jl2012: we are skippng RC1 because of the non version bump iirc
872016-10-19T05:37:06 <jl2012> btcdrak: it should be announced earlier so people won't waste time on building.....
882016-10-19T05:39:08 <gmaxwell> good practice? (sorry)
892016-10-19T05:40:32 *** bluerazor has quit IRC
902016-10-19T05:50:37 *** d_t has joined #bitcoin-core-dev
912016-10-19T05:51:19 *** DigiByteDev has joined #bitcoin-core-dev
922016-10-19T05:55:12 *** d_t has quit IRC
932016-10-19T06:10:09 *** aalex has quit IRC
942016-10-19T06:10:32 *** Alopex has quit IRC
952016-10-19T06:10:32 *** DigiByteDev has quit IRC
962016-10-19T06:11:37 *** Alopex has joined #bitcoin-core-dev
972016-10-19T06:11:40 *** bluerazo_ has joined #bitcoin-core-dev
982016-10-19T06:13:24 *** aalex has joined #bitcoin-core-dev
992016-10-19T06:33:17 *** Evel-Knievel has quit IRC
1002016-10-19T06:47:40 *** BashCo has quit IRC
1012016-10-19T06:59:15 *** AtashiCon has quit IRC
1022016-10-19T07:03:43 <wumpus> it should be announced earlier so people won't waste time on building <- still makes sense to build to make sure that your gitian infrastructure is working an capable of building deterministic 0.13.1 executables
1032016-10-19T07:04:08 <wumpus> also dependencies are cached by gitian so rc2 build will be faster
1042016-10-19T07:06:29 <GitHub108> [bitcoin] laanwj closed pull request #8962: Correct checksum error message (and debug node id) (master...CorrectChecksumError) https://github.com/bitcoin/bitcoin/pull/8962
1052016-10-19T07:08:19 <GitHub6> [bitcoin] laanwj closed pull request #8957: Additional UpdateBlockAvailability (master...AddUpdateBlockAvailability) https://github.com/bitcoin/bitcoin/pull/8957
1062016-10-19T07:09:00 *** Evel-Knievel has joined #bitcoin-core-dev
1072016-10-19T07:09:23 *** BashCo has joined #bitcoin-core-dev
1082016-10-19T07:10:12 <GitHub111> [bitcoin] laanwj closed pull request #8963: NodeId missing from this debug line (master...SocketSendErrorNodeId) https://github.com/bitcoin/bitcoin/pull/8963
1092016-10-19T07:12:29 <sipa> wumpus: wow, do you sleep?
1102016-10-19T07:12:49 <wumpus> I've slept a bit
1112016-10-19T07:13:14 <wumpus> back to whack-a-mole now...
1122016-10-19T07:14:46 *** aalex has quit IRC
1132016-10-19T07:15:02 <wumpus> and merging #8951 and tagging rc2 I guess
1142016-10-19T07:17:31 *** paveljanik has joined #bitcoin-core-dev
1152016-10-19T07:17:32 *** paveljanik has joined #bitcoin-core-dev
1162016-10-19T07:19:38 <wumpus> anything else that needs to go into rc2 but doesn't have a 'Needs backport' tag?
1172016-10-19T07:20:47 <wumpus> sipa: better question, do *you* sleep? You're still here afterall :)
1182016-10-19T07:21:22 <tulip> wumpus: #8949 maybe? seems sort of critical.
1192016-10-19T07:21:33 <sipa> 8949?
1202016-10-19T07:21:46 <tulip> "Be more agressive in getting connections to peers with relevant services."
1212016-10-19T07:21:47 <sipa> wumpus: currently at the airport
1222016-10-19T07:22:27 <wumpus> thanks added tag
1232016-10-19T07:22:39 *** paveljanik has quit IRC
1242016-10-19T07:22:41 <sipa> wumpus: my comment is more aimed "8 hours ago you were merging/closing PRs, and now again" :)
1252016-10-19T07:23:05 <sipa> i'm just hanging out on irc
1262016-10-19T07:28:42 *** nibor has joined #bitcoin-core-dev
1272016-10-19T07:31:45 <gmaxwell> I expect 8949 to apply cleanly to 0.13 or nearly so, it's a trivial patch in any case.
1282016-10-19T07:31:46 *** bluerazo_ has quit IRC
1292016-10-19T07:32:21 *** bluerazor has joined #bitcoin-core-dev
1302016-10-19T07:37:20 *** achow101 has quit IRC
1312016-10-19T07:40:21 *** instagibbs has quit IRC
1322016-10-19T07:41:21 <wumpus> leave it up to rebroad to come up with lousy suggestions
1332016-10-19T07:42:31 *** sdaftuar has quit IRC
1342016-10-19T07:42:38 <gmaxwell> what PR?
1352016-10-19T07:42:47 <sipa> 8949
1362016-10-19T07:43:16 *** sdaftuar has joined #bitcoin-core-dev
1372016-10-19T07:43:23 <gmaxwell> lol
1382016-10-19T07:43:52 <Victorsueca> morning
1392016-10-19T07:43:53 <wumpus> I mean you're runnig a P2P network with decentralized propagation of node addresses, and what would you want to do, query centralized servers automatically periodically? :p
1402016-10-19T07:44:01 <wumpus> morning Victorsueca
1412016-10-19T07:44:09 <gmaxwell> better that he asked instead of submitting a patch "Improve DNSseeding."
1422016-10-19T07:44:10 <btcdrak> yeah wumpus I replied to him
1432016-10-19T07:44:16 *** shangzhou has joined #bitcoin-core-dev
1442016-10-19T07:44:21 <wumpus> true gmaxwell , very true
1452016-10-19T07:44:37 <gmaxwell> had I added the skip I would have written a comment in the code that explained why it was there.
1462016-10-19T07:44:48 <gmaxwell> perhaps I should have done so when editing that section.
1472016-10-19T07:44:48 <Victorsueca> left 0.13.1rc1 running all night
1482016-10-19T07:44:54 <Victorsueca> seems to work good
1492016-10-19T07:45:27 *** AtashiCon has joined #bitcoin-core-dev
1502016-10-19T07:45:30 <wumpus> gmaxwell: you could do it at the same time as the c++11 nit if you want, if not I'll just merge it as-is
1512016-10-19T07:45:31 <gmaxwell> Victorsueca: do you have nodewitness peers?
1522016-10-19T07:47:09 *** instagibbs has joined #bitcoin-core-dev
1532016-10-19T07:47:43 <gmaxwell> wumpus: Didn't know if we wanted the range based for. Okay, doing.
1542016-10-19T07:47:58 <wumpus> 13 witness peers on ereshkigal, two outgoing, rest incoming
1552016-10-19T07:48:06 <wumpus> gmaxwell: yes,we do :)
1562016-10-19T07:48:15 <wumpus> for new code, absolutely
1572016-10-19T07:48:25 <Victorsueca> gmaxwell: have 4
1582016-10-19T07:48:36 <gmaxwell> Victorsueca: inbound or outbound?
1592016-10-19T07:49:34 <Victorsueca> 3 outbound 1 inbound
1602016-10-19T07:53:01 <gmaxwell> will push an update as soon as this compiles.
1612016-10-19T07:53:38 <wumpus> going to kick my non-witness outbound peers until they're witness too :)
1622016-10-19T07:54:13 <Victorsueca> wumpus: lol, you'll hardfork the network if everybody does that
1632016-10-19T07:54:34 <wumpus> Victorsueca: I don't think so, I have plenty of non-witness inbound peers
1642016-10-19T07:54:53 <gmaxwell> Victorsueca: nah, it won't partition due to inbounds-- SW is intended to be witness only on outbound.
1652016-10-19T07:55:43 *** Ylbam has joined #bitcoin-core-dev
1662016-10-19T07:55:45 <gmaxwell> We don't want the topology to suddenly change when SW activates, if something goes wrong it's better if it goes wrong for people as they upgrade.
1672016-10-19T07:55:56 <gmaxwell> and once SW is active we'll need to only fetch new blocks from SW peers.
1682016-10-19T07:56:08 <sipa> Victorsueca: and if that actually happened, we could set up some proxy nodes to relay across (though that is an emergency only, obviously)
1692016-10-19T07:57:25 <wumpus> Victorsueca: though, arguably if everyone did the same things as me it'd be a weird place
1702016-10-19T07:57:34 <gmaxwell> yes, if there are any partioning problems as a result of some oversight there, the partition can be healed by even a single fixed node.
1712016-10-19T07:58:46 *** bluerazor has quit IRC
1722016-10-19T08:03:16 <wumpus> it's somewhat working: gained one more outgoing witness peer
1732016-10-19T08:08:44 <gmaxwell> I updated #8949 but did not rerun tests locally (laptop slow, took all that time to just compile it. :) )
1742016-10-19T08:09:29 *** mkarrer_ has quit IRC
1752016-10-19T08:10:21 *** mkarrer has joined #bitcoin-core-dev
1762016-10-19T08:10:21 *** davec has quit IRC
1772016-10-19T08:10:47 *** davec has joined #bitcoin-core-dev
1782016-10-19T08:12:41 *** timothy has quit IRC
1792016-10-19T08:15:19 <wumpus> gmaxwell: luckily there's travis, and also if you just changes the loop type I'm not terribly afraid of that messing up :)
1802016-10-19T08:16:38 <gmaxwell> just letting you know.
1812016-10-19T08:16:40 <sipa> it's not like we're merging things and then immediately after marking it as release candidate
1822016-10-19T08:16:44 <sipa> oh, wait
1832016-10-19T08:16:53 <btcdrak> XD
1842016-10-19T08:17:38 <wumpus> noo, we woudl never do something ill-advised like that
1852016-10-19T08:18:35 <Victorsueca> lol
1862016-10-19T08:19:48 <gmaxwell> maybe we should think about having a non-mandatory beta as part of the process. I noticed RC picked up a lot of testing pretty much instantly.. way more than what we had going on with 0.13 before it.
1872016-10-19T08:20:48 <wumpus> non-mandatory beta?
1882016-10-19T08:21:07 <wumpus> sounds intruiging, how do you suggest forcing people to install it :)
1892016-10-19T08:21:40 <gmaxwell> hah I mean when we think were close to an rc, tagging something as 'beta' as inspiration to get people to switch their attention.
1902016-10-19T08:21:50 <wumpus> oh, never mind, NON-mandatory. Boo.
1912016-10-19T08:21:56 <gmaxwell> lol
1922016-10-19T08:22:02 *** rebroad has joined #bitcoin-core-dev
1932016-10-19T08:22:14 <gmaxwell> We only have mandatory fun.
1942016-10-19T08:22:15 <wumpus> well the good news is that we can use the word 'beta' now in releases
1952016-10-19T08:22:23 <rebroad> is testnet broken?
1962016-10-19T08:22:27 <Victorsueca> if you think more testing is required then the beta release is pretty much mandatory
1972016-10-19T08:22:38 <wumpus> as it's no longer a static part of the release naming, as it used to be
1982016-10-19T08:23:34 *** JackH has joined #bitcoin-core-dev
1992016-10-19T08:23:57 <gmaxwell> rebroad: looks fine to me, can you be more specific?
2002016-10-19T08:24:30 <rebroad> My node and my peers are al stuck on block 998938
2012016-10-19T08:24:40 <rebroad> all
2022016-10-19T08:24:54 <rebroad> have raised an issue for it
2032016-10-19T08:25:33 <gmaxwell> rebroad: why are you saying they're stuck?
2042016-10-19T08:25:50 <rebroad> based on their reported startheight and my last new best
2052016-10-19T08:26:20 <gmaxwell> if your height is 998938 and all of their height is 998938 ... then perhaps you are all one big happy family.
2062016-10-19T08:26:32 <rebroad> have been for over an hour now
2072016-10-19T08:26:38 <tulip> receive version message: /Satoshi:0.11.0/: version 70002, blocks=1002280
2082016-10-19T08:26:50 <Victorsueca> rebroad: have you considered the possibility that 998938 is the best block right now?
2092016-10-19T08:27:05 <gmaxwell> it looks like the best block to me.
2102016-10-19T08:27:10 <tulip> rebroad: that's pretty normal for testnet though, and even the main network, frequently there's no blocks for hours at a time.
2112016-10-19T08:27:16 <gmaxwell> may just be no one is actively mining at the moment.
2122016-10-19T08:27:42 <rebroad> I am seeing many headers for higher heights though
2132016-10-19T08:28:07 <Victorsueca> maybe testnet is hard-forked
2142016-10-19T08:28:15 <gmaxwell> Yes, and?
2152016-10-19T08:28:20 <Victorsueca> that's why some nodes have a higher height
2162016-10-19T08:28:42 <Victorsueca> there's nothing to do with that
2172016-10-19T08:28:44 <gmaxwell> it has been for something like 6 months now, rogerver's "bitcoin.com" pool.
2182016-10-19T08:28:47 <rebroad> why isn't my node sending getdata requests for headers that are new to the block index though?
2192016-10-19T08:28:59 <gmaxwell> Not being sent by witness peers.
2202016-10-19T08:29:06 <tulip> that's not really a good view to have as your first diagnosis. testnet is very frequently completely hosed, it's par for the course.
2212016-10-19T08:29:34 <rebroad> unless proof of work is too low or something.. i guess more debug is needed
2222016-10-19T08:29:39 *** laurentmt has joined #bitcoin-core-dev
2232016-10-19T08:30:09 <rebroad> AcceptBlockHeader returns true and AddToBlockIndex was called... but it needs more debug to debug
2242016-10-19T08:30:37 <Victorsueca> "needs more debug to debug" -genius
2252016-10-19T08:32:36 <rebroad> either it's broken or my understanding is wrong. probably the latter
2262016-10-19T08:32:42 *** laurentmt has quit IRC
2272016-10-19T08:34:02 <sipa> rebroad: < gmaxwell> Not being sent by witness oeers.
2282016-10-19T08:35:19 *** laurentmt has joined #bitcoin-core-dev
2292016-10-19T08:36:37 <GitHub170> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/05998da5a7e2...1230890a6d04
2302016-10-19T08:36:38 <GitHub170> bitcoin/master a1919ad R E Broadley: Report NodeId in misbehaving debug
2312016-10-19T08:36:38 <GitHub170> bitcoin/master 1230890 Wladimir J. van der Laan: Merge #8936: Report NodeId in misbehaving debug...
2322016-10-19T08:36:45 *** MarcoFalke has joined #bitcoin-core-dev
2332016-10-19T08:36:47 <GitHub189> [bitcoin] laanwj closed pull request #8936: Report NodeId in misbehaving debug (master...NodeIdWhenMisbehaving) https://github.com/bitcoin/bitcoin/pull/8936
2342016-10-19T08:39:24 <gmaxwell> https://www.blocktrail.com/tBTC appears to be having fun, it's a non-SW testnet explorer and it seems to be jumping back in forth between different chains.
2352016-10-19T08:39:59 <wumpus> we have a blocktrail contact
2362016-10-19T08:41:34 <gmaxwell> pretty interesting to reload it and watch the block numbers constantly change but continue reading 1 hr 48m ago.
2372016-10-19T08:42:23 <gmaxwell> may be nothing wrong there, I currently don't have any non-SW testnet nodes, but that chain may be flapping around in a reorg war.
2382016-10-19T08:42:24 <wumpus> hehe
2392016-10-19T08:44:21 *** laurentmt has quit IRC
2402016-10-19T08:44:23 <GitHub181> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/1230890a6d04...e44753c06794
2412016-10-19T08:44:25 <GitHub181> bitcoin/master 9583477 Gregory Maxwell: Be more aggressive in connecting to peers with relevant services....
2422016-10-19T08:44:25 <GitHub181> bitcoin/master 4630479 Gregory Maxwell: Make dnsseed's definition of acute need include relevant services....
2432016-10-19T08:44:25 <GitHub181> bitcoin/master e44753c Wladimir J. van der Laan: Merge #8949: Be more agressive in getting connections to peers with relevant services....
2442016-10-19T08:44:38 <GitHub25> [bitcoin] laanwj closed pull request #8949: Be more agressive in getting connections to peers with relevant services. (master...more_agressive_witness_connect) https://github.com/bitcoin/bitcoin/pull/8949
2452016-10-19T08:48:09 <Victorsueca> has somebody actually tried to fill a block over 1MB on testnet too see if the whole witness thing works and doesn't hard-fork the chain due to a invalid block size?
2462016-10-19T08:48:27 *** mkarrer_ has joined #bitcoin-core-dev
2472016-10-19T08:48:34 <aj> Victorsueca: https://testnet.smartbit.com.au/blocks?sort=size
2482016-10-19T08:49:02 <tulip> Victorsueca: you're not being at all helpful by continuously saying that.
2492016-10-19T08:49:32 <Victorsueca> tulip: when did I say it previously?
2502016-10-19T08:49:49 <Victorsueca> aj: thanks
2512016-10-19T08:50:11 <wumpus> SegWit has been extensively tested, if we weren't sure "the whole witness thing works" it certainly wouldn't have been merged
2522016-10-19T08:50:53 <Victorsueca> wumpus: I guess so, just couldn't find any block that went over 1MB
2532016-10-19T08:51:00 <wumpus> and certainly no activation parameter would have been set on mainnet
2542016-10-19T08:51:02 <gmaxwell> Victorsueca: yes, there are many very large blocks on testnet (and segnet before it)
2552016-10-19T08:51:25 <gmaxwell> Victorsueca: https://testnet.smartbit.com.au/block/0000000000000896420b918a83d05d028ad7d61aaab6d782f580f2d98984a392
2562016-10-19T08:51:35 <wumpus> Victorsueca: sure, then just ask a question, instead of injecting fud into it
2572016-10-19T08:51:51 *** mkarrer has quit IRC
2582016-10-19T08:52:01 <Victorsueca> wumpus: sorry, didn't mean to FUD stuff
2592016-10-19T08:52:40 <wumpus> okay :)
2602016-10-19T08:54:03 <GitHub172> [bitcoin] MarcoFalke opened pull request #8972: [Qt] make warnings label selectable (master...Mf1610-qtWarnSelJS) https://github.com/bitcoin/bitcoin/pull/8972
2612016-10-19T08:55:31 *** DigiByteDev has joined #bitcoin-core-dev
2622016-10-19T08:55:37 <btcdrak> wumpus: rubensayshi and afk11 are Blocktrail contacts
2632016-10-19T08:56:07 <btcdrak> but Blocktrail isnt segwitty, so use https://testnet.smartbit.com.au/ for the time being
2642016-10-19T08:56:16 *** cdecker has joined #bitcoin-core-dev
2652016-10-19T08:56:35 <wumpus> btcdrak: thanks
2662016-10-19T08:57:52 <rebroad> MarcoFalke, how did you find that commit by jonasschnelli to fix #8970 so quickly?!
2672016-10-19T08:58:31 <wumpus> search the current pulls / issues before opening a new one
2682016-10-19T08:58:32 <MarcoFalke> out of memory :P
2692016-10-19T08:59:33 <MarcoFalke> rebroad: I think it helps if "trivial" pull don't come in massive batches. If you see there is still a "trivial" pull open on your name, make sure to queue up additional ones locally.
2702016-10-19T08:59:35 <GitHub169> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e44753c06794...b2df292e341d
2712016-10-19T08:59:36 <GitHub169> bitcoin/master 59daa58 Luke Dashjr: RPC/Mining: getblocktemplate: Update and fix formatting of help
2722016-10-19T08:59:36 <GitHub169> bitcoin/master b2df292 Wladimir J. van der Laan: Merge #8951: RPC/Mining: getblocktemplate: Update and fix formatting of help...
2732016-10-19T08:59:45 <MarcoFalke> You can submit a new one when the old one got merged.
2742016-10-19T08:59:49 <MarcoFalke> or closed
2752016-10-19T08:59:50 <GitHub139> [bitcoin] laanwj closed pull request #8951: RPC/Mining: getblocktemplate: Update and fix formatting of help (master...gbt_help_update) https://github.com/bitcoin/bitcoin/pull/8951
2762016-10-19T09:00:05 <rebroad> MarcoFalke, "locally"?
2772016-10-19T09:00:11 <MarcoFalke> on your machine
2782016-10-19T09:00:21 <MarcoFalke> in your .git folder
2792016-10-19T09:00:23 <wumpus> MarcoFalke: interesting, why did the original change never get merged? it looks fine
2802016-10-19T09:00:33 <rebroad> MarcoFalke, you mean some sort of "rate limiting"?
2812016-10-19T09:00:41 <MarcoFalke> ^
2822016-10-19T09:00:57 <MarcoFalke> Jup, we have over 100 open pulls and there is lack of review.
2832016-10-19T09:00:59 <wumpus> yes, rate limiting, to avoid DoSing other people
2842016-10-19T09:02:01 <rebroad> MarcoFalke, to hold back branches on my end would create more rebase work for me. I tend to work in bursts, so the PRs get raised in bursts too.
2852016-10-19T09:02:19 <MarcoFalke> Then wumpus has to go ahead and merge something and later on people complain that there are bugs in master.
2862016-10-19T09:02:20 <wumpus> which is fine if the topics of the branches are wildly different
2872016-10-19T09:02:30 <btcdrak> each comment, or action taken on the tracker mails 1230 people...
2882016-10-19T09:02:41 <MarcoFalke> rebroad: But it seems you don't even compile the changes sometimes
2892016-10-19T09:02:46 <wumpus> but if they are the same or simlar (e.g. change a log message) then group them or add them to an existing PR
2902016-10-19T09:03:04 <MarcoFalke> Please make sure to put work in a pull before you send it to a thousand people
2912016-10-19T09:03:20 <MarcoFalke> at least: compile, run tests, run python tests
2922016-10-19T09:03:33 <MarcoFalke> Also, mention the motivation in the commit body or pull body
2932016-10-19T09:03:47 <MarcoFalke> (I know I don't do it either, sometimes)
2942016-10-19T09:04:05 <MarcoFalke> but it is good practice and helps review
2952016-10-19T09:04:09 <wumpus> I don't think there's ever a good reason for one person to submit 8 pulls at once, I'm sure some are similar or part of similar intent
2962016-10-19T09:04:39 <wumpus> working on 8 completely disparate things at the same time is beyond the scope of human memory :p
2972016-10-19T09:05:05 <rebroad> MarcoFalke, I am sometimes guilty of not compiling after what looks like a very simple rebase... I do need to revise my workflow admittedly
2982016-10-19T09:05:13 <MarcoFalke> I stole the commit from https://github.com/bitcoin/bitcoin/pull/7134/commits
2992016-10-19T09:05:16 <MarcoFalke> :P
3002016-10-19T09:05:53 <rebroad> MarcoFalke, I am only just starting to familiarise myself with the tests.... do you mean "make check" or something else?
3012016-10-19T09:06:18 <MarcoFalke> ./qa/pull-tester/rpc-tests.py
3022016-10-19T09:06:24 <rebroad> wumpus, "8 pulls at once"? why ever not?
3032016-10-19T09:06:27 <wumpus> rebroad: so did #8972 solve your problem?
3042016-10-19T09:06:48 <MarcoFalke> We need more people running the pull tester suite, anyway
3052016-10-19T09:07:34 <wumpus> rebroad: because a) it comes over as horribly spammy, there are 120 pulls open by many different people, you're monoolizing the pull list with trivial stuff b) as I said above, if there's so many changes you must be able to combine a few as they will share a theme
3062016-10-19T09:08:24 <wumpus> 'shoot a buckshot at the codebase and see what sticks' is not a strategy for development
3072016-10-19T09:09:23 <wumpus> at least not one that respects the time constraints and priorities of other people partaking in the project
3082016-10-19T09:12:07 <wumpus> to get started on testing, read https://github.com/bitcoin/bitcoin#automated-testing , it mentions the kinds of tests available
3092016-10-19T09:12:19 *** jannes has joined #bitcoin-core-dev
3102016-10-19T09:14:01 <rebroad> wumpus, how does it make any difference between raising 1 PR a day, and 7 only on Saturdays?
3112016-10-19T09:14:16 <wumpus> please, dont' keep arguing this
3122016-10-19T09:15:01 <rebroad> wumpus, you put forward an argument (based on false assumptions) and then complain when I correct those assumptions. I am not interested in hearing your rants.
3132016-10-19T09:15:10 <tulip> for anyone following, there's progress on testnet now.
3142016-10-19T09:15:21 <wumpus> then just go away
3152016-10-19T09:15:43 *** ChanServ sets mode: +o wumpus
3162016-10-19T09:16:20 *** wumpus sets mode: +b *!*@180.183.72.230
3172016-10-19T09:16:23 *** rebroad was kicked by wumpus (rebroad)
3182016-10-19T09:16:43 *** ChanServ sets mode: -o wumpus
3192016-10-19T09:20:00 *** bluerazor has joined #bitcoin-core-dev
3202016-10-19T09:25:17 <GitHub106> [bitcoin] laanwj pushed 3 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/2c0913d0b3e1...7c2bf4b1759b
3212016-10-19T09:25:18 <GitHub106> bitcoin/0.13 33cd553 Gregory Maxwell: Be more aggressive in connecting to peers with relevant services....
3222016-10-19T09:25:18 <GitHub106> bitcoin/0.13 91ae0b0 Gregory Maxwell: Make dnsseed's definition of acute need include relevant services....
3232016-10-19T09:25:19 <GitHub106> bitcoin/0.13 7c2bf4b Luke Dashjr: RPC/Mining: getblocktemplate: Update and fix formatting of help...
3242016-10-19T09:27:47 <GitHub93> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b2df292e341d...d736a6eb1f91
3252016-10-19T09:27:47 <GitHub93> bitcoin/master ef0c9ee Jonas Schnelli: [Qt] make warnings label selectable
3262016-10-19T09:27:48 <GitHub93> bitcoin/master d736a6e Wladimir J. van der Laan: Merge #8972: [Qt] make warnings label selectable (jonasschnelli)...
3272016-10-19T09:27:52 <wumpus> MarcoFalke: #8972 for 0.13 too?
3282016-10-19T09:27:57 <GitHub37> [bitcoin] laanwj closed pull request #8972: [Qt] make warnings label selectable (jonasschnelli) (master...Mf1610-qtWarnSelJS) https://github.com/bitcoin/bitcoin/pull/8972
3292016-10-19T09:28:21 <MarcoFalke> Should not matter
3302016-10-19T09:28:47 <wumpus> ok, going to update the release notes lists and pulling in new translations and tagging rc2
3312016-10-19T09:30:21 <gmaxwell> oops.
3322016-10-19T09:30:29 <gmaxwell> backport is going to fail to compile.
3332016-10-19T09:30:45 <wumpus> we'll hear from travis soon I guess
3342016-10-19T09:30:47 <gmaxwell> net.cpp:1718:108: error: ‘nMaxOutbound’ was not declared in this scope if ((addr.nServices & nRelevantServices) != nRelevantServices && (nTries < 40 || nOutbound >= (nMaxOutbound >> 1)))
3352016-10-19T09:32:44 <Victorsueca> RIP backport
3362016-10-19T09:33:36 <gmaxwell> replace with MAX_OUTBOUND_CONNECTIONS
3372016-10-19T09:33:54 *** ChanServ sets mode: +o wumpus
3382016-10-19T09:33:59 *** wumpus sets mode: -b *!*@180.183.72.230
3392016-10-19T09:34:03 *** ChanServ sets mode: -o wumpus
3402016-10-19T09:35:11 *** rebroad has joined #bitcoin-core-dev
3412016-10-19T09:35:29 <rebroad> Apologies for earlier. I need to learn to get less emotionally involved in my pull requests.
3422016-10-19T09:36:09 <wumpus> we all do, np, it's kind of a stressful time and not a good time to pick fights now :)
3432016-10-19T09:36:34 <rebroad> oh.. I didn't realise that? stress due to SegWit...? bitcoin related?
3442016-10-19T09:36:52 <btcdrak> releases are always stressful. lots to get done.
3452016-10-19T09:37:03 <MarcoFalke> rebroad: Also the pull request backlog
3462016-10-19T09:37:17 <rebroad> ah ok. will bear that in mind. PRT (pre-release-tension)
3472016-10-19T09:37:22 <btcdrak> ha!
3482016-10-19T09:38:19 *** PRab_ has joined #bitcoin-core-dev
3492016-10-19T09:39:01 <rebroad> I am inclined to think of the backlog in the same way I think of my browser tabs. I have so many I struggle to keep track of them.. I do need to find a new system to organise them rather than a simple list as they currently are. Perhaps there might be a similar way to organise the issues - i.e. it's not the large number that's the issue but they way they are organised/sorted..?
3502016-10-19T09:40:30 <btcdrak> rebroad: well the first thing we can do is be good citizens and consider the whole process - submitting a PR is just one part of the process. Think of reviewers and the effort they have to go through to verify and review. This is why grouping things is important. Etiquette starts from there.
3512016-10-19T09:40:44 <rebroad> if there is anything I can do to help make the backlog seem less daunting, please do let me know
3522016-10-19T09:40:46 *** PRab has quit IRC
3532016-10-19T09:40:52 *** PRab_ is now known as PRab
3542016-10-19T09:41:01 <btcdrak> rebroad: review more PRs
3552016-10-19T09:41:24 <btcdrak> review and _test_
3562016-10-19T09:42:07 <wumpus> "error: use of undeclared identifier 'nMaxOutbound'; did you mean 'nOutbound'" eh, no thangs clang
3572016-10-19T09:42:26 *** bluerazor has quit IRC
3582016-10-19T09:42:38 <rebroad> btcdrak, I certainly could do that, although it's hard to know which ones to review and test. is there an easy way to see which ones require greater attention or are the more useful/desired PRs?
3592016-10-19T09:42:49 <gmaxwell> wumpus: yea, helpful compiler suggestions: Good news, your code compiles. You really didn't want that nice compiler static analysis to actually help you find bugs, right?
3602016-10-19T09:43:10 <btcdrak> rebroad: right, so putting yourself in the POV of the reviewers is very good practice...
3612016-10-19T09:43:19 <MarcoFalke> rebroad: Those tagged for 0.14, right now.
3622016-10-19T09:43:36 <rebroad> MarcoFalke, ah... great starting point. thanks
3632016-10-19T09:44:36 <MarcoFalke> We have also different labels where you can group by. E.g. https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+is%3Aopen+label%3AP2P
3642016-10-19T09:45:18 *** DigiByteDev has quit IRC
3652016-10-19T09:50:53 <GitHub144> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/7c2bf4b1759b...0dbc48a5bd83
3662016-10-19T09:50:54 <GitHub144> bitcoin/0.13 53e6196 Wladimir J. van der Laan: qt: pre-rc2 translations update
3672016-10-19T09:50:54 <GitHub144> bitcoin/0.13 0dbc48a Wladimir J. van der Laan: nMaxOutbound is MAX_OUTBOUND_CONNECTIONS on 0.13...
3682016-10-19T09:52:25 <rebroad> has anyone else notices that the arrows point the wrong way in the peer table in the debug window? I've raised #8959 to fix this
3692016-10-19T09:52:50 <rebroad> (the arrows to indicate sort direction)
3702016-10-19T09:53:12 <wumpus> I haven't noticed, but don't think I've ever paid close attention to it so it's certainly possible
3712016-10-19T09:53:46 <Victorsueca> you mean the ones on the table sort?
3722016-10-19T09:53:52 <rebroad> Victorsueca, yes
3732016-10-19T09:54:14 *** drizztbsd has joined #bitcoin-core-dev
3742016-10-19T09:54:25 <Victorsueca> ahh yeah, I aalways felt weird when sorting that table, now I know why
3752016-10-19T09:54:38 <rebroad> I wasn't sure if I fixed it in the best pace. the way I did it makes columns default to descending when you first click to sort them
3762016-10-19T09:54:45 *** drizztbsd is now known as timothy
3772016-10-19T09:55:09 <rebroad> which is fine as descending is the more useful for most of the columns, IMHO
3782016-10-19T09:56:03 <rebroad> an extra click to make it ascending, of course
3792016-10-19T09:56:30 <wumpus> for things such as ping that makes sense, I guess, the only time descending is annoying is in text columns
3802016-10-19T09:58:04 <Victorsueca> I think the arrow should be a bit darker to make it more visible, this is pure aesthetics tho
3812016-10-19T09:58:28 *** maluzek_ has joined #bitcoin-core-dev
3822016-10-19T09:58:45 <wumpus> that's up to your theme
3832016-10-19T09:59:16 <Victorsueca> ahh windows theme
3842016-10-19T10:00:24 <Victorsueca> but it seems to be rendered as text, why is it lighter than the rest of text?
3852016-10-19T10:00:26 <wumpus> I don't know where qt takes the theme from on windows
3862016-10-19T10:01:07 <wumpus> in any case it's not something that should be micro-managed, e.g. I have a theme that is pretty much black on black so marking the arrow *darker* would make it invisible :)
3872016-10-19T10:02:28 <Victorsueca> that could be solved with a white outline
3882016-10-19T10:02:40 <Victorsueca> but anyway, it's ok now, no reason to bother on that
3892016-10-19T10:03:05 <wumpus> that's up to the theme, too
3902016-10-19T10:04:02 <wumpus> some of the altcoins set up their own qt theme instead of using the system theme, but I think that's kind of pushy, no need to push your asthethic preferences to others
3912016-10-19T10:04:49 <Victorsueca> yeah, dogecoin for example uses a funny typography
3922016-10-19T10:05:03 <GitHub156> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/6e8936032fb865c0448bec0e0f168e041a586285
3932016-10-19T10:05:04 <GitHub156> bitcoin/0.13 6e89360 Wladimir J. van der Laan: doc: Update release notes for rc2
3942016-10-19T10:07:42 *** maluzek_ has quit IRC
3952016-10-19T10:11:48 <Victorsueca> 3 outbound 2 inbound right now
3962016-10-19T10:13:16 <wumpus> 4 outbound 10 inbound SW connections here
3972016-10-19T10:13:34 <Victorsueca> found a fail on the peers screen
3982016-10-19T10:13:58 <Victorsueca> some peers display "via 127.0.0.1:8333" instead of the address bitcoin is bound to
3992016-10-19T10:15:00 <gmaxwell> Victorsueca: you have tor HS peers.
4002016-10-19T10:15:54 <Victorsueca> tor peers display "via mytoraddress.onion:8333"
4012016-10-19T10:17:37 <gmaxwell> Victorsueca: no, _outbound_ hs peers do, inbound ones are 127,0,0,1.
4022016-10-19T10:17:54 <Victorsueca> ahh, makes sense
4032016-10-19T10:18:15 <tulip> there's no meaningful identifier for them other than "hey there's a tcp connection"
4042016-10-19T10:18:21 *** testnet has joined #bitcoin-core-dev
4052016-10-19T10:18:46 <gmaxwell> I expect someday we'll listen on a special port for those... and then we'll be able to display "onion" or whatnot.
4062016-10-19T10:19:08 <Victorsueca> it's a bit deceptive to invert a "something via something" sentence without explanation
4072016-10-19T10:21:04 <Victorsueca> maybe we should rephrase that to "Local address:...." and "Remote address:..."
4082016-10-19T10:21:37 *** testnet0 has joined #bitcoin-core-dev
4092016-10-19T10:21:37 *** testnet has quit IRC
4102016-10-19T10:27:16 *** testnet0 is now known as testnet
4112016-10-19T10:27:53 *** rebroad has quit IRC
4122016-10-19T10:29:14 <wumpus> yes, listening on a special port would make a lot of sense
4132016-10-19T10:29:32 <wumpus> not sure why we haven't chosen to do that esp. for the auto-torcontrol stuff
4142016-10-19T10:30:25 <wumpus> another things some hs hosts do is to use alternative localhost interfaces, e.g. 127.0.0.2, but the alternative port is a no-brainer
4152016-10-19T10:33:54 *** testnet has quit IRC
4162016-10-19T10:35:06 *** Victorsueca is now known as Victor_sueca
4172016-10-19T10:35:41 *** Victor_sueca is now known as Victorsueca|Mob
4182016-10-19T10:35:48 *** Victorsueca|Mob is now known as aceusrotciV
4192016-10-19T10:35:56 *** aceusrotciV is now known as Tipper
4202016-10-19T10:36:02 *** Tipper is now known as ErroneousNicknam
4212016-10-19T10:36:07 *** ErroneousNicknam is now known as Victorsueca
4222016-10-19T10:40:23 <gmaxwell> yea, for autocontrol its especially a no-brainer... other than needing to find another reliably free port.
4232016-10-19T10:40:52 <gmaxwell> (it could be ephemeral, but better if not.. if I saw a random listning port on my host I'd be rather concerned. :) )
4242016-10-19T10:41:15 <wumpus> won't TCP automatically choose a port for you if you listen() without setting one?
4252016-10-19T10:41:15 <tulip> 6667 seems pretty unused.
4262016-10-19T10:41:49 <tulip> if you attempt to listen on port 0, apparently that's the behaviour.
4272016-10-19T10:41:56 <wumpus> oh, random is not good, okay wouldn't know then. Just pick a new fixed one one and put it in chainparams then
4282016-10-19T10:42:19 <gmaxwell> just means that when you run multiple daemons on the same network and host, they'll collide.
4292016-10-19T10:42:33 <gmaxwell> same as p2p/rpc.
4302016-10-19T10:43:01 <wumpus> https://github.com/bitcoin/bitcoin/issues/8973 in the issue I propose ` hsport` option for that
4312016-10-19T10:43:06 <tulip> random would also have the weird effect of killing other daemons that try to bind to something after bitcoind
4322016-10-19T10:43:14 <gmaxwell> wumpus: sounds great to me.
4332016-10-19T10:43:31 <Victorsueca> what about random but exclude common ports?
4342016-10-19T10:43:37 <wumpus> why would it kill other daemons?
4352016-10-19T10:43:50 <gmaxwell> the special port would also allow more than labling, e.g. preferrential relay to HS peers.. which we can only do for outbound hs peers right now.
4362016-10-19T10:43:58 <tulip> wumpus: say bitcoind came up, randomly chose 22, and then openssh tried to come up.
4372016-10-19T10:44:00 <wumpus> I'm all for daemon-kiliing functionality in bitcoind, but arguably it should happen intentionally :p
4382016-10-19T10:44:04 <btcdrak> is that everything now for rc2?
4392016-10-19T10:44:13 <gmaxwell> tulip: it won't randomly choose 22. It will get some port over 32768.
4402016-10-19T10:44:41 <tulip> gmaxwell: talking hypothetical, but ok.
4412016-10-19T10:45:02 <gmaxwell> kernel reserves some range of ports for ephemeral use that is outside of the range normally used for services.
4422016-10-19T10:45:10 <wumpus> I wonder if tor can create some kind of private, non-TCP socket
4432016-10-19T10:45:23 <wumpus> anyhow that's not relevant to solving the issue, but for the far future would be nice list
4442016-10-19T10:45:58 <tulip> gmaxwell: so there's privileged 1-1023, and >32768 for ephemeral. are there any other ranges?
4452016-10-19T10:46:03 <wumpus> btcdrak: I think so!
4462016-10-19T10:46:20 <btcdrak> wumpus: my gitian VM is ready!
4472016-10-19T10:46:51 <wumpus> tulip: ranges are configurable and depend on the OS, although <1024 private is pretty ingrained (I think windows is an exception there?)
4482016-10-19T10:46:55 <gmaxwell> tulip: not coming to mind. keep in mind these are local policy... there are sysctls to change them.
4492016-10-19T10:47:28 <gmaxwell> yea, for a long time if you could get access to ports <1024 you could escilate to root access on other hosts that rhosts trusted your host.
4502016-10-19T10:48:01 <tulip> I hate to think what caused that to be implemented.
4512016-10-19T10:49:05 <wumpus> yeah rsh :-(
4522016-10-19T10:51:13 *** shangzhou has quit IRC
4532016-10-19T10:51:20 <wumpus> * [new tag] v0.13.1rc2 -> v0.13.1rc2
4542016-10-19T10:52:29 <wumpus> I guess that was a time in which the number of people having enough knowledge to circumvent that was so small that you could just trust them not to do it, sysadmin-inside-knowledge-based-access-control or so:p
4552016-10-19T10:52:41 * Victorsueca starts compiling
4562016-10-19T10:52:58 <gmaxwell> wumpus: yea, that time lasted about 10 minutes.
4572016-10-19T10:53:57 * btcdrak starts gitian
4582016-10-19T10:56:35 <wumpus> gmaxwell: yes I can't imagine it taking long. And after that the long period it was (mis)configured by default on some OSes
4592016-10-19T10:59:32 *** Guyver2 has joined #bitcoin-core-dev
4602016-10-19T11:09:59 *** fengling has quit IRC
4612016-10-19T11:13:18 <Victorsueca> so... rc2 has gmaxwell's aggressive witness node search right?
4622016-10-19T11:13:25 <wumpus> yes
4632016-10-19T11:18:33 <btcdrak> that sounds so mafia
4642016-10-19T11:19:02 <Victorsueca> lol
4652016-10-19T11:19:37 <btcdrak> the node needs a witnesss protection program
4662016-10-19T11:24:51 <sipa> bitcoind --aggressive=passive
4672016-10-19T11:34:52 <Victorsueca> done building, now starting
4682016-10-19T11:45:49 <jonasschnelli> [22:07:48] <wumpus:#bitcoin-core-dev> jonasschnelli: could you elaborate in #8546 what you mean with " I think its acceptable if it breaks wallets used back in 0.3.x in conjunction with IP transaction". I don't think it'd be acceptable if the client suddenly crashes if someone happens to be using a wallet that still has a pay-to-IP transaction in it.
4692016-10-19T11:45:58 <jonasschnelli> Yes. Your probably right...
4702016-10-19T11:46:44 <jonasschnelli> I don't have enough informations about the field-usage of IP transactions...
4712016-10-19T11:47:22 <jonasschnelli> Better keep the code as it is
4722016-10-19T11:51:22 *** jtimon has joined #bitcoin-core-dev
4732016-10-19T11:53:06 *** cryptapus has joined #bitcoin-core-dev
4742016-10-19T11:53:06 *** cryptapus has joined #bitcoin-core-dev
4752016-10-19T11:53:17 <arubi> is it bad to symlink the database directory which is in datadir (contains log.0000000001 like files) to a tmpfs filesystem like /dev/shm ? It makes things like importing scripts and generating keys much quicker for me, e.g. initial keypool population takes 14418ms vs. 4236ms with the database dir in /dev/shm
4762016-10-19T11:53:40 <arubi> I did (superficially with iotop) notice that a lot of writing is done to this log.0000.. file when I import many scripts, so this is why I ask.
4772016-10-19T12:02:40 <Victorsueca> 7 witness peers now, all outbound
4782016-10-19T12:04:32 *** paveljanik has joined #bitcoin-core-dev
4792016-10-19T12:12:00 *** achow101 has joined #bitcoin-core-dev
4802016-10-19T12:19:25 <wumpus> arubi: I don't know about berkeleydb specifics but having the wallet database crossing filesystem boundaries is reasonably dangerous
4812016-10-19T12:19:52 <achow101> was rc1 DOA?
4822016-10-19T12:20:04 <wumpus> arubi: also tmpfs is lost on reboot, which means you may lose data
4832016-10-19T12:22:39 <arubi> wumpus, yea I'm aware about the second point. thought about copying it back to the hard drive periodically, but didn't take into account if bdb itself might not like it. I'll rtfm about bdb
4842016-10-19T12:25:48 <jonasschnelli> BDB has some really strange way of storing data...
4852016-10-19T12:26:44 <jonasschnelli> Look at http://bitcoin.stackexchange.com/questions/48070/format-of-mkey-field-in-encrypted-wallet-dat-file
4862016-10-19T12:27:20 <jonasschnelli> I tried to track this down and found out, that the chunks of the records value are stored in different locations.
4872016-10-19T12:31:29 <luke-jr> https://curl.haxx.se/mail/lib-2016-10/0076.html sigh
4882016-10-19T12:32:57 <arubi> thanks for the lead jonasschnelli
4892016-10-19T12:33:22 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4902016-10-19T12:44:25 <wumpus> jonasschnelli: yeah I wouldn't mind changing the 'transaction details' window if anyone has a good plan to do so, but this just seemed like ripping out a few things at semi-random, not sure either whether it would affect things such as watch-only or payment requests
4912016-10-19T12:44:53 <jonasschnelli> wumpus: Yes. Indeed.
4922016-10-19T12:44:59 <wumpus> with so many more urgent pulls open, it didn't seem worth the bother
4932016-10-19T12:46:26 <wumpus> gah instead of building rc2 I re-built rc1
4942016-10-19T12:46:42 <wumpus> achow101: yes
4952016-10-19T12:47:12 <wumpus> it didn't have the version bumped and BlueMatt discovered a crash issue within a few minutes
4962016-10-19T12:48:58 <wumpus> (probably in an RPC command that only he uses, but okay that's clearly a bug that shouldn't be in a release)
4972016-10-19T12:49:12 <jonasschnelli> wumpus: what crash? The wallet/init one? https://github.com/bitcoin/bitcoin/pull/8928
4982016-10-19T12:49:20 <wumpus> addnode
4992016-10-19T12:49:45 <wumpus> #8928 issue doesn't exist in 0.13
5002016-10-19T12:49:58 <wumpus> fairly sure it was introduced in the refactoring
5012016-10-19T12:50:11 <jonasschnelli> We should extend addnode's RPC tests
5022016-10-19T12:50:16 <wumpus> yes
5032016-10-19T12:52:28 <jonasschnelli> wumpus: The RPC command-structure refactoring (https://github.com/bitcoin/bitcoin/pull/8788) includes your JSONRPCRequestObj renaming now. Would be nice to get this in soon to escape the rebase-hamster-wheel
5042016-10-19T12:53:42 <luke-jr> I still prefer 8775 :x
5052016-10-19T12:54:08 <luke-jr> it's just ugly to have request.params everywhere
5062016-10-19T12:57:54 <wumpus> I like request.params
5072016-10-19T12:58:13 <wumpus> it's literally "request parameters", what naming could be better
5082016-10-19T12:58:21 <jonasschnelli> I think request.param improves readability
5092016-10-19T12:58:26 <luke-jr> params is clear and much shorter. but whatever
5102016-10-19T12:58:55 <jonasschnelli> params is to generic and could be interpreted as local scope var
5112016-10-19T12:59:13 <luke-jr> obviously when it comes to taste, majority rules, so if everyone else disagrees, just go ahead and do it
5122016-10-19T12:59:27 <wumpus> yes it's a bit of a taste issue
5132016-10-19T12:59:48 *** MarcoFalke has left #bitcoin-core-dev
5142016-10-19T12:59:49 <jonasschnelli> Right. The important thing is, that we have a flexible container in the RPC command function structure.
5152016-10-19T13:01:24 <wumpus> right
5162016-10-19T13:20:08 <BlueMatt> who is mining testnet-segwit?
5172016-10-19T13:20:13 <BlueMatt> phantomcircuit: or Lightsword, maybe?
5182016-10-19T13:24:06 <tulip> BlueMatt: me, problem?
5192016-10-19T13:25:07 <GitHub21> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/d736a6eb1f91...97c7f7362f9b
5202016-10-19T13:25:08 <GitHub21> bitcoin/master 23c32a9 Wladimir J. van der Laan: rpc: Change JSONRPCRequest to JSONRPCRequestObj...
5212016-10-19T13:25:08 <GitHub21> bitcoin/master 69d1c25 Jonas Schnelli: [RPC] Give RPC commands more information about the RPC request
5222016-10-19T13:25:09 <GitHub21> bitcoin/master e7156ad Jonas Schnelli: [RPC] pass HTTP basic authentication username to the JSONRequest object
5232016-10-19T13:25:17 <GitHub131> [bitcoin] laanwj closed pull request #8788: [RPC] Give RPC commands more information about the RPC request (master...2016/09/rpc_container) https://github.com/bitcoin/bitcoin/pull/8788
5242016-10-19T13:28:16 <BlueMatt> tulip: yes, we havent addnode'd between the new fibre test network and your mining bitcoind :p
5252016-10-19T13:34:10 <wumpus> jonasschnelli: darn now #7551 needs rebase again
5262016-10-19T13:34:22 <luke-jr> :p
5272016-10-19T13:39:27 <wumpus> I really think we should merge that one soon, it's been open for ages and he's been rebasing time after time and fixing load of nits after load of nits. And it has tests. I'm not convinced that it is bugless (it adds a lot of functionality) but it'd probably be better to merge it so it gets more testing.
5282016-10-19T13:40:02 <wumpus> but it's very useful functionality that definitely needs to be in 0.14
5292016-10-19T13:44:58 *** fengling has joined #bitcoin-core-dev
5302016-10-19T13:46:42 *** kadoban has joined #bitcoin-core-dev
5312016-10-19T13:47:32 *** Chris_Stewart_5 has quit IRC
5322016-10-19T14:00:42 *** wumpus has quit IRC
5332016-10-19T14:01:46 *** wumpus has joined #bitcoin-core-dev
5342016-10-19T14:01:47 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5352016-10-19T14:02:01 *** wumpus has quit IRC
5362016-10-19T14:03:39 *** wumpus has joined #bitcoin-core-dev
5372016-10-19T14:05:28 <btcdrak> BlueMatt: Lightsword, but he stopped mining yesterday to let cfields test out cgminer I believe.
5382016-10-19T14:07:04 *** Ylbam has quit IRC
5392016-10-19T14:08:22 *** adiabat has joined #bitcoin-core-dev
5402016-10-19T14:18:16 <luke-jr> http://arstechnica.com/security/2016/10/flaw-in-intel-chips-could-make-malware-attacks-more-potent/ :/
5412016-10-19T14:20:49 <wumpus> the branch prediction profiling makes local attacks (e.g. against the kernel) somewhat easier, ASLR is still a good measure against remote attacks
5422016-10-19T14:23:03 *** Guyver2 has quit IRC
5432016-10-19T14:24:18 <wumpus> also think function-level ASLR (selfrando) would make this harder to exploit, as you cannot just guess one offset and compute others from it
5442016-10-19T14:25:27 <wumpus> haven't heard about using that at the kernel level though :)
5452016-10-19T14:27:11 <BlueMatt> hey-o, fibre works on segwit
5462016-10-19T14:27:13 <BlueMatt> look at that
5472016-10-19T14:27:20 <BlueMatt> anyone need high-speed testnet blocks? :p
5482016-10-19T14:27:37 <wumpus> awesome!
5492016-10-19T14:27:48 <BlueMatt> even worked on the first try :)
5502016-10-19T14:29:23 <wumpus> of course we need fast testnet blocks
5512016-10-19T14:31:58 <adiabat> repost from wizards, but anyone know what's up with testnet3?
5522016-10-19T14:32:07 <adiabat> seem to be 2 chains
5532016-10-19T14:32:09 <BlueMatt> what about it?
5542016-10-19T14:32:23 <BlueMatt> all my nodes ended up on the same chain when i synced them last night?
5552016-10-19T14:32:27 *** Giszmo has joined #bitcoin-core-dev
5562016-10-19T14:32:29 <BlueMatt> adiabat: is classic forked off again?
5572016-10-19T14:32:35 <adiabat> could be
5582016-10-19T14:32:52 <adiabat> test.webbtc.com is where I can see another one, that's longer
5592016-10-19T14:33:06 <adiabat> seems to diverge at 996198, but not sure why
5602016-10-19T14:33:14 <BlueMatt> 2016-10-19 14:25:57.059547 UpdateTip: new best=00000000000f939a09a192c06dec99490018fa8dc488cb25cc9141612eb57bf2 height=1003480 version=0x20000000 log2_work=68.579739 tx=11657519 date='2016-10-19 14:45:27' progress=1.000000 cache=0.3MiB(1882tx)
5612016-10-19T14:33:47 *** rebroad has joined #bitcoin-core-dev
5622016-10-19T14:38:33 <GitHub143> [bitcoin] s-matthew-english opened pull request #8974: readability improvement (master...patch-5) https://github.com/bitcoin/bitcoin/pull/8974
5632016-10-19T14:40:13 <adiabat> BlueMatt: yeah I'm on that one as well. Guess it doesn't really matter, just curious why there's a longer (presumably invalid) chain
5642016-10-19T14:41:47 <BlueMatt> adiabat: well at least tulip and Lightsword are both mining
5652016-10-19T14:41:50 <BlueMatt> maybe they're not peered.....
5662016-10-19T14:42:27 <GitHub129> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/97c7f7362f9b...5d2c8e524e10
5672016-10-19T14:42:28 <GitHub129> bitcoin/master fc14609 mruddy: RPC: augment getblockchaininfo bip9_softforks data
5682016-10-19T14:42:28 <GitHub129> bitcoin/master 5d2c8e5 Wladimir J. van der Laan: Merge #7948: RPC: augment getblockchaininfo bip9_softforks data...
5692016-10-19T14:42:33 <GitHub154> [bitcoin] laanwj closed pull request #7948: RPC: augment getblockchaininfo bip9_softforks data (master...version_bits_locked_in_block) https://github.com/bitcoin/bitcoin/pull/7948
5702016-10-19T14:50:41 <jonasschnelli> wumpus: Yes. 7551 should go in soon. I gave it my tested ACK (tested pretty well), though, some comments where added/amend-changed afterwards.
5712016-10-19T14:50:50 <jonasschnelli> sipa said he want to test it as well (before we merge)
5722016-10-19T14:51:10 <jonasschnelli> I think we should merge it and fix (possible) issues later
5732016-10-19T14:51:16 <jonasschnelli> but the rebase needs to be done
5742016-10-19T14:51:47 <jonasschnelli> I guess 8788 will lead to plenty of rebases
5752016-10-19T14:58:07 <btcdrak> Lightsword wanna connect to FIBRE?
5762016-10-19T14:59:34 *** Ylbam has joined #bitcoin-core-dev
5772016-10-19T15:06:44 <GitHub37> [bitcoin] MarcoFalke closed pull request #8974: readability improvement (master...patch-5) https://github.com/bitcoin/bitcoin/pull/8974
5782016-10-19T15:07:08 *** jl2012 has quit IRC
5792016-10-19T15:07:25 <tulip> adiabat: BlueMatt: 00000000000f939a09a192c06dec99490018fa8dc488cb25cc9141612eb57bf2 is my chain and is valid with 0.13.1. I don't know why webbtc is showing a different one, I noticed that before.
5802016-10-19T15:07:36 *** jl2012 has joined #bitcoin-core-dev
5812016-10-19T15:08:35 <GitHub48> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/5d2c8e524e10...3e942a7060fe
5822016-10-19T15:08:36 <GitHub48> bitcoin/master 1880aeb Luke Dashjr: Qt: Get the private key for signing messages via WalletModel
5832016-10-19T15:08:37 <GitHub48> bitcoin/master 178cd88 Luke Dashjr: Qt/splash: Specifically keep track of which wallet(s) we are connected to for later disconnecting
5842016-10-19T15:08:37 <GitHub48> bitcoin/master 3e942a7 Jonas Schnelli: Merge #8774: Qt refactors to better abstract wallet access...
5852016-10-19T15:08:49 <GitHub155> [bitcoin] jonasschnelli closed pull request #8774: Qt refactors to better abstract wallet access (master...multiwallet_prefactor_qt) https://github.com/bitcoin/bitcoin/pull/8774
5862016-10-19T15:09:27 <tulip> I have >30 peers connected to that node, 11 of which are NODE_WITNESS. if there's a peering problem it's unlikely to be mine.
5872016-10-19T15:23:22 *** LeMiner has quit IRC
5882016-10-19T15:29:09 <GitHub135> [bitcoin] jonasschnelli closed pull request #8775: RPC refactoring: Never access wallet directly, only via new CRPCRequestInfo (master...multiwallet_prefactor_rpc) https://github.com/bitcoin/bitcoin/pull/8775
5892016-10-19T15:34:30 <Lightsword> btcdrak, sure
5902016-10-19T15:40:28 *** Anduck has quit IRC
5912016-10-19T15:42:06 <GitHub16> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3e942a7060fe...475d68252e9c
5922016-10-19T15:42:06 <GitHub16> bitcoin/master acf853d Johnson Lau: Add script tests for FindAndDelete in pre-segwit and segwit scripts
5932016-10-19T15:42:06 <GitHub16> bitcoin/master 475d682 Wladimir J. van der Laan: Merge #8927: Add script tests for FindAndDelete in pre-segwit and segwit scripts...
5942016-10-19T15:42:15 <GitHub87> [bitcoin] laanwj closed pull request #8927: Add script tests for FindAndDelete in pre-segwit and segwit scripts (master...findanddeletetest) https://github.com/bitcoin/bitcoin/pull/8927
5952016-10-19T15:45:05 *** mkarrer has joined #bitcoin-core-dev
5962016-10-19T15:49:06 *** mkarrer_ has quit IRC
5972016-10-19T15:53:08 *** Anduck has joined #bitcoin-core-dev
5982016-10-19T16:00:26 *** fengling has quit IRC
5992016-10-19T16:06:56 *** MarcoFalke has joined #bitcoin-core-dev
6002016-10-19T16:11:44 <GitHub183> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/475d68252e9c...c5875773561c
6012016-10-19T16:11:44 <GitHub183> bitcoin/master 37aefff Matt Corallo: Fix init segfault where InitLoadWallet() calls ATMP before genesis
6022016-10-19T16:11:44 <GitHub183> bitcoin/master c587577 Wladimir J. van der Laan: Merge #8928: Fix init segfault where InitLoadWallet() calls ATMP before genesis...
6032016-10-19T16:11:59 <GitHub121> [bitcoin] laanwj closed pull request #8928: Fix init segfault where InitLoadWallet() calls ATMP before genesis (master...2016-10-fix-segfault) https://github.com/bitcoin/bitcoin/pull/8928
6042016-10-19T16:24:38 *** Chris_Stewart_5 has quit IRC
6052016-10-19T16:28:54 *** goatpig has joined #bitcoin-core-dev
6062016-10-19T16:29:38 *** laurentmt has joined #bitcoin-core-dev
6072016-10-19T16:30:21 <goatpig> is someone trolling the testnet?
6082016-10-19T16:34:55 *** laurentmt has quit IRC
6092016-10-19T16:36:25 <btcdrak> goatpig: what do you mean?
6102016-10-19T16:41:53 <goatpig> someone pointed me to a 4k long fork
6112016-10-19T16:42:36 <goatpig> got me thinking
6122016-10-19T16:42:47 <rabidus_> how did your software manage that? :P
6132016-10-19T16:42:56 <goatpig> no idea, someone showed that to me
6142016-10-19T16:43:15 <goatpig> so, say i create a SW anyone can spend output
6152016-10-19T16:43:16 <goatpig> mine it
6162016-10-19T16:43:18 <goatpig> spend it
6172016-10-19T16:43:32 <goatpig> that would fork the chain for any 0.13 testnet node
6182016-10-19T16:43:40 <goatpig> but 0.12 nodes would see it as valid
6192016-10-19T16:43:51 <goatpig> say I throw in a couple asics and mine the hell out of that fork
6202016-10-19T16:44:00 <goatpig> I could maintain a testnet fork for a wihle, right?
6212016-10-19T16:46:33 <arubi> it really doesn't matter what you do. sure the partitioning of post fork and pre fork nodes is obvious, but that's any soft fork. you're really fighting hashpower, which is what pow is about
6222016-10-19T16:46:52 <goatpig> im trying to figure out if someone could pull that out on the testnet
6232016-10-19T16:47:08 <goatpig> im not concerned about the mainnet because, precisely because of the hashpower competition there
6242016-10-19T16:47:34 <arubi> you could probably do that on testnet, sure
6252016-10-19T16:47:41 <goatpig> ok
6262016-10-19T16:49:48 *** Evel-Knievel has quit IRC
6272016-10-19T16:51:46 <Victorsueca> testnet shows "Warning: unknown new rules activate (versionbit 28)
6282016-10-19T16:51:58 <Victorsueca> activated*
6292016-10-19T16:52:27 <jtimon> oh, rc already?
6302016-10-19T16:52:31 <jtimon> oh, rc2 already?
6312016-10-19T16:53:13 <Victorsueca> yep
6322016-10-19T16:53:43 *** Evel-Knievel has joined #bitcoin-core-dev
6332016-10-19T16:54:48 *** echonaut has quit IRC
6342016-10-19T16:55:50 *** echonaut has joined #bitcoin-core-dev
6352016-10-19T16:56:45 <wumpus> yes, rc1 was doa
6362016-10-19T16:59:01 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6372016-10-19T17:00:06 <wumpus> for rc2 we're actually going to upload executables
6382016-10-19T17:00:10 *** timothy has quit IRC
6392016-10-19T17:00:13 *** drizztbsd has joined #bitcoin-core-dev
6402016-10-19T17:00:44 *** drizztbsd is now known as timothy
6412016-10-19T17:02:20 *** cbit has joined #bitcoin-core-dev
6422016-10-19T17:03:11 <cbit> I'm getting hit with spy nodes again. Running RC1, and just checked the peers connected after running it all night.
6432016-10-19T17:05:52 <GitHub127> [bitcoin] jtimon opened pull request #8975: Chainparams: Trivial: In AppInit2(), s/Params()/chainparams/ (master...0.13-chainparams-init) https://github.com/bitcoin/bitcoin/pull/8975
6442016-10-19T17:07:04 *** Ylbam has quit IRC
6452016-10-19T17:16:00 *** face has quit IRC
6462016-10-19T17:22:51 <btcdrak> testnet is a total mess at the moment. Not sure this diff 1 thing is working out very well.
6472016-10-19T17:31:17 *** Alina-malina has quit IRC
6482016-10-19T17:34:01 *** aalex has joined #bitcoin-core-dev
6492016-10-19T17:42:43 *** Alina-malina has joined #bitcoin-core-dev
6502016-10-19T17:49:27 <Chris_Stewart_5> Yeah, I was trying to figure out what the heck is going on
6512016-10-19T17:49:53 <Chris_Stewart_5> btcdrak: What is the difficult 1 thing?
6522016-10-19T17:52:54 <rabidus_> if there is no mined blocks within x minutes, difficulty drops to 1
6532016-10-19T17:53:21 <rabidus_> so no one can make difficulty bomb at testnet
6542016-10-19T17:53:24 <Chris_Stewart_5> rabidus_: Yes, but blocks are clearly being mined within the 20 minute threshold, unless it was dropped or something
6552016-10-19T17:54:07 *** laurentmt has joined #bitcoin-core-dev
6562016-10-19T17:55:29 <cbit> uh. 58 connections off a fresh rc2. Everything inbound: 52.xx.... At least I have 6 outbound witness peers off the bat, one being wumpus ha
6572016-10-19T18:01:21 <molz> how can you tell if your node and other nodes are witness nodes or not?
6582016-10-19T18:02:28 <rabidus_> i know how to tell that my node is :P
6592016-10-19T18:03:31 <molz> mine is 0.13.1rc2 but bitnodes doesn't list it as a witness node
6602016-10-19T18:04:24 <goatpig> shoudn't that be advertized in the services?
6612016-10-19T18:04:45 <Lauda> cbit just ban it all
6622016-10-19T18:05:13 *** cbit has quit IRC
6632016-10-19T18:08:26 *** Victorsueca has quit IRC
6642016-10-19T18:10:56 *** Victorsueca has joined #bitcoin-core-dev
6652016-10-19T18:18:35 *** Alina-malina has quit IRC
6662016-10-19T18:18:35 *** Alina-malina has joined #bitcoin-core-dev
6672016-10-19T18:21:36 <achow101> wtf. gitian is failing to build the binaries.
6682016-10-19T18:23:38 <wumpus> what error? mac/linux/win all built fine here
6692016-10-19T18:24:12 *** Guyver2 has joined #bitcoin-core-dev
6702016-10-19T18:25:09 <achow101> it fails for all three for me
6712016-10-19T18:25:38 <achow101> here's the log starting from actually building the binaries for windows http://pastebin.com/rSDHf76d
6722016-10-19T18:25:41 <Victorsueca> windows built correctly here using WSL
6732016-10-19T18:26:16 <wumpus> "
6742016-10-19T18:26:17 <wumpus> x86_64-w64-mingw32-g++: internal compiler error: Killed (program cc1plus)"
6752016-10-19T18:26:43 <wumpus> either out of memory, or memory corruption/CPU overheat
6762016-10-19T18:27:14 <wumpus> could also be a compiler bug, but those are extrememly rare, usually it's a hw issue :/
6772016-10-19T18:27:24 <rabidus_> hot stuff
6782016-10-19T18:27:29 <achow101> ok... The memory is whatever gitian's default is
6792016-10-19T18:28:44 <achow101> If it's a hardware issue, i'm not too surprised then. This computer I'm using has some hardware issues.
6802016-10-19T18:30:35 <wumpus> you could try with lower parallelism
6812016-10-19T18:30:57 <wumpus> -j8 is a lot, esp. if you didn't increase the amount of memory available
6822016-10-19T18:31:53 <achow101> ok. I didn't set the -m parameter this time. so I guess I should set that?
6832016-10-19T18:33:00 <wumpus> --memory 3000 is recommended by reease-process.md
6842016-10-19T18:33:12 <wumpus> that is if you don't change -j from the default
6852016-10-19T18:34:04 <achow101> well. I just set it to -j8 and -m 9000 because I have cores and memory to spare
6862016-10-19T18:54:06 <btcdrak> i just use -j4 and nothing else, works nicely for me
6872016-10-19T19:00:49 *** BashCo has quit IRC
6882016-10-19T19:01:25 *** BashCo has joined #bitcoin-core-dev
6892016-10-19T19:02:20 *** cbit has joined #bitcoin-core-dev
6902016-10-19T19:06:00 *** BashCo has quit IRC
6912016-10-19T19:06:18 *** laurentmt has quit IRC
6922016-10-19T19:14:52 *** JackH has quit IRC
6932016-10-19T19:14:55 *** cbit has quit IRC
6942016-10-19T19:21:05 *** cbit has joined #bitcoin-core-dev
6952016-10-19T19:21:30 *** BashCo has joined #bitcoin-core-dev
6962016-10-19T19:27:56 *** Chris_Stewart_5 has quit IRC
6972016-10-19T19:42:17 *** cbit has quit IRC
6982016-10-19T19:55:32 *** cbit has joined #bitcoin-core-dev
6992016-10-19T19:56:41 *** cryptapus has quit IRC
7002016-10-19T19:59:03 <sipa> wumpus: maybe you know: http://bitcoin.stackexchange.com/q/49077/208
7012016-10-19T19:59:21 *** Chris_Stewart_5 has joined #bitcoin-core-dev
7022016-10-19T20:16:55 *** d_t has joined #bitcoin-core-dev
7032016-10-19T20:19:26 *** d_t has joined #bitcoin-core-dev
7042016-10-19T20:23:26 *** cbit has quit IRC
7052016-10-19T20:34:48 *** Ylbam has joined #bitcoin-core-dev
7062016-10-19T20:43:29 *** cbit has joined #bitcoin-core-dev
7072016-10-19T20:47:47 *** MarcoFalke has quit IRC
7082016-10-19T20:51:18 *** droark has joined #bitcoin-core-dev
7092016-10-19T20:52:18 <michagogo> rc2 detached sigs coming soon?
7102016-10-19T20:55:30 *** cbit has quit IRC
7112016-10-19T20:56:06 <michagogo> Oh, right, that's still cfields_
7122016-10-19T20:56:23 <michagogo> Why did I think wumpus was doing those these days
7132016-10-19T20:56:59 <cfields_> michagogo: will do in a bit, my cpus are tied up atm
7142016-10-19T20:58:56 *** cryptapus_afk is now known as cryptapus
7152016-10-19T21:00:39 <michagogo> cfields_: np
7162016-10-19T21:02:27 *** cryptapus has quit IRC
7172016-10-19T21:04:02 <michagogo> cfields_: I think my shell should now be retrying it every 10 minutes until it works
7182016-10-19T21:04:24 <michagogo> so whenever you push them up, my result should show up
7192016-10-19T21:05:18 <michagogo> (until <myscript>; do sleep 600; done)
7202016-10-19T21:05:51 *** cryptapus has joined #bitcoin-core-dev
7212016-10-19T21:05:52 *** cbit has joined #bitcoin-core-dev
7222016-10-19T21:23:15 *** cdecker has quit IRC
7232016-10-19T21:29:03 <BlueMatt> so there was a reasonably large performance regression in block acceptance time jeremyrubin found a while back...what are folks opinions on https://github.com/TheBlueMatt/bitcoin/commits/2016-10-fix-tx-regression ?
7242016-10-19T21:29:16 <BlueMatt> it switches ProcessNewBlock's block pointer to a shared_ptr to a const CBlock
7252016-10-19T21:29:46 <BlueMatt> ehh, fuck it, I'ma just pr it
7262016-10-19T21:30:35 <sipa> BlueMatt: which pr caused the regression?
7272016-10-19T21:30:46 <BlueMatt> the one where we moved tx wallet callbacks out of main
7282016-10-19T21:30:53 <BlueMatt> because now we keep a vector of every tx we connected
7292016-10-19T21:30:57 <BlueMatt> which requires lots of copies
7302016-10-19T21:31:10 <BlueMatt> solution: keep a shared_ptr to the block itself either as you deserialize it or as you call into ProcessNewBlock
7312016-10-19T21:31:33 <BlueMatt> later we should change the CValidationState callback to just take that shared_ptr instead of calling it for each tx
7322016-10-19T21:31:54 <sipa> does #8515 affect it?
7332016-10-19T21:32:39 <BlueMatt> sipa: I'm talking about txChanged, not txConflicted
7342016-10-19T21:32:44 <BlueMatt> so, no
7352016-10-19T21:32:48 <sipa> ok
7362016-10-19T21:32:50 <BlueMatt> though probably conflicts like a motherfucker
7372016-10-19T21:33:15 <BlueMatt> sipa: if you go ahead and rebase that I'll ack it and then we dont have to have two open prs that conflict so much
7382016-10-19T21:33:19 <BlueMatt> (if you have time)
7392016-10-19T21:33:43 <sipa> BlueMatt: about to land in SF, i can rebase 8515 in a few hours
7402016-10-19T21:34:14 <BlueMatt> sipa: alright, I'll hold off until tomorrow
7412016-10-19T21:34:21 <BlueMatt> sipa: give gmaxwell a big hug from me :p
7422016-10-19T21:37:07 *** laurentmt has joined #bitcoin-core-dev
7432016-10-19T21:37:07 *** laurentmt has quit IRC
7442016-10-19T21:37:48 <sipa> :)
7452016-10-19T21:39:40 * gmaxwell guesses he should go into the office.
7462016-10-19T21:46:12 *** goatpig has quit IRC
7472016-10-19T21:54:31 *** cryptapus is now known as cryptapus_afk
7482016-10-19T22:03:51 *** cbit has quit IRC
7492016-10-19T22:05:59 * achow101 is about to throw his computer out the window
7502016-10-19T22:06:44 <sipa> achow101: graphics acceleration at 9.81 m/s^2?
7512016-10-19T22:08:00 <achow101> :)
7522016-10-19T22:18:30 *** achow101 has quit IRC
7532016-10-19T22:22:39 *** cbit has joined #bitcoin-core-dev
7542016-10-19T22:25:15 *** achow101 has joined #bitcoin-core-dev
7552016-10-19T22:28:36 *** cbit has quit IRC
7562016-10-19T22:31:21 <cfields_> gitian builders: detached sigs for 0.13.1rc2 pushed
7572016-10-19T22:34:48 *** jannes has quit IRC
7582016-10-19T22:37:01 *** cbit has joined #bitcoin-core-dev
7592016-10-19T22:39:16 *** Victorsueca has quit IRC
7602016-10-19T22:40:25 *** Victorsueca has joined #bitcoin-core-dev
7612016-10-19T22:43:24 *** cbit has quit IRC
7622016-10-19T22:51:33 <sipa> test
7632016-10-19T22:51:49 *** sipa has left #bitcoin-core-dev
7642016-10-19T22:52:01 *** sipa has joined #bitcoin-core-dev
7652016-10-19T22:52:12 <sipa> d_t: yow
7662016-10-19T22:54:42 *** alpalp has joined #bitcoin-core-dev
7672016-10-19T22:55:12 *** cbit has joined #bitcoin-core-dev
7682016-10-19T22:56:08 <d_t> sipa: yow
7692016-10-19T22:56:15 <sipa> :)
7702016-10-19T23:04:14 *** aalex has quit IRC
7712016-10-19T23:07:40 *** Guyver2 has quit IRC
7722016-10-19T23:08:32 *** aalex has joined #bitcoin-core-dev
7732016-10-19T23:27:04 *** Ylbam has quit IRC
7742016-10-19T23:27:08 *** alpalp has quit IRC
7752016-10-19T23:50:18 *** alpalp has joined #bitcoin-core-dev