1 2016-09-22 03:44:50 <achow101> any dates planned for the alert key retirement yet?
2 2016-09-22 03:50:44 <wumpus> dunno, the mailing list thread kind of started with a lot offanfare, then fizzled out. Maybe remind gmaxwell of it :)
3 2016-09-22 03:51:28 <wumpus> I did propose a timeframe https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013110.html but no one replied to it
4 2016-09-22 03:53:58 <moa> wumpus: that seems reasonable
5 2016-09-22 03:55:54 <achow101> maybe an "official" announcement with pgp sigs posted to bitcoin.org would help
6 2016-09-22 03:56:23 <achow101> and emailing all wallet developers in case they aren't following the mailing list
7 2016-09-22 03:56:27 <wumpus> it would help to have a timeframe before doing that
8 2016-09-22 03:56:42 <achow101> assuming your timeframe
9 2016-09-22 03:56:50 <achow101> (which sounds good to me)
10 2016-09-22 03:56:52 <wumpus> I do think that wsa the intention, but there are so many things going on, probably it was just forgotten about
11 2016-09-22 03:57:02 <wumpus> I did at least
12 2016-09-22 03:58:09 <achow101> so did I, I only remembered because I saw one of the mails while going through my spam
13 2016-09-22 04:03:55 <Diablo-D3> whats going on?
14 2016-09-22 05:57:36 <gmaxwell> wumpus: I was busy trying to push other implementations to agree that they'd remove it. the last I was chasing finally did.
15 2016-09-22 05:58:09 <wumpus> at some point we should just set a timeframe
16 2016-09-22 05:58:42 <wumpus> it's 'our' key, they should just be aware that it is going to happen, I don't think they necessarily need to agree
17 2016-09-22 05:59:33 <gmaxwell> Moot issue now.
18 2016-09-22 05:59:35 <wumpus> if they keep it all that will happen isthat they'll get a generic message
19 2016-09-22 05:59:46 <gmaxwell> if they hadn't I eventually wouldn't have waited.
20 2016-09-22 05:59:57 <gmaxwell> but I thought it prudent to try.
21 2016-09-22 06:00:34 <wumpus> it's madness that you have to go through trouble to convince projects to remove a key you control
22 2016-09-22 06:02:08 <gmaxwell> The world is full of crazy things. 'grant me the serenity to accept the things I can not change, courage to change the things I can, and wisdom to know the difference.' :)
23 2016-09-22 06:02:14 <wumpus> 'no we don't want to remove your backdoor!'
24 2016-09-22 06:03:26 <wumpus> okay let's agree on a timeframe then
25 2016-09-22 06:04:40 <gmaxwell> Did you see my vague suggestion of hardcoding the final alert to be given to old peers, in new ones?
26 2016-09-22 06:05:14 <gmaxwell> it would just be a char blob, and a if protocolversion<x send_blob. or the like.
27 2016-09-22 06:05:16 <wumpus> isn't sending it once enough?
28 2016-09-22 06:05:25 <wumpus> I would prefer not to have any alert related code in new versions
29 2016-09-22 06:05:42 <wumpus> we could just agree to keep broadcasting it
30 2016-09-22 06:05:47 <gmaxwell> no so the issue is that as no-alert-support nodes spread the alert will not propagate anymore. And the longer we wait until sending it, the worst that effect gets.
31 2016-09-22 06:05:49 <wumpus> no need to have it in any client
32 2016-09-22 06:06:31 <gmaxwell> but if there are few to no listening nodes with alert support, old clients won't get it and they'll be exposed to getting garbage alerts once the key is out.
33 2016-09-22 06:07:07 <gmaxwell> it wouldn't really be alert specific code, it would be basically a oneliner "throw these bytes blindly at older peers on connect"
34 2016-09-22 06:07:15 <wumpus> and protocol version is something different than bitcoin core client version
35 2016-09-22 06:07:38 <wumpus> yes ok... not against that, though as said I'd prefer not to
36 2016-09-22 06:07:48 <wumpus> I just want this gone from bitcoin
37 2016-09-22 06:10:43 <wumpus> nah otoh it's a one-time overhead on connect, and if it is only two lines of code, and we can plan in advance when it can be removed again, it's fine
38 2016-09-22 06:10:58 <gmaxwell> Another question is, do we want to send a prefinal alert first, which can say something less alarming than KEY COMPROMISED or whatever the final one says.
39 2016-09-22 06:11:32 <gmaxwell> yes, one time overhead on connect, I suppose it could also be for inbound peers only. and I'd say we'd leave it in for a year or something like that.
40 2016-09-22 06:11:39 <wumpus> it indeed can just contain the serialized data, no reason to bring back the key or CAlert calss
41 2016-09-22 06:11:41 <wumpus> class*
42 2016-09-22 06:12:50 <wumpus> yes
43 2016-09-22 06:13:02 <wumpus> I think we should make a page on bitcoin.org then point there
44 2016-09-22 06:13:13 <wumpus> this needs an 'official' announcement anyway
45 2016-09-22 06:13:41 <wumpus> could just as well send out an alert to point at that
46 2016-09-22 06:14:04 <wumpus> then when the day comes send the final alert
47 2016-09-22 06:14:28 <gmaxwell> yea, so in tomorrows meeting I will propose: in one week we'll have up a page, and a prefinal alert that points to it. Then some time after that a final alert, and code that final alert as a one/two liner in new versions of bitcoin core for a year or two.
48 2016-09-22 06:14:41 <wumpus> sounds good to me
49 2016-09-22 06:15:25 <gmaxwell> Basically give people a weeks notice on the prefinal just in case someone has automation that will shut things down on an alert which they might want to bypass in advance.
50 2016-09-22 06:15:58 <wumpus> yeah
51 2016-09-22 06:16:30 <wumpus> first create the page then spread it through other channels, e.g. the announce list
52 2016-09-22 20:49:59 <jcarter9753> I have a question about the tests around script validation. Specifically the test 'P2PK with too little R padding but no DERSIG'. How does the R value affect the signature of the Transaction?
53 2016-09-22 20:51:50 <jcarter9753> The script signature is embedded into the sigScript of the Tx being spent. Assuming I can parse the DER signature correctly (I can) it should verify - does anyone know where I should begin investigation?
54 2016-09-22 20:58:05 <gmaxwell> "Assuming I can parse the DER signature correctly (I can)"... you might be the first person on earth then.
55 2016-09-22 20:58:14 <gmaxwell> pretty much nothing implements DER correctly.
56 2016-09-22 20:58:33 <jcarter9753> :) I mean I verify most usually transactions correctly
57 2016-09-22 20:58:39 <gmaxwell> "too little R padding" means that the signature is not valid DER, though virtually every 'der parser' ever written will accept it.
58 2016-09-22 20:59:27 <jcarter9753> Understood - I will look further into BIP0066 to understand more. Thank you.
59 2016-09-22 20:59:37 <gmaxwell> We have a special DER parser which is designed to accept and parse according to the most common incorrect DER implementations, which is sufficient for the historic bitcin blockchain.
60 2016-09-22 21:00:10 <gmaxwell> https://github.com/bitcoin-core/secp256k1/blob/master/contrib/lax_der_parsing.h
61 2016-09-22 21:00:24 <jcarter9753> Super thank you.
62 2016-09-22 21:09:52 <jcarter9753> gmaxwell I assume secp256k1_ecdsa_verify is the function that actually does the verification for these tests?
63 2016-09-22 21:18:38 <jcarter9753> I moved to BIP66 tests to verify I had that correct, in the script_valid.json file there is BIP66 example 1, without DERSIG - so it expects to pass here, but in the BIP0066 page there is an example 1: S1' P1 CHECKSIG fails (changed)
64 2016-09-22 21:18:55 <jcarter9753> Does this mean script_valid.json is wrong? Ah.. Perhaps I have wrong version...
65 2016-09-22 21:21:00 <jcarter9753> I do have old version, they are now in one script_tests.json file. However that test 'BIP66 example 1, without DERSIG' is still there expecting OK, but https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki says it should fail, unless they are unrelated.
66 2016-09-22 21:22:28 <jcarter9753> Sorry I see, it does not specify in the flags the script should fail that because of the DER BIP0066 rules.
67 2016-09-22 21:24:02 <jcarter9753> Maybe too much Bitcoin for one try, I'll try with a fresh head.