1 2016-11-17 07:27:07 <jonasschnelli> <venzen>	[16:46:20] the identity pubkey specified are ECC (32 byte) - is this a Bitcoin compressed pubkey minus the initial parity byte?
 2 2016-11-17 07:27:22 <jonasschnelli> A compressed pubkey is always 33 bytes.
 3 2016-11-17 07:27:27 <jonasschnelli> Where does it say 32?
 4 2016-11-17 07:28:44 <jonasschnelli> https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki#local-identity-key-management
 5 2016-11-17 07:28:55 <jonasschnelli> It says: "Each peer can configure multiple identity-keys (ECC, 32 bytes)"
 6 2016-11-17 07:29:06 <jonasschnelli> Thats correct. 32bytes key (=private key)
 7 2016-11-17 07:29:42 <jonasschnelli> (pub)Keys are never submitted in BIP150
 8 2016-11-17 07:29:45 <jonasschnelli> Only signatures...
 9 2016-11-17 07:29:55 <jonasschnelli> And signatures are always 64bytes
10 2016-11-17 07:30:00 <jonasschnelli> (non DER compact sigs)
11 2016-11-17 07:30:21 <jonasschnelli> <venzen>	[16:55:21] when I put an ECC 32 pubkey through ripemd160(sha256) and then b58check encode it, I get a much longer hash
12 2016-11-17 07:30:42 <jonasschnelli> You mean an ECC 33 bytes compressed pubkey.
13 2016-11-17 07:31:03 <jonasschnelli> ripemd160(sha256(pubkey)) >must< result in 20 bytes
14 2016-11-17 07:31:42 <jonasschnelli> <venzen>	[17:48:53] BIP150: "The base58check identity byte is 0x0F followed by an identity-address version number (=0xFF01)"
15 2016-11-17 07:32:13 <jonasschnelli> Base58check can have a prefix. Like the 1 and 3 for bitcoin addresses.
16 2016-11-17 07:35:35 <venzen> jonasschnel>| Thats correct. 32bytes key (=private key)
17 2016-11-17 07:35:37 <venzen> jonasschnel>| (pub)Keys are never submitted in BIP150
18 2016-11-17 07:35:49 <venzen> understood
19 2016-11-17 07:36:24 <venzen> < jonasschnel>| Base58check can have a prefix. Like the 1 and 3 for bitcoin addresses.
20 2016-11-17 07:37:09 <venzen> ok, thanks jonasschnelli, i'll get onto my fn() for that
21 2016-11-17 07:41:13 <venzen> jonasschnelli: the ripemd160(sha256(pubkey)) is applied to the *pub*key right? I know understand that we put the full 33 byte pubkey through the ripemd160 function and then b58check encode it
22 2016-11-17 07:42:28 <venzen> jonasschnelli: my 33 byte result is obviously a result of not prepending the base58check identity byte 0x0F
23 2016-11-17 07:43:22 <venzen> jonasschnelli: how is the identity-address version number (=0xFF01) applied?
24 2016-11-17 07:43:26 <jonasschnelli> jonasschnelli: ripemd160(sha256(pubkey)) is a standard function in bitcoin. Expect to find it in every bitcoin python tool
25 2016-11-17 07:43:44 <venzen> ok
26 2016-11-17 07:44:02 <venzen> i'm using the one from pycoin
27 2016-11-17 07:45:05 <venzen> i'll have a look at the C++ key.cpp source and compare to what I'm using in python
28 2016-11-17 07:45:36 <jonasschnelli> venzen: you take a 22byte buffer...
29 2016-11-17 07:45:56 <jonasschnelli> then you apply the 20byte ripemd(sha256(pubkey)) to byte 2-22
30 2016-11-17 07:46:12 <jonasschnelli> in front you set 0xFF01
31 2016-11-17 07:46:38 <jonasschnelli> = 0xFF01<ripemd160(sha256(pubkey))
32 2016-11-17 07:46:51 <jonasschnelli> then you do a btc_base58_encode_check of those 22 bytes
33 2016-11-17 07:47:28 <venzen> and the 0xFF01 is applied, or no?
34 2016-11-17 07:47:37 <venzen> version number
35 2016-11-17 07:48:09 <jonasschnelli> 0xFF = identity-address prefix
36 2016-11-17 07:48:13 <jonasschnelli> 0x01 = version number
37 2016-11-17 07:48:23 <jonasschnelli> 0xFF01 = complete two byte prefix
38 2016-11-17 07:48:26 <venzen> aha!
39 2016-11-17 07:48:31 <jonasschnelli> = 22 byte buffer
40 2016-11-17 07:48:44 <jonasschnelli> 20 byte ripemd160, 2 bytes prefix
41 2016-11-17 07:48:44 <venzen> thanks, jonasschnelli , i get it
42 2016-11-17 07:50:10 <venzen> jonasschnelli: can you point me to a working implementation of chacha20poly1305@openssh ? I need to wrap that for python
43 2016-11-17 07:57:01 <venzen> I'll probably compile from the C sources available at OpenGrok, because I'm not finding ready-rolled implementations
44 2016-11-17 08:08:20 <jonasschnelli> venzen: I just wrote an chacha20poly1305@openssh implementation in C:
45 2016-11-17 08:08:21 <jonasschnelli> https://github.com/jonasschnelli/chacha20poly1305
46 2016-11-17 08:08:33 <jonasschnelli> It's relatively untested.
47 2016-11-17 08:08:40 <jonasschnelli> And only a few test vectors
48 2016-11-17 08:08:46 <jonasschnelli> Most of the code is extracted from openssh
49 2016-11-17 08:09:19 <jonasschnelli> Also... bcoin has a bip150/151 implementation in JS: https://github.com/bcoin-org/bcoin/blob/6215954ffbb727d2c7af359c0c0b7d4dd93162b2/lib/net/bip150.js
50 2016-11-17 08:10:16 <venzen> jonasschnelli: thanks for the links. Your C implementation is really useful
51 2016-11-17 08:56:27 <mappum> PSA: 100 blocks until segwit signalling begins
52 2016-11-17 11:02:24 <venzen> jonasschnelli: an identity address prefix to ripemd160(256) of 0x0F01 (instead of 0xFF01) yields the correct length base58-check format (35 chars)
53 2016-11-17 11:03:38 <venzen> presumably a result of the way base58 handles leading zeroes...
54 2016-11-17 17:13:44 <Skirmant> This isn't specifically #bitcoin related, but does someone know how to pick the timestamp field for a new transaction? https://wiki.peercointalk.org/index.php?title=Transactions
55 2016-11-17 17:30:14 <venzen> Skirmant: you'll be able to get help with user interface questions in #bitcoin
56 2016-11-17 17:31:53 <venzen> Skirmant: are you using bitcoin-cli ?
57 2016-11-17 17:33:36 <Skirmant> venzen: sorry, i mean this isn't interference related. It has to do with the peercoin protocol
58 2016-11-17 17:34:17 <Skirmant> venzen: there's an extra 4 byte field in the transaction format that's suppose to cointain a timestamp
59 2016-11-17 17:35:07 <venzen> yeah, i don't know anything about the peercoin interface... try #peercoin ? (dunno if it exists)
60 2016-11-17 17:35:20 <Skirmant> it does, but everyone is dead
61 2016-11-17 17:35:44 <venzen> :) quiet here too
62 2016-11-17 17:36:27 <venzen> i'm logging off, goodluck Skirmant
63 2016-11-17 17:36:34 <Skirmant> thanks fam
64 2016-11-17 17:36:37 <Skirmant> you too