< GitHub180>
[bitcoin] pooleja opened pull request #8935: Documentation: Building on Windows with WSL (master...windows_build_docs) https://github.com/bitcoin/bitcoin/pull/8935
< 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)
< 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 ^^
< 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?
< 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
< 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
< 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
< sipa>
so NETWORK, NETWORK|BLOOM, NETWORK|WITNESS, NETWORK|BLOOM|WITNESS.
< 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
< 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 :)
< 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
< 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
< 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
< 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
< 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?
< 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
< 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
< 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
< 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.