< GitHub180> [bitcoin] pooleja opened pull request #8935: Documentation: Building on Windows with WSL (master...windows_build_docs) https://github.com/bitcoin/bitcoin/pull/8935
< GitHub13> [bitcoin] rebroad opened pull request #8936: Report NodeId in misbehaving debug (master...NodeIdWhenMisbehaving) https://github.com/bitcoin/bitcoin/pull/8936
< phantomcircuit> wumpus: in trying to make more of the wallet things private i have run into a problem
< phantomcircuit> all the things which are private are called by tests
< phantomcircuit> so i cant just make them private
< sipa> make them protected, and let the tests work with a subclass
< phantomcircuit> sipa: that is a good solution
< wumpus> phantomcircuit: +1 on sipa's solution
< wumpus> we do a similar thing for CAddrMan for a test interface to override the randomness
< wumpus> cfields_: hey, I've been trying something weird: to build bitcoin core in the 'termux' environment on my android phone. This is basically just a arm (64 bit in this case) Linux system, with one catch: there is no shell interpreter, or anything useful for that matter in /bin. All the shell utilities are available in the path though.
< wumpus> cfields_: I have no idea whether this can be realistically gotten to work though, so much assumes that /bin/sh is a shell :)
< wumpus> cfields_: not a high priority thing though building bitcoin core *on* my phone would be quite awesome
< wumpus> (I know there's debian chroots which avoid this, but that requires root and don't want to bother rooting right now)
< GitHub13> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/49c591037289...0329511b9cd6
< GitHub13> bitcoin/master 032e883 Matt Corallo: [qa] Send segwit-encoded blocktxn messages in p2p-compactblocks
< GitHub13> bitcoin/master a4ad37d Matt Corallo: [qa] Build v4 blocks in p2p-compactblocktests...
< GitHub13> bitcoin/master 0329511 Wladimir J. van der Laan: Merge #8922: [qa] Send segwit-encoded blocktxn messages in p2p-compactblocks...
< GitHub100> [bitcoin] laanwj closed pull request #8922: [qa] Send segwit-encoded blocktxn messages in p2p-compactblocks (master...segwitcb) https://github.com/bitcoin/bitcoin/pull/8922
< GitHub8> [bitcoin] sipa opened pull request #8937: Define start and end time for segwit deployment (master...bip141start) https://github.com/bitcoin/bitcoin/pull/8937
< GitHub80> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/0329511b9cd6...53133c1c041d
< GitHub80> bitcoin/master 3ade2f6 Johnson Lau: Add standard limits for P2WSH with tests
< GitHub80> bitcoin/master 4c0c25a Johnson Lau: Require compressed keys in segwit as policy and disable signing with uncompressed keys for segwit scripts
< GitHub80> bitcoin/master 9f0397a Johnson Lau: Make test framework produce lowS signatures
< GitHub23> [bitcoin] laanwj closed pull request #8499: Add several policy limits and disable uncompressed keys for segwit scripts (master...badwitnesscheck) https://github.com/bitcoin/bitcoin/pull/8499
< sipa> petertodd, cdecker, BlueMatt, luke-jr: do your dns seeds support flag filtering?
< cdecker> sipa: not yet, was intending to implement it for the longest time
< cdecker> Is there a plan to rely on it in future?
< sipa> yes, for segwit
< cdecker> Ok, then I'll invest some time to support it ^^
< sipa> cool!
< GitHub27> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/53133c1c041d...c90111314435
< GitHub27> bitcoin/master 282abd8 fanquake: [build-aux] Boost_Base serial 27
< GitHub27> bitcoin/master 6dd3723 fanquake: Set minimum required Boost to 1.47.0
< GitHub27> bitcoin/master c901113 Wladimir J. van der Laan: Merge #8920: Set minimum required Boost to 1.47.0...
< GitHub135> [bitcoin] laanwj closed pull request #8920: Set minimum required Boost to 1.47.0 (master...set-minimum-boost) https://github.com/bitcoin/bitcoin/pull/8920
< wumpus> I'm trying to cherry-pick #8499 into #8916 for backporting to 0.13, however I'm running into conflicts in the tests (p2p-segwit.py) - does anyone know if any precursor changes to the RPC tests there that are not in #8916 yet?
< wumpus> (big conflicts, not trivial one-liners)
< wumpus> may be better to leave this backport to jl2012
< sipa> $ ./src/bitcoind
< sipa> Error: -daemon is not supported on this operating system
< sipa> Ubuntu 14.04.5 LTS
< wumpus> sipa: you need to clean your tree
< sipa> ah
< sipa> thanks
< wumpus> (or at least rerun autoconf and configure)
< sipa> ah yes, i remember reading that comment
< wumpus> never mind on #8499, I was somehow trying to backports the commit in reverse order
< wumpus> (testing a new script and all that)
< jl2012> wumpus, you want me to make a backport?
< wumpus> jl2012: I was afraid so as the diff looked quite large, but it's no longer necessary
< wumpus> it's part of #8916 now
< jl2012> if it could be cleanly cherry-picked, that should be fine
< wumpus> there was only a trivial two-liner conflict in the tests
< jl2012> ok
< achow101> Yay! 0.13.1 is almost here! #8937 needs to be added to the milestone
< jl2012> let me know if you need any action from me
< wumpus> I will, thank you
< petertodd> sipa: mine does
< sipa> petertodd: oh, i'm confused, you don't even have a mainnet seed
< petertodd> sipa: yes, my testnet seed does :)
< sipa> interesting, my seeder has 8 IPs that already report NODE_WITNESS
< petertodd> sipa: what else are they reporting? I've noticed that some nodes put total garbage in nServices
< sipa> i wad about to check, and my laptop battery died
< petertodd> ha
< sipa> 3 of them are possibly legitimate
< BlueMatt> sipa: no, am I supposed to do that?
< BlueMatt> sipa: oh, you mean to filter to only give segwit peers?
< sipa> yes
< sipa> a request for xHEXFLAGS.your.dns.seed gives only peers that report said flags in their result
< BlueMatt> oh
< BlueMatt> uhhhhh
< BlueMatt> hum
< sipa> if supported, bitcoin core will ask for x9.your.dns.seed
< BlueMatt> that doesnt work with my dnsseed
< sipa> that's fine, it doesn't have to
< BlueMatt> my seed generates a bind zonefile and schleps that off to a bunch of servers
< sipa> it's enabled on a per seed basis
< BlueMatt> so there is no way for me to reasonably do that
< BlueMatt> though i could do it for a small subset of possible flags
< sipa> yes, only x9 is needed
< BlueMatt> mmm, ok
< BlueMatt> give me a few hours
< sipa> ha, there isn't *that* much hurry either
< BlueMatt> all y'all with dnsseed-server-homogeneousness
< BlueMatt> need some diversity :p
< sipa> i am not complaining.
< sipa> :)
< BlueMatt> ehh, 0.13.1rc1 today, should get it done :p
< paveljanik> better discussing Oxford comma than FT ;-)
< instagibbs> FT? :P
< GitHub66> [bitcoin] laanwj closed pull request #8916: 0.13.1 backports (0.13...2016_10_backports) https://github.com/bitcoin/bitcoin/pull/8916
< GitHub73> [bitcoin] laanwj pushed 22 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/4ed26277347c...09bc76de60b7
< GitHub73> bitcoin/0.13 0027672 Johnson Lau: Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH...
< GitHub73> bitcoin/0.13 3e80ab7 Johnson Lau: Add policy: null signature for failed CHECK(MULTI)SIG...
< GitHub73> bitcoin/0.13 7ae6242 Cory Fields: net: fix a few cases where messages were sent rather than dropped upon disconnection...
< BlueMatt> instagibbs: flexible transactions - tom zanders shit
< instagibbs> Oh, haha.
< paveljanik> hmm, removing the Oxford commas can save us 2 (two!) bytes!
< paveljanik> imagine all those forks!
< instagibbs> I see you've found your scaling bitcoin topic for 2017
< paveljanik> the next SB will surely be at the date of my wife' birthday or any similar death-important family date as always :-(
< sipa> well at least we'll have a few topics for the next SB, such as segwit, ft, and the oxford comma.
< sipa> *ducks*
< paveljanik> Can't parse the sentence ;-)
< BlueMatt> I think he meant ft, segwit and the oxford comma
< btcdrak> FTFY: ft, segwit and, the oxford comma
< BlueMatt> bip 9 bit 1 has def never been used, right?
< BlueMatt> has someone scanned recent block versions?
< btcdrak> blocks have only been 0x30000000, 0x20000000, 0x20000001, and 0x30000001
< BlueMatt> bit 1 being 0x2, right?
< btcdrak> BlueMatt: yes
< sipa> yes
< btcdrak> we used bit 0 for CSV
< BlueMatt> ok, sounds good
< BlueMatt> just figued I'd doube check
< instagibbs> just to make sure what about bip109
< btcdrak> We can save more bytes on the BIPs by aggregating like Schnorr: BIP141+143+147 = BIP431
< sipa> BlueMatt: last use of bit 1 was over 20k blocks ago
< BlueMatt> sipa: thanks
< sipa> though apparently it has been used with some frequency further back
< BlueMatt> heh, funny
< sipa> 1128 blocks set bit 1 in the past 50k blocks
< btcdrak> sipa bit 1?
< instagibbs> BlueMatt, sigh, at a minimum I'd like the debug help for cmpctblocks(sp!?)
< BlueMatt> instagibbs: yes, thats why I'm poking sipa :p
< instagibbs> cmpctblock
< sipa> cmpctblcks, w dnt spprt th s f vwls hr
< BlueMatt> we dont support the use of vowels here, for those with parse-issues
< sipa> i approve of BlueMatt's compact writing decoder
< achow101> it would be much more compact if you removed all the spaces
< jtimon> wumpus: around?
< jtimon> re https://github.com/bitcoin/bitcoin/pull/8921 "getinfo has been deprecated" when did that happened? for 0.13 or for 0.14 ?
< jtimon> ie is there any blocker to remove it already or are we just waiting to do it for 0.15 ?
< instagibbs> 0.14
< jtimon> instagibbs: I see, so we're in fact waiting for removing it in 0.15, thanks
< btcdrak> oh why is getinfo for the chop?
< GitHub170> [bitcoin] s-matthew-english opened pull request #8938: update to bitcoin-qt.desktop (master...master) https://github.com/bitcoin/bitcoin/pull/8938
< instagibbs> Not sure, just saying it's not deprecated in 0.13.1
< achow101> jtimon: apparently it has been deprecated for years
< instagibbs> it's a hodgepodge of info you can individually get elsewhere
< GitHub167> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/cb8887e87df315dbc6c560149b3a97b704a676aa
< GitHub167> bitcoin/0.13 cb8887e Wladimir J. van der Laan: qt: periodic translation update
< jonasschnelli> getinfo is to general and uses all sorts of locks
< GitHub185> [bitcoin] s-matthew-english closed pull request #8938: update to bitcoin-qt.desktop (master...master) https://github.com/bitcoin/bitcoin/pull/8938
< jtimon> btcdrak: it has been for a while, at least jun12 2014, see https://github.com/bitcoin/bitcoin/pull/4333#issuecomment-45882887
< btcdrak> wow, looks like an RC today
< achow101> so if rc is tagged today, then should we hold off on that pre-final alert?
< jtimon> jonasschnelli: are there more locks than cs_main ? :p
< jonasschnelli> hehe...
< instagibbs> "Perhaps 0.10 is a good release for killing getinfo :)?" heh
< jonasschnelli> "all sorts of locks" mostly means: cs_main and cs_wallet
< sipa> we clearly need to add a cs_getinfo first.
< jtimon> yeah, not sure if I should wait for 0.15 to remove the "temporal" TestnetToBeDeprecatedFieldRPC or do it directly in #8921, certainly rpcmining can remove its redundant "testnet" field though
< btcdrak> sipa: you need to update your BIP PR to amend this as well https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki
< btcdrak> maybe I can just edit it
< sipa> BlueMatt: your rebase of compact block tweaks differs from my manual version
< sipa> - if (mi->second->nHeight >= chainActive.Height() - MAX_CMPCTBLOCK_DEPTH) {
< sipa> + if (CanDirectFetch(Params().GetConsensus()) && mi->second->nHeight >= chainActive.Height() - MAX_CMPCTBLOCK_DEPTH) {
< sipa> - LOCK(cs_main);
< BlueMatt> argh
< sipa> + CBlock block;
< sipa> + bool fBlockRead = false;
< sipa> we want the '+' side of this, right?
< BlueMatt> i have no idea, need context
< sipa> the '-' side lacks your fix for reduction of locks
< BlueMatt> note that my branch includes one commit on top
< sipa> ah
< BlueMatt> yea, i was suggesting we dont bother with that commit (the cs_main fix)
< * jtimon> sees Params().GetConsensus() being used directly...
< BlueMatt> just because it already has acks on the pr
< BlueMatt> easy to push it to another pr
< sipa> BlueMatt: then there is still a difference
< BlueMatt> jtimon: yea, i think sdaftuar point that out to me on fri or so
< BlueMatt> should fix
< jtimon> BlueMatt: great. I mean, not a big deal, but I grep Params() every time I rebase #7829 git blame would blame you
< BlueMatt> jtimon: no, its already passed into that function, so should not call Params()
< BlueMatt> sipa: lemme look
< sipa> BlueMatt: in response to receiving a getdata MSG_CMPCT_BLOCK, and we're likely in IBD, should we respond with a normal block or not?
< BlueMatt> yes
< sipa> i don't remember where this patch originates
< BlueMatt> normal block
< sipa> ok
< sipa> rebased
< sipa> (using your history)
< BlueMatt> kk
< BlueMatt> wait, now I'm confused
< BlueMatt> i thought we did want the CanDirectFetch?
< sipa> indeed
< sipa> your version had that, mine does not
< BlueMatt> i dont see it on the github diff now?
< sipa> presumably because the CanDirectFetch already exists in master, and my patch unintentionally undid it
< sipa> while yours leaves it alone
< BlueMatt> ahh, ok
< sipa> actually, no
< BlueMatt> yea, no, it should be on L4877
< sipa> i just pushed the wrong branch
< sipa> fixed now
< BlueMatt> (though, as jtimon points out, it shouldnt call Params(), it should use consensusParams)
< sipa> ah
< sipa> fixing
< BlueMatt> thanks
< sipa> jtimon: sorry, wasn't clear to me that we actually already had a consensusParams variable there
< GitHub157> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c90111314435...c6b959efcf2d
< GitHub157> bitcoin/master f9c23de Pieter Wuille: Define start and end time for segwit deployment
< GitHub157> bitcoin/master c6b959e Wladimir J. van der Laan: Merge #8937: Define start and end time for segwit deployment...
< GitHub74> [bitcoin] laanwj closed pull request #8937: Define start and end time for segwit deployment (master...bip141start) https://github.com/bitcoin/bitcoin/pull/8937
< sipa> > No results matched your search.
< sipa> \0/
< achow101> \o/
< jtimon> sipa: ideally if we don't have it, create it at the top for "my minions" to turn it into a parameter more easily
< sipa> jtimon: fixed in #8637
< * BlueMatt> goes to update his node due to preferential peering stuff
< jtimon> thanks!
< sipa> BlueMatt: how ready is FIBRE for segwit?
< BlueMatt> uhhh, uhhhhh
< BlueMatt> just needs rebased on master now
< sipa> You have 6 weeks.
< BlueMatt> I'll do that this week
< sipa> May the blocks be ever in your favor.
< GitHub97> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/8b66659921e6170831f3a043e9a54fa45776aa68
< GitHub97> bitcoin/0.13 8b66659 Pieter Wuille: Define start and end time for segwit deployment...
< achow101> rc1 tag now?
< btcdrak> achow101: we need release notes yet I think?
< sipa> going to update my node to 0.13 branch
< instagibbs> cmpctblks twkz, and notes?
< sipa> i don't think we need the tweaks in 0.13
< instagibbs> ok fine :( I'll just tattoo it on my arm
< jtimon> yeah, doesn't 8637 need backporting?
< jtimon> oh, ok
< achow101> oh, release notes. can't forget about those
< instagibbs> Well at this point, I should just proposed we change the debug string to something easier to remember
< jtimon> what debug string?
< instagibbs> -debug=cmpctblock. I'll stop complaining now :)
< wumpus> working on release notes
< sipa> you need help?
< wumpus> probably; I'll do the list of pulls and authors, but if something needs special mention please submit a pull
< BlueMatt> sipa: if i update my dnsseed today do we want that in 0.13?
< sipa> BlueMatt: i would say so
< wumpus> yes
< BlueMatt> argh, ok, I'll prioritize that today
< sipa> BlueMatt: you can of course 'trivially' support it by just making x9.* an alias for the normal seed
< btcdrak> are petertodd and jonasschnelli's seed working ok yet? they seemed really flakey for a while
< sipa> so you can do the actual implementation work later
< BlueMatt> sipa: ok, true, I'll do that and we can add the tag today
< sipa> btcdrak: jonasschnelli's seems to work, though it only returns one x9 node
< btcdrak> I was just about to say
< btcdrak> sipa: yours in only returning 3 x9s
< sipa> btcdrak: it knows about 8, though a few are fake
< sipa> the result corresponds with my database, though
< sipa> so i think we're good
< sipa> once 0.13.1 nodes appear, they should be detected
< sipa> wumpus: are the release notes for 0.13.1 supposed to be relative to 0.13.0 or 0.12?
< sipa> 0.13.0 i suppose, as the file is empty
< wumpus> wumpus: 0.13.0
< sipa> wumpus: is wumpus talking to himself?
< wumpus> release notes are relative to the last minor release in case of a major release, and relative to the previous release on that branch in case of a minor release
< wumpus> lol
< achow101> what are x9 nodes?
< sipa> achow101: 9 == hex for NODE_NETWORK|NODE_WITNESS
< achow101> i see
< BlueMatt> dig x9.dnsseed.bluematt.me
< BlueMatt> ;; ANSWER SECTION:
< BlueMatt> x9.dnsseed.bluematt.me.120INCNAMEdnsseed.bluematt.me.
< gribble> Error: "ANSWER" is not a valid command.
< BlueMatt> is that sufficient sipa ?
< sipa> ack
< BlueMatt> if you add it to src, please include a comment noting that this is only active for x9, and someone needs to ping me if they want more
< sipa> same for my seeder
< sipa> it supports only a few combinations
< BlueMatt> ok, should add a comment, then :)
< achow101> how do i see what nodes the seeder reports for those nodes?
< achow101> for x9
< sipa> dig x9.[seedername]
< achow101> thnx
< GitHub16> [bitcoin] sipa opened pull request #8939: Update implemented bips for 0.13.1 (master...bips131) https://github.com/bitcoin/bitcoin/pull/8939
< sipa> BlueMatt: send PR?
< BlueMatt> sipa: I'ma add lots o comments
< sipa> k!
< BlueMatt> sipa: which does yours support?
< sipa> x1, x5, x9, x13
< BlueMatt> jonasschnelli: which does yours support?
< BlueMatt> I assume the same as sipa?
< sipa> presumably the same - it's the software default, though it can be configured with a cmdline flag
< achow101> does the current master advertise WITNESS?
< sipa> yes
< sipa> it should!
< GitHub145> [bitcoin] TheBlueMatt opened pull request #8940: Add x9 service bit support to dnsseed.bluematt.me (master...2016-10-dnsseed) https://github.com/bitcoin/bitcoin/pull/8940
< BlueMatt> sipa: ^
< achow101> hmm. I don't see my node in the seeders for x9
< BlueMatt> achow101: lol, they're not /that/ fast to pick up updates
< sipa> achow101: wait a few days
< achow101> I've been running builds of master since a very long time ago
< sipa> master only advertizes NODE_WITNESS since the merge of 8937, 40 minutes ago
< BlueMatt> achow101: master has only supported it for like the last hour
< achow101> oh. I thought it advertised it earlier.
< instagibbs> achow101, NODE_WITNESS is only advertised once bip9 parameters have been defined for a chain
< achow101> yup. just realized that
< sipa> "subver": "/Satoshi:0.13.99(Ereshkigal)/",
< sipa> anyone know what that is?
< MarcoFalke> just someone setting -uacomment?
< sipa> there are multiple nodes reporting that
< wumpus> should be only one, mine
< sipa> ah
< MarcoFalke> Anything holding back 8928?
< sipa> wumpus: i have hereby deanonimized your onion address (i have two connections reporting that, one onion one ipv4)
< wumpus> good one :-) luckily it's a public node
< wumpus> though good point on deanonimization using bitcoin user agents, woudl be something to add as warning to onionscan
< wumpus> though one shouldn't have their node listening on both onion and clearnet if the intention is to hide, I hope we mention that in tor.md
< sipa> i believe we do
< wumpus> MarcoFalke: completely focused on 0.13.1 right now, will look later
< wumpus> sipa: I can't find the commit for #8651 (Predeclare PrecomputedTransactionData as struct) in https://github.com/bitcoin/bitcoin/pull/8679 , am I missing something or was it squashed into another one?
< wumpus> (need to manually fix these as they have no Github-Pull header)
< sipa> wumpus: seems it was squashed
< wumpus> yes, seems to be part of b8c79a057c48c871a5e48bdcdf600fbfe68f656b, thanks
< sipa> wumpus: i'll remember to add Github-Pull tags in the future
< sipa> wumpus: is there some reference for that in the developer notes?
< wumpus> no, I don't think it's mentioned anywhere, it should be
< wumpus> I recently wrote my own auto-backport script and there's one by luke-jr floating around, should probably reference at least one of them there then
< wumpus> anyhow having to sort a few manually is not a big deal, it's a lot of manual work anyway
< MarcoFalke> I like the script by luke-jr. Makes sure the formatting is consistent and it requires less brain power, so less typos.
< MarcoFalke> Oh, Is 8939 the last pull before tagging 0.13.1?
< BlueMatt> also need #8940
< wumpus> a script does help, it's easy to mistype pull numbers
< wumpus> they should have an error correcting digit :)
< btcdrak> s/wumpus/sipa/
< sipa> btcdrak: i had found that myself, but didnt answer who was running the node :)
< btcdrak> pagans
< wumpus> releases are still too infrequent to warrant automating a lot of the things, though it would be good for consistency
< wumpus> btcdrak: :D
< sipa> we need wumpus.sh, though
< btcdrak> testnet is running 0.13 now
< btcdrak> ^ mining with
< sipa> 0.13.1?
< btcdrak> yes
< btcdrak> cfields_: any update on cgminer?
< btcdrak> proof reading appreciated please https://github.com/bitcoin-core/bitcoincore.org/pull/235
< wumpus> wumpus.sh hah, could at least spawn a few instances in parallel then
< sipa> btcdrak: will read
< waxwing> btcdrak: "Despite the keyhash formula is same as" should be "Despite the fact that the .. is the same as"
< GitHub169> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/7462125724ed3b88de490ab1bc3a4c3bea65fe2d
< GitHub169> bitcoin/0.13 7462125 Wladimir J. van der Laan: doc: Fill in changelog and authors in release notes
< GitHub124> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/614ef85ff97602c31f471436004210a74f2d8946
< GitHub124> bitcoin/0.13 614ef85 Wladimir J. van der Laan: doc: Properly sort authors list
< waxwing> well, for some values of 'you'
< waxwing> lines 122-124 'permanent(ly)'
< jl2012> waxing: thanks for reviewing. Sorry for many typos. I'll fix later
< GitHub61> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c6b959efcf2d...ef3402d9a8cb
< GitHub61> bitcoin/master 0941f55 Pieter Wuille: Update implemented bips for 0.13.1
< GitHub61> bitcoin/master ef3402d Wladimir J. van der Laan: Merge #8939: Update implemented bips for 0.13.1...
< GitHub44> [bitcoin] laanwj closed pull request #8939: Update implemented bips for 0.13.1 (master...bips131) https://github.com/bitcoin/bitcoin/pull/8939
< waxwing> actually just s/scripPubKey/scriptPubKey/g
< GitHub22> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/06d15fbea6fafb714f9576664422615704ad05fb
< GitHub22> bitcoin/0.13 06d15fb Pieter Wuille: Update implemented bips for 0.13.1...
< wumpus> https://github.com/bitcoin/bitcoin/blob/0.13/doc/release-notes.md#notable-changes I guess the segwit activation needs special mention? Is there any text we can take over from any of the FAQs for this?
< GitHub195> [bitcoin] cdecker opened pull request #8941: Marking filter support for cdecker's DNS seed (master...dns-filter) https://github.com/bitcoin/bitcoin/pull/8941
< harding> wumpus: I can probably find and adapt something.
< wumpus> harding: that'd be awesome
< cdecker> sipa: DNS filtering support added :-)
< wumpus> cdecker: thanks
< sipa> cdecker vs BlueMatt: 1-0
< sipa> ;)
< cdecker> Didn't know it was a competition
< sipa> (just kidding, i'm amazed you both started working on this immediately)
< cdecker> But I'll take the point ^^
< BlueMatt> wait, do you have your own seeder codebase cdecker?
< BlueMatt> sipa: also, have you seen my seeder codebase? good god its horendous
< cdecker> Yep, I have implemented my own crawler + dns seed
< sipa> BlueMatt: thankfully i don't need to
< cdecker> Same here, I'll have to rework it eventually
< BlueMatt> I mean I guess its better than the old one...which was based on magicaltux's php half-node and spawned a new process for each node it tested
< BlueMatt> :p
< sipa> i knew the php part
< BlueMatt> also, mysql
< sipa> i guess you've learned.
< BlueMatt> lol, not really, now its in java :p
< wumpus> at least not javascript...
< Lightsword> I hear javascript is the new big thing
< * Lightsword> *hides*
< sipa> asmjs is almost a decent object format :p
< cdecker> Oh yeah we should do crypto in JS :D
< BlueMatt> Lightsword: no, you're thinking of BASIC
< cdecker> Visual Basic!
< BlueMatt> cdecker: no, that was never the new big thing
< Lightsword> BlueMatt, I suggest COBOL, I hear it’s what all the banks use so it must be good :P
< sipa> can we please not start a flamewar about programming languages? everybody knows that ALGOL was never beaten
< cdecker> You're right, it's the rock solid foundation we all built upon
< BlueMatt> sipa: its called a "religious" war
< sipa> BlueMatt: that'd be emacs vs vi :)
< BlueMatt> you forgot the m
< BlueMatt> in vim
< BlueMatt> :p
< sipa> BlueMatt: pff, vim == vi improved
< BlueMatt> sipa: ehh, i guess either is better than mcedit :p
< sipa> that's right.
< sipa> you misspelled "neither"
< BlueMatt> cdecker: which flags do you support?
< sipa> Lightsword: edlin?
< cdecker> The 4 least significant bits
< cdecker> Any combination thereof
< BlueMatt> argh, you broke my scheme
< cdecker> So x5 and x13 are included
< BlueMatt> cdecker: so x1 - x13?
< sipa> x1-x15
< cdecker> Yep
< BlueMatt> yea, thats what i said
< BlueMatt> x1-x15
< GitHub15> [bitcoin] MarcoFalke opened pull request #8942: [doc] 0.13.1: Minor clarification to release notes (0.13...Mf1610-131doc) https://github.com/bitcoin/bitcoin/pull/8942
< cdecker> Well x0 actually also replies, but is equal to no filter
< sipa> i always require NODE_NETWORK, so nothing is equivalent to x1
< cdecker> Hm, haven't found a node without that bit set yet, I'm sure someone broke it somewhere xD
< BlueMatt> wumpus: ok, merged the two
< wumpus> thanks!
< GitHub157> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/06d15fbea6fa...498e950daaf3
< GitHub157> bitcoin/0.13 fa161e8 MarcoFalke: [doc] 0.13.1: Minor clarification to release notes
< GitHub96> [bitcoin] laanwj closed pull request #8942: [doc] 0.13.1: Minor clarification to release notes (0.13...Mf1610-131doc) https://github.com/bitcoin/bitcoin/pull/8942
< GitHub157> bitcoin/0.13 498e950 Wladimir J. van der Laan: Merge #8942: [doc] 0.13.1: Minor clarification to release notes...
< GitHub85> [bitcoin] cdecker closed pull request #8941: Marking filter support for cdecker's DNS seed (master...dns-filter) https://github.com/bitcoin/bitcoin/pull/8941
< wumpus> this leaves MarcoFalke's remark about sipa's seeder - any explanation why it wouldn't respond to x13?
< sipa> hmm
< cdecker> Does it reply to x8?
< sipa> i just responded
< sipa> but i'm confused myself
< sipa> let me check
< sipa> sigh
< sipa> 13 would xd.seed.bitcoin.sipa.be
< sipa> not x13
< * sipa> fails at hex
< sipa> BlueMatt: ^
< BlueMatt> cdecker: so you reply to 0x1 - 0xf, right?
< cdecker> Darn, I'm using the decimal representation
< sipa> cdecker: no worries, it works for x9 :)
< wumpus> heh, it would have been more clear if we had padded to 64 bits
< sipa> waste of bandwidth!!!!1
< cdecker> So wait, which one is the format to implement? Hex or decimal
< wumpus> hex
< cdecker> Ok, give me a minute
< wumpus> sorry for the confusion, I had forgot too
< sipa> ^ not a blocker
< BlueMatt> ok, fixed the text to indicate hex everyhwere
< cdecker> Fixed and restarted
< GitHub190> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/ef3402d9a8cb...763828df499f
< GitHub190> bitcoin/master 504c72a Matt Corallo: Comment that most dnsseeds only support some service bits combos
< GitHub190> bitcoin/master ffb4713 Matt Corallo: Add x9 service bit support to dnsseed.bluematt.me
< GitHub190> bitcoin/master 2449e12 Christian Decker: My DNS seed supports filtering...
< GitHub161> [bitcoin] laanwj closed pull request #8940: Add x9 service bit support to dnsseed.bluematt.me (master...2016-10-dnsseed) https://github.com/bitcoin/bitcoin/pull/8940
< BlueMatt> phew, back to 100% on 0.13.1
< GitHub87> [bitcoin] laanwj pushed 3 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/498e950daaf3...5b4192bc4c40
< GitHub87> bitcoin/0.13 9aa0c15 Matt Corallo: Comment that most dnsseeds only support some service bits combos...
< GitHub87> bitcoin/0.13 3d770a8 Matt Corallo: Add x9 service bit support to dnsseed.bluematt.me...
< GitHub87> bitcoin/0.13 5b4192b Christian Decker: My DNS seed supports filtering...
< GitHub171> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/e1169b052991671db1043f432a85b31f9245a4c2
< GitHub171> bitcoin/0.13 e1169b0 Wladimir J. van der Laan: doc: Update release notes for last-minute pulls
< wumpus> time to tag 0.13.0rc1? would be a shame to hold it up on the release notes, those can be updates right until -final anyway
< wumpus> 0.13.1rc1*
< btcdrak> do it!
< btcdrak> I just fired up my gitian VM in anticipation
< harding> I'll be done it about 5 minutes.
< wumpus> harding: then we'll wait for you, I need to run pre-release tests anyway
< MarcoFalke> Oh I should have started caching for gitian yesterday..
< wumpus> its not a competition :p
< GitHub18> [bitcoin] harding opened pull request #8943: Release notes: add info about segwit and null dummy soft forks (0.13...notable-change-segwit) https://github.com/bitcoin/bitcoin/pull/8943
< btcdrak> MarcoFalke: for Travis?
< MarcoFalke> btcdrak: gitian will cache the depends dir, so it will run faster if you do it the day before rc1 :P
< achow101> MarcoFalke: doesn't the cache persist across builds? When I run the cacheing command again it doesn't actually do anything since everything is already there
< MarcoFalke> Yes, it does. But usually some of the depends are bumped, so the compiled and cached ones are no longer valid.
< achow101> did we bump any depends this time?
< achow101> nvm, we did with boost for windows waking
< wumpus> looks like travis is failing on 0.13 brnach
< wumpus> linux 64 bits, no clear error https://travis-ci.org/bitcoin/bitcoin/jobs/168377467
< wumpus> "Running test/bitcoin-util-test.py..."
< MarcoFalke> Should we backport the "run prevector tests faster"
< MarcoFalke> ?
< gmaxwell> wumpus: we'll need to do a lot of release note work for 0.13.1 in any case. It would be stupid to hold it now.
< wumpus> well if it's just a problem with the tests I don't care, can fix that at any time later
< gmaxwell> wumpus: for example, we need to have a section on miner software compatiblity... and I expect that some of the things we'd list won't be done until after rc1.
< MarcoFalke> But we should understand the failure, ideally.
< wumpus> gmaxwell: agreed
< wumpus> just going to tag now (before I go to bed), if there's any problems we'll just do another rc...
< gmaxwell> \O/
< gmaxwell> RC's are free, esp when we don't even put up binaries for them. :P
< wumpus> it will at least get people to actually test
< wumpus> yep
< wumpus> * [new tag] v0.13.1rc1 -> v0.13.1rc1
< achow101> yay!
< gmaxwell> because of the preferential peering, y'all should upgrade your own nodes ASAP, if you're not on a very current master or on 0.13.1rc1
< wumpus> ah yes good point still need to update my own nodes post-f9c23de
< btcdrak> upgraded and building
< achow101> gmaxwell: cobra merged the alert announcement to bitcoin.org. The date for the alert is set to tomorrow. Should that still happen or should it be pushed back a bit?
< gmaxwell> achow101: with 0.13.1rc1 tagged now, I'd like to push it until after the 0.13.1release.
< achow101> I'll make another pr for that. Just set the date to "After 0.13.1 is released" instead of a hard date.
< gmaxwell> sorry for adding delays. :)
< wumpus> well at least I don't think anyone is waiting for that one :)
< wumpus> makes sense to prioritize 0.13.1
< gmaxwell> well I don't want to encourage a wave of updating to 0.13.0 now, since we've seen tolerance effects before (people update slower to a release if its sooner to their last upgrade)
< BlueMatt> ^ while I get why, this is fucked up...if something comes out really quickly after the last its probably a) an easy, small, update, and b) liekly has security hotfixes
< btcdrak> achow101: the alert has actually gone live on the bitcoin.org RSS feeds....
< btcdrak> It's just pinged up in Slack for example...
< achow101> yes, it has
< achow101> that happens when it goes live on bitcoin.org.
< sipa> gmaxwell: yup, already upgraded my node, and seen it appear on my fikteree seed
< sipa> *filtered
< gmaxwell> I'm also seeing a lot of my connection slots eaten up by spynodes. Here is the banlist I've created: http://0bin.net/paste/0Zo6iK2ZFLcryvGp#SQiUU268nld78Z1aMJG4GRwBjXpD4rasRP266adp7-+
< achow101> given that we don't want people to upgrade yet, it would probably be a good idea to take down the alert post for now, yes?
< gmaxwell> achow101: ugh. yea, I didn't want that with a banner up on bitcoin.org
< gmaxwell> achow101: crap.
< gmaxwell> damnit.
< achow101> wasn't expecting cobra to be so active today
< wumpus> gmaxwell: number of connections went from 54 to 14 after applying that banlist :)
< kanzure> oh crud, he merged because of the ACK probably
< achow101> he merged probably because of the multiple previous ACKs and then we didn't tell him not to merge today
< achow101> well it's gone now, so that's good (I guess)
< sipa> who merged what?
< Lauda> Alert key warning on Bitcoin.org
< achow101> cobra merged the post about the prefinal alert on bitcoin.org a few minutes after rc1 was tagged
< sipa> ah
< gmaxwell> hm. /r/bitcoin could set the automoderator to automatically hide posts from non verified submitters for moderator approval that contain the string "Bitcoin.*Core.*releas"
< wumpus> that's kind of smart
< wumpus> avoids the most straightforward attack of someone falsely announcing a release, at least
< BlueMatt> aaaaannnndddd segfault with 0.13.1
< achow101> oh?
< BlueMatt> lol, feelers broke addnode
< BlueMatt> excuse me, not segfault, assert
< sipa> BlueMatt: which is why we have rcs :)
< BlueMatt> net.cpp: assert(nOutbound <= (MAX_OUTBOUND_CONNECTIONS + MAX_FEELER_CONNECTIONS)); is bogus if you use addnode
< wumpus> is that just on 0.13.1 or also on master?
< wumpus> please don't tell me that we have no tests for addnode, and no one tried it since feeler was merged :(
< sipa> i have addnodes
< GitHub67> [bitcoin] TheBlueMatt opened pull request #8944: Remove bogus assert on number of oubound connections. (master...2016-10-bad-assert) https://github.com/bitcoin/bitcoin/pull/8944
< sipa> and i've been running master for a long time
< sipa> i see no assert fail
< BlueMatt> wumpus: I dont know how anyone could have used addnode after their node has been running and not have hit this
< BlueMatt> if they have addnodes in bitcoin.conf they would likely not have
< sipa> oh, you mean addnode rpc?
< BlueMatt> yes
< sipa> yeah, i think you're the only user for that :)
< BlueMatt> or an addnode which was offline and then came up after running
< BlueMatt> i just wanted to addnode other segwit peers :(
< achow101> just tried it on master and I don't see a problem
< achow101> It just returns null
< BlueMatt> achow101: addnode onetry a few times
< BlueMatt> to different nodes
< wumpus> is that assertion new?
< BlueMatt> yes
< BlueMatt> blame on 0.13.1 shows it as from 2611ad79a5d53e2ce1535b342a9b72c2888a6c3f
< BlueMatt> which is feelers
< achow101> oh. I think I see now. It just crashed on me after I did it a few times
< sipa> i don't understand why addnode breaks that assertion
< sipa> i'd say something is broken with addnode then
< BlueMatt> because addnode will result in you having $ADDNODE_COUNT + $ORIGINAL_OUTBOUND_COUNT outbound peers
< BlueMatt> the addnode peers are not marked fInbound (because they are not inbound0
< BlueMatt> )
< wumpus> I think it used to be the case that addnode wouldn't allow you to create more outbound connections than allowed
< sipa> addnode doesn't respect the max outgoing connection count?
< BlueMatt> sipa: no it doesnt
< BlueMatt> why would it
< wumpus> I don't think an assertion is the right way to enforce that, though
< sipa> didn't we fix that?
< BlueMatt> wumpus: im rather confident that is not the case
< wumpus> BlueMatt: so addnode allowes you to create, say, 100 outgoing connections?
< BlueMatt> yes
< wumpus> blegh
< BlueMatt> it would be massively surprising behavior for it not to
< wumpus> that limit exists for a reason
< BlueMatt> what if I want to peer with the 10 other nodes that I run?
< sipa> ThreadOpenAddedConnections uses semOutbound
< sipa> ah, no
< sipa> it does, but doesn't check the result
< sipa> i remember
< wumpus> BlueMatt: yes with that reasoning it makes some sense
< wumpus> though I don't htink anyone but you was understanding this implication
< BlueMatt> addnode does, however, result in your node making fewer other outbound connections, which i think is (mostly) reasonable
< BlueMatt> though it might be nice to lower-bound that (to, say, 2 or 3)
< BlueMatt> because you might addnode yourself into a sybil
< BlueMatt> where you only connect outbound to yourself
< sipa> or always treat the outgoing connections as using a connection slot, unless the peer knows you specifically (whitelist/bip150/...)
< BlueMatt> hey, my node found a segwit peer of its own volition
< BlueMatt> well, unless that person addnode'd me
< sipa> addnode=eu.ng.bitcoinrelaynetwork.org
< sipa> addnode=nns4r54x3lfbrkq5.onion
< sipa> addnode=t3x2266jvxpwwwzq.onion
< sipa> addnode=
< sipa> are you any of those?
< BlueMatt> dig +short public-seed.bluematt.me
< BlueMatt>
< BlueMatt> no
< Lightsword> is there any way to do “bitcoin-cli getblocktemplate” with segwit active?
< sipa> Lightsword: you need to pass some extra parameter to indicate the miner supports segwit
< Lightsword> sipa, how do I do that with bitcoin-cli?
< sipa> $ ./bitcoin-cli -testnet getblocktemplate '{"rules":["segwit"]}'
< wumpus> seems that's not documented in the help for the request
< wumpus> just 'capabilities' and 'mode'; 'rules' is only shown as a reply field
< sipa> indeed
< Lightsword> would it make sense to just have bitcoin-cli pass the segwit rules by default?
< Lightsword> so that scripts don’t get broken
< Lightsword> since nobody is actually going to mine using bitcoin-cli
< sipa> Lightsword: it's intended to break things
< sipa> as clients need to explicitly make changes to support segwit
< Lightsword> intended to break bitcoin-cli? yes I know it breaks clients intentionally
< btcdrak> wumpus: I see your asserts in the gitian.sigs repo but not signatures.
< sipa> well it should equally break those scripts, right? even if they're not used for mining directly, if they're not modified, some things may silently break when segwit activates
< sipa> but we should update the help output
< wumpus> btcdrak: eh yes, added
< Lightsword> sipa, I assume most would just use it for checking if a transaction is going to be mined next block
< BlueMatt> I complained about this months ago
< BlueMatt> well, a month ago
< wumpus> connected to four witness nodes already
< BlueMatt> dig +short x9.dnsseed.bluematt.me | wc -l
< BlueMatt> 7
< GitHub170> [bitcoin] Michagogo opened pull request #8947: Add historical release notes for v0.13.0 (0.13...0.13) https://github.com/bitcoin/bitcoin/pull/8947
< michagogo> Er, wait a sec
< michagogo> master's historical release notes for 0.13.0 don't match release-notes.md in the v0.13.0 tag
< michagogo> -- #8072 `1b87e5b` Travis: 'make check' in parallel and verbose (theuni)
< michagogo> +- #8072 `1b87e5b` Travis: 'make check' in parallel and verbose (MarcoFalke)
< BlueMatt> heh
< wumpus> that happens, some people update the release notes on master
< wumpus> it's too late to update them on the tag so they update the historical release notes, I also find that curious, but meh
< BlueMatt> clearly MarcoFalke and cfields_ are in a commit-count feud
< cfields_> eh?
< btcdrak> ha
< gmaxwell> Lightsword: there is some risk that some genius is mining using system('bitcoin-cli getblocktemplate').
< gmaxwell> I don't know how great that risk is... but one thing I've learned is to not underestimate the liklyhood of someone doing something crazy, so long as it works.
< cfields_> gmaxwell: agreed. That sounds like exactly something someone might do as a quick hack, then forgets to clean up and it ends up in production
< wumpus> also passing arguments automatically from -cli is going to confuse people
< MarcoFalke> michagogo: The diff should be inversed :P
< Lightsword> gmaxwell, that sounds very unlikely since most pools are based off of open source software and none does that
< sipa> Lightsword: how about we add an RPC to just list what txids would be mined?
< wumpus> the bitcoin-cli API has been kept as close to the RPC API as used by other languages as possible, the only difference is the 'parse this as string or not' bit
< sipa> BlueMatt: complained about what?
< gmaxwell> Lightsword: most hashpower has previously been doing things that no open source software does...
< cfields_> Lightsword: i haven't had a single pool willing to let me poke at their production code...
< Lightsword> sipa, that would be better since full transactions aren’t needed most of the time when using cli
< BlueMatt> sipa: lack of getblocktemplate documentation in rpc help
< wumpus> BlueMatt: you should have created an issue like I just did
< BlueMatt> this is true
< gmaxwell> I'd love an RPC that would let me ask for a block of an arbritary weight limit. ... and also only returns the ids, and some extra fields like the total amount of fees.
< Lightsword> cfields_, kano.is is essentially the open source stock ckpool, mine is a minor patchset(most of my changes are webif related)
< Lightsword> cfields_, btc.com should be open source
< Lightsword> gmaxwell, btc.com pool software there is a public example of a how the stratum based validationless mining software works
< sipa> wumpus, MarcoFalke: ha, 3 identical issues simultabeously
< MarcoFalke> heh
< Lightsword> btw the btc.com pool software is based off of bitcoin core(an old version 0.8.something)
< wumpus> lol
< sipa> Lightsword: wah
< BlueMatt> whyyyyy
< Lightsword> very heavially modified of course
< achow101_> I wonder how that will react to an alert..
< gmaxwell> achow101_: 0.8 didn't do anything with the alerts except display them and relay them.
< Lightsword> that part was all stripped out
< Lightsword> I think it’s mostly just the serialization stuff that was kept
< sipa> ah, ok
< Lightsword> by based off of I mean, took lots of code from 0.8 and built a real pool around it
< michagogo> MarcoFalke: is this better?
< michagogo> (fixed it myself, then went to the PR page and saw something about you requesting changes... what does that mean?)
< michagogo> Oh, this is that upgraded review thing GH launched a while back
< michagogo> I forgot about that, haven't seen it in action yet
< michagogo> Looks like I broke it with my --amend :-/
< * MarcoFalke> Your review was dismissed successfully.
< michagogo> Can someone remind me: was there a process for trivial PRs?
< michagogo> Some other branch/fork or something?
< michagogo> (I feel like there was, but I don't remember where/what)
< wumpus> there was in the past, but there is no longer
< sipa> gmaxwell: sounds useful
< gmaxwell> why is my 0.13.1rc checkout claiming to be Bitcoin version v0.13.0.0-e1169b0 ? did we not bump the version?
< BlueMatt> yes
< gmaxwell> I wonder if we need to add a 'witnessconnections" to getnetworkinfo?
< gmaxwell> it's going to be a pita to support people who are witness partitioned when right not checking for it requires inspecting all of the getpeerinfo output.
< michagogo> wumpus: so just a regular PR?
< wumpus> gmaxwell: if you do, at least add a connection # per service bit, instead of special-casing witness
< wumpus> michagogo: sure
< wumpus> yes, we forgot to bump the version
< gmaxwell> wumpus: okay, though witness is special due to preferential connection and block fetching restrictions.
< gmaxwell> With segwit active, a node with witness connection 0 is really no less partitioned from the network than one with connections 0.
< wumpus> yes, many more may be special in the future
< gmaxwell> True.
< wumpus> it will look like a bad design decision in the future to special-case anything now, no matter how important it looks, trust me
< gmaxwell> uh hm. so another peer that I updated, shows Bitcoin version v0.13.1rc1
< gmaxwell> s/peer/node/
< gmaxwell> now I am mystifie.d
< wumpus> just a map of {version_bit: count} histogram would work, you could leave out those that are 0
< gmaxwell> alternatively letting getpeerinfo take a mask like the dnsseeds would also work.
< wumpus> yes
< GitHub131> [bitcoin] Michagogo opened pull request #8948: [TRIVIAL] reorder Windows gitian build order to match Linux (master...master) https://github.com/bitcoin/bitcoin/pull/8948
< GitHub81> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/a5cef7b0777f13ac83312759ebf576c9d773599f
< GitHub81> bitcoin/0.13 a5cef7b Wladimir J. van der Laan: Bump version to 0.13.1
< wumpus> gmaxwell: if it reports v0.13.1rc1 it must hav gotten the tag version from git, there is no other way it can know it is an rc
< wumpus> (or that it is 0.13.1 without ^)
< gmaxwell> yea, it must have gotten it from git.
< michagogo> (Release notes are still in flux, right? I see there are references to it being 0.13.x...)
< wumpus> michagogo: release notes can be updated until -final
< wumpus> michagogo: (or, according to some people, even after that as 'historical release notes' in master...)
< michagogo> Should I assume the .x in the header will be fixed as part of a cleanup before final tag? Or should I PR that myself?
< wumpus> probably better to not assume anything and just do it yourself
< wumpus> although you should check harding 's pull, he may have already changed some things
< michagogo> Ah, yep
< michagogo> He got it
< michagogo> Good call
< gmaxwell> Found another tidbit for SW deployment guide: do not addnode= or connect= yourself to only non-witness peers...
< BlueMatt> oh, yea, that'd be bad
< GitHub152> [bitcoin] laanwj pushed 4 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/a5cef7b0777f...c418c0550db3
< GitHub47> [bitcoin] laanwj closed pull request #8943: Release notes: add info about segwit and null dummy soft forks (0.13...notable-change-segwit) https://github.com/bitcoin/bitcoin/pull/8943
< GitHub152> bitcoin/0.13 5f9c7b0 David A. Harding: Release notes: add info about segwit and null dummy soft forks...
< GitHub152> bitcoin/0.13 2de93f0 David A. Harding: Relase notes: correct segwit activation point
< GitHub152> bitcoin/0.13 bf86073 David A. Harding: Release notes: correct segwit signalling period start conditions...
< wumpus> would it make sense to add a alert condition when only connected to non-witness peers?
< BlueMatt> yes
< BlueMatt> though this is default for most nodes until the network upgrades
< BlueMatt> so that would suck :/
< wumpus> I guess it should only trigger when it actually becomes a concern, e.g. segwit about to activate
< wumpus> not right after installing 0.13.1
< BlueMatt> yea, i mean gate it on locked-in state
< wumpus> though I wonder if it'll still be a common problem at that point
< wumpus> if people haven't upgraded to 0.13.1+ en masse by then there's another problem
< BlueMatt> i would not be surprised if we see increasing sybil attacks over the coming month(s)
< gmaxwell> right now its very easy to end up in this state. I'm going to open a PR to improve it some for discussion.
< gmaxwell> (just waiting for tests to run before opening it)
< michagogo> achow101: Interesting. I have LXC set up and it seems to work for me
< michagogo> In what way does it fail for you?
< GitHub89> [bitcoin] gmaxwell opened 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
< tulip> the v0.13.1rc1 tag doesn't have the subver updated, but the 0.13 branch does; confused me for a second.