< 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?
< gmaxwell> aj: right, or get picked up as part of some other addition that needs an additional commitment.
< 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.
< gmaxwell> aj: why do you ask?
< aj> gmaxwell: have been pondering a companion segwit-costs/risks page, and when reviewing the benefits page thought that one seemed mistaken now
< 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. :)
< gmaxwell> they same deployment approach could be used though, so basically a straightforward extension.
< GitHub75> [bitcoin] rebroad closed pull request #8958: Improve logic for advertising blocks (master...BetterBroadcastLogic) https://github.com/bitcoin/bitcoin/pull/8958
< GitHub120> [bitcoin] rebroad reopened pull request #8958: Improve logic for advertising blocks (master...BetterBroadcastLogic) https://github.com/bitcoin/bitcoin/pull/8958
< 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
< gmaxwell> I don't think there was anything else.
< gmaxwell> maybe the fact that pruned nodes could skip downloading stuff they wouldn't vakidate or keep? thats stull true though, commitment structure wise.
< 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.
< 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
< 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.
< 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?
< gmaxwell> aj: thats not incorrect.
< aj> haha, high praise
< 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.
< gmaxwell> but you still sign the prevouts.
< Victorsueca> gmaxwell: the how is it prevented that somebody changes the outputs?
< Victorsueca> then*
< * Victorsueca> wonders if he just asked the whole point of segwit and should read the docs instead
< gmaxwell> Victorsueca: it's sighash single-- you're specifically flagging the signature so people can change outputs.
< Victorsueca> OMG
< Victorsueca> A wild bitcoin-qt.exe appeared
< Victorsueca> it's finally compiled
< tulip> neat, I now have 11 peers with NODE_WITNESS (but all inbound, less than ideal).
< gmaxwell> 4 on my bog standard host, all inbound.
< tulip> that was on my bog standard host, too.
< luke-jr> there's probably significantly fewer peers that they'll be willing to connect to
< tulip> restarted the patched node and it managed 7/8 outbound peers as segwit, ha.
< luke-jr> I thought it won't tolerate non-witness outbound peers at all?
< tulip> in r1 you can end up with no NODE_WITNESS peers.
< tulip> with #8949 you will continuously search until at least 4 as NODE_WITNESS.
< 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.
< luke-jr> hm
< 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.
< luke-jr> what are things coming to, when we can't even find a witness peer anymore? :<
< luke-jr> oh wait, that comment was meant for 2026, but this is 2016
< jl2012> why 0.13.1rc1 binary is not yet released?
< jl2012> aj: re SIGHASH_SINGLE: yes, BIP143 sort of fixed the bug
< jl2012> or removed the unintentional "feature" of making a replay-able signature
< 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.
< btcdrak> jl2012: we are skippng RC1 because of the non version bump iirc
< jl2012> btcdrak: it should be announced earlier so people won't waste time on building.....
< gmaxwell> good practice? (sorry)
< 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
< wumpus> also dependencies are cached by gitian so rc2 build will be faster
< GitHub108> [bitcoin] laanwj closed pull request #8962: Correct checksum error message (and debug node id) (master...CorrectChecksumError) https://github.com/bitcoin/bitcoin/pull/8962
< GitHub6> [bitcoin] laanwj closed pull request #8957: Additional UpdateBlockAvailability (master...AddUpdateBlockAvailability) https://github.com/bitcoin/bitcoin/pull/8957
< GitHub111> [bitcoin] laanwj closed pull request #8963: NodeId missing from this debug line (master...SocketSendErrorNodeId) https://github.com/bitcoin/bitcoin/pull/8963
< sipa> wumpus: wow, do you sleep?
< wumpus> I've slept a bit
< wumpus> back to whack-a-mole now...
< wumpus> and merging #8951 and tagging rc2 I guess
< wumpus> anything else that needs to go into rc2 but doesn't have a 'Needs backport' tag?
< wumpus> sipa: better question, do *you* sleep? You're still here afterall :)
< tulip> wumpus: #8949 maybe? seems sort of critical.
< sipa> 8949?
< tulip> "Be more agressive in getting connections to peers with relevant services."
< sipa> wumpus: currently at the airport
< wumpus> thanks added tag
< sipa> wumpus: my comment is more aimed "8 hours ago you were merging/closing PRs, and now again" :)
< sipa> i'm just hanging out on irc
< gmaxwell> I expect 8949 to apply cleanly to 0.13 or nearly so, it's a trivial patch in any case.
< wumpus> leave it up to rebroad to come up with lousy suggestions
< gmaxwell> what PR?
< sipa> 8949
< gmaxwell> lol
< Victorsueca> morning
< 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
< wumpus> morning Victorsueca
< gmaxwell> better that he asked instead of submitting a patch "Improve DNSseeding."
< btcdrak> yeah wumpus I replied to him
< wumpus> true gmaxwell , very true
< gmaxwell> had I added the skip I would have written a comment in the code that explained why it was there.
< gmaxwell> perhaps I should have done so when editing that section.
< Victorsueca> left 0.13.1rc1 running all night
< Victorsueca> seems to work good
< 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
< gmaxwell> Victorsueca: do you have nodewitness peers?
< gmaxwell> wumpus: Didn't know if we wanted the range based for. Okay, doing.
< wumpus> 13 witness peers on ereshkigal, two outgoing, rest incoming
< wumpus> gmaxwell: yes,we do :)
< wumpus> for new code, absolutely
< Victorsueca> gmaxwell: have 4
< gmaxwell> Victorsueca: inbound or outbound?
< Victorsueca> 3 outbound 1 inbound
< gmaxwell> will push an update as soon as this compiles.
< wumpus> going to kick my non-witness outbound peers until they're witness too :)
< Victorsueca> wumpus: lol, you'll hardfork the network if everybody does that
< wumpus> Victorsueca: I don't think so, I have plenty of non-witness inbound peers
< gmaxwell> Victorsueca: nah, it won't partition due to inbounds-- SW is intended to be witness only on outbound.
< 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.
< gmaxwell> and once SW is active we'll need to only fetch new blocks from SW peers.
< sipa> Victorsueca: and if that actually happened, we could set up some proxy nodes to relay across (though that is an emergency only, obviously)
< wumpus> Victorsueca: though, arguably if everyone did the same things as me it'd be a weird place
< 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.
< wumpus> it's somewhat working: gained one more outgoing witness peer
< gmaxwell> I updated #8949 but did not rerun tests locally (laptop slow, took all that time to just compile it. :) )
< wumpus> gmaxwell: luckily there's travis, and also if you just changes the loop type I'm not terribly afraid of that messing up :)
< gmaxwell> just letting you know.
< sipa> it's not like we're merging things and then immediately after marking it as release candidate
< sipa> oh, wait
< btcdrak> XD
< wumpus> noo, we woudl never do something ill-advised like that
< Victorsueca> lol
< 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.
< wumpus> non-mandatory beta?
< wumpus> sounds intruiging, how do you suggest forcing people to install it :)
< 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.
< wumpus> oh, never mind, NON-mandatory. Boo.
< gmaxwell> lol
< gmaxwell> We only have mandatory fun.
< wumpus> well the good news is that we can use the word 'beta' now in releases
< rebroad> is testnet broken?
< Victorsueca> if you think more testing is required then the beta release is pretty much mandatory
< wumpus> as it's no longer a static part of the release naming, as it used to be
< gmaxwell> rebroad: looks fine to me, can you be more specific?
< rebroad> My node and my peers are al stuck on block 998938
< rebroad> all
< rebroad> have raised an issue for it
< gmaxwell> rebroad: why are you saying they're stuck?
< rebroad> based on their reported startheight and my last new best
< gmaxwell> if your height is 998938 and all of their height is 998938 ... then perhaps you are all one big happy family.
< rebroad> have been for over an hour now
< tulip> receive version message: /Satoshi:0.11.0/: version 70002, blocks=1002280
< Victorsueca> rebroad: have you considered the possibility that 998938 is the best block right now?
< gmaxwell> it looks like the best block to me.
< tulip> rebroad: that's pretty normal for testnet though, and even the main network, frequently there's no blocks for hours at a time.
< gmaxwell> may just be no one is actively mining at the moment.
< rebroad> I am seeing many headers for higher heights though
< Victorsueca> maybe testnet is hard-forked
< gmaxwell> Yes, and?
< Victorsueca> that's why some nodes have a higher height
< Victorsueca> there's nothing to do with that
< gmaxwell> it has been for something like 6 months now, rogerver's "bitcoin.com" pool.
< rebroad> why isn't my node sending getdata requests for headers that are new to the block index though?
< gmaxwell> Not being sent by witness peers.
< 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.
< rebroad> unless proof of work is too low or something.. i guess more debug is needed
< rebroad> AcceptBlockHeader returns true and AddToBlockIndex was called... but it needs more debug to debug
< Victorsueca> "needs more debug to debug" -genius
< rebroad> either it's broken or my understanding is wrong. probably the latter
< sipa> rebroad: < gmaxwell> Not being sent by witness oeers.
< GitHub170> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/05998da5a7e2...1230890a6d04
< GitHub170> bitcoin/master a1919ad R E Broadley: Report NodeId in misbehaving debug
< GitHub170> bitcoin/master 1230890 Wladimir J. van der Laan: Merge #8936: Report NodeId in misbehaving debug...
< GitHub189> [bitcoin] laanwj closed pull request #8936: Report NodeId in misbehaving debug (master...NodeIdWhenMisbehaving) https://github.com/bitcoin/bitcoin/pull/8936
< 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.
< wumpus> we have a blocktrail contact
< gmaxwell> pretty interesting to reload it and watch the block numbers constantly change but continue reading 1 hr 48m ago.
< 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.
< wumpus> hehe
< GitHub181> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/1230890a6d04...e44753c06794
< GitHub181> bitcoin/master 9583477 Gregory Maxwell: Be more aggressive in connecting to peers with relevant services....
< GitHub181> bitcoin/master 4630479 Gregory Maxwell: Make dnsseed's definition of acute need include relevant services....
< GitHub181> bitcoin/master e44753c Wladimir J. van der Laan: Merge #8949: Be more agressive in getting connections to peers with relevant services....
< 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
< 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?
< tulip> Victorsueca: you're not being at all helpful by continuously saying that.
< Victorsueca> tulip: when did I say it previously?
< Victorsueca> aj: thanks
< wumpus> SegWit has been extensively tested, if we weren't sure "the whole witness thing works" it certainly wouldn't have been merged
< Victorsueca> wumpus: I guess so, just couldn't find any block that went over 1MB
< wumpus> and certainly no activation parameter would have been set on mainnet
< gmaxwell> Victorsueca: yes, there are many very large blocks on testnet (and segnet before it)
< wumpus> Victorsueca: sure, then just ask a question, instead of injecting fud into it
< Victorsueca> wumpus: sorry, didn't mean to FUD stuff
< wumpus> okay :)
< GitHub172> [bitcoin] MarcoFalke opened pull request #8972: [Qt] make warnings label selectable (master...Mf1610-qtWarnSelJS) https://github.com/bitcoin/bitcoin/pull/8972
< btcdrak> wumpus: rubensayshi and afk11 are Blocktrail contacts
< btcdrak> but Blocktrail isnt segwitty, so use https://testnet.smartbit.com.au/ for the time being
< wumpus> btcdrak: thanks
< rebroad> MarcoFalke, how did you find that commit by jonasschnelli to fix #8970 so quickly?!
< wumpus> search the current pulls / issues before opening a new one
< MarcoFalke> out of memory :P
< 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.
< GitHub169> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e44753c06794...b2df292e341d
< GitHub169> bitcoin/master 59daa58 Luke Dashjr: RPC/Mining: getblocktemplate: Update and fix formatting of help
< GitHub169> bitcoin/master b2df292 Wladimir J. van der Laan: Merge #8951: RPC/Mining: getblocktemplate: Update and fix formatting of help...
< MarcoFalke> You can submit a new one when the old one got merged.
< MarcoFalke> or closed
< 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
< rebroad> MarcoFalke, "locally"?
< MarcoFalke> on your machine
< MarcoFalke> in your .git folder
< wumpus> MarcoFalke: interesting, why did the original change never get merged? it looks fine
< rebroad> MarcoFalke, you mean some sort of "rate limiting"?
< MarcoFalke> ^
< MarcoFalke> Jup, we have over 100 open pulls and there is lack of review.
< wumpus> yes, rate limiting, to avoid DoSing other people
< 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.
< MarcoFalke> Then wumpus has to go ahead and merge something and later on people complain that there are bugs in master.
< wumpus> which is fine if the topics of the branches are wildly different
< btcdrak> each comment, or action taken on the tracker mails 1230 people...
< MarcoFalke> rebroad: But it seems you don't even compile the changes sometimes
< 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
< MarcoFalke> Please make sure to put work in a pull before you send it to a thousand people
< MarcoFalke> at least: compile, run tests, run python tests
< MarcoFalke> Also, mention the motivation in the commit body or pull body
< MarcoFalke> (I know I don't do it either, sometimes)
< MarcoFalke> but it is good practice and helps review
< 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
< wumpus> working on 8 completely disparate things at the same time is beyond the scope of human memory :p
< 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
< MarcoFalke> I stole the commit from https://github.com/bitcoin/bitcoin/pull/7134/commits
< MarcoFalke> :P
< rebroad> MarcoFalke, I am only just starting to familiarise myself with the tests.... do you mean "make check" or something else?
< MarcoFalke> ./qa/pull-tester/rpc-tests.py
< rebroad> wumpus, "8 pulls at once"? why ever not?
< wumpus> rebroad: so did #8972 solve your problem?
< MarcoFalke> We need more people running the pull tester suite, anyway
< 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
< wumpus> 'shoot a buckshot at the codebase and see what sticks' is not a strategy for development
< wumpus> at least not one that respects the time constraints and priorities of other people partaking in the project
< wumpus> to get started on testing, read https://github.com/bitcoin/bitcoin#automated-testing , it mentions the kinds of tests available
< rebroad> wumpus, how does it make any difference between raising 1 PR a day, and 7 only on Saturdays?
< wumpus> please, dont' keep arguing this
< 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.
< tulip> for anyone following, there's progress on testnet now.
< wumpus> then just go away
< GitHub106> [bitcoin] laanwj pushed 3 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/2c0913d0b3e1...7c2bf4b1759b
< GitHub106> bitcoin/0.13 33cd553 Gregory Maxwell: Be more aggressive in connecting to peers with relevant services....
< GitHub106> bitcoin/0.13 91ae0b0 Gregory Maxwell: Make dnsseed's definition of acute need include relevant services....
< GitHub106> bitcoin/0.13 7c2bf4b Luke Dashjr: RPC/Mining: getblocktemplate: Update and fix formatting of help...
< GitHub93> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b2df292e341d...d736a6eb1f91
< GitHub93> bitcoin/master ef0c9ee Jonas Schnelli: [Qt] make warnings label selectable
< GitHub93> bitcoin/master d736a6e Wladimir J. van der Laan: Merge #8972: [Qt] make warnings label selectable (jonasschnelli)...
< wumpus> MarcoFalke: #8972 for 0.13 too?
< GitHub37> [bitcoin] laanwj closed pull request #8972: [Qt] make warnings label selectable (jonasschnelli) (master...Mf1610-qtWarnSelJS) https://github.com/bitcoin/bitcoin/pull/8972
< MarcoFalke> Should not matter
< wumpus> ok, going to update the release notes lists and pulling in new translations and tagging rc2
< gmaxwell> oops.
< gmaxwell> backport is going to fail to compile.
< wumpus> we'll hear from travis soon I guess
< gmaxwell> net.cpp:1718:108: error: ‘nMaxOutbound’ was not declared in this scope if ((addr.nServices & nRelevantServices) != nRelevantServices && (nTries < 40 || nOutbound >= (nMaxOutbound >> 1)))
< Victorsueca> RIP backport
< gmaxwell> replace with MAX_OUTBOUND_CONNECTIONS
< rebroad> Apologies for earlier. I need to learn to get less emotionally involved in my pull requests.
< wumpus> we all do, np, it's kind of a stressful time and not a good time to pick fights now :)
< rebroad> oh.. I didn't realise that? stress due to SegWit...? bitcoin related?
< btcdrak> releases are always stressful. lots to get done.
< MarcoFalke> rebroad: Also the pull request backlog
< rebroad> ah ok. will bear that in mind. PRT (pre-release-tension)
< btcdrak> ha!
< 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..?
< 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.
< rebroad> if there is anything I can do to help make the backlog seem less daunting, please do let me know
< btcdrak> rebroad: review more PRs
< btcdrak> review and _test_
< wumpus> "error: use of undeclared identifier 'nMaxOutbound'; did you mean 'nOutbound'" eh, no thangs clang
< 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?
< 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?
< btcdrak> rebroad: right, so putting yourself in the POV of the reviewers is very good practice...
< MarcoFalke> rebroad: Those tagged for 0.14, right now.
< rebroad> MarcoFalke, ah... great starting point. thanks
< 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
< GitHub144> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/7c2bf4b1759b...0dbc48a5bd83
< GitHub144> bitcoin/0.13 53e6196 Wladimir J. van der Laan: qt: pre-rc2 translations update
< GitHub144> bitcoin/0.13 0dbc48a Wladimir J. van der Laan: nMaxOutbound is MAX_OUTBOUND_CONNECTIONS on 0.13...
< 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
< rebroad> (the arrows to indicate sort direction)
< wumpus> I haven't noticed, but don't think I've ever paid close attention to it so it's certainly possible
< Victorsueca> you mean the ones on the table sort?
< rebroad> Victorsueca, yes
< Victorsueca> ahh yeah, I aalways felt weird when sorting that table, now I know why
< 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
< rebroad> which is fine as descending is the more useful for most of the columns, IMHO
< rebroad> an extra click to make it ascending, of course
< wumpus> for things such as ping that makes sense, I guess, the only time descending is annoying is in text columns
< Victorsueca> I think the arrow should be a bit darker to make it more visible, this is pure aesthetics tho
< wumpus> that's up to your theme
< Victorsueca> ahh windows theme
< Victorsueca> but it seems to be rendered as text, why is it lighter than the rest of text?
< wumpus> I don't know where qt takes the theme from on windows
< 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 :)
< Victorsueca> that could be solved with a white outline
< Victorsueca> but anyway, it's ok now, no reason to bother on that
< wumpus> that's up to the theme, too
< 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
< Victorsueca> yeah, dogecoin for example uses a funny typography
< GitHub156> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/6e8936032fb865c0448bec0e0f168e041a586285
< GitHub156> bitcoin/0.13 6e89360 Wladimir J. van der Laan: doc: Update release notes for rc2
< Victorsueca> 3 outbound 2 inbound right now
< wumpus> 4 outbound 10 inbound SW connections here
< Victorsueca> found a fail on the peers screen
< Victorsueca> some peers display "via" instead of the address bitcoin is bound to
< gmaxwell> Victorsueca: you have tor HS peers.
< Victorsueca> tor peers display "via mytoraddress.onion:8333"
< gmaxwell> Victorsueca: no, _outbound_ hs peers do, inbound ones are 127,0,0,1.
< Victorsueca> ahh, makes sense
< tulip> there's no meaningful identifier for them other than "hey there's a tcp connection"
< gmaxwell> I expect someday we'll listen on a special port for those... and then we'll be able to display "onion" or whatnot.
< Victorsueca> it's a bit deceptive to invert a "something via something" sentence without explanation
< Victorsueca> maybe we should rephrase that to "Local address:...." and "Remote address:..."
< wumpus> yes, listening on a special port would make a lot of sense
< wumpus> not sure why we haven't chosen to do that esp. for the auto-torcontrol stuff
< wumpus> another things some hs hosts do is to use alternative localhost interfaces, e.g., but the alternative port is a no-brainer
< gmaxwell> yea, for autocontrol its especially a no-brainer... other than needing to find another reliably free port.
< gmaxwell> (it could be ephemeral, but better if not.. if I saw a random listning port on my host I'd be rather concerned. :) )
< wumpus> won't TCP automatically choose a port for you if you listen() without setting one?
< tulip> 6667 seems pretty unused.
< tulip> if you attempt to listen on port 0, apparently that's the behaviour.
< wumpus> oh, random is not good, okay wouldn't know then. Just pick a new fixed one one and put it in chainparams then
< gmaxwell> just means that when you run multiple daemons on the same network and host, they'll collide.
< gmaxwell> same as p2p/rpc.
< wumpus> https://github.com/bitcoin/bitcoin/issues/8973 in the issue I propose ` hsport` option for that
< tulip> random would also have the weird effect of killing other daemons that try to bind to something after bitcoind
< gmaxwell> wumpus: sounds great to me.
< Victorsueca> what about random but exclude common ports?
< wumpus> why would it kill other daemons?
< 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.
< tulip> wumpus: say bitcoind came up, randomly chose 22, and then openssh tried to come up.
< wumpus> I'm all for daemon-kiliing functionality in bitcoind, but arguably it should happen intentionally :p
< btcdrak> is that everything now for rc2?
< gmaxwell> tulip: it won't randomly choose 22. It will get some port over 32768.
< tulip> gmaxwell: talking hypothetical, but ok.
< gmaxwell> kernel reserves some range of ports for ephemeral use that is outside of the range normally used for services.
< wumpus> I wonder if tor can create some kind of private, non-TCP socket
< wumpus> anyhow that's not relevant to solving the issue, but for the far future would be nice list
< tulip> gmaxwell: so there's privileged 1-1023, and >32768 for ephemeral. are there any other ranges?
< wumpus> btcdrak: I think so!
< btcdrak> wumpus: my gitian VM is ready!
< wumpus> tulip: ranges are configurable and depend on the OS, although <1024 private is pretty ingrained (I think windows is an exception there?)
< gmaxwell> tulip: not coming to mind. keep in mind these are local policy... there are sysctls to change them.
< 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.
< tulip> I hate to think what caused that to be implemented.
< wumpus> yeah rsh :-(
< wumpus> * [new tag] v0.13.1rc2 -> v0.13.1rc2
< 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
< * Victorsueca> starts compiling
< gmaxwell> wumpus: yea, that time lasted about 10 minutes.
< * btcdrak> starts gitian
< 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
< Victorsueca> so... rc2 has gmaxwell's aggressive witness node search right?
< wumpus> yes
< btcdrak> that sounds so mafia
< Victorsueca> lol
< btcdrak> the node needs a witnesss protection program
< sipa> bitcoind --aggressive=passive
< Victorsueca> done building, now starting
< 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.
< jonasschnelli> Yes. Your probably right...
< jonasschnelli> I don't have enough informations about the field-usage of IP transactions...
< jonasschnelli> Better keep the code as it is
< 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
< 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.
< Victorsueca> 7 witness peers now, all outbound
< wumpus> arubi: I don't know about berkeleydb specifics but having the wallet database crossing filesystem boundaries is reasonably dangerous
< achow101> was rc1 DOA?
< wumpus> arubi: also tmpfs is lost on reboot, which means you may lose data
< 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
< jonasschnelli> BDB has some really strange way of storing data...
< jonasschnelli> I tried to track this down and found out, that the chunks of the records value are stored in different locations.
< arubi> thanks for the lead jonasschnelli
< 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
< jonasschnelli> wumpus: Yes. Indeed.
< wumpus> with so many more urgent pulls open, it didn't seem worth the bother
< wumpus> gah instead of building rc2 I re-built rc1
< wumpus> achow101: yes
< wumpus> it didn't have the version bumped and BlueMatt discovered a crash issue within a few minutes
< wumpus> (probably in an RPC command that only he uses, but okay that's clearly a bug that shouldn't be in a release)
< jonasschnelli> wumpus: what crash? The wallet/init one? https://github.com/bitcoin/bitcoin/pull/8928
< wumpus> addnode
< wumpus> #8928 issue doesn't exist in 0.13
< wumpus> fairly sure it was introduced in the refactoring
< jonasschnelli> We should extend addnode's RPC tests
< wumpus> yes
< 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
< luke-jr> I still prefer 8775 :x
< luke-jr> it's just ugly to have request.params everywhere
< wumpus> I like request.params
< wumpus> it's literally "request parameters", what naming could be better
< jonasschnelli> I think request.param improves readability
< luke-jr> params is clear and much shorter. but whatever
< jonasschnelli> params is to generic and could be interpreted as local scope var
< luke-jr> obviously when it comes to taste, majority rules, so if everyone else disagrees, just go ahead and do it
< wumpus> yes it's a bit of a taste issue
< jonasschnelli> Right. The important thing is, that we have a flexible container in the RPC command function structure.
< wumpus> right
< BlueMatt> who is mining testnet-segwit?
< BlueMatt> phantomcircuit: or Lightsword, maybe?
< tulip> BlueMatt: me, problem?
< GitHub21> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/d736a6eb1f91...97c7f7362f9b
< GitHub21> bitcoin/master 23c32a9 Wladimir J. van der Laan: rpc: Change JSONRPCRequest to JSONRPCRequestObj...
< GitHub21> bitcoin/master 69d1c25 Jonas Schnelli: [RPC] Give RPC commands more information about the RPC request
< GitHub21> bitcoin/master e7156ad Jonas Schnelli: [RPC] pass HTTP basic authentication username to the JSONRequest object
< 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
< BlueMatt> tulip: yes, we havent addnode'd between the new fibre test network and your mining bitcoind :p
< wumpus> jonasschnelli: darn now #7551 needs rebase again
< luke-jr> :p
< 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.
< wumpus> but it's very useful functionality that definitely needs to be in 0.14
< btcdrak> BlueMatt: Lightsword, but he stopped mining yesterday to let cfields test out cgminer I believe.
< wumpus> the branch prediction profiling makes local attacks (e.g. against the kernel) somewhat easier, ASLR is still a good measure against remote attacks
< 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
< wumpus> haven't heard about using that at the kernel level though :)
< BlueMatt> hey-o, fibre works on segwit
< BlueMatt> look at that
< BlueMatt> anyone need high-speed testnet blocks? :p
< wumpus> awesome!
< BlueMatt> even worked on the first try :)
< wumpus> of course we need fast testnet blocks
< adiabat> repost from wizards, but anyone know what's up with testnet3?
< adiabat> seem to be 2 chains
< BlueMatt> what about it?
< BlueMatt> all my nodes ended up on the same chain when i synced them last night?
< BlueMatt> adiabat: is classic forked off again?
< adiabat> could be
< adiabat> test.webbtc.com is where I can see another one, that's longer
< adiabat> seems to diverge at 996198, but not sure why
< 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)
< GitHub143> [bitcoin] s-matthew-english opened pull request #8974: readability improvement (master...patch-5) https://github.com/bitcoin/bitcoin/pull/8974
< 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
< BlueMatt> adiabat: well at least tulip and Lightsword are both mining
< BlueMatt> maybe they're not peered.....
< GitHub129> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/97c7f7362f9b...5d2c8e524e10
< GitHub129> bitcoin/master fc14609 mruddy: RPC: augment getblockchaininfo bip9_softforks data
< GitHub129> bitcoin/master 5d2c8e5 Wladimir J. van der Laan: Merge #7948: RPC: augment getblockchaininfo bip9_softforks data...
< 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
< 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.
< jonasschnelli> sipa said he want to test it as well (before we merge)
< jonasschnelli> I think we should merge it and fix (possible) issues later
< jonasschnelli> but the rebase needs to be done
< jonasschnelli> I guess 8788 will lead to plenty of rebases
< btcdrak> Lightsword wanna connect to FIBRE?
< GitHub37> [bitcoin] MarcoFalke closed pull request #8974: readability improvement (master...patch-5) https://github.com/bitcoin/bitcoin/pull/8974
< 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.
< GitHub48> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/5d2c8e524e10...3e942a7060fe
< GitHub48> bitcoin/master 1880aeb Luke Dashjr: Qt: Get the private key for signing messages via WalletModel
< GitHub48> bitcoin/master 178cd88 Luke Dashjr: Qt/splash: Specifically keep track of which wallet(s) we are connected to for later disconnecting
< GitHub48> bitcoin/master 3e942a7 Jonas Schnelli: Merge #8774: Qt refactors to better abstract wallet access...
< 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
< 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.
< 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
< Lightsword> btcdrak, sure
< GitHub16> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3e942a7060fe...475d68252e9c
< GitHub16> bitcoin/master acf853d Johnson Lau: Add script tests for FindAndDelete in pre-segwit and segwit scripts
< GitHub16> bitcoin/master 475d682 Wladimir J. van der Laan: Merge #8927: Add script tests for FindAndDelete in pre-segwit and segwit scripts...
< 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
< GitHub183> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/475d68252e9c...c5875773561c
< GitHub183> bitcoin/master 37aefff Matt Corallo: Fix init segfault where InitLoadWallet() calls ATMP before genesis
< GitHub183> bitcoin/master c587577 Wladimir J. van der Laan: Merge #8928: Fix init segfault where InitLoadWallet() calls ATMP before genesis...
< 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
< goatpig> is someone trolling the testnet?
< btcdrak> goatpig: what do you mean?
< goatpig> someone pointed me to a 4k long fork
< goatpig> got me thinking
< rabidus_> how did your software manage that? :P
< goatpig> no idea, someone showed that to me
< goatpig> so, say i create a SW anyone can spend output
< goatpig> mine it
< goatpig> spend it
< goatpig> that would fork the chain for any 0.13 testnet node
< goatpig> but 0.12 nodes would see it as valid
< goatpig> say I throw in a couple asics and mine the hell out of that fork
< goatpig> I could maintain a testnet fork for a wihle, right?
< 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
< goatpig> im trying to figure out if someone could pull that out on the testnet
< goatpig> im not concerned about the mainnet because, precisely because of the hashpower competition there
< arubi> you could probably do that on testnet, sure
< goatpig> ok
< Victorsueca> testnet shows "Warning: unknown new rules activate (versionbit 28)
< Victorsueca> activated*
< jtimon> oh, rc already?
< jtimon> oh, rc2 already?
< Victorsueca> yep
< wumpus> yes, rc1 was doa
< wumpus> for rc2 we're actually going to upload executables
< cbit> I'm getting hit with spy nodes again. Running RC1, and just checked the peers connected after running it all night.
< 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
< btcdrak> testnet is a total mess at the moment. Not sure this diff 1 thing is working out very well.
< Chris_Stewart_5> Yeah, I was trying to figure out what the heck is going on
< Chris_Stewart_5> btcdrak: What is the difficult 1 thing?
< rabidus_> if there is no mined blocks within x minutes, difficulty drops to 1
< rabidus_> so no one can make difficulty bomb at testnet
< Chris_Stewart_5> rabidus_: Yes, but blocks are clearly being mined within the 20 minute threshold, unless it was dropped or something
< 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
< molz> how can you tell if your node and other nodes are witness nodes or not?
< rabidus_> i know how to tell that my node is :P
< molz> mine is 0.13.1rc2 but bitnodes doesn't list it as a witness node
< goatpig> shoudn't that be advertized in the services?
< Lauda> cbit just ban it all
< achow101> wtf. gitian is failing to build the binaries.
< wumpus> what error? mac/linux/win all built fine here
< achow101> it fails for all three for me
< achow101> here's the log starting from actually building the binaries for windows http://pastebin.com/rSDHf76d
< Victorsueca> windows built correctly here using WSL
< wumpus> "
< wumpus> x86_64-w64-mingw32-g++: internal compiler error: Killed (program cc1plus)"
< wumpus> either out of memory, or memory corruption/CPU overheat
< wumpus> could also be a compiler bug, but those are extrememly rare, usually it's a hw issue :/
< rabidus_> hot stuff
< achow101> ok... The memory is whatever gitian's default is
< achow101> If it's a hardware issue, i'm not too surprised then. This computer I'm using has some hardware issues.
< wumpus> you could try with lower parallelism
< wumpus> -j8 is a lot, esp. if you didn't increase the amount of memory available
< achow101> ok. I didn't set the -m parameter this time. so I guess I should set that?
< wumpus> --memory 3000 is recommended by reease-process.md
< wumpus> that is if you don't change -j from the default
< achow101> well. I just set it to -j8 and -m 9000 because I have cores and memory to spare
< btcdrak> i just use -j4 and nothing else, works nicely for me
< sipa> wumpus: maybe you know: http://bitcoin.stackexchange.com/q/49077/208
< michagogo> rc2 detached sigs coming soon?
< michagogo> Oh, right, that's still cfields_
< michagogo> Why did I think wumpus was doing those these days
< cfields_> michagogo: will do in a bit, my cpus are tied up atm
< michagogo> cfields_: np
< michagogo> cfields_: I think my shell should now be retrying it every 10 minutes until it works
< michagogo> so whenever you push them up, my result should show up
< michagogo> (until <myscript>; do sleep 600; done)
< 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 ?
< BlueMatt> it switches ProcessNewBlock's block pointer to a shared_ptr to a const CBlock
< BlueMatt> ehh, fuck it, I'ma just pr it
< sipa> BlueMatt: which pr caused the regression?
< BlueMatt> the one where we moved tx wallet callbacks out of main
< BlueMatt> because now we keep a vector of every tx we connected
< BlueMatt> which requires lots of copies
< BlueMatt> solution: keep a shared_ptr to the block itself either as you deserialize it or as you call into ProcessNewBlock
< BlueMatt> later we should change the CValidationState callback to just take that shared_ptr instead of calling it for each tx
< sipa> does #8515 affect it?
< BlueMatt> sipa: I'm talking about txChanged, not txConflicted
< BlueMatt> so, no
< sipa> ok
< BlueMatt> though probably conflicts like a motherfucker
< 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
< BlueMatt> (if you have time)
< sipa> BlueMatt: about to land in SF, i can rebase 8515 in a few hours
< BlueMatt> sipa: alright, I'll hold off until tomorrow
< BlueMatt> sipa: give gmaxwell a big hug from me :p
< sipa> :)
< * gmaxwell> guesses he should go into the office.
< * achow101> is about to throw his computer out the window
< sipa> achow101: graphics acceleration at 9.81 m/s^2?
< achow101> :)
< cfields_> gitian builders: detached sigs for 0.13.1rc2 pushed
< sipa> test
< sipa> d_t: yow
< d_t> sipa: yow
< sipa> :)