1 2016-03-30T00:02:13  *** harding has quit IRC
  2 2016-03-30T00:12:20  *** harding has joined #bitcoin-core-dev
  3 2016-03-30T00:13:19  *** supasonic has quit IRC
  4 2016-03-30T00:13:50  *** supasonic has joined #bitcoin-core-dev
  5 2016-03-30T00:14:38  *** wangchun_ has quit IRC
  6 2016-03-30T00:17:12  *** wangchun has joined #bitcoin-core-dev
  7 2016-03-30T00:20:26  *** gijensen has joined #bitcoin-core-dev
  8 2016-03-30T00:27:42  *** Giszmo has quit IRC
  9 2016-03-30T00:27:56  *** Giszmo has joined #bitcoin-core-dev
 10 2016-03-30T00:30:58  *** roidster has quit IRC
 11 2016-03-30T00:41:02  *** Ylbam has quit IRC
 12 2016-03-30T00:42:10  *** fengling_ has joined #bitcoin-core-dev
 13 2016-03-30T00:42:40  *** molz has quit IRC
 14 2016-03-30T00:42:56  *** molz has joined #bitcoin-core-dev
 15 2016-03-30T00:43:12  *** arowser_ has quit IRC
 16 2016-03-30T00:44:59  *** dermoth has quit IRC
 17 2016-03-30T00:45:08  *** fengling_ is now known as fengling
 18 2016-03-30T00:58:01  *** Alopex has quit IRC
 19 2016-03-30T00:58:16  *** frankenmint has quit IRC
 20 2016-03-30T00:59:06  *** Alopex has joined #bitcoin-core-dev
 21 2016-03-30T01:05:42  *** p15 has joined #bitcoin-core-dev
 22 2016-03-30T01:19:58  *** belcher has quit IRC
 23 2016-03-30T01:19:58  *** davec has quit IRC
 24 2016-03-30T01:20:24  *** davec has joined #bitcoin-core-dev
 25 2016-03-30T01:27:18  *** AaronvanW has quit IRC
 26 2016-03-30T02:15:16  *** xiangfu has joined #bitcoin-core-dev
 27 2016-03-30T02:22:16  *** fengling has quit IRC
 28 2016-03-30T02:24:56  *** fengling has joined #bitcoin-core-dev
 29 2016-03-30T02:29:18  *** Chris_Stewart_5 has quit IRC
 30 2016-03-30T02:29:56  *** fengling has quit IRC
 31 2016-03-30T02:35:15  *** xiangfu has quit IRC
 32 2016-03-30T02:37:09  *** xiangfu has joined #bitcoin-core-dev
 33 2016-03-30T02:37:10  *** fengling has joined #bitcoin-core-dev
 34 2016-03-30T02:43:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 35 2016-03-30T02:55:59  *** Chris_Stewart_5 has quit IRC
 36 2016-03-30T02:57:03  *** xiangfu has quit IRC
 37 2016-03-30T02:58:49  *** xiangfu has joined #bitcoin-core-dev
 38 2016-03-30T03:03:25  <GitHub66> [bitcoin] RHavar opened pull request #7768: Clarify outdated text in comment (master...patch-1) https://github.com/bitcoin/bitcoin/pull/7768
 39 2016-03-30T03:08:12  *** xiangfu has quit IRC
 40 2016-03-30T03:10:21  *** xiangfu has joined #bitcoin-core-dev
 41 2016-03-30T03:15:01  *** Giszmo has quit IRC
 42 2016-03-30T03:22:01  *** achow101 has quit IRC
 43 2016-03-30T03:23:56  *** fengling has quit IRC
 44 2016-03-30T03:27:09  <GitHub15> [bitcoin] RHavar closed pull request #7768: Clarify outdated text in comment (master...patch-1) https://github.com/bitcoin/bitcoin/pull/7768
 45 2016-03-30T03:47:46  *** cryptapus_afk is now known as cryptapus
 46 2016-03-30T03:49:37  *** cryptapus is now known as cryptapus_afk
 47 2016-03-30T04:15:01  *** Alopex has quit IRC
 48 2016-03-30T04:16:06  *** Alopex has joined #bitcoin-core-dev
 49 2016-03-30T04:31:43  *** d_t has joined #bitcoin-core-dev
 50 2016-03-30T04:32:20  *** d_t has joined #bitcoin-core-dev
 51 2016-03-30T05:04:01  *** Alopex has quit IRC
 52 2016-03-30T05:05:06  *** Alopex has joined #bitcoin-core-dev
 53 2016-03-30T05:06:47  *** zooko has joined #bitcoin-core-dev
 54 2016-03-30T05:19:07  *** d_t has quit IRC
 55 2016-03-30T05:20:01  *** Alopex has quit IRC
 56 2016-03-30T05:21:07  *** Alopex has joined #bitcoin-core-dev
 57 2016-03-30T05:29:13  *** supasonic has quit IRC
 58 2016-03-30T05:29:41  *** supasonic has joined #bitcoin-core-dev
 59 2016-03-30T05:59:01  *** Alopex has quit IRC
 60 2016-03-30T06:00:06  *** Alopex has joined #bitcoin-core-dev
 61 2016-03-30T06:14:50  *** Don_John has quit IRC
 62 2016-03-30T06:15:55  *** Thireus has quit IRC
 63 2016-03-30T06:33:19  *** supasonic has quit IRC
 64 2016-03-30T06:33:48  *** supasonic has joined #bitcoin-core-dev
 65 2016-03-30T06:44:39  *** fengling has joined #bitcoin-core-dev
 66 2016-03-30T06:48:01  *** Alopex has quit IRC
 67 2016-03-30T06:49:06  *** Alopex has joined #bitcoin-core-dev
 68 2016-03-30T06:58:20  *** abritoid has joined #bitcoin-core-dev
 69 2016-03-30T07:17:18  *** jtimon has quit IRC
 70 2016-03-30T07:32:22  <GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5131005e5b26...352fd577291e
 71 2016-03-30T07:32:23  <GitHub101> bitcoin/master e1523ce mruddy: P2P: add maxtimeadjustment command line option
 72 2016-03-30T07:32:23  <GitHub101> bitcoin/master 352fd57 Wladimir J. van der Laan: Merge #7573: P2P: add maxtimeadjustment command line option...
 73 2016-03-30T07:32:27  <GitHub196> [bitcoin] laanwj closed pull request #7573: P2P: add maxtimeadjustment command line option (master...trust-system-clock) https://github.com/bitcoin/bitcoin/pull/7573
 74 2016-03-30T07:39:59  *** jarret has quit IRC
 75 2016-03-30T07:42:40  *** xiangfu has quit IRC
 76 2016-03-30T08:00:52  *** AaronvanW has joined #bitcoin-core-dev
 77 2016-03-30T08:00:53  *** AaronvanW has joined #bitcoin-core-dev
 78 2016-03-30T08:03:21  *** zooko has quit IRC
 79 2016-03-30T08:04:28  *** Ylbam has joined #bitcoin-core-dev
 80 2016-03-30T08:04:29  *** zooko has joined #bitcoin-core-dev
 81 2016-03-30T08:08:05  *** MarcoFalke has joined #bitcoin-core-dev
 82 2016-03-30T08:17:34  *** cjcj has quit IRC
 83 2016-03-30T08:29:29  *** Alopex has quit IRC
 84 2016-03-30T08:29:29  <wumpus> cfields: no particular reason, that was just the simplest to do, and every proxy seems to support it
 85 2016-03-30T08:32:08  <wumpus> cfields: really don't want DNS leakage so we don't aim to support proxies that cannot support connecting by name
 86 2016-03-30T08:33:43  <wumpus> of course if you already have a ipv4/ipv6 address (say, from the P2P network) you could pass that directly instead of converting it to a name, I considered that at some point but gave up, not enough reason, some chance it may break things with some proxies, etc. There's .onion to contend with for example which we rolled into IPv6 but really need to pass as name to the proxy.
 87 2016-03-30T08:33:56  <wumpus> converting it to a string*
 88 2016-03-30T08:35:18  <wumpus> tl;dr. it was done because it fitted most easily into the current code, feel free to do it differently in a re-implementation, but don't do any host-side DNS queries when a proxy is set,ever
 89 2016-03-30T08:40:01  *** Thireus has joined #bitcoin-core-dev
 90 2016-03-30T08:40:29  *** randy-waterhouse has joined #bitcoin-core-dev
 91 2016-03-30T08:44:00  *** Arnavion has quit IRC
 92 2016-03-30T08:44:34  *** AtashiCon has quit IRC
 93 2016-03-30T08:50:06  *** Alopex has joined #bitcoin-core-dev
 94 2016-03-30T09:01:08  *** Guyver2 has joined #bitcoin-core-dev
 95 2016-03-30T09:16:56  *** MarcoFalke has quit IRC
 96 2016-03-30T09:25:47  <jonasschnelli> sipa: gmaxwell: p2p encryption: you said the ECDH secret should go into a PRNG. Wouldn't this require a custom PRNG implementation (something like the fortuna PR) to get the same result on both sides?
 97 2016-03-30T09:26:20  <jonasschnelli> What about using something similar than BIP32 to derive the session id, symmetric cipher key from the ecdh secret?
 98 2016-03-30T09:26:57  <jonasschnelli> SHA512_hmac from both pubkeys (or the requesting pubkey), use the ecdh as SHA512 mac
 99 2016-03-30T09:27:36  <jonasschnelli> wumpus: how do i pass a -g into the gitian build? Just a -g for the ./gbuild command?
100 2016-03-30T09:28:06  *** jarret has joined #bitcoin-core-dev
101 2016-03-30T09:30:22  <jonasschnelli> or do i need to change the descriptor?
102 2016-03-30T09:33:32  <sipa> jonasschnelli: sha512 and ecdh are not macs
103 2016-03-30T09:35:53  <sipa> jonasschnelli: yes, you need a fixed PRNG... i shouldn't have used the name PRNG though - just something to derive keys in a deterministic manner... i would suggest encryption_key = HMAC(key=ecdh_output,msg="encryption key"), session_id = HMAC-SHA256(key=ecdh_output,message="session id"), ...
104 2016-03-30T09:36:55  <sipa> jonasschnelli: i've been playing with chacha20-poly1305, and it's so fast... ~5 cycles per byte or so
105 2016-03-30T09:37:23  <sipa> i don't think i can get aes128-gcm below 80 cycles per byte without using assembly
106 2016-03-30T09:38:02  <sipa> in theory, aes128-gcm, on very modern hardware should be doable in ~1 cycle per byte, with aes-ni and carryless multiplication instructions
107 2016-03-30T09:41:24  <sipa> jonasschnelli: if we just copy chacha20-poly1305 from openssh (it's very simple code, and fast), it needs 2 256-bit keys (one for encrypting the sizes, one for encrypting and authenticating the data)
108 2016-03-30T09:48:45  *** sturles_ is now known as sturles
109 2016-03-30T09:49:00  <jonasschnelli> sipa: Thanks. Your HMAC make sense and is already possible with our codebase.
110 2016-03-30T09:49:26  <jonasschnelli> sipa: I think I drop the AES-GCM cipersuite  in the BIP any only cover chacha20-poly1305
111 2016-03-30T09:49:43  <jonasschnelli> (still allows AES256-GCM in a later BIP update or another BIP)
112 2016-03-30T09:57:13  <sipa> our current sha256 implementation is around 16 c/b, so using chacha20-poly1305 would actually be faster than our current checksumming
113 2016-03-30T10:02:40  <wumpus> jonasschnelli: just change the descriptor
114 2016-03-30T10:04:19  *** supasonic has quit IRC
115 2016-03-30T10:05:00  <sipa> jonasschnelli: or HMAC-SHA512, which we already have, and can provide larger keys at once
116 2016-03-30T10:05:02  <wumpus> jonasschnelli: I'm not exactly sure how I did it last time, wouldb e nice if we had a more structured way of doing this, or even better, have the build produce external symbol files for gdb by defalt
117 2016-03-30T10:05:29  <wumpus> I think I just added CPPFLAGS="-g" to CONFIGFLAGS
118 2016-03-30T10:05:54  <wumpus> (which is a hack, but CPPFLAGS are passed to both g++ and gcc, without overriding the current C*FLAGS optimizations etc)
119 2016-03-30T10:06:40  *** chris2000 has joined #bitcoin-core-dev
120 2016-03-30T10:07:17  *** gevs_ has quit IRC
121 2016-03-30T10:08:05  *** Arnavion has joined #bitcoin-core-dev
122 2016-03-30T10:08:10  *** AtashiCon has joined #bitcoin-core-dev
123 2016-03-30T10:12:29  *** chris2000 has quit IRC
124 2016-03-30T10:13:30  *** Guyver2 has quit IRC
125 2016-03-30T10:14:42  *** cjcj has joined #bitcoin-core-dev
126 2016-03-30T10:14:59  <sipa> jonasschnelli: perhaps it makes sense to refer to this document: https://github.com/jhcloos/openssh-chacha-poly1305/blob/master/PROTOCOL.chacha20poly1305
127 2016-03-30T10:17:21  <sipa> or https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.chacha20poly1305
128 2016-03-30T10:17:40  <wumpus> jonasschnelli: oh I remember! no i didn't even do that last time - i just replaced install_strip with install. This won't give full line number information, but at least basic symbols, which could be enough (and is guaranteed not to change the binary otherwise)
129 2016-03-30T10:24:08  *** randy-waterhouse has quit IRC
130 2016-03-30T10:28:17  <jonasschnelli> wumpus: thanks. Will try. What speaks again releasing with symbols as long as we are bellow <v1.0?
131 2016-03-30T10:28:56  <wumpus> jonasschnelli: it'd waste a lot of space - remember we're static linking every executable, and have quite a lot of executables
132 2016-03-30T10:29:18  <wumpus> https://github.com/bitcoin/bitcoin/issues/7770 is a better solution I think
133 2016-03-30T10:29:52  <wumpus> (and static linking gives lots of symbols, for every executable you have all the dependency symbols as well - and c++ symbols like from boost are huuuge)
134 2016-03-30T10:37:05  <jonasschnelli> Right. 7770 makes sense!
135 2016-03-30T10:41:56  <wumpus> talking about executables, it doesn't make a lot of sense to package bench_bitcoin and test_bitcoin-qt, but that's a whole other issue :)
136 2016-03-30T10:43:23  <wumpus> packaging the main test_bitcoin makes sense to check the tests on the specific OS/platform combination, but those two don't add much
137 2016-03-30T10:44:47  <jonasschnelli> Indeed. Lets remove those.
138 2016-03-30T10:45:00  <wumpus> CodeShark: I remember you were planning to use bitcoin core's rpc system in another project - you may like https://github.com/bitcoin/bitcoin/pull/7766, it removes further bitcoin-specific logic from rpc/server.cpp
139 2016-03-30T10:46:17  <wumpus> jonasschnelli: not sure what the best way would be - either deleting them in the gitian descriptor before packaging, or changing the build system to not install them in the first place
140 2016-03-30T10:46:41  <wumpus> probably the first is best, other distributions may want to make their own decision about what to ship
141 2016-03-30T10:46:51  <wumpus> OTOH they don't need to get built either
142 2016-03-30T10:47:45  <jonasschnelli> wumpus: Yes. We might need to set two different test level, so we could distinct over ./configure which test should be built and installed.
143 2016-03-30T10:50:22  <CodeShark> wumpus: yeah, that's a good idea
144 2016-03-30T10:59:36  <CodeShark> is it pretty safe to say CSV will be merged in the next couple weeks?
145 2016-03-30T11:00:14  <CodeShark> specifically, https://github.com/bitcoin/bitcoin/pull/7648
146 2016-03-30T11:06:38  <btcdrak> CodeShark: I would hope it gets merged this week. It's a very trivial PR with a ton of tested ACKs already
147 2016-03-30T11:09:56  *** fengling has quit IRC
148 2016-03-30T11:19:50  <btcdrak> wumpus: is there any news on the clion licenses?
149 2016-03-30T11:32:26  <wumpus> jonasschnelli: ah we can already --disable-bench
150 2016-03-30T11:32:32  <wumpus> btcdrak: no, no reply on that yet
151 2016-03-30T11:32:53  <sipa> what is clion?
152 2016-03-30T11:33:15  <btcdrak> sipa: https://www.jetbrains.com/clion/
153 2016-03-30T11:34:06  <btcdrak> sipa: and we're also applying for https://www.jetbrains.com/pycharm/
154 2016-03-30T11:35:09  <sipa> hmm, why?
155 2016-03-30T11:36:27  <btcdrak> sipa: some of us can't survive with vim :-p
156 2016-03-30T11:36:51  <wumpus> it's free for open source projects so why not
157 2016-03-30T11:37:03  <wumpus> I'm happy with vim myself
158 2016-03-30T11:37:59  <sipa> ah, i see
159 2016-03-30T11:38:18  <sipa> it would license anyone to use it for the purpose of developing bitcoin core?
160 2016-03-30T11:39:22  <wumpus> I think we get a limited number of licenses, to be distributed over people developing bitcoin core
161 2016-03-30T11:39:56  <wumpus> the license allows using it for developing any open source software
162 2016-03-30T11:40:09  <btcdrak> sipa: yes. Personally, I love the IDE and debugger features.
163 2016-03-30T11:40:33  <btcdrak> API autocomplete in itself is gold for me.
164 2016-03-30T11:41:51  *** gevs has joined #bitcoin-core-dev
165 2016-03-30T11:41:58  *** laurentmt has joined #bitcoin-core-dev
166 2016-03-30T11:42:58  *** chris2000 has joined #bitcoin-core-dev
167 2016-03-30T11:43:16  *** cryptapus has joined #bitcoin-core-dev
168 2016-03-30T11:43:25  *** laurentmt has quit IRC
169 2016-03-30T11:46:05  <sipa> btcdrak: i've used Eclipse a long time ago (including CDT), but had no problem going back to a text editor for other projects
170 2016-03-30T11:47:03  <btcdrak> sipa: I was an Eclipse fan until I discovered JetBrains. They are remarkably good.
171 2016-03-30T11:48:33  <wumpus> I tried to like eclipse very hard, i really did, but it never stuck with me. All the features are awesome, but it feels too slow and heavy.
172 2016-03-30T11:48:59  <kinlo> vim ftw :p
173 2016-03-30T11:49:23  <sipa> mcedit!
174 2016-03-30T11:49:25  <wumpus> it's like an OS in itself. I'm old-fashioned and just like opening the editor on separate files
175 2016-03-30T11:49:26  * sipa hides
176 2016-03-30T11:49:45  <kinlo> sipa: heh, I actually use that aswell, you're an mc user?
177 2016-03-30T11:49:59  <sipa> yeah
178 2016-03-30T11:50:00  <kinlo> sipa: there aren't enough mc users in this world :)
179 2016-03-30T11:50:19  <wumpus> I used 'joe' editor a long time
180 2016-03-30T11:50:29  <sipa> i like bluescreens
181 2016-03-30T11:50:33  <sipa> ;)
182 2016-03-30T11:50:40  <kinlo> haha :)
183 2016-03-30T11:52:00  <wumpus> but it's no longer maintained, and at some point someone convinced me to use vim, which has a lot more plugins and syntax highlighting etc available. And I'm kind of happy with it. Though most of the true hard-core vim-golf tricks elude me.
184 2016-03-30T11:52:10  <btcdrak> Sublime is fun.
185 2016-03-30T11:53:25  <jl2012>   if i want to return the size and hash of every txs in the blockchain to log during block validation, where should i do it? main.cpp?
186 2016-03-30T11:54:17  <wumpus> yes, sublime is nice too, I used sublime 2 at a job for a while. At least it's simply an editor and not en IDE monster :)
187 2016-03-30T11:55:37  <wumpus> jl2012: why would you want to do that during validation, and not do a after-pass using getblockhash and getblock verbose=true to get all the txids??
188 2016-03-30T11:57:21  <wumpus> in any case if you want such logging, ConnectBlock is probably the best place, where it checks the transactions in the block for consensus
189 2016-03-30T11:58:21  <jl2012> wumpus: just for studying purpose. Logging of fee of each tx, for example, could also be done in ConnectBlock?
190 2016-03-30T11:59:05  <jl2012> I'm self-learning C++
191 2016-03-30T11:59:07  <wumpus> yes, I think so, it should have all the information available there
192 2016-03-30T11:59:17  <jl2012> thanks
193 2016-03-30T12:01:03  <wumpus> the fee/block reward computation should also be somewhere areound those parts
194 2016-03-30T12:02:01  <sipa> so the naive uint32-based chacha20-poly1305 implementation from OpenSSH, compiled at -O2, needs 8.6 c/b for chacha20, and 2.8 c/b for poly1305... that's faster than sha256 or naive variable-time AES
195 2016-03-30T12:02:34  <wumpus> wow
196 2016-03-30T12:02:43  *** Guyver2 has joined #bitcoin-core-dev
197 2016-03-30T12:02:54  <wumpus> obviously that's not fast enough and we should do an asm implementation *ducks*
198 2016-03-30T12:03:16  *** cryptapus_ has joined #bitcoin-core-dev
199 2016-03-30T12:03:59  *** cryptapus_afk has quit IRC
200 2016-03-30T12:04:32  <sipa> AES-NI + CLMUL based implementations can do AES-GCM in 1 c/b; without those, 22 c/b, without SIMD, 35 c/b
201 2016-03-30T12:06:07  <sipa> wumpus: i just realized! we only compute the p2p message checksum before sending it, or after receiving it entirely; for a 1 MB block message, that means an unnecessary 5ms delay on both sides!
202 2016-03-30T12:06:52  <sipa> on the sending side, that's inevitable, as the checksum goes before the actual data
203 2016-03-30T12:07:06  <sipa> but on the receiver side we could in theory compute it while receiving the data, in the network thread
204 2016-03-30T12:07:15  <wumpus> sipa: right, for receiving we could certainly use a CHashWriter there
205 2016-03-30T12:07:36  <sipa> not that it matters much for 1 MB messages, but it does indicate that there is a downside to having large p2p messages
206 2016-03-30T12:07:38  <wumpus> for sending all the data is processed at once anyway
207 2016-03-30T12:08:01  <sipa> if the checksum was at the end, it could in theory be computed by the networking thread during sending, which is usually not loaded
208 2016-03-30T12:08:28  <wumpus> well the networking thread receives messages entirely right? so it could still do the computation there
209 2016-03-30T12:09:01  <sipa> no the networking thread receives whatever recv() returns
210 2016-03-30T12:09:16  <sipa> the message handler receives entire messages
211 2016-03-30T12:09:17  <wumpus> just leave it blank initially then fill it in before sending it to the wire
212 2016-03-30T12:09:21  <wumpus> no, I'm talking about sending
213 2016-03-30T12:09:46  <wumpus> messages could be queued up without checksum, then the network thread fills in the checksum before actually dispatching them on the wire
214 2016-03-30T12:09:51  *** fengling has joined #bitcoin-core-dev
215 2016-03-30T12:10:08  <sipa> that doesn't change the latency, but it can take some load of the message handler thread, indeed
216 2016-03-30T12:10:17  <sipa> *off
217 2016-03-30T12:10:28  <wumpus> well, sure, there's a good point for adding the checksum at the end
218 2016-03-30T12:10:33  <sipa> jonasschnelli: ^
219 2016-03-30T12:10:38  <wumpus> and using a cheaper to compute one in the first place
220 2016-03-30T12:10:52  <sipa> jonasschnelli: in the encrypted p2p protocol, the authentication tag (produced by poly1305) goes at the end :)
221 2016-03-30T12:14:06  <wumpus> also I agree that there is a downside to having very large messages, it may make sense to divide up realy big data into multiple messages at some point and stream them
222 2016-03-30T12:14:31  <wumpus> (also because of memory usage and buffers)
223 2016-03-30T12:15:36  *** fengling has quit IRC
224 2016-03-30T12:17:49  <sipa> indeed
225 2016-03-30T12:23:10  *** belcher has joined #bitcoin-core-dev
226 2016-03-30T12:27:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
227 2016-03-30T12:36:20  *** Giszmo has joined #bitcoin-core-dev
228 2016-03-30T12:37:28  *** jannes has joined #bitcoin-core-dev
229 2016-03-30T12:39:00  *** Guyver2 has quit IRC
230 2016-03-30T12:43:51  * jonasschnelli is back at keyboard and reads backlog
231 2016-03-30T12:48:26  <jonasschnelli> sipa: did I got this right: the (truncated) mac tag (https://github.com/bitcoin/bips/pull/362/files#diff-0bd7a3b80179294f4bcb38cae13c8534R87) should be after the crypted message to allow faster hashing or chunk based sending?
232 2016-03-30T12:49:16  <sipa> jonasschnelli: yup, after the crypted message, so that the sender can compute it while sending, instead of computing it before any send can occur
233 2016-03-30T12:51:27  <jonasschnelli> sipa: so using poly1305 as mac (hash replacement) would make the transmission process faster because chacha20+poly1305 requires less cycles then sha256?
234 2016-03-30T12:51:41  <sipa> jonasschnelli: yup
235 2016-03-30T12:51:54  <jonasschnelli> That is an argument.
236 2016-03-30T12:52:02  <sipa> or rather: naive implementation of chacha20+poly1305 is faster than naive implementation of sha256
237 2016-03-30T12:52:16  <sipa> both can be made a small multiple faster with SIMD code etc
238 2016-03-30T12:52:31  * jonasschnelli is looking over to wumpus asm skills... 
239 2016-03-30T12:52:40  <sipa> i'm not saying we should do that
240 2016-03-30T12:53:08  <sipa> but it's not fair to say "algorithm X is faster than algorithm Y" without qualifying what kind of implementation you're talking about
241 2016-03-30T12:53:15  <jonasschnelli> SIMD?
242 2016-03-30T12:53:26  <jonasschnelli> Yes.
243 2016-03-30T12:54:39  <jonasschnelli> sipa: you said: "it needs 2 256-bit keys (one for encrypting the sizes, one for encrypting and authenticating the data)" Whats the purpose to encrypt the "sizes"?
244 2016-03-30T12:55:30  <sipa> jonasschnelli: because the sizes leak privacy
245 2016-03-30T12:56:33  <sipa> if you observe an ingoing message of a certain unusual size, followed by output messages of the same size to several peers, you may be able to distinguish transactions and trace them
246 2016-03-30T12:56:49  <jonasschnelli> sipa: but by analyzing the stream you could still get the encrypted chunk/message sizes,... or would it then allow padding of random data while knowing the size only when you can decrypt?
247 2016-03-30T12:58:09  <sipa> jonasschnelli: sure, stream analysis may still leak information, but leaking sizes is just giving away potentially private information without reason
248 2016-03-30T12:58:37  <sipa> jonasschnelli: read the link to openssh's document about it
249 2016-03-30T12:59:11  <jonasschnelli> sipa: thanks. Will check it. I guess you pass in a int32 into chacha20 and get a "encrypted" int32 back while providing a sizes key?
250 2016-03-30T12:59:35  <jonasschnelli> howevery,... i need to check the openssl docs first.
251 2016-03-30T13:00:22  <sipa> OpenSSH, not OpenSSL
252 2016-03-30T13:00:41  <jonasschnelli> arg. right.
253 2016-03-30T13:00:47  <sipa> jonasschnelli: yes, chacha20 is a stream cipher, so it can encrypt things of any byte size
254 2016-03-30T13:00:52  <sipa> without expanding them
255 2016-03-30T13:01:09  <sipa> it's essentially just xoring the data with the output of a deterministic PRNG
256 2016-03-30T13:01:15  <sipa> which is seeded by the key
257 2016-03-30T13:03:17  <jonasschnelli> sipa: what do you think about an approach where each message could contain arbitrary pseudo-random data padded?
258 2016-03-30T13:07:39  <sipa> sure
259 2016-03-30T13:07:51  <sipa> that's orthogonal, i think
260 2016-03-30T13:09:54  <jonasschnelli> Yes. I just wondered if it would make sense to mention in the BIP. But agree,... has nothing to do with the encrypted sized.
261 2016-03-30T13:09:57  <jonasschnelli> *size
262 2016-03-30T13:12:55  *** jtimon has joined #bitcoin-core-dev
263 2016-03-30T13:19:26  *** cryptapus has quit IRC
264 2016-03-30T13:20:10  *** cryptapus has joined #bitcoin-core-dev
265 2016-03-30T13:20:10  *** cryptapus has joined #bitcoin-core-dev
266 2016-03-30T13:20:27  *** Luke-Jr has quit IRC
267 2016-03-30T13:20:30  *** zmanian__ has quit IRC
268 2016-03-30T13:21:02  *** Luke-Jr has joined #bitcoin-core-dev
269 2016-03-30T13:23:52  *** zmanian__ has joined #bitcoin-core-dev
270 2016-03-30T13:45:05  <GitHub27> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/352fd577291e...60db51dcb200
271 2016-03-30T13:45:05  <GitHub27> bitcoin/master 7d5e31a Jonas Schnelli: [Qt] remove trailing output-index from transaction-id...
272 2016-03-30T13:45:06  <GitHub27> bitcoin/master 60db51d Wladimir J. van der Laan: Merge #7761: [Qt] remove trailing output-index from transaction-id...
273 2016-03-30T13:45:17  <GitHub38> [bitcoin] laanwj closed pull request #7761: [Qt] remove trailing output-index from transaction-id (master...2016/03/ui_txid) https://github.com/bitcoin/bitcoin/pull/7761
274 2016-03-30T13:50:34  *** d_t has joined #bitcoin-core-dev
275 2016-03-30T13:52:37  *** Thireus1 has joined #bitcoin-core-dev
276 2016-03-30T13:53:16  *** Thireus1 has joined #bitcoin-core-dev
277 2016-03-30T13:55:04  *** d_t has quit IRC
278 2016-03-30T13:56:13  *** Thireus has quit IRC
279 2016-03-30T14:03:04  *** xiangfu has joined #bitcoin-core-dev
280 2016-03-30T14:09:54  *** laurentmt has joined #bitcoin-core-dev
281 2016-03-30T14:13:32  <instagibbs> is there a way to run individual unit tests instead of all?
282 2016-03-30T14:14:49  *** fengling has joined #bitcoin-core-dev
283 2016-03-30T14:15:01  *** zooko has quit IRC
284 2016-03-30T14:16:10  <sipa> instagibbs: ./test_bitcoin --run_tests=test_name
285 2016-03-30T14:16:24  <sipa> for example --run_test=crypto_tests
286 2016-03-30T14:16:47  <sipa> (use the name from the TEST_SUITE line
287 2016-03-30T14:17:27  <instagibbs> awesome thanks
288 2016-03-30T14:19:36  *** fengling has quit IRC
289 2016-03-30T14:24:08  *** abritoid has quit IRC
290 2016-03-30T14:27:06  *** zooko has joined #bitcoin-core-dev
291 2016-03-30T14:28:34  *** laurentmt has quit IRC
292 2016-03-30T14:30:12  *** ZerownZ has joined #bitcoin-core-dev
293 2016-03-30T14:37:19  *** cryptapus has quit IRC
294 2016-03-30T14:37:35  *** cryptapus has joined #bitcoin-core-dev
295 2016-03-30T14:46:29  *** zooko has quit IRC
296 2016-03-30T14:46:31  *** jouke has quit IRC
297 2016-03-30T14:46:32  *** jouke has joined #bitcoin-core-dev
298 2016-03-30T14:57:28  *** ZerownZ has quit IRC
299 2016-03-30T14:57:42  *** ZerownZ has joined #bitcoin-core-dev
300 2016-03-30T15:05:00  <wumpus> instagibbs: you can even do --run-test=suite_name/test_name
301 2016-03-30T15:05:38  <sipa> ha!
302 2016-03-30T15:05:52  <sipa> i had tried various separators, but not /
303 2016-03-30T15:07:39  *** xabbix__ is now known as xabbix
304 2016-03-30T15:07:43  *** xabbix has joined #bitcoin-core-dev
305 2016-03-30T15:07:46  <wumpus> stumbled on it by accident too
306 2016-03-30T15:08:39  <instagibbs> heh, I should probably write this up as PR for the testing doc
307 2016-03-30T15:09:11  <wumpus> just grepped it, we somehow already documented this in test/README.md
308 2016-03-30T15:09:39  <wumpus> never know
309 2016-03-30T15:09:43  <wumpus> knew*
310 2016-03-30T15:10:03  <instagibbs> wah, I just read the document, didn't see it?
311 2016-03-30T15:10:07  <instagibbs> maybe an old version
312 2016-03-30T15:10:12  <wumpus> so many things I forget most of it
313 2016-03-30T15:10:52  <instagibbs> oh i see, doc/unit-tests.md doesn't mention this
314 2016-03-30T15:11:04  <instagibbs> that's what I found and read
315 2016-03-30T15:12:09  <wumpus> may make sense to combine them
316 2016-03-30T15:12:40  *** Guyver2 has joined #bitcoin-core-dev
317 2016-03-30T15:15:52  <paveljanik> jonasschnelli, in the GUI, after using the autocomplete in the console tab, what do you have in the entry line?
318 2016-03-30T15:16:24  <jonasschnelli> paveljanik: what do you mean with "after"?
319 2016-03-30T15:16:48  <paveljanik> get cursor down, Enter
320 2016-03-30T15:16:53  <paveljanik> type get, ...
321 2016-03-30T15:16:59  <jonasschnelli> Yes. It keeps the command...
322 2016-03-30T15:17:01  <jonasschnelli> hmm...
323 2016-03-30T15:18:44  <jonasschnelli> until i send it again,... than its gone.
324 2016-03-30T15:18:48  <jonasschnelli> Needs fixing...
325 2016-03-30T15:18:52  <paveljanik> yup
326 2016-03-30T15:19:11  <paveljanik> I'll have a look once I finish the rest.
327 2016-03-30T15:19:14  <jonasschnelli> Why I did not recognized that in the first place...
328 2016-03-30T15:19:27  <jonasschnelli> paveljanik: super. Thanks. Should be easy to implement.
329 2016-03-30T15:19:28  <paveljanik> How can I create immediatelly abandonable transaction so I can test #7707 now?
330 2016-03-30T15:19:51  <jonasschnelli> paveljanik: set -walletboardcast=0, create a transaction, restart
331 2016-03-30T15:19:58  <jonasschnelli> then you can abandone
332 2016-03-30T15:20:03  <jonasschnelli> *abandon
333 2016-03-30T15:22:13  <paveljanik> jonasschnelli, restart with -walletboardcast=0 again? Probably yes. Still grayed Abandon transaction in the UI
334 2016-03-30T15:22:38  <paveljanik> ah, boardcast :-)
335 2016-03-30T15:38:56  *** molz has quit IRC
336 2016-03-30T15:39:24  *** molz has joined #bitcoin-core-dev
337 2016-03-30T15:47:16  *** chris2000 has quit IRC
338 2016-03-30T15:53:03  *** laurentmt has joined #bitcoin-core-dev
339 2016-03-30T16:12:35  *** zooko has joined #bitcoin-core-dev
340 2016-03-30T16:12:57  <instagibbs> btcdrak, once csv cherry-picks are validated, what's the speed at which a release comes?
341 2016-03-30T16:13:18  <instagibbs> s/speed/process
342 2016-03-30T16:14:47  *** Guyver2 has quit IRC
343 2016-03-30T16:17:55  *** fengling has joined #bitcoin-core-dev
344 2016-03-30T16:19:46  *** JeromeLegoupil has joined #bitcoin-core-dev
345 2016-03-30T16:20:05  *** abritoid has joined #bitcoin-core-dev
346 2016-03-30T16:21:34  *** supasonic has joined #bitcoin-core-dev
347 2016-03-30T16:22:56  *** fengling has quit IRC
348 2016-03-30T16:28:24  *** zooko has quit IRC
349 2016-03-30T16:39:43  <btcdrak> instagibbs: I am not the release manager, but my understanding is that once #7648 is merged, we can merge #7543 (the 0.12 backport). And #7543 is the only PR pending for 0.12.1 release cycle that I am aware of.
350 2016-03-30T16:40:29  <instagibbs> I suppose since it's directly off of 0.12, it doesn't require a long freeze period, etc
351 2016-03-30T16:40:46  <instagibbs> enough time for RCs
352 2016-03-30T16:42:48  <btcdrak> instagibbs: we discussed the contents of 0.12.1 a few meetings back, so basically we're good to go once #7543 is merged.
353 2016-03-30T16:44:09  *** zooko has joined #bitcoin-core-dev
354 2016-03-30T16:44:22  <btcdrak> instagibbs: actually there are a couple tickets still see https://bitcoincore.org/en/meetings/2016/03/17/#features-for-0121-besides-bip-9
355 2016-03-30T16:49:07  *** JeromeLegoupil has quit IRC
356 2016-03-30T16:49:10  *** xiangfu has quit IRC
357 2016-03-30T16:49:23  <instagibbs> writeups coming in handy, thanks
358 2016-03-30T16:56:48  *** laurentmt has quit IRC
359 2016-03-30T17:01:12  <GitHub114> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/60db51dcb200...e8a8f3d4b22b
360 2016-03-30T17:01:13  <GitHub114> bitcoin/master 65751a3 Pieter Wuille: Add CHECKSEQUENCEVERIFY softfork through BIP9
361 2016-03-30T17:01:13  <GitHub114> bitcoin/master 478fba6 BtcDrak: Soft fork logic for BIP113
362 2016-03-30T17:01:14  <GitHub114> bitcoin/master 02c2435 BtcDrak: Soft fork logic for BIP68
363 2016-03-30T17:01:17  <GitHub193> [bitcoin] laanwj closed pull request #7648: BIP9 versionbits softfork for BIP68, BIP112 and BIP113 (master...vb_68_112_113_1) https://github.com/bitcoin/bitcoin/pull/7648
364 2016-03-30T17:03:44  *** laurentmt has joined #bitcoin-core-dev
365 2016-03-30T17:04:36  <btcdrak> omg boat party!
366 2016-03-30T17:04:36  <Ylbam> \o/
367 2016-03-30T17:07:17  <wumpus> o/ \o
368 2016-03-30T17:10:15  <gmaxwell> Is there a reason we can't get all these IsSuperMajority checks? they're kinda slow. There are 6 of them used in accepting a header right now.
369 2016-03-30T17:11:03  *** molly has joined #bitcoin-core-dev
370 2016-03-30T17:12:16  *** ZerownZ_ has joined #bitcoin-core-dev
371 2016-03-30T17:13:28  <wumpus> there have been pulls in the past replacing at least one of them with a fixed height. No idea what happened to it, or why it isn't merged.
372 2016-03-30T17:13:59  <sipa> it was merged for BIP34
373 2016-03-30T17:14:11  <sipa> not for later ones
374 2016-03-30T17:14:34  *** molz has quit IRC
375 2016-03-30T17:14:49  <wumpus> ok
376 2016-03-30T17:15:42  *** ZerownZ has quit IRC
377 2016-03-30T17:15:42  <wumpus> in any case there is no pressing reason why they couldn't go
378 2016-03-30T17:15:50  *** ZerownZ_ is now known as ZerownZ
379 2016-03-30T17:20:16  <ZerownZ> hahaha
380 2016-03-30T17:36:13  *** Guyver2 has joined #bitcoin-core-dev
381 2016-03-30T17:40:05  <cfields> wumpus: thanks for the explanation, that was very helpful
382 2016-03-30T17:42:02  *** JeromeLegoupil has joined #bitcoin-core-dev
383 2016-03-30T17:46:24  *** d_t has joined #bitcoin-core-dev
384 2016-03-30T17:50:14  *** neha has joined #bitcoin-core-dev
385 2016-03-30T17:52:41  *** abritoid has quit IRC
386 2016-03-30T17:52:57  *** belcher has quit IRC
387 2016-03-30T17:53:49  *** moli has joined #bitcoin-core-dev
388 2016-03-30T17:54:38  *** belcher has joined #bitcoin-core-dev
389 2016-03-30T17:55:50  *** molly has quit IRC
390 2016-03-30T17:56:17  *** zooko has quit IRC
391 2016-03-30T18:04:46  <GitHub95> [bitcoin] laanwj pushed 2 new commits to 0.11: https://github.com/bitcoin/bitcoin/compare/0ba7020cf6f9...c251f46bea8f
392 2016-03-30T18:04:46  <GitHub95> bitcoin/0.11 12943ad Wladimir J. van der Laan: bump version to 0.11.3...
393 2016-03-30T18:04:46  <GitHub95> bitcoin/0.11 c251f46 BtcDrak: Mark p2p alert system as deprecated....
394 2016-03-30T18:07:55  *** JeromeLegoupil has quit IRC
395 2016-03-30T18:13:09  *** moli has quit IRC
396 2016-03-30T18:14:48  *** JeromeLegoupil has joined #bitcoin-core-dev
397 2016-03-30T18:14:49  <GitHub76> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/ba80ceef59bdfb7e0a42da4df81335698047fbce
398 2016-03-30T18:14:49  <GitHub76> bitcoin/0.12 ba80cee Wladimir J. van der Laan: bump version to 0.12.1
399 2016-03-30T18:15:04  <morcos> btcdrak: sipa: yeah the remaining thing we were hoping to get in 0.12.1 is #7568...  unfortunately that still doesn't have much review...  i suppose we could get that backported in time for 0.12.2, but it would be nice to expedite.  sorry for not reviewing myself
400 2016-03-30T18:15:14  <morcos> s/much/enough/
401 2016-03-30T18:17:07  <btcdrak> Trolling for review of https://github.com/bitcoin/bitcoin/pull/7707 - we'd like this for 0.12.1
402 2016-03-30T18:17:37  <btcdrak> trolling for review/commentary on https://github.com/bitcoin/bitcoin/pull/7568
403 2016-03-30T18:18:34  <btcdrak> morcos: actually, since these are master, it seems unlikely these could be reviewed and backported in time for 0.12.1
404 2016-03-30T18:18:58  <morcos> btcdrak: we don't want 7707
405 2016-03-30T18:19:09  <morcos> we already got the commit we wanted, jonas broke it out separately
406 2016-03-30T18:19:17  <btcdrak> morcos: ah
407 2016-03-30T18:19:35  <btcdrak> oh right I cant read "#7707 RPC-only (commit 42e945d79fd54ab11ad48978910b42d10c1c7cf8), which is 1 line of code."
408 2016-03-30T18:20:16  <btcdrak> yeah, so #7568 wont happen in time. We should consider disabling the warnings instead.
409 2016-03-30T18:20:40  <morcos> 7568 would have been very nice, but we all dropped the ball on that.  the existing false positives on alerts are terrible, especially with the upcoming slew of soft and hard forks, having a more functional alert system is important
410 2016-03-30T18:20:59  <btcdrak> as it stands, with so many false positives, the longer they are giving false positives, the more they will get ignored into the future.
411 2016-03-30T18:21:09  *** fengling has joined #bitcoin-core-dev
412 2016-03-30T18:21:17  <morcos> i'd be more in favor of properly reviewing 7568 than trying to rush in some other half ass solution such as disabling them
413 2016-03-30T18:21:34  <btcdrak> morcos: not on our timeline.
414 2016-03-30T18:23:28  *** zooko has joined #bitcoin-core-dev
415 2016-03-30T18:23:46  <btcdrak> that's a basically unreviewed PR in master. It would need to get review, merge and backport. We have to start a 0.12.1 release cycle soon. since the QA process is laborious as it is for release, we just dont have time unless we let it slip. The 0.12.1 is suppose to be released well in advance of the May 1st start date for counting CSV signalling.
416 2016-03-30T18:23:53  *** moli has joined #bitcoin-core-dev
417 2016-03-30T18:23:58  <morcos> i know!
418 2016-03-30T18:25:36  <morcos> honestly its a bit tricky to think about and review for correctness, but its not much in the way of code changes, and it seems highly likely to not be WORSE than what we have now.
419 2016-03-30T18:25:40  *** zooko has quit IRC
420 2016-03-30T18:25:56  *** fengling has quit IRC
421 2016-03-30T18:26:06  *** abritoid has joined #bitcoin-core-dev
422 2016-03-30T18:26:19  *** zooko has joined #bitcoin-core-dev
423 2016-03-30T18:26:27  <morcos> i'd vote that sipa reviews it for 10 mins and decides that its got a very high liklihood of being an improvement and we just merge and call it a day.  :)
424 2016-03-30T18:26:44  <morcos> i will try to look at it in the next 24 hours... but i do agree that we can't hold up 0.12.1
425 2016-03-30T18:27:01  *** moli has quit IRC
426 2016-03-30T18:27:32  <morcos> we suck though if we can't do something about these wonky alerts..  this is exactly what we need to be building into the installed base to make things safer in the future
427 2016-03-30T18:29:04  <wumpus> <morcos> i'd vote that sipa reviews it for 10 mins and decides that its got a very high liklihood of being an improvement and we just merge and call it a day.  :) <- for master that'd be totally ok, for a backport I do think the bar should be higher
428 2016-03-30T18:29:46  <wumpus> but sure, even if sipa were to look at it for 10 minutes that's better than nothing :D
429 2016-03-30T18:29:49  <GitHub0> [bitcoin] paveljanik opened pull request #7772: Clear the input line after activating autocomplete (master...20160330_completer_clean_input_line) https://github.com/bitcoin/bitcoin/pull/7772
430 2016-03-30T18:30:41  <morcos> wumpus: yes i agree in principle, its just that the current situation is bad..  and i'm pretty optimistic that 0.12.1 will be upgraded too widely..  but its not 100% clear what happens after that, so would be nice to have alerts working as well as reasonably possible in short notice.
431 2016-03-30T18:32:40  <wumpus> yes you could say that the current handling is so bad that everything is an improvement :)
432 2016-03-30T18:33:09  <morcos> right, all we have to do is be confident it will alert LESS often, and its an improvement
433 2016-03-30T18:33:15  <wumpus> and at least if we can rule out that it causes crashes or reversions outside the immediate area of chain-alerts
434 2016-03-30T18:33:47  <morcos> terrible way to code a project though...   incremental improvements without caring that they are right... :)  its like monkeys typing shakespeare
435 2016-03-30T18:34:11  <wumpus> yes, to be honest I'd rather disable the code until we get it right
436 2016-03-30T18:34:27  <btcdrak> wumpus: +1
437 2016-03-30T18:34:43  <wumpus> at least on major releases, in master we still have quite some time until a release
438 2016-03-30T18:34:57  <btcdrak> disable for 0.12.1, then if we fix it properly in master, we can backport it to 0.12.2
439 2016-03-30T18:35:07  <wumpus> that sounds like the responsible thing to do
440 2016-03-30T18:35:11  <morcos> well lets give it 24 hours, til the meeting, if it gets reviews, then we can merge, if not we can decide what to do
441 2016-03-30T18:35:26  <morcos> disabling sounds like its also bad to me, thats still a code change to be merged
442 2016-03-30T18:35:48  <btcdrak> disabling is easy code though.
443 2016-03-30T18:36:37  <wumpus> it is a very predictable and safe change
444 2016-03-30T18:39:27  *** Guyver2 has quit IRC
445 2016-03-30T18:39:33  <GitHub155> [bitcoin] btcdrak opened pull request #7773: Fix comments in tests (master...csv-comments) https://github.com/bitcoin/bitcoin/pull/7773
446 2016-03-30T18:40:40  *** moli has joined #bitcoin-core-dev
447 2016-03-30T18:40:50  *** Guyver2 has joined #bitcoin-core-dev
448 2016-03-30T18:41:18  <paveljanik> who will win #7777? ;-)
449 2016-03-30T18:41:32  <wumpus> in any case let's say that if we can unequivocably decide that  7568 is an improvement that makes it worth keeping the system in the next 24 hours then we'll merge and backport that, otherwise we'll disable it in 0.12 for now
450 2016-03-30T18:42:27  <morcos> roger.  paging sipa.  :)  ok got to run
451 2016-03-30T18:43:15  <wumpus> yes, gtg in a bit too. later!
452 2016-03-30T18:43:55  *** moli has quit IRC
453 2016-03-30T18:51:36  *** moli has joined #bitcoin-core-dev
454 2016-03-30T18:53:15  *** frankenmint has joined #bitcoin-core-dev
455 2016-03-30T18:54:13  *** achow101 has joined #bitcoin-core-dev
456 2016-03-30T18:57:07  *** frankenmint has quit IRC
457 2016-03-30T19:03:59  *** frankenmint has joined #bitcoin-core-dev
458 2016-03-30T19:05:18  *** frankenmint has quit IRC
459 2016-03-30T19:05:23  *** frankenm_ has joined #bitcoin-core-dev
460 2016-03-30T19:06:22  *** frankenmint has joined #bitcoin-core-dev
461 2016-03-30T19:44:31  *** achow101 has quit IRC
462 2016-03-30T19:47:38  *** achow101 has joined #bitcoin-core-dev
463 2016-03-30T19:49:19  *** laurentmt has quit IRC
464 2016-03-30T19:55:55  *** molz has joined #bitcoin-core-dev
465 2016-03-30T19:56:36  *** jannes has quit IRC
466 2016-03-30T19:58:52  *** moli has quit IRC
467 2016-03-30T20:00:08  *** molly has joined #bitcoin-core-dev
468 2016-03-30T20:02:37  *** molz has quit IRC
469 2016-03-30T20:04:49  *** ryan-c has quit IRC
470 2016-03-30T20:05:11  *** zooko has quit IRC
471 2016-03-30T20:09:16  *** ryan-c has joined #bitcoin-core-dev
472 2016-03-30T20:15:14  *** zooko has joined #bitcoin-core-dev
473 2016-03-30T20:15:51  *** cryptapus has quit IRC
474 2016-03-30T20:24:26  *** fengling has joined #bitcoin-core-dev
475 2016-03-30T20:28:42  *** Don_John has joined #bitcoin-core-dev
476 2016-03-30T20:29:16  *** fengling has quit IRC
477 2016-03-30T20:37:56  <sipa> wumpus, morcos: i think it's an improvement and technically correct, but the logic is a bit hard to read, and meni brings up good points
478 2016-03-30T20:56:50  *** zooko has quit IRC
479 2016-03-30T20:57:32  *** cryptapus_ is now known as cryptapus
480 2016-03-30T20:59:21  <gmaxwell> Meni's point is really good.
481 2016-03-30T20:59:35  <gmaxwell> I think we _must_ reduce the false positives ASAP, even if it means turning off the functionality.
482 2016-03-30T20:59:46  <gmaxwell> We're destroying the future utility by producing false positives now.
483 2016-03-30T21:00:24  <sipa> i think i can implement meni's proposal easily though
484 2016-03-30T21:01:13  <gmaxwell> we also need the too few blocks warning to go away immediately, not after 4 hours.
485 2016-03-30T21:01:27  <gmaxwell> or it produces another kind of false positive.
486 2016-03-30T21:01:37  <sipa> though, to be correct, it would actually need to check every 4 hours
487 2016-03-30T21:01:43  <sipa> not just every 24 blocks
488 2016-03-30T21:02:14  <sipa> i guess it can just happen based on clock/adjusted timr
489 2016-03-30T21:02:24  <gmaxwell> yes.
490 2016-03-30T21:12:52  *** arubi has quit IRC
491 2016-03-30T21:16:10  *** arubi has joined #bitcoin-core-dev
492 2016-03-30T21:23:27  *** frankenmint has quit IRC
493 2016-03-30T21:29:59  *** frankenmint has joined #bitcoin-core-dev
494 2016-03-30T21:34:27  *** frankenmint has quit IRC
495 2016-03-30T21:46:24  *** zooko has joined #bitcoin-core-dev
496 2016-03-30T21:50:28  <Luke-Jr> hmm, so trying to update BIP 145, but VB doesn't have GBT support yet..
497 2016-03-30T21:50:55  *** frankenmint has joined #bitcoin-core-dev
498 2016-03-30T21:51:27  <gmaxwell> VB?
499 2016-03-30T21:51:37  <Luke-Jr> versionbits
500 2016-03-30T21:53:24  <Luke-Jr> are we still numbering bits 24..31, 16..23, 8..15, 0..7? not entirely clear from BIP 9 :x
501 2016-03-30T21:55:29  <sipa> nVersion is interpreted as an integer; bits in that integer are being set
502 2016-03-30T21:55:46  <sipa> how those map to byte position is a block serialization issue, which is unchanged
503 2016-03-30T21:56:00  <Luke-Jr> so yes
504 2016-03-30T21:56:19  <sipa> i have no idea what you mean
505 2016-03-30T21:57:22  <sipa> nVersion is a little-endian 32-bit signed integer
506 2016-03-30T21:57:30  <sipa> in the block header serialization
507 2016-03-30T21:57:45  <sipa> so the lowest 8 bits map to the first byte
508 2016-03-30T21:58:22  <Lightsword> Luke-Jr, is your issue with it just the format?
509 2016-03-30T21:59:16  <Luke-Jr> Lightsword: ? just clarifying
510 2016-03-30T21:59:27  <Luke-Jr> "The nVersion block header field is to be interpreted as a 32-bit little-endian integer (as present), and bits are selected within this integer as values (1 << N) where N is the bit number." sounds correct?
511 2016-03-30T21:59:47  <sipa> sounds correct to me!
512 2016-03-30T22:00:00  <sipa> indeed, i notice that there is no 2^N anymore in the text
513 2016-03-30T22:01:04  *** ZerownZ has quit IRC
514 2016-03-30T22:01:24  <Luke-Jr> would 2^N be a better way to phrase that?
515 2016-03-30T22:01:32  <sipa> i don't care :)
516 2016-03-30T22:01:54  <Luke-Jr> curiously, I observe that << is more universal than ^ in syntax
517 2016-03-30T22:02:04  <sipa> actually, the code snippet inside bip9 does define the behaviour fully
518 2016-03-30T22:02:14  *** PaulCape_ has joined #bitcoin-core-dev
519 2016-03-30T22:02:14  <gmaxwell> Luke-Jr: the stream operator?
520 2016-03-30T22:02:16  <sipa> though clarifying in the text makes sense..
521 2016-03-30T22:02:19  <Luke-Jr> gmaxwell: nevermind :P
522 2016-03-30T22:02:30  <gmaxwell> (screw you C++)
523 2016-03-30T22:02:42  <Luke-Jr> so to throw in a simply GBT section, how about "bips_supported":[141:28],"bips_required":[] ? does that seem practically complete?
524 2016-03-30T22:02:46  <Luke-Jr> simple*
525 2016-03-30T22:03:00  <Luke-Jr> bip-number:bit-number
526 2016-03-30T22:03:25  <Luke-Jr> where bit-number is true when ACTIVE
527 2016-03-30T22:03:35  *** JeromeLegoupil has quit IRC
528 2016-03-30T22:04:03  <Luke-Jr> … {} instead of [] in JSON
529 2016-03-30T22:04:15  <Lightsword> can’t the stratum server/miner just decode that itself from the version number?
530 2016-03-30T22:04:23  <sipa> Luke-Jr: VB does not identify deployments by bip number
531 2016-03-30T22:04:37  <Luke-Jr> sipa: does it identify them at all?
532 2016-03-30T22:04:51  <Luke-Jr> Lightsword: not without teaching every client about the VB options..
533 2016-03-30T22:05:03  <sipa> Luke-Jr: they get a name in getblockchaininfo
534 2016-03-30T22:05:05  <Luke-Jr> Lightsword: and median time past etc
535 2016-03-30T22:05:16  <Luke-Jr> sipa: that name isn't in the BIP afaict
536 2016-03-30T22:05:22  <Luke-Jr> sipa: shall I add it?
537 2016-03-30T22:05:44  <Luke-Jr> (considering that GBT will need to keep it in the list basically forever, smaller might be best?)
538 2016-03-30T22:05:44  *** PaulCapestany has quit IRC
539 2016-03-30T22:06:12  *** zooko has quit IRC
540 2016-03-30T22:06:13  <Lightsword> Luke-Jr, can’t the miner/stratum server just issue a getblockchaininfo rpc call if it actually needs fork status info?
541 2016-03-30T22:06:25  <Luke-Jr> Lightsword: no such RPC exists in GBT spec
542 2016-03-30T22:06:49  <Lightsword> why does it have to be in GBT?
543 2016-03-30T22:07:23  <Luke-Jr> Lightsword: how else will the client and server negotiate rules?
544 2016-03-30T22:07:41  <sipa> i still think that trying to replicate the consensus rules in the mining client is folly
545 2016-03-30T22:07:42  <Lightsword> it can issue other RPC calls
546 2016-03-30T22:07:53  <sipa> if you want to be able to modify the transaction, run a bitcoind yourself
547 2016-03-30T22:08:03  <Lightsword> IMO best not to try and stuff too much into GBT
548 2016-03-30T22:08:16  <Luke-Jr> sipa: still need to figure out the union of what the local bitcoind and remote are
549 2016-03-30T22:08:18  <sipa> but i don't oppose adding some string list of extra rules that are active to GBT
550 2016-03-30T22:08:36  <sipa> Luke-Jr: no, you tell the bitcoind "this is the coinbase txn i want, give me a block"
551 2016-03-30T22:08:41  <sipa> no merging
552 2016-03-30T22:09:19  <Luke-Jr> that may be a better approach, but it's not how GBT works
553 2016-03-30T22:09:49  <sipa> does anyone in the world actually have code that can even do txn merging over GBT?
554 2016-03-30T22:10:03  <Luke-Jr> there is a fork of libblkmaker that can
555 2016-03-30T22:10:47  <Luke-Jr> in any case, for BIP 145, it needs to know whether BIP 141 is being used or not, to figure out what the sigop definition is
556 2016-03-30T22:11:55  <Lightsword> can’t it infer that?
557 2016-03-30T22:11:57  <Luke-Jr> which is needed even without merging, for eg truncation
558 2016-03-30T22:12:01  <Luke-Jr> Lightsword: infer it how?
559 2016-03-30T22:12:31  <Lightsword> if there’s both a hash and txid and a defaultwitnesscommitment available?
560 2016-03-30T22:13:51  <Luke-Jr> defaultwitnesscommitment is not even part of GBT spec
561 2016-03-30T22:14:05  <sipa> txid/hash are
562 2016-03-30T22:14:19  <Luke-Jr> anyway, inferring it can't reliably be expected to work for other softforks
563 2016-03-30T22:14:23  <Lightsword> Luke-Jr, is defaultwitnesscommitment going to be in the final version of GBT?
564 2016-03-30T22:14:35  <Luke-Jr> Lightsword: no (but maybe in bitcoind's implementation)
565 2016-03-30T22:14:53  <sipa> i'm not opposed to adding some list to the GBT output that lists the active consensus rules
566 2016-03-30T22:15:21  <sipa> maybe BIP145 should specify that every BIP9 softfork should also list a canonical name?
567 2016-03-30T22:15:29  <Luke-Jr> sipa: so should VB add a name, or does BIP number work?
568 2016-03-30T22:15:59  <sipa> the deployment being considered now is called "csv", and it activates the rules specified by bip68, bip112, and bip113
569 2016-03-30T22:16:06  <Luke-Jr> oh
570 2016-03-30T22:16:09  <Luke-Jr> right
571 2016-03-30T22:16:30  <sipa> and they are intentionally being rolled out at once, as the alternative would mean testing way more combinations of their interactions
572 2016-03-30T22:16:49  <Lightsword> Luke-Jr, GBT needs to be overhauled/replaced at some point anyways, not sure if it’s worth putting fork status info in it
573 2016-03-30T22:19:52  <Luke-Jr> # The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. <-- ACK?
574 2016-03-30T22:21:23  *** abritoid has quit IRC
575 2016-03-30T22:27:31  *** fengling has joined #bitcoin-core-dev
576 2016-03-30T22:32:16  *** fengling has quit IRC
577 2016-03-30T22:33:21  *** cryptapus is now known as cryptapus_afk
578 2016-03-30T22:33:47  *** JeromeLegoupil has joined #bitcoin-core-dev
579 2016-03-30T22:36:32  *** d_t has quit IRC
580 2016-03-30T22:37:46  *** AaronvanW has quit IRC
581 2016-03-30T22:38:37  *** arubi has quit IRC
582 2016-03-30T22:41:03  *** frankenmint has quit IRC
583 2016-03-30T22:43:37  *** arubi has joined #bitcoin-core-dev
584 2016-03-30T22:53:27  *** cguida has joined #bitcoin-core-dev
585 2016-03-30T22:57:04  *** p15 has quit IRC
586 2016-03-30T23:01:39  *** ghtdak has quit IRC
587 2016-03-30T23:06:18  <GitHub77> [bitcoin] mruddy opened pull request #7774: RPC: BIP9 version bits related, format version as hex in getblock and getblockheader (master...hexver) https://github.com/bitcoin/bitcoin/pull/7774
588 2016-03-30T23:11:00  *** JeromeLegoupil has quit IRC
589 2016-03-30T23:12:43  *** Guyver2 has quit IRC
590 2016-03-30T23:14:25  <dgenr8> morcos: in 7568 I had to change the test to generate blocks faster than before, to get it to trigger.  so yes, harder to trigger.
591 2016-03-30T23:26:08  *** zooko has joined #bitcoin-core-dev
592 2016-03-30T23:34:38  *** belcher has quit IRC
593 2016-03-30T23:49:41  *** randy-waterhouse has joined #bitcoin-core-dev
594 2016-03-30T23:55:05  *** zooko has quit IRC