1 2016-08-17 08:00:54 <luke-jr> jonasschnelli: Does *any* other software use URI schemes strictly as an API between software?
 2 2016-08-17 08:01:20 <jonasschnelli> luke-jr: most iOS/Android app does.
 3 2016-08-17 08:01:36 <jonasschnelli> http://wiki.akosma.com/IPhone_URL_Schemes
 4 2016-08-17 08:01:40 <luke-jr> weird.
 5 2016-08-17 08:01:56 <luke-jr> I don't think there's even a standard for doing it on GNU/Linux
 6 2016-08-17 08:02:10 <jonasschnelli> Facebook: fb://event/(fbid)/members/attending
 7 2016-08-17 08:02:20 <luke-jr> that's not IPC…
 8 2016-08-17 08:03:13 <luke-jr> that's actually using URIs correctly, as a way to indicate resources :p
 9 2016-08-17 08:03:14 <jonasschnelli> luke-jr Not sure if it counts as IPC.. probably not. Its just a way how application in a sandboxed enviromnent can interact with each other.
10 2016-08-17 08:03:28 <luke-jr> jonasschnelli: but there are applications that do bi-directional communication with URIs?
11 2016-08-17 08:03:50 <jonasschnelli> I'm pretty sure, but I don't have an example/use-case
12 2016-08-17 08:04:42 <jonasschnelli> It's basically: wallet) "I have a unsigned transaction, who wants to sign it over bitcoinsign://"?
13 2016-08-17 08:04:44 <jonasschnelli> , signing device) "thanks, signed,... I have a signed transaction, who wants it bitcoinsignresponse://
14 2016-08-17 08:05:12 <jonasschnelli> (the BIP makes "bitcoinsignresponse://" configurable over the first URI scheme.
15 2016-08-17 08:05:25 <jonasschnelli> Which seems to be a good design IMO
16 2016-08-17 08:05:36 <jonasschnelli> the problems are more when to timeout, etc.
17 2016-08-17 08:05:58 <jonasschnelli> key-advantages: app do not know each other, there is no configuration required on app level
18 2016-08-17 08:13:50 <jonasschnelli> luke-jr: URL Handling on Posix should work fine. Its supported since Qt4.2 (http://doc.qt.io/qt-4.8/qdesktopservices.html) which means it must be available in most (all) Linux WMs.
19 2016-08-17 08:14:22 <luke-jr> jonasschnelli: yeah, was just reading about xdg-open ☺
20 2016-08-17 10:03:40 <luke-jr> jl2012: the DROP isn't needed except for cleanstack. which IMO is an argument against cleanstack :p
21 2016-08-17 10:06:23 <jl2012> luke-jr: no, in your example, the CHECKSIG will treat the <num> as the signature
22 2016-08-17 10:06:41 <luke-jr> oh, right you are
23 2016-08-17 11:11:51 <gribble> I have not seen schildbach.
24 2016-08-17 11:11:51 <ThomasV> !seen schildbach
25 2016-08-17 11:11:54 <ThomasV> !seen aschildbach
26 2016-08-17 11:11:55 <gribble> aschildbach was last seen in #bitcoin-dev 22 weeks, 6 days, 14 hours, 35 minutes, and 0 seconds ago: <aschildbach> ok
27 2016-08-17 13:18:58 <wallet42> aschildbach was last seen in #room77 on bitcoin halving day
28 2016-08-17 14:19:04 <venzen> i'm implementing jonasschnelli's Encrypted channels and peer Auth in python.
29 2016-08-17 14:19:16 <jonasschnelli> venzen: +1
30 2016-08-17 14:19:29 <venzen> what is meant by "standard ECC keypair" (for Auth)?
31 2016-08-17 14:19:37 <venzen> hi jonasschnelli
32 2016-08-17 14:19:49 <jonasschnelli> a normal ECC private key and the according public key.
33 2016-08-17 14:20:09 <venzen> is that ECDSA, perhaps?
34 2016-08-17 14:20:15 <jonasschnelli> ECC (elliptic curve crypto.)
35 2016-08-17 14:20:53 <venzen> ok, i'm having some problems finding a library (python) that will yield a 64bit key
36 2016-08-17 14:21:10 <jonasschnelli> The private key is 32bit
37 2016-08-17 14:21:47 <jonasschnelli> But the public key should be 65bytes... I guess.
38 2016-08-17 14:21:58 <jonasschnelli> ah.. wait. 33 bytes.
39 2016-08-17 14:22:12 <jonasschnelli> venzen: where does it say 64bit?
40 2016-08-17 14:22:17 <venzen> aha, and we want to put the receiver's pubkey in AuthChallenge
41 2016-08-17 14:22:21 <venzen> let me have a look
42 2016-08-17 14:23:05 <venzen> he, it doesn't say that :) 64bits is the signature
43 2016-08-17 14:23:17 <jonasschnelli> yes. Signatures are 64bits
44 2016-08-17 14:23:21 <jonasschnelli> We don't use DER there.
45 2016-08-17 14:23:38 <jonasschnelli> Just plain compact normalized ECDSA signatures
46 2016-08-17 14:23:51 <venzen> also, i'm saying bits, i mean bytes
47 2016-08-17 14:23:57 <jonasschnelli> Though, if your library spits out DER, you can convert it to a compact signature of 64 bytes
48 2016-08-17 14:25:48 <venzen> ok, let me give that a try with ECDSA
49 2016-08-17 14:25:54 <venzen> thank you
50 2016-08-17 14:29:34 <venzen> jonasschnelli: i assume we use the secp256k1 curve and the usual "Bitcoin parameters" for field, basepoint, etc?
51 2016-08-17 14:29:47 <jonasschnelli> Yes. Sure.
52 2016-08-17 14:30:41 <jonasschnelli> The only crypto differences are ChaCha20Poly1305@openssl for channel encryption, ECDH and HKDF
53 2016-08-17 14:31:34 <jonasschnelli> HKDF is currently available with a python module... ChaCha20Poly1305@openssl, not sure. Be aware of that we use the @openssl AEAD an not the "standard" ChaCha20Poly1305
54 2016-08-17 14:32:10 <jonasschnelli> If you use libsecp256k1 (I guess there is a python module) ECDH should be available... but I'm sure openssl also supports ECDH
55 2016-08-17 14:32:22 <venzen> great, as soon as i get the Auth keypairs generated to spec then I'll set up Encryption channels and the Encryption message type... some python class challenges there but i'm sure it can be done
56 2016-08-17 14:33:24 <venzen> ok, i see your message about openssl AEAD - the BIP you wrote also mentions the ChaCha20 lib
57 2016-08-17 14:39:04 <jonasschnelli> venzen: you mix up openssl with openssh
58 2016-08-17 14:39:21 <jonasschnelli> Bip151 uses openssh ChaCha20Poly1305 AEAD
59 2016-08-17 15:48:32 <venzen> no i didn't - i'm following your BIP - its great :)
60 2016-08-17 15:49:20 <venzen> also I have a lib for ephemeral ECDH in Python. Will let you know when i get to the Encrypted channel implementation.
61 2016-08-17 16:53:54 <venzen> jonasschnelli: do you have any preference for the hash algo?
62 2016-08-17 16:54:07 <venzen> for example in AuthChallenge:
63 2016-08-17 16:54:12 <venzen> hash(encryption-session-ID || challenge_type || remote-peers-expected-identity-public-key)
64 2016-08-17 16:55:26 <venzen> SHA or openssl('DSA'), perhaps?