1 2016-11-16 04:01:00 <mappum> is my code wrong or have there really only been 11 blocks of the last 172 that signal segwit?
 2 2016-11-16 04:02:08 <achow101> mappum: signalling technically hasn't started yet. It starts on the first retarget period after the 15th
 3 2016-11-16 04:03:21 <mappum> ok, so then are those 11 blocks probably from full node implementations with improper bip9 implementations?
 4 2016-11-16 04:03:35 <achow101> yes. they are probably slush who has begun signalling
 5 2016-11-16 04:03:44 <mappum> got it, thanks
 6 2016-11-16 04:05:05 <mappum> ok, then 360 blocks to go (~2.5 days)
 7 2016-11-16 04:22:53 <j_ybt> anyone know if bitcoinjs-lib can build coinbase tx's?
 8 2016-11-16 04:28:34 <mappum> j_ybt: sure, you just create a transaction like any other but with the input hash, index, and sequence set to zeroes
 9 2016-11-16 04:29:05 <j_ybt> i've tried that with TransactionBuilder() but it's giving me a coinbase that's larger than 100 bytes
10 2016-11-16 04:35:29 <j_ybt> ah nvm i think i was signing it and it isn't supposed to be
11 2016-11-16 15:39:16 <venzen> ping jonasschnelli
12 2016-11-16 15:41:36 <venzen> hi jonasschnelli, I've got the Enc handshake working as per BIP151 - this is still in my own python node implementation and i'll port to python-bitcoinlib as soon as my POC is good
13 2016-11-16 15:43:53 <venzen> the chachapoly@openssh is an immediate roadbloack for me, because there is no python wrapper (that i can find). I've begun compiling the openssh C sources but must still write the python wrapper
14 2016-11-16 15:44:54 <venzen> in the meantime, I've returned to BIP150 Auth and have a question:
15 2016-11-16 15:46:21 <venzen> the identity pubkey specified are ECC (32 byte) - is this a Bitcoin compressed pubkey minus the initial parity byte?
16 2016-11-16 15:52:35 <venzen> jonasschnelli: following from the question above, the example b58check representation in BIP150 is shown as: TfG4ScDgysrSpodWD4Re5UtXmcLbY5CiUHA
17 2016-11-16 15:55:21 <venzen> when I put an ECC 32 pubkey through ripemd160(sha256) and then b58check encode it, I get a much longer hash
18 2016-11-16 15:56:38 <venzen> any suggestion of a function I can look at to get the hash length required by BIP150?
19 2016-11-16 15:58:39 <waxwing> venzen: are you accidentally b58check encoding hex? ( just a thought)
20 2016-11-16 16:09:30 <venzen> waxwing: let me check the function
21 2016-11-16 16:15:51 <venzen> waxwing: i'm definitely passing a 32 byte length pubkey, as bytes, to a b58encode function that also adds a checksum BUT thanks to your prompt I see that the ripemd160(sha256) is never calculated! :P
22 2016-11-16 16:18:40 <venzen> waxwing: and yes, the bytestream is hex, should the key be represented as a long int instead?
23 2016-11-16 16:38:55 <venzen> waxwing: jonasschnelli: ok, now i'm getting closer to the 35 char length hash rep shown in BIP510 - my output happens to be 33, but I should soon solve it - provided my assumption about using a compressed key minus the first byte is correct
24 2016-11-16 16:48:54 <venzen> BIP150: "The base58check identity byte is 0x0F followed by an identity-address version number (=0xFF01)"
25 2016-11-16 16:49:50 <venzen> if someone can point me at a function or explain how the above is applied, that'll be muy bien