< sdaftuar>
does it need to be approved by someone with write privs maybe?
< achow101>
I don't know. I can't approve it since I wrote it. I'll try with the other account.
< achow101>
oh yeah. That was totally it.
< achow101>
Interesting that the status checks are still pending.
< rebroad>
is the -dropmessagestest code still needed in main.cpp? It's not even mentioned as a command line option in init.cpp
< rebroad>
oh... sorry, it is
< rebroad>
ok, so I am wondering... develoeprs seem to complain when I either raise too many pull requests or raise a pull request with too many changes.. so it seems the complain is about the amount of development I am doing, so my thnking is that this is implying I should be working on other thnigs, code review perhaps? In what areas is it that the complaint might be indication that I am not contributing enough?
< achow101>
I've mostly figured out how the review thing works, and it could benefit us.
< achow101>
So comments through the review thing are just general comments on the whole thing, kind of useless. You can still do line notes though and that is good
< achow101>
approving cannot be done commit by commit but rather by the full diff at the time of review.
< achow101>
requesting changes seems like it will revoke a previous approval
< dcousens>
achow101: you can't edit comments interestingly when posting an 'approval'
< achow101>
And lastly branches can be setup with protections to require an approve from a committer, pass status checks (travis), and prevent administrators from merging regardless
< achow101>
also the submitter can't approve or request changes in his own PR (duh)
< GitHub54>
[bitcoin] rebroad opened pull request #8734: Send NOTFOUND when we don't have the block data. (master...NotfoundIfPruned) https://github.com/bitcoin/bitcoin/pull/8734
< achow101>
dcousens: right. so any comments done with the review thing can't be edited
< rebroad>
achow101, all sounds good!
< achow101>
I think the best thing about this is that it can be set so that a PR submitted by a committer must have another committer review it before it can be merged
< achow101>
just in case someone gets hacked
< dcousens>
achow101: eh, they already have multiple processes in place... trusting github further isn't really necessary
< dcousens>
I honestly don't see this being any better than the current ACK' system
< achow101>
anyone can approve, but only certain people's approvals (the committers) will allow a PR to be merged when the branch is protected
< achow101>
If you look at the one I linked earlier, you can see the message there about an "approved review" which apparantly must come from someone with write access
< jonasschnelli>
I guess thats also a new Githup thing: you can later change the base branch of a pull request
< cfields_>
wumpus: lots of work remains. But, mingw depends build fully, and bitcoin build breaks with the same threading problems that have been reported, so it's enough to help with testing/debugging.
< cfields_>
will continue with it tomorrow.
< jonasschnelli>
nice cfields_ !
< cfields_>
jonasschnelli: heh, not really. It's at the "it's a bloodbath, but it builds" stage of development :)
< GitHub156>
[bitcoin] jonasschnelli opened pull request #8735: [Wallet] add option for a custom extended master privat key (xpriv) (master...2016/09/hd_set_seed) https://github.com/bitcoin/bitcoin/pull/8735
< dcousens>
wumpus: oh, I wanted to mention. And all other things aside. A small RPC cache works wonders for reducing some of the performance issues with high loads (10-20 mb)
< GitHub86>
[bitcoin] paveljanik opened pull request #8737: Trivial: UndoReadFromDisk works on undo files (rev), not on block files. (master...20160915_Undo_error_message_fix) https://github.com/bitcoin/bitcoin/pull/8737
< kanzure>
i think the concern was that 0.11 was not marked as EOL, not that it wasn't considered EOL.
< MarcoFalke>
Jup, note that I already changed maintenance end to 2016-08-23
< wumpus>
yes the bitcoin.org page needs to be updated
< wumpus>
+Core
< achow101>
If 0.11 is EOL, then what about 0.10?
< sipa>
ah, so 0.11 is not EOL but maintenance end
< sipa>
EOL means not even security critical backports
< sipa>
according to that website
< gmaxwell>
achow101: it was unmaintained as of january or so.
< achow101>
gmaxwell: but it is still marked as receiving critical updates on bitcoincore.org
< jonasschnelli>
According to bitcoincore.org 0.10 has EOL in 2017
< sipa>
but 0.10 should be EOL at 2016-08-23
< morcos>
it seems to me that ending security critical backports depends not just on how old the release is but on how many people are still using it
< gmaxwell>
what morcos says.
< wumpus>
and how difficult it is to backport/test
< morcos>
ha ha, of course!
< wumpus>
I mean if it's just updating a dependency library like upnp...
< gmaxwell>
the reality is that it has nothing to do with dates. We're not actively seeking to maintain these versions but will do what it takes to protect the ecosystem.
< sipa>
sure, but the reason for having a clearly stated policy is so that people can make informed decisions about what to run
< MarcoFalke>
^
< wumpus>
I think this will always be a discussion people can't really agree on
< MarcoFalke>
We should communicate the EOL in advance
< luke-jr>
frankly 0.12 seems like EOL before 0.14 at this rate
< petertodd>
gmaxwell: setting expectations also can help protect the ecosystem
< gmaxwell>
We also continue to see no feedback from parties that would prefer to use a 0.old.next over a 0.new.hottness. :)
< * jonasschnelli>
still count 569 0.10.x peers with status "good" on his seeder
< morcos>
agreed with all, but i'm saying we should be supplementing our discussion with #'s of nodes running 0.10, 0.11
< sipa>
i wish we had more insight in users' needs... that there would be requests of the form "wait! no! i can't upgrade to 0.12 yet for reason X, but we really need updated for now"
< wumpus>
in practice it's indeed not about dates, but if someone cares about using/maintainging it
< BlueMatt>
am I the only one who wasnt aware of that page? I mean I dont think a strict N-monghts schedule really works, so we'd need to all be thinking about it/aware of it, at least, to make it reasonable
< wumpus>
it seems to be 0 people
< gmaxwell>
Which supports the view that effort spent supporting older versions is of negative value.
< luke-jr>
wumpus: maintaining it is not practical without testing/usage
< petertodd>
morcos: so many nodes are run because users "want to contribute" - I wouldn't read too much into that number. Equally, a lot of nodes are likely spy-nodes...
< wumpus>
luke-jr: right it's a chicken egg problem
< sipa>
wumpus: that's a fair characterization of reality, but perhaps that page should reflect that
< kanzure>
BlueMatt: i think it's something like "people should be following the mailing lists and announcement mailing lists and the webpage, although apparently the webpage is out of sync with reality for the moment"
< wumpus>
yes, updating the webpage to reflect reality would make sense
< BlueMatt>
kanzure: hmm? people shouldnt have to follow the ml to find out if their node is EOL...we should have some kind of information for users, but devs have to be aware that it exists for it to be accurate :p
< gmaxwell>
If we were being completely pragmatic we would probably say that we only support the very latest thing put out at all.-- this is all that I can tell people are upgrading to. But I think that is a bad principle and the fact that the only thing people upgrade to is the latest thing is an aspect of industry immaturity which will hopefully go away.
< luke-jr>
wumpus: I maintained old versions back to 0.4 for years with no indication of real usage or feedback - the first few got some testing, but after a while it never made it past RC
< petertodd>
fwiw I've never gotten any feedback from python-bitcoinlib users complaining about non-backwards-compatible changes
< luke-jr>
IMO we *should* have longer support, but it just doesn't seem feasible with softforks
< wumpus>
the point of creating that webpage was to have an easier available place where release maintenance status was available, but yes if it runs out of date with reality then at some point it's only confusing
< * BlueMatt>
wishes there was an "ask the community" button for this kind of thing....
< petertodd>
BlueMatt: too bad we got rid of the alert system... /ducks
< kanzure>
wumpus: probably a good fix would be to have a checklist for releases, and add EOL webpage updates to that checklist.
< wumpus>
and it should reflect how things are, not how we think ideally they should be
< sipa>
we could make node software automatically show a warning X months after being released...
< luke-jr>
kanzure: we do have release-process.md
< kanzure>
well is it in there?
< luke-jr>
sipa: +1
< wumpus>
kanzure: there's one in the release process, but there is already so much stuff there. I don't thin kthe assumption should be that the same person does all that
< kanzure>
"EOL" not found in that doc, nor variations of it.
< petertodd>
sipa: signal does that actually - they forgot the timer expired once and scared a bunch of people
< kanzure>
wumpus: sure, sure, perhaps it's multiple people. but a checklist can still be helpful regardless of number of people that use it.
< BlueMatt>
petertodd: is that automated? heh, yea, maybe
< achow101>
has anyone actually tried asking the community? like posting on reddit, bitcointalk, etc.
< luke-jr>
petertodd: if we stagnate for 12 months, something else is wrong
< wumpus>
I think we should first document how things are clearly on the site, and only then worry about maybe changing it
< btcdrak>
oh sorry I am late
< jonasschnelli>
The problem is probably not what the community want, its more what the team is capable of delivering
< gmaxwell>
achow101: we've posted asking for feedback on older versions many times in the past, and also called for testing on old support backups.
< wumpus>
exactly jonasschnelli
< jonasschnelli>
Its an OSS, if people want longer EOL, they should contribute
< gmaxwell>
I've also gone 1:1 to several companies. Mostly we've recieved complete silence. scanning the network (and watching inbounds) also shows that adoption of point releases after a new major is out is basically non-existant.
< wumpus>
as I've said before I have nothing against maintaining old releases if someone really commits to that
< sipa>
that's fair... we're only so many people, and review for backports is a significant burden
< luke-jr>
I'm happy to go back to maintaining stable versions longer if people will actually use it (and can't upgrade)
< gmaxwell>
jonasschnelli: or at least speak up.
< wumpus>
but I've never seen much interest, so reality is, it doesn't
< kanzure>
i don't know what to think about re: automatic warnings after timelapse. as long a there's some good reason to think it' dissimilar from automatic updates, i suppose..
< jonasschnelli>
gmaxwell: right.
< wumpus>
kanzure: I don't know what to think about it either
< kanzure>
didn't mean to impose on wumpus with the checklist suggestion
< luke-jr>
maybe update EOL page, and mention the lack of usage as the reason, suggesting if people want it, they should get in touch
< jonasschnelli>
Luke-Jr: +1
< BlueMatt>
ok, so lets post something on the ml or so that says "We're gonna stop doing this, but would very much love to hear if anyone actually wants it" and then link to that from reddit/emails/twitter/whatever
< BlueMatt>
yea, that
< gmaxwell>
stop doing what?
< gmaxwell>
I am really confused.
< BlueMatt>
stop supporting backports
< BlueMatt>
beyond like one or two versions, maybe
< wumpus>
kanzure: I really don't like time-locks in programs. Though this would just be a warning I guess... but it could be intimidating
< gmaxwell>
We have a stated policy, we maintain one major version behind.
< gmaxwell>
BlueMatt: we already did that, like, a yea ago.
< jonasschnelli>
stop doing sound negative... something more like "...we are concentrating ressources on X"
< gmaxwell>
year*
< sipa>
BlueMatt: "beyond one version" is exactly what the page says
< BlueMatt>
s/one or two versions/one or so point releases/
< luke-jr>
wumpus: might be good to make the time limit fuzzy, so not everyone gets hit at the same time
< btcdrak>
Seems there's a lot of discussion here which was _already)_ covered in previous meetings and is detailed in the Lifecycle document https://bitcoincore.org/en/lifecycle/ tldr maintenance and EOL are two different things.
< luke-jr>
perhaps 1 year from when it was installed?
< gmaxwell>
what btcdrak says
< BlueMatt>
sipa: gmaxwell to be fair, the website doesnt say that
< wumpus>
well then add it to the website!
< wumpus>
everyone can submit pulls there you know
< btcdrak>
I suggest people re-read the Lifecycle page after the meeting :)
< wumpus>
we can spend an hour discussing what should be added to the website, or just add it
< jonasschnelli>
#action update Lifecycle page on bitcoincore.org
< Chris_Stewart_5>
^
< kanzure>
luke-jr: cool idea. fuzzy random noise time-delay notifications. (hopefully nobody proposes "intentionally low performance over time until someone thinks to get a new version")
< BlueMatt>
ok, next topic
< gmaxwell>
BlueMatt: read the "Maintance period" section on the site, I think it's completely clear.
< wumpus>
I'll mail it around on the mailing lists if there are no issues with it
< BlueMatt>
yea, looks good now
< CodeShark>
+1
< wumpus>
ok great!
< kanzure>
jonasschnelli: you have a typo in your form ("your are")
< morcos>
wumpus: my only thought is 0.13.1 release is a bit of a heavy lift, and depending on when that happens, it may seem like 0.14.0 is coming up quite quickly... but i don't feel strongly about it
< jonasschnelli>
kanzure: ill give you edit right. :)
< wumpus>
morcos: it's already a month later compared to 0.12 was this year
< MarcoFalke>
No worries. I am sure the will be last-minute blockers for 0.14.0
< wumpus>
morcos: postponsing major releases for minor releases makes very little sense I think
< wumpus>
0.14 will have lots of new features, 0.13.1 will not
< morcos>
wumpus: yeah i was only pointing out that 0.13.1 is not minor in a lot of ways.. but if others are fine with it, i don't object
< wumpus>
morcos: I agree with that
< luke-jr>
? 0.13.1 should only be fixes + softfork
< btcdrak>
yes.
< wumpus>
luke-jr: it is
< morcos>
anyway, seems not its a widely shared concern, so lets stick with the schedule
< gmaxwell>
having a short gap between releases would be a good problem to have. :)
< BlueMatt>
yup
< jonasschnelli>
#topic 0.13.1 release
< wumpus>
it's a minor release strictly, just a lot of code changes, so you can jokingly call it 'major'
< btcdrak>
I guess the big blocker is #8393 compact blocks.
< jonasschnelli>
untagged
< wumpus>
#decision dropped #8635 for 0.13.1
< luke-jr>
jonasschnelli: if that's strictly an optimisation, it should wait for 0.14
< jonasschnelli>
sipa: why did you want to see 8654 in 0.13.1?
< wumpus>
luke-jr: depends on whether it's an optimisation or an 'optimisation' (e.g. - DoS fix)
< gmaxwell>
btcdrak: thats ... working fine for me, but we probably need to do a bit more organized testing. sdaftuar was updating some tests for it.
< luke-jr>
wumpus: right, hence "if" ☺
< btcdrak>
gmaxwell: well it's fine to merge afaik, but there was some discussion about the BIP text which is blocking it afaik
< btcdrak>
I think #8636 is ok to merge.
< wumpus>
that has a lot of ACKs
< michagogo>
Hi
< wumpus>
#action merge #8636
< wumpus>
michagogo: hey!
< gmaxwell>
Can someone make a list of all PR's merged for master that are not in 0.13 so we can check to make sure we haven't missed any that need backport?
< morcos>
oh i was going to vote against 8636 as well
< * BlueMatt>
isnt a huge fan of 8636 in 0.13.1
< morcos>
i haven't reviewed it and don't necessarily have any concrete concerns
< wumpus>
gmaxwell: all that still need backport should have the 'needs backport' tag
< BlueMatt>
its just more stuff for segwit that could easily fit in another softfork
< michagogo>
Sorry, not too around -- was with my grandmother (my grandfather passed away on Sunday), and now shopping with the family.
< gmaxwell>
assuming they got tagged.
< BlueMatt>
better to push any more complication further
< luke-jr>
gmaxwell: I did, but I may have missed some. (minor ones I didn't comment on, and have a local list I can backport myself)
< wumpus>
(including what is already merged)
< morcos>
but just seems it possibly hasn't been thought about enough to know there isn't a hidden risk like jl2012 found low-s
< gmaxwell>
it's an istandardness rule
< * michagogo>
wonders if zu will become the new 11
< btcdrak>
morcos: it's already a standard rule
< gmaxwell>
oh you're talkign about nulldummy sorry.
< BlueMatt>
gmaxwell: yea, sorry, nulldummy...I'm more ok with adding standard rules for things we want to softfork out soon
< wumpus>
michagogo: hah, luckily the C parser doesn't accept it as number
< wumpus>
otherwise some magic constants should be defined as zuzuzuzu, especially on windows
< jl2012>
#8499 actually somehow depends on nulldummy softfork
< luke-jr>
#define zu 11
< luke-jr>
fixed C parser
< jl2012>
it still works, just can't protect CHECKMULTISIG
< morcos>
re: nulldummy, ok so if we think its got sufficient technical review, and we also think its technical enough it doesn't need more community discussion (for instance never appears in chain?) then ok wiht me
< sipa>
i think the risk for nulldummy is very low
< petertodd>
nulldummy is very, very simple
< jl2012>
since without a softfork, we can't DoS ban a peer sending us a violating transaction
< sipa>
jl2012: well we can't generally do that anyway
< sipa>
an attacker node can always pretend to be an old version
< jl2012>
for segwit tx we could
< gmaxwell>
we could for Sw things however, as it doesn't have transisiton issue.
< cfields_>
crap, gtg. wumpus: not a meeting topic, but I noticed that the libevent unit tests fail for the zu case. We should consider running unit tests for deps somewhere.
< cfields_>
bbl
< jl2012>
8499 is for segwit only
< luke-jr>
sipa: if it's bundled with segwit I think we can?
< gmaxwell>
But we could ban without the softfork in such a case too.
< sipa>
luke-jr: an old node can always pretend to be pre-segwit
< gmaxwell>
There is no need to link those behaviors though we have previously.
< luke-jr>
but then it won't have witness data at all
< wumpus>
cfields_: running libevent tests would make some sense, yes, although we'd first need a travis run on ubuntu 16.04
< sipa>
luke-jr: so? it's an attacker node. it just won't send segwit txn
< cfields_>
wumpus: yes, I'm still making my way through that problem.
< sipa>
it can make up all its transactions
< gmaxwell>
in any case, I only think that its urgent to at least have these behaviors non-standard.
< cfields_>
wumpus: indeed, it was just a general thought
< luke-jr>
sipa: afaik the proposal is to ban Nulldummy-violating sw txns
< sipa>
luke-jr: to ban nulldummy-violation sw *peers*
< sipa>
so an attacker will just not be an sw peer
< wumpus>
cfields_: at least that one's easy to fix, the -stack-protector-all problem is more worrying
< wumpus>
cfields_: anyhw better to speak of this outside the meeting some time
< jl2012>
sipa: I think it's to ban segwit-nulldummy-violation peers
< sipa>
jl2012: ok
< morcos>
too many conversations
< sipa>
same thing
< sipa>
morcos: agree
< luke-jr>
well, whether it's useful or not is another matter - maybe it isn't
< sipa>
what is the topic?
< jonasschnelli>
0.13.1
< morcos>
in summary i'm happy to let you guys decide what should go into 0.13.1 and what shouldn't, as i have been a bit out of the loop
< jonasschnelli>
(nulldummy)
< wumpus>
0.13.1 still
< morcos>
however i just want to raise the concern that maybe we're putting a lot of things in very quickly at the end
< gmaxwell>
welcome back
< morcos>
and that should cause us to be nervous
< sipa>
i think nulldummy is very low risk, but also not very useful
< gmaxwell>
:)
< morcos>
when already the segwit activation is going to be a lot to pay attention to
< BlueMatt>
0.13.1 - various things...I think morcos, sdaftuar and I generally arent a fan of all these policy and various things coming in last minute before 0.13.1, but, I think we've all been out of the loop so maybe they have more review than we think
< sipa>
it should happen at some point, and perhaps doing it together with segwit is easier
< btcdrak>
morcos: in all fairness, these PRs have been worked on over quite a long time.. they arent out of the blue.
< BlueMatt>
maybe nulldummy is ok, but still, so many things happening at the same time is a review burden and complicates things further
< btcdrak>
you need to sync up on the conversations / background of them
< sipa>
BlueMatt: yes, i don't like that either, but i think we just discovered many things to improve
< BlueMatt>
when segwit is already complicated
< BlueMatt>
sipa: ok, lets do it in a later sf
< BlueMatt>
?
< BlueMatt>
i mean sf-able things, that is
< gmaxwell>
it's unclear whats being discussed now.
< BlueMatt>
and maybe if policy isnt as restrictive as we'd like in 0.13.1, thats ok
< sipa>
nulldummy sf
< btcdrak>
the only sf is nulldummy, the rest is just policy standardness.
< jonasschnelli>
Didn't we had this discussion already and where mostly for including nulldummy sf together with SW in 0.13.1?
< gmaxwell>
bluematt is talking about many, if the discussion is limited to nulldummy whatever.
< gmaxwell>
But the policy changes are more important.
< wumpus>
yes I think trying to stash a lot of changes into 0.13.1 has caused some delays already, at the least we shouldn't be adding anything else now and focus on what is there getting in
< gmaxwell>
jonasschnelli: yes, we did.
< luke-jr>
IMO nulldummy isn't worth all the time we're spending disucssing it now.
< Chris_Stewart_5>
Do we have a tentative release date for 0.13.1 or feature freeze?
< gmaxwell>
wumpus: that isn't what happened. We had specific necessary to fix issues related to SW specific moderate risk denial of service attacks, and the path to fixing them spun off a number of sub isues along the way.
< wumpus>
if you discover any other nice improvements they can wait until next version, unless it's critical to deployment of segwit
< jonasschnelli>
cfields_: no
< jonasschnelli>
Chris_Stewart_5: no
< gmaxwell>
It's a little frustrating to loop rediscussing the same things over again. Makes the meetings feel like a waste of time, FWIW.
< wumpus>
gmaxwell: agreed
< wumpus>
there are a lot of repeated topics lately
< jonasschnelli>
agree with gmaxwell
< jonasschnelli>
(which is mostly a sign of not made decistions)
< wumpus>
e.g. people that have been out of the loop then bring up something that was discussed a meeting or a few meetings ago
< wumpus>
meetings are not there to bring you up to speed
< btcdrak>
we publish meeting summaries, people should be reading them :-p
< wumpus>
the logs and minutes are available, and summaries are made and published on the site
< gmaxwell>
okay, thats enough probably. :) people get the point.
< wumpus>
and you can always ask about things outside the meeting
< gmaxwell>
(I am glad to not be alone!)
< BlueMatt>
wumpus: IIRC there are folks complaining now who were in favor of it, as there are now 5 related issues that are coming up.....8634, eg, was not previously discussed and is in the same veign
< BlueMatt>
maybe that should be the next topic
< BlueMatt>
otherwise, someone can propose a different topic :)
< wumpus>
BlueMatt: yes, I'm not saying it should be impossible to reconsider things discussed in previous meetings if convinng new reasons come up! just that repeating the same discussions with the same outcomes is not constructive
< gmaxwell>
BlueMatt: thats fine, things can be rediscussed again, but instead of repeating the discussion we should focus on whats changed or whats disagreed with.. a diff rather than a redo.
< btcdrak>
We need some more ACKs on #8634 and #8499 and #8526
< wumpus>
yes
< wumpus>
#action review #8634 and #8499 and #8526
< sipa>
it's not clear what is being discussed. if we're talking about nulldummy sf, i think there is little risk, but little benefit. it was discussed before however, and unless people strongly feel that everything being done is too much, then this is something that can be reconsidered. please don't start reconsidering everything. there are good reasons and they were discussed before
< btcdrak>
then the compact block/BIP thing needs to be finalised so we can merge the compact block pull #8393
< BlueMatt>
sipa: eg, btcdrak just pointed out three prs...two of which i think are optional in 0.13.1
< BlueMatt>
as is nulldummy
< BlueMatt>
now we're in a position where we have a at least 3 prs that are "optional", at least one or two has been previously agreed upon
< wumpus>
nulldummy softwork has been discussed zillions of times in the meeting, everytime the sentiment was slightly in favor of doing it because it has very little risk
< btcdrak>
sipa: it's been well reviewed, and run on testnet for 4 weeks already.
< BlueMatt>
but we want to get this thing out the door without spreading ourselves thin over too much review
< wumpus>
and by now it has lots of testing and review too
< btcdrak>
can we move on?
< sipa>
so let's just stick to it
< wumpus>
so if you want to reconsider it have a very good reason
< wumpus>
not just 'I personally don't like it very much'
< BlueMatt>
btcdrak: "run on testnet for 4 weeks" is the opposite of "good testing"
< gmaxwell>
fwiw, all of my testing lately has been with most of this stack applied.
< btcdrak>
BlueMatt: it's completely trivial, come on.
< wumpus>
topc nulldummy is over now
< btcdrak>
Is there any thing I can do regarding CB, I'm sort of confused about what is holding it up?
< wumpus>
other topic proposals?
< sipa>
segwit cb?
< btcdrak>
yes please
< wumpus>
#topic segwit cb
< gmaxwell>
yes, I'm also unsure what else is required. I have been testing.
< sipa>
gmaxwell: the latest version?
< sdaftuar>
i'm working on testing. i foudn a bunch of problems with the test unfortunately :(
< sipa>
(as of a few days ago)
< BlueMatt>
it was updated a few days ago, afaik only sdaftuar has looked at it since
< sipa>
i did
< morcos>
i like the concept of the latest version, and looked at the code. but unfortunately i have to review CB in the first place before i can review the pull, so thats what i'm doing
< BlueMatt>
and sdaftuar is now rewriting the testers for it, so not much to talk about aside from people should look at it?
< gmaxwell>
sipa: as of a week ago? I could check.
< morcos>
not to say you need to wait for my review of course
< sipa>
gmaxwell: 2 days ago
< BlueMatt>
next topic?
< gmaxwell>
(Fwiw, more segwit traffic on testnet would make live testing of that PR more useful)
< luke-jr>
gmaxwell: where did you guys go btw?
< gmaxwell>
luke-jr: to the photo room.
< btcdrak>
gmaxwell: roasbeef is preparing to produce some load in the next day
< gmaxwell>
btcdrak: okay, I'll try to get things updated to the latest first.
< jonasschnelli>
any other topics?
< sipa>
specifically it would be useful to test connections between 0.13-with-segwit-activation-removed testnet nodes with #8393
< sdaftuar>
sipa: i'm also working on doing that in regtest, fyi
< sipa>
awesome
< btcdrak>
great
< gmaxwell>
sipa: okay, I'll make sure that I run with that too.
< sipa>
thanks
< luke-jr>
would be handy to have some regular segwit spam on testnet in general IMO
< btcdrak>
luke-jr: it's coming, roasbeef is setting something up
< btcdrak>
*silence*
< jonasschnelli>
#endmeeting
< lightningbot>
Meeting ended Thu Sep 15 19:53:41 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< petertodd>
jonasschnelli: a step-by-step example of a case where you could use it (e.g. sipa's key compromise) would be good though
< jonasschnelli>
petertodd: your git sig time-stamping is very clever...
< petertodd>
jonasschnelli: yeah, that's a fun hack! I noticed it was possible awhile back, and made a demo of a PGP-signed git commit with signatures from Isis Lovecruft and myself on one commit :)
< petertodd>
jonasschnelli: unfortunately, github shows those sigs as "unverified", but that's a minor problem
< jonasschnelli>
Yes. The github-verified icon is nice. But does not prove anything. :)
< roasbeef>
re testnet segwit spam: would help if we could get more segwit enabled hashpower on testnet and to get those currently mining to limit by max weight (4mil) instead of stripped size
< petertodd>
jonasschnelli: well, if you trust github...
< roasbeef>
err I mean regular size
< sipa>
jonasschnelli: sure it does. as long as you trust github and the companies hosting their hardware.
< jonasschnelli>
sipa: Yes. And probably trust all your browser plugins. :)
< jonasschnelli>
I guess github.com does not include any third-party CDN-ish CSS/JS files..
< sipa>
yes, and you c library, X server, kernel, cpu, motherboard manufacturer, delivery company, ...
< jonasschnelli>
okay. stop. :)
< btcdrak>
roasbeef: will pass it on
< sipa>
(but admittedly, the browser is the easiest target of all of those)
< luke-jr>
sipa: ping
< sipa>
luke-jr: pung
< phantomcircuit>
jonasschnelli: just the newline?
< GitHub48>
[bitcoin] laanwj opened pull request #8740: net: No longer send local address in addrMe (master...2016_09_addrfrom_version) https://github.com/bitcoin/bitcoin/pull/8740
< gmaxwell>
would it be unreasonable for us to keep a bitcoin-core keyring file that has the pgp keys of all the regulars around here in it?
< BlueMatt>
argh ffs...can we all agree to not use github's fancy new review mode thing? it seems to be breaking github's emails as they are no longer threaded together for a single issue...hopefully they can fix in a day or two but they really broke my bitcoin-email workflow :(
< BlueMatt>
damn github and their not always working perfectly :(