18:59:48 <wumpus> #startmeeting
18:59:48 <lightningbot> Meeting started Thu Sep 22 18:59:48 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:48 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:54 <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
18:59:55 <CodeShark> Here
18:59:58 <jonasschnelli> here
19:00:04 <btcdrak> jl2012 ping
19:00:11 <murch> hello
19:00:15 <sipa> pyng
19:00:17 <kanzure> hi.
19:00:21 <sdaftuar> hi
19:00:22 <wumpus> jl2012 probably won't be here this meeting
19:00:22 <paveljanik> peng
19:00:53 <michagogo> May show up in a bit - at dinner with my grandmother atm
19:00:54 <btcdrak> 01110000 01101001 01101110 01100111
19:01:06 <gmaxwell> our meeting is at an unfriendly time for our contributors in asia/au/nz/etc. Alas.
19:01:10 <wumpus> <jl2012> I may not join the meeting today but I suggest not to do https://github.com/bitcoin/bitcoin/pull/8654 in 0.13.1
19:01:10 <wumpus> <jl2012> It seems the risks is too much comparing with the benefit
19:01:52 <wumpus> yes what ever time you pick it's always unfriendly to someone
19:01:54 <btcdrak> I was discussing this with him yesterday. I also think it should be dropped.
19:02:38 <btcdrak> wumpus: we should find a time that is unfriendly to everyone :)
19:02:56 <wumpus> #topic Drop reuse sighash computations across evaluation  #8654 from 0.13.1?
19:02:58 <gmaxwell> wumpus: wasn't a complaint, just reminding people of it. :) (and we can all make an effort to stand in for people who can't make it)
19:03:26 <wumpus> gmaxwell: something else we could do is have e.g. alternating times every week
19:03:48 <sipa> yes, i'm in favor of dropping it. i believed the advantages were larger first
19:03:49 <wumpus> but given that people already have a hard time being there intime for a meeting with a fixed time... :-)
19:04:03 <sipa> but it seems we'll need more changes anyway than we can tolerate for 0.13.1
19:04:07 <gmaxwell> So re: that PR. We can do it later. We've survived thus far without it.
19:04:13 <btcdrak> yes.
19:04:16 <wumpus> ok
19:04:38 <wumpus> removing 0.13.1 milestone from it
19:04:55 <petertodd> how much worse is the maximum O(n^2) time for segwit? my understanding is that w/o segwit in theory even dozens of minutes are possible anyway
19:05:19 <sipa> petertodd: the same
19:05:43 <petertodd> sipa: but can't you get more checksig ops w/ segwit?
19:05:45 <sipa> petertodd: as segwit inputs only hash the entire transaction at most once
19:05:57 <sipa> see bip143
19:06:02 <gmaxwell> petertodd: IIRC. this change is primarily fixing the non-segwit case. The plain hashcache in segwit already optimizes segwit so its basically solved under segwit.
19:06:23 <jtimon> hi
19:06:57 <sipa> petertodd: the worst case for a pure segwit-inputs transaction is around 6 ms per block
19:07:04 <gmaxwell> so the non-segwit cases are the worst case, but we have determined that exploiting some additional caching oppturnities radically reduces that worst case when coupled with a few inconsequential additional limits.
19:07:06 <petertodd> gmaxwell: ah right, because of how we changed SIGHASH_SINGLE behavior
19:07:22 <sipa> petertodd: all sighashing is changed in segwit
19:07:24 <petertodd> alright, I'm ACK to remove that for 0.13.1
19:07:33 <wumpus> great
19:07:39 <petertodd> sipa: well sure, but SIGHASH_SINGLE is changed in substance significantly :)
19:08:09 <gmaxwell> petertodd: right but the reason segwit doesn't have the n^2 blowup anymore is the general change so that the hashing work across inputs can be shared.
19:08:14 <sipa> petertodd: hmm? they're all changed in a very similar way, with the whole-transaction parts precomputed rather than inlined
19:09:15 <achow101> are #8634 and #8499 and #8526 ready for merge?
19:09:34 <wumpus> that's a new topic proposal achow101?
19:09:58 <achow101> just a question
19:10:00 <gmaxwell> related topic at least.
19:10:28 <btcdrak> well they were part of last week's homework
19:10:34 <wumpus> Add policy: null signature for failed CHECK(MULTI)SIG https://github.com/bitcoin/bitcoin/pull/8634
19:10:54 <wumpus> Check bad witness and implement several policy limits for segwit scripts https://github.com/bitcoin/bitcoin/pull/8499
19:11:19 <wumpus> Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH https://github.com/bitcoin/bitcoin/pull/8526
19:11:43 <CodeShark> The first and last commits for 8634 should be squashed together, have only done limited testing, but the code changes look good
19:12:20 <CodeShark> Still reviewing 8499
19:13:28 <wumpus> ok, anyone else with opinion about those pulls?
19:14:47 <gmaxwell> 8634 needs a squash. LGTM.
19:14:56 <sipa> 8499 is a blocker for 0.13.1 for sure
19:15:02 <achow101> wasn't it decided that 8393 was ready, or just about ready
19:15:04 <sdaftuar> fyi i'm just starting my review of 8499 now
19:15:06 <wumpus> looks like #8634 has quite a lot of (u)tACKs
19:15:30 <sdaftuar> (but don't let me hold thigns up!)
19:16:19 <wumpus> #action merge #8634 after squashing
19:16:35 <wumpus> 8499 is still very much in progress
19:17:18 <instagibbs> 8393 isn't that hard to review but only a couple people have given acks
19:17:44 <gmaxwell> reminder on milestone 22, https://github.com/bitcoin/bitcoin/milestone/22  (and if there are 0.13 things in that, which aren't tagged, make sure they get tagged)
19:19:56 <sipa> i'll address the latest nits in 8393
19:20:00 <wumpus> so anything between those that is ready for merge?
19:20:43 <btcdrak> We need a few more acks on 8526 but it looks harmless enough as is.
19:21:23 <wumpus> there seems to be disagreement on the RPC behavior change in Fix issue with conflicted mempool tx in listsinceblock https://github.com/bitcoin/bitcoin/pull/8757
19:21:35 <wumpus> this probably means it should be untagged for 0.13.1
19:21:38 <btcdrak> sipa: I think there are a couple of niggles on the BIP also https://github.com/bitcoin/bips/pull/423
19:21:47 <jonasschnelli> Yes. No need for 0.13.1
19:21:57 <sipa> btcdrak: yes, i'm aware
19:22:17 <wumpus> jonasschnelli: right, if we do that it should be something documented in the release notes of a major release
19:22:23 <jonasschnelli> ack
19:22:41 <jonasschnelli> People probably built apps on the "strange" listsinceblock behavior.
19:22:48 <wumpus> exactly
19:23:12 <jonasschnelli> remved the 0.13.1 ms from 8757
19:23:17 <wumpus> okay that leaves four to go
19:23:27 <BlueMatt> wumpus: wait, we're unmarking compact blocks for 0.13.1?
19:23:32 <BlueMatt> (you just did)
19:23:32 <gmaxwell> re the listsince blocks The complaint is that conflicts are always shown and the proposed change made them never shown?
19:23:34 <btcdrak> regarding segwitcb, roasbeef's scripts are running spamming testnet. If there are any miners pointing hash at testnet, can they set "-blockmaxweight=4000000", leaving off any other related params so we get more bigger blocks.
19:23:43 <wumpus> BlueMatt: uh
19:23:47 <gmaxwell> BlueMatt: wat?
19:23:54 <BlueMatt> @laanwj laanwj removed this from the 0.13.1 milestone a minute ago
19:23:55 <instagibbs> er did someone remove the segwit cb?
19:23:56 <wumpus> that was a mistake
19:23:57 <BlueMatt> I assume that was accidental
19:24:00 <wumpus> please readd
19:24:05 <BlueMatt> #8393
19:24:15 <gmaxwell> unclick
19:24:27 <BlueMatt> ok, so 5 to go
19:24:32 <jonasschnelli> readded
19:24:47 <instagibbs> 4 PRs, one related issue
19:24:52 <sipa> you take one down, pass it around, 5 PR to g
19:25:19 * BlueMatt is not sure how to feel about #8526...it'll surely end up merged onto master before segwit activates...agree its nice to have things "clean from the start", but do we define clean as policy in 0.13.1 or policy on master/0.14?
19:25:20 <Chris_Stewart_5> exponential PR blow up
19:25:22 <btcdrak> There is also this nice project https://github.com/bitcoin/bitcoin/projects/5
19:25:26 <gmaxwell> if you just want the percentage to go up, feel free to add tags to closed prs that got backported but were never tagged 0.13.1... There are many. :P
19:26:13 <wumpus> yes good point btcdrak PSA: I've started using the new feature of github projects for tracking a few longer-running projects: https://github.com/bitcoin/bitcoin/projects
19:26:14 <BlueMatt> same with 8634
19:26:55 <paveljanik> wumpus, nice!
19:27:08 <BlueMatt> or, really, what about ignoring #8634 and #8526 and going to solicit feedback for segwit dates after the other ones are in, and then if they make it in before we get date consensus, then they go in, otherwise no
19:27:13 <gmaxwell> minor meta aside, is there any facility for backing up and retaining all this new github stuff?
19:27:33 <BlueMatt> gmaxwell: havent looked, but the github api has historically been very, very complete
19:27:39 <BlueMatt> so i ass-u-me so?
19:27:42 <wumpus> gmaxwell: that's iwilcox's department (but he's not here)
19:28:17 <wumpus> but yes I guess it's available on the API if you know where to look, or it will become available, as BlueMatt says
19:28:21 <gmaxwell> BlueMatt: 8526 when it goes SF could plausably conficate coins, so it's more important to have it non-standard from the getgo.
19:28:53 <gmaxwell> and 8634 is done but for a squash as far as I can tell.
19:29:24 <wumpus> already created an action for #8634, we're repeating ourselves
19:29:26 <BlueMatt> gmaxwell: I'm not sold on it needing to be in anything but master before release, but, ok, in any case, i'd propose we start looking for date-consensus after #8279 and #8499 are in
19:29:26 <btcdrak> gmaxwell: the github API supports all this new stuff https://developer.github.com/v3/repos/projects/
19:29:45 <BlueMatt> (ie lets start looking for date consensus like...soon)
19:29:55 <achow101> like.. now?
19:30:01 <sipa> no, not now
19:30:05 <instagibbs> achow101: no, after critical updates are merged
19:30:11 <sipa> first know when we can possibly have a release
19:30:14 <BlueMatt> like...in a few days after the non-critical ones are merged
19:30:14 <btcdrak> BlueMatt: well we need #8393 merged too before we can be sure to set dates
19:30:37 <BlueMatt> btcdrak: sure, fine, #8393, #8279, and #8499, then dates?
19:30:50 <btcdrak> ack
19:30:55 <sdaftuar> i believe 8279 is sufficiently resolved for 0.13.1
19:31:11 <wumpus> let's try to finish those pulls this week then we can talk about the release next meeting
19:31:11 <gmaxwell> BlueMatt: do we know what the status of btcd's SW support is?
19:31:22 <BlueMatt> gmaxwell: thats part of soliciting consensus on dates :p
19:31:24 <btcdrak> ping roasbeef
19:31:30 <BlueMatt> (ie reaching out to non-bitcoin core people)
19:31:46 <gmaxwell> BlueMatt: well I've been doing that for a while. that doesn't have any binding on pending PRs.
19:31:46 <instagibbs> wumpus: ack
19:32:02 <wumpus> sdaftuar: ok, so let's remove that issue from the 0.13.1 milestone, but not close it
19:32:12 <sdaftuar> wumpus: sounds good to me
19:32:28 <sipa> wumpus: sounds good
19:32:55 <gmaxwell> btcd is the only active alt implementation that I'm aware of that didn't respond to my "when do you think you'll work on this" with a "only after it's locked in on the network".
19:34:59 <gmaxwell> BlueMatt: in any case, out of meeting lets try to work on a list of required actions for the activation.
19:35:13 <wumpus> makes sense to reach out to them then
19:35:21 <btcdrak> well in terms of wallet code and supporting libraries, there are many which are SW ready, or have it almost ready to go.
19:35:33 <gmaxwell> yes.
19:35:34 <petertodd> python-bitcoinlib has a fairly good pull-req for segwit
19:35:45 <wumpus> awesome
19:36:08 <gmaxwell> mining software was in a sad state last time I checked, but I know things have improved a lot.
19:37:03 <gmaxwell> in any case, many things to discuss there that don't need everyone. :)
19:37:07 <roasbeef> will be starting to finalize my segwit stuff for btcd starting tomorrow, have been busy with lightning stuff and getting btcd up-to-date with past recent soft-forks (CSV, etc)
19:37:32 <petertodd> roasbeef: +1
19:37:34 <roasbeef> primarily need to improve the test coverage, and make changes like cost->weight and the nulldummy stuff
19:37:36 <gmaxwell> roasbeef: fantastic.
19:38:00 <cfields> i keep meaning to return to patching miners but getting distracted. Feel free to ponk me if there's some mining software that actually gets used that needs to be updated.
19:39:15 <achow101> armory is.. getting there. We're aiming for the release after the next to have full segwit support
19:39:44 <petertodd> achow101: thanks!
19:39:47 <gmaxwell> achow101: thats a good timeframe, really no one should be using it the instant it activates, except for testing.
19:40:03 <btcdrak> oh I didnt know you work on Armory achow101 +1
19:40:22 <CodeShark> my stuff is almost 100% segwit ready, just need merkle proofs for witnesses in filtered blocks or some better SPV solution
19:40:47 <petertodd> gmaxwell: I'll probably switch opentimestamps to use segwit, but that's a maximum loss of something like $20 :)
19:40:57 <gmaxwell> It's just good to hear that more things are almost read, as it's another angle of testing.
19:41:25 <Chris_St1> CodeShark: What BIP is that related to?
19:41:50 <CodeShark> We don't have a BIP yet, I don't think
19:41:52 <sipa> Chris_St1: that will need a new bip
19:42:26 <sipa> it's trivial (just combine bip37 with bip141 wtxids)
19:42:32 <Chris_St1> ok, gotcha.
19:42:34 <gmaxwell> Chris_St1: he wants something like the filtered block messages that provide witnesses too. (the opposite of what most SPV wallets do, but codeshark extracts participant data from witnesses)
19:42:49 <sipa> but it needs to be fleshed out... and i don't know how keen people are on extending bip37 further
19:43:12 <CodeShark> I'd prefer a replacement to bip37, but that's more involved
19:43:14 <Chris_St1> BIP37 is definitely a monster in terms of implementation... or atleast it was for me
19:43:14 <gmaxwell> We could probably do better.
19:43:55 <sipa> at least we could propose to drop some of the auto-inserting that causes false positive rate blowup
19:43:56 <petertodd> note that it's reasonable to ask for a full block even if you are a lite-client in many cases
19:44:28 <BlueMatt> CodeShark: uhhhhhhhhh, that sounds like a blocker
19:44:32 <gmaxwell> petertodd: Satoshi's vision.
19:44:34 <btcdrak> petertodd: such as?
19:44:49 <jtimon> I guess he means as a way to get more privacy?
19:44:53 <sipa> BlueMatt: how so?
19:45:05 <BlueMatt> it seems to me it is impossible to use the bloom-filtered connection stuff in segwit....I mean we can decide to not support it because its bad, but we need to actively decide that
19:45:06 <petertodd> no, I just mean that the data increase is relatively low
19:45:07 <gmaxwell> BlueMatt: wut? hell no. I am aware of no other SPV client than codeshark's that does _anything_ with the witness data right now.
19:45:07 <jtimon> no tevealing which txs you care about? just thinking out loud...
19:45:22 <sipa> BlueMatt: spv wallets shouldn't care about the witness data
19:45:55 <sipa> hell, it's an advantage that their bandwidth will drop
19:45:57 <petertodd> sipa: indeed, they can't verify that the witness is valid
19:46:09 <gmaxwell> BlueMatt: it works fine, you just don't get witnesses, which is an intentional and desirable outcome thats actually listed on the segwit advantage sheets. For the most part they can't do anything with the data.
19:46:09 <CodeShark> wallets that don't tell you who signed a multisig are incomplete ;)
19:46:34 <gmaxwell> There should be some option for those who want it, sure. Though they can also fetch the whole block, so its not a big deal even there.
19:46:37 <petertodd> CodeShark: well, that's an example where you can request a full block - not many wallets need to actually know that
19:46:53 <petertodd> CodeShark: as an example, I don't think GreenAddress will tell you who actually signed txs in a GA wallet
19:47:12 <CodeShark> it's critical for enterprise applications
19:47:20 <CodeShark> Accountability is important
19:47:22 <petertodd> CodeShark: enterprise can afford some extra bandwidth I'm sure :)
19:47:29 <achow101> I think we're getting OT
19:47:32 <petertodd> CodeShark: this isn't a blocker is all I'm saying
19:47:45 <CodeShark> we can revisit this after 0.13.1
19:47:48 <gmaxwell> It's also not news or an accident.
19:48:00 <wumpus> no one is considering it is a blocker except for BlueMatt
19:48:03 <petertodd> CodeShark: ack
19:48:28 <BlueMatt> gmaxwell: sure, I'm saying that you cant use segwit as an spv client
19:48:36 <sipa> BlueMatt: of course you can?
19:48:38 <gmaxwell> BlueMatt: thats not true.
19:49:00 <petertodd> BlueMatt: note how with segwit, your txids aren't malleable, therefore you can add the txids of outputs in your wallet to your bloom filter and be sure you'll know if they get spent
19:49:05 <BlueMatt> gmaxwell: however, in cases like a scripthash, you previously are able to see things that were to your public, or partially to your pubkey
19:49:08 <BlueMatt> which you might want to
19:49:21 <BlueMatt> petertodd: you already do that, the malleability doesnt help
19:49:31 <Chris_St1> May be a stupid question, but are we refering to 'blocker' in the context of blocking 0.13.1 or downloading a full block?
19:49:36 * BlueMatt isnt recalling exactly what the use-case was for scriptSig matching, but you now can no longer do that
19:49:38 <petertodd> BlueMatt: true, once confirmed
19:49:52 <wumpus> Chris_St1: I think it would be really ill-advices to add a blocker for 0.13.1
19:49:52 <jtimon> Chris_St1: the former
19:49:53 <petertodd> BlueMatt: I take back that comment
19:50:21 <petertodd> anyway, we can agree that anything fixing this is non-consensus, right? therefore it's not relevant for 0.13.1
19:50:24 <gmaxwell> BlueMatt: I carefully went through the code base of some three different wallets to confirm there were no complications there.  Of course, it also does nothing to _existing_ software.
19:50:48 <BlueMatt> gmaxwell: i take back my comment, i no longer recall why we needed to match scriptSigs...maybe we didnt need to
19:51:03 <sipa> i think there was no reason for that, indeed
19:51:07 <BlueMatt> but it is the case that you lose this property of matching pubkeys which were used
19:51:10 <sipa> and if there is, we can still add it back
19:51:17 <BlueMatt> sipa: well, you might want it, but not a ton
19:51:19 <gmaxwell> which all works fine. And so even where there are things that want that data (which appear to be almost none of them), they can be accomidated later. The most common case (of not needing it) is already accomidated. And all existing things are unchanged as well.
19:51:21 <petertodd> I can imagine silly embedded consensus applications where it'd be useful... but supporting that is definitely not a priority
19:51:23 <wumpus> at this point we should be careful to only let critical problems block 0.13.1, not everything that would be nice for some applications
19:51:36 <Chris_St1> BlueMatt: Matching scriptSig constants in BIP37 right?
19:52:00 <BlueMatt> wumpus: well, if it were the case that you couldnt match properly in segwit it would be bad, but it seems that you're fine
19:52:01 <wumpus> BIP37 can be extended, sure
19:52:17 <BlueMatt> Chris_St1: bip37 only ever matches constants
19:52:17 <wumpus> but that's not yet another reason to move forward the release
19:52:28 <BlueMatt> agreed
19:52:33 <achow101> topic proposal: alert system retirement
19:52:43 <gmaxwell> AFAICT the only 'utility' of that matching was degrading privacy by tainting the filter with FPs on extrainous data. :P
19:52:44 <instagibbs> 8 minutes left
19:52:47 <BlueMatt> we might fix this by throwing out bip37 and doing something not-batshit-insane, but thats an aside from the meeting
19:53:00 <BlueMatt> gmaxwell: yup
19:53:00 <gmaxwell> BlueMatt: yup.
19:53:12 <CodeShark> I want a good fairly secure quick sync solution. BIP37 sucks :p
19:53:25 <gmaxwell> second on achow101's topic.
19:53:28 <petertodd> CodeShark: sure, fiber-to-the-home :)
19:53:33 <CodeShark> But we'll do that after 0.13.1
19:53:33 <wumpus> #topic  alert system retirement
19:53:34 <petertodd> gmaxwell: ack
19:54:11 <gmaxwell> Okay I sent out an email on this. Mostly well recieved (at least in public). I went and bludgenoned alt implementations into removing the alert key and only got mildly bloodied in the process.
19:54:39 <petertodd> gmaxwell: sounds like it's time to set dates
19:54:41 <gmaxwell> My view on the next steps:
19:54:54 <gmaxwell> (1) Create a bitcoincore.org or bitcoin.org announcement message.
19:55:16 <gmaxwell> (2) send a penulitmate alert with more polite text than the COMPROMISED message that directs people to it.
19:55:26 <gmaxwell> (3) much later, send final alert.
19:55:46 <wumpus> I'd say we send the final alert with the 0.14 release
19:55:57 <gmaxwell> (4) hardcode nodes to send the final alert to peers to overcome the lack of propagation. (just using the one or two lines of code needed to send a static message, not pulling back any alert code)
19:56:09 <wumpus> then include code in there to send it to old peers that connect, as gmaxwell says
19:56:28 <BlueMatt> gmaxwell: ACK
19:56:35 <BlueMatt> wumpus: ACK final alert with 0.14
19:56:48 <jtimon> ack
19:56:49 <achow101> ack
19:56:51 <petertodd> gmaxwell: and release the privkey for the alert key w/ the final alert?
19:56:54 <btcdrak> ack
19:57:03 <gmaxwell> I think we can do 1/2 in the next week. I'm not aware of any reason to delay, and there are propagation advantages to doing it earlier rather than later.
19:57:08 <sipa> i'd release the key later even
19:57:09 <petertodd> gmaxwell: ack
19:57:16 <instagibbs> make sure to sweep the funds people have sent to the key :P
19:57:26 <petertodd> instagibbs: ha
19:57:28 <roasbeef> btcd still has the code in place to parse the alert messages, but we simply drop-it-like-its-hot once recv of the message without any further processing (and have since early last year)
19:57:36 <BlueMatt> sipa: ack
19:57:52 <sipa> there may be alternate codebases that use the key who want to do something similar to (3) and (4)
19:58:10 <sipa> oh, wait
19:58:16 <sipa> they need the key for that
19:58:24 <BlueMatt> 2 min
19:58:31 <instagibbs> any pressing topics
19:58:36 <wumpus> well after the final alert is sent, the key is only historical curiosity
19:58:42 <gmaxwell> okay, I'll send a message to the list.
19:58:47 <luke-jr> can the final alert match all clients?
19:59:05 <wumpus> luke-jr: you mean the pre-final alert, and yes
19:59:07 <petertodd> wumpus: yeah, once that final alert is sent, I doubt releasing the key will do any harm
19:59:14 <gmaxwell> It cann't not match all clients.
19:59:30 <wumpus> gmaxwell: I think he means the penultimate alert
19:59:44 <wumpus> obviously the final alert matches all clients, at least those that still parse alerts
20:00:00 <gmaxwell> petertodd: if I can parition your network I can make your client show "Your bitcoin is outdated and vulnerable. You MUST download an update to continue. http://bitcoinscam.eu/"
20:00:22 <wumpus> gmaxwell: wasn't that the point in adding it to the client?
20:00:29 <gmaxwell> I was thinking of limiting the applicability of the penultimate alert to users of Bitcoin Core, open to suggestions.
20:00:40 <petertodd> gmaxwell: sure, but that'll have been after months of alert - I'm not worried there
20:00:51 <wumpus> it applies to everyone using the key, not just users of bitcoin core
20:00:53 <gmaxwell> in any case, can continue after, we should wrap the meeting. :)
20:00:58 <petertodd> gmaxwell: I'd be inclined to provide it to everyone - it's a warning that everyone will soon have a final alert
20:00:59 <instagibbs> ding ding
20:01:01 <btcdrak> ding ding ding
20:01:02 <wumpus> yes it's time
20:01:03 <wumpus> #endmeeting