12016-03-30T00:02:13 *** harding has quit IRC
22016-03-30T00:12:20 *** harding has joined #bitcoin-core-dev
32016-03-30T00:13:19 *** supasonic has quit IRC
42016-03-30T00:13:50 *** supasonic has joined #bitcoin-core-dev
52016-03-30T00:14:38 *** wangchun_ has quit IRC
62016-03-30T00:17:12 *** wangchun has joined #bitcoin-core-dev
72016-03-30T00:20:26 *** gijensen has joined #bitcoin-core-dev
82016-03-30T00:27:42 *** Giszmo has quit IRC
92016-03-30T00:27:56 *** Giszmo has joined #bitcoin-core-dev
102016-03-30T00:30:58 *** roidster has quit IRC
112016-03-30T00:41:02 *** Ylbam has quit IRC
122016-03-30T00:42:10 *** fengling_ has joined #bitcoin-core-dev
132016-03-30T00:42:40 *** molz has quit IRC
142016-03-30T00:42:56 *** molz has joined #bitcoin-core-dev
152016-03-30T00:43:12 *** arowser_ has quit IRC
162016-03-30T00:44:59 *** dermoth has quit IRC
172016-03-30T00:45:08 *** fengling_ is now known as fengling
182016-03-30T00:58:01 *** Alopex has quit IRC
192016-03-30T00:58:16 *** frankenmint has quit IRC
202016-03-30T00:59:06 *** Alopex has joined #bitcoin-core-dev
212016-03-30T01:05:42 *** p15 has joined #bitcoin-core-dev
222016-03-30T01:19:58 *** belcher has quit IRC
232016-03-30T01:19:58 *** davec has quit IRC
242016-03-30T01:20:24 *** davec has joined #bitcoin-core-dev
252016-03-30T01:27:18 *** AaronvanW has quit IRC
262016-03-30T02:15:16 *** xiangfu has joined #bitcoin-core-dev
272016-03-30T02:22:16 *** fengling has quit IRC
282016-03-30T02:24:56 *** fengling has joined #bitcoin-core-dev
292016-03-30T02:29:18 *** Chris_Stewart_5 has quit IRC
302016-03-30T02:29:56 *** fengling has quit IRC
312016-03-30T02:35:15 *** xiangfu has quit IRC
322016-03-30T02:37:09 *** xiangfu has joined #bitcoin-core-dev
332016-03-30T02:37:10 *** fengling has joined #bitcoin-core-dev
342016-03-30T02:43:26 *** Chris_Stewart_5 has joined #bitcoin-core-dev
352016-03-30T02:55:59 *** Chris_Stewart_5 has quit IRC
362016-03-30T02:57:03 *** xiangfu has quit IRC
372016-03-30T02:58:49 *** xiangfu has joined #bitcoin-core-dev
382016-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
392016-03-30T03:08:12 *** xiangfu has quit IRC
402016-03-30T03:10:21 *** xiangfu has joined #bitcoin-core-dev
412016-03-30T03:15:01 *** Giszmo has quit IRC
422016-03-30T03:22:01 *** achow101 has quit IRC
432016-03-30T03:23:56 *** fengling has quit IRC
442016-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
452016-03-30T03:47:46 *** cryptapus_afk is now known as cryptapus
462016-03-30T03:49:37 *** cryptapus is now known as cryptapus_afk
472016-03-30T04:15:01 *** Alopex has quit IRC
482016-03-30T04:16:06 *** Alopex has joined #bitcoin-core-dev
492016-03-30T04:31:43 *** d_t has joined #bitcoin-core-dev
502016-03-30T04:32:20 *** d_t has joined #bitcoin-core-dev
512016-03-30T05:04:01 *** Alopex has quit IRC
522016-03-30T05:05:06 *** Alopex has joined #bitcoin-core-dev
532016-03-30T05:06:47 *** zooko has joined #bitcoin-core-dev
542016-03-30T05:19:07 *** d_t has quit IRC
552016-03-30T05:20:01 *** Alopex has quit IRC
562016-03-30T05:21:07 *** Alopex has joined #bitcoin-core-dev
572016-03-30T05:29:13 *** supasonic has quit IRC
582016-03-30T05:29:41 *** supasonic has joined #bitcoin-core-dev
592016-03-30T05:59:01 *** Alopex has quit IRC
602016-03-30T06:00:06 *** Alopex has joined #bitcoin-core-dev
612016-03-30T06:14:50 *** Don_John has quit IRC
622016-03-30T06:15:55 *** Thireus has quit IRC
632016-03-30T06:33:19 *** supasonic has quit IRC
642016-03-30T06:33:48 *** supasonic has joined #bitcoin-core-dev
652016-03-30T06:44:39 *** fengling has joined #bitcoin-core-dev
662016-03-30T06:48:01 *** Alopex has quit IRC
672016-03-30T06:49:06 *** Alopex has joined #bitcoin-core-dev
682016-03-30T06:58:20 *** abritoid has joined #bitcoin-core-dev
692016-03-30T07:17:18 *** jtimon has quit IRC
702016-03-30T07:32:22 <GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5131005e5b26...352fd577291e
712016-03-30T07:32:23 <GitHub101> bitcoin/master e1523ce mruddy: P2P: add maxtimeadjustment command line option
722016-03-30T07:32:23 <GitHub101> bitcoin/master 352fd57 Wladimir J. van der Laan: Merge #7573: P2P: add maxtimeadjustment command line option...
732016-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
742016-03-30T07:39:59 *** jarret has quit IRC
752016-03-30T07:42:40 *** xiangfu has quit IRC
762016-03-30T08:00:52 *** AaronvanW has joined #bitcoin-core-dev
772016-03-30T08:00:53 *** AaronvanW has joined #bitcoin-core-dev
782016-03-30T08:03:21 *** zooko has quit IRC
792016-03-30T08:04:28 *** Ylbam has joined #bitcoin-core-dev
802016-03-30T08:04:29 *** zooko has joined #bitcoin-core-dev
812016-03-30T08:08:05 *** MarcoFalke has joined #bitcoin-core-dev
822016-03-30T08:17:34 *** cjcj has quit IRC
832016-03-30T08:29:29 *** Alopex has quit IRC
842016-03-30T08:29:29 <wumpus> cfields: no particular reason, that was just the simplest to do, and every proxy seems to support it
852016-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
862016-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.
872016-03-30T08:33:56 <wumpus> converting it to a string*
882016-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
892016-03-30T08:40:01 *** Thireus has joined #bitcoin-core-dev
902016-03-30T08:40:29 *** randy-waterhouse has joined #bitcoin-core-dev
912016-03-30T08:44:00 *** Arnavion has quit IRC
922016-03-30T08:44:34 *** AtashiCon has quit IRC
932016-03-30T08:50:06 *** Alopex has joined #bitcoin-core-dev
942016-03-30T09:01:08 *** Guyver2 has joined #bitcoin-core-dev
952016-03-30T09:16:56 *** MarcoFalke has quit IRC
962016-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?
972016-03-30T09:26:20 <jonasschnelli> What about using something similar than BIP32 to derive the session id, symmetric cipher key from the ecdh secret?
982016-03-30T09:26:57 <jonasschnelli> SHA512_hmac from both pubkeys (or the requesting pubkey), use the ecdh as SHA512 mac
992016-03-30T09:27:36 <jonasschnelli> wumpus: how do i pass a -g into the gitian build? Just a -g for the ./gbuild command?
1002016-03-30T09:28:06 *** jarret has joined #bitcoin-core-dev
1012016-03-30T09:30:22 <jonasschnelli> or do i need to change the descriptor?
1022016-03-30T09:33:32 <sipa> jonasschnelli: sha512 and ecdh are not macs
1032016-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"), ...
1042016-03-30T09:36:55 <sipa> jonasschnelli: i've been playing with chacha20-poly1305, and it's so fast... ~5 cycles per byte or so
1052016-03-30T09:37:23 <sipa> i don't think i can get aes128-gcm below 80 cycles per byte without using assembly
1062016-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
1072016-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)
1082016-03-30T09:48:45 *** sturles_ is now known as sturles
1092016-03-30T09:49:00 <jonasschnelli> sipa: Thanks. Your HMAC make sense and is already possible with our codebase.
1102016-03-30T09:49:26 <jonasschnelli> sipa: I think I drop the AES-GCM cipersuite in the BIP any only cover chacha20-poly1305
1112016-03-30T09:49:43 <jonasschnelli> (still allows AES256-GCM in a later BIP update or another BIP)
1122016-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
1132016-03-30T10:02:40 <wumpus> jonasschnelli: just change the descriptor
1142016-03-30T10:04:19 *** supasonic has quit IRC
1152016-03-30T10:05:00 <sipa> jonasschnelli: or HMAC-SHA512, which we already have, and can provide larger keys at once
1162016-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
1172016-03-30T10:05:29 <wumpus> I think I just added CPPFLAGS="-g" to CONFIGFLAGS
1182016-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)
1192016-03-30T10:06:40 *** chris2000 has joined #bitcoin-core-dev
1202016-03-30T10:07:17 *** gevs_ has quit IRC
1212016-03-30T10:08:05 *** Arnavion has joined #bitcoin-core-dev
1222016-03-30T10:08:10 *** AtashiCon has joined #bitcoin-core-dev
1232016-03-30T10:12:29 *** chris2000 has quit IRC
1242016-03-30T10:13:30 *** Guyver2 has quit IRC
1252016-03-30T10:14:42 *** cjcj has joined #bitcoin-core-dev
1262016-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
1272016-03-30T10:17:21 <sipa> or https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.chacha20poly1305
1282016-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)
1292016-03-30T10:24:08 *** randy-waterhouse has quit IRC
1302016-03-30T10:28:17 <jonasschnelli> wumpus: thanks. Will try. What speaks again releasing with symbols as long as we are bellow <v1.0?
1312016-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
1322016-03-30T10:29:18 <wumpus> https://github.com/bitcoin/bitcoin/issues/7770 is a better solution I think
1332016-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)
1342016-03-30T10:37:05 <jonasschnelli> Right. 7770 makes sense!
1352016-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 :)
1362016-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
1372016-03-30T10:44:47 <jonasschnelli> Indeed. Lets remove those.
1382016-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
1392016-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
1402016-03-30T10:46:41 <wumpus> probably the first is best, other distributions may want to make their own decision about what to ship
1412016-03-30T10:46:51 <wumpus> OTOH they don't need to get built either
1422016-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.
1432016-03-30T10:50:22 <CodeShark> wumpus: yeah, that's a good idea
1442016-03-30T10:59:36 <CodeShark> is it pretty safe to say CSV will be merged in the next couple weeks?
1452016-03-30T11:00:14 <CodeShark> specifically, https://github.com/bitcoin/bitcoin/pull/7648
1462016-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
1472016-03-30T11:09:56 *** fengling has quit IRC
1482016-03-30T11:19:50 <btcdrak> wumpus: is there any news on the clion licenses?
1492016-03-30T11:32:26 <wumpus> jonasschnelli: ah we can already --disable-bench
1502016-03-30T11:32:32 <wumpus> btcdrak: no, no reply on that yet
1512016-03-30T11:32:53 <sipa> what is clion?
1522016-03-30T11:33:15 <btcdrak> sipa: https://www.jetbrains.com/clion/
1532016-03-30T11:34:06 <btcdrak> sipa: and we're also applying for https://www.jetbrains.com/pycharm/
1542016-03-30T11:35:09 <sipa> hmm, why?
1552016-03-30T11:36:27 <btcdrak> sipa: some of us can't survive with vim :-p
1562016-03-30T11:36:51 <wumpus> it's free for open source projects so why not
1572016-03-30T11:37:03 <wumpus> I'm happy with vim myself
1582016-03-30T11:37:59 <sipa> ah, i see
1592016-03-30T11:38:18 <sipa> it would license anyone to use it for the purpose of developing bitcoin core?
1602016-03-30T11:39:22 <wumpus> I think we get a limited number of licenses, to be distributed over people developing bitcoin core
1612016-03-30T11:39:56 <wumpus> the license allows using it for developing any open source software
1622016-03-30T11:40:09 <btcdrak> sipa: yes. Personally, I love the IDE and debugger features.
1632016-03-30T11:40:33 <btcdrak> API autocomplete in itself is gold for me.
1642016-03-30T11:41:51 *** gevs has joined #bitcoin-core-dev
1652016-03-30T11:41:58 *** laurentmt has joined #bitcoin-core-dev
1662016-03-30T11:42:58 *** chris2000 has joined #bitcoin-core-dev
1672016-03-30T11:43:16 *** cryptapus has joined #bitcoin-core-dev
1682016-03-30T11:43:25 *** laurentmt has quit IRC
1692016-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
1702016-03-30T11:47:03 <btcdrak> sipa: I was an Eclipse fan until I discovered JetBrains. They are remarkably good.
1712016-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.
1722016-03-30T11:48:59 <kinlo> vim ftw :p
1732016-03-30T11:49:23 <sipa> mcedit!
1742016-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
1752016-03-30T11:49:26 * sipa hides
1762016-03-30T11:49:45 <kinlo> sipa: heh, I actually use that aswell, you're an mc user?
1772016-03-30T11:49:59 <sipa> yeah
1782016-03-30T11:50:00 <kinlo> sipa: there aren't enough mc users in this world :)
1792016-03-30T11:50:19 <wumpus> I used 'joe' editor a long time
1802016-03-30T11:50:29 <sipa> i like bluescreens
1812016-03-30T11:50:33 <sipa> ;)
1822016-03-30T11:50:40 <kinlo> haha :)
1832016-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.
1842016-03-30T11:52:10 <btcdrak> Sublime is fun.
1852016-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?
1862016-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 :)
1872016-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??
1882016-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
1892016-03-30T11:58:21 <jl2012> wumpus: just for studying purpose. Logging of fee of each tx, for example, could also be done in ConnectBlock?
1902016-03-30T11:59:05 <jl2012> I'm self-learning C++
1912016-03-30T11:59:07 <wumpus> yes, I think so, it should have all the information available there
1922016-03-30T11:59:17 <jl2012> thanks
1932016-03-30T12:01:03 <wumpus> the fee/block reward computation should also be somewhere areound those parts
1942016-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
1952016-03-30T12:02:34 <wumpus> wow
1962016-03-30T12:02:43 *** Guyver2 has joined #bitcoin-core-dev
1972016-03-30T12:02:54 <wumpus> obviously that's not fast enough and we should do an asm implementation *ducks*
1982016-03-30T12:03:16 *** cryptapus_ has joined #bitcoin-core-dev
1992016-03-30T12:03:59 *** cryptapus_afk has quit IRC
2002016-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
2012016-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!
2022016-03-30T12:06:52 <sipa> on the sending side, that's inevitable, as the checksum goes before the actual data
2032016-03-30T12:07:06 <sipa> but on the receiver side we could in theory compute it while receiving the data, in the network thread
2042016-03-30T12:07:15 <wumpus> sipa: right, for receiving we could certainly use a CHashWriter there
2052016-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
2062016-03-30T12:07:38 <wumpus> for sending all the data is processed at once anyway
2072016-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
2082016-03-30T12:08:28 <wumpus> well the networking thread receives messages entirely right? so it could still do the computation there
2092016-03-30T12:09:01 <sipa> no the networking thread receives whatever recv() returns
2102016-03-30T12:09:16 <sipa> the message handler receives entire messages
2112016-03-30T12:09:17 <wumpus> just leave it blank initially then fill it in before sending it to the wire
2122016-03-30T12:09:21 <wumpus> no, I'm talking about sending
2132016-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
2142016-03-30T12:09:51 *** fengling has joined #bitcoin-core-dev
2152016-03-30T12:10:08 <sipa> that doesn't change the latency, but it can take some load of the message handler thread, indeed
2162016-03-30T12:10:17 <sipa> *off
2172016-03-30T12:10:28 <wumpus> well, sure, there's a good point for adding the checksum at the end
2182016-03-30T12:10:33 <sipa> jonasschnelli: ^
2192016-03-30T12:10:38 <wumpus> and using a cheaper to compute one in the first place
2202016-03-30T12:10:52 <sipa> jonasschnelli: in the encrypted p2p protocol, the authentication tag (produced by poly1305) goes at the end :)
2212016-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
2222016-03-30T12:14:31 <wumpus> (also because of memory usage and buffers)
2232016-03-30T12:15:36 *** fengling has quit IRC
2242016-03-30T12:17:49 <sipa> indeed
2252016-03-30T12:23:10 *** belcher has joined #bitcoin-core-dev
2262016-03-30T12:27:18 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2272016-03-30T12:36:20 *** Giszmo has joined #bitcoin-core-dev
2282016-03-30T12:37:28 *** jannes has joined #bitcoin-core-dev
2292016-03-30T12:39:00 *** Guyver2 has quit IRC
2302016-03-30T12:43:51 * jonasschnelli is back at keyboard and reads backlog
2312016-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?
2322016-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
2332016-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?
2342016-03-30T12:51:41 <sipa> jonasschnelli: yup
2352016-03-30T12:51:54 <jonasschnelli> That is an argument.
2362016-03-30T12:52:02 <sipa> or rather: naive implementation of chacha20+poly1305 is faster than naive implementation of sha256
2372016-03-30T12:52:16 <sipa> both can be made a small multiple faster with SIMD code etc
2382016-03-30T12:52:31 * jonasschnelli is looking over to wumpus asm skills...
2392016-03-30T12:52:40 <sipa> i'm not saying we should do that
2402016-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
2412016-03-30T12:53:15 <jonasschnelli> SIMD?
2422016-03-30T12:53:26 <jonasschnelli> Yes.
2432016-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"?
2442016-03-30T12:55:30 <sipa> jonasschnelli: because the sizes leak privacy
2452016-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
2462016-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?
2472016-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
2482016-03-30T12:58:37 <sipa> jonasschnelli: read the link to openssh's document about it
2492016-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?
2502016-03-30T12:59:35 <jonasschnelli> howevery,... i need to check the openssl docs first.
2512016-03-30T13:00:22 <sipa> OpenSSH, not OpenSSL
2522016-03-30T13:00:41 <jonasschnelli> arg. right.
2532016-03-30T13:00:47 <sipa> jonasschnelli: yes, chacha20 is a stream cipher, so it can encrypt things of any byte size
2542016-03-30T13:00:52 <sipa> without expanding them
2552016-03-30T13:01:09 <sipa> it's essentially just xoring the data with the output of a deterministic PRNG
2562016-03-30T13:01:15 <sipa> which is seeded by the key
2572016-03-30T13:03:17 <jonasschnelli> sipa: what do you think about an approach where each message could contain arbitrary pseudo-random data padded?
2582016-03-30T13:07:39 <sipa> sure
2592016-03-30T13:07:51 <sipa> that's orthogonal, i think
2602016-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.
2612016-03-30T13:09:57 <jonasschnelli> *size
2622016-03-30T13:12:55 *** jtimon has joined #bitcoin-core-dev
2632016-03-30T13:19:26 *** cryptapus has quit IRC
2642016-03-30T13:20:10 *** cryptapus has joined #bitcoin-core-dev
2652016-03-30T13:20:10 *** cryptapus has joined #bitcoin-core-dev
2662016-03-30T13:20:27 *** Luke-Jr has quit IRC
2672016-03-30T13:20:30 *** zmanian__ has quit IRC
2682016-03-30T13:21:02 *** Luke-Jr has joined #bitcoin-core-dev
2692016-03-30T13:23:52 *** zmanian__ has joined #bitcoin-core-dev
2702016-03-30T13:45:05 <GitHub27> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/352fd577291e...60db51dcb200
2712016-03-30T13:45:05 <GitHub27> bitcoin/master 7d5e31a Jonas Schnelli: [Qt] remove trailing output-index from transaction-id...
2722016-03-30T13:45:06 <GitHub27> bitcoin/master 60db51d Wladimir J. van der Laan: Merge #7761: [Qt] remove trailing output-index from transaction-id...
2732016-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
2742016-03-30T13:50:34 *** d_t has joined #bitcoin-core-dev
2752016-03-30T13:52:37 *** Thireus1 has joined #bitcoin-core-dev
2762016-03-30T13:53:16 *** Thireus1 has joined #bitcoin-core-dev
2772016-03-30T13:55:04 *** d_t has quit IRC
2782016-03-30T13:56:13 *** Thireus has quit IRC
2792016-03-30T14:03:04 *** xiangfu has joined #bitcoin-core-dev
2802016-03-30T14:09:54 *** laurentmt has joined #bitcoin-core-dev
2812016-03-30T14:13:32 <instagibbs> is there a way to run individual unit tests instead of all?
2822016-03-30T14:14:49 *** fengling has joined #bitcoin-core-dev
2832016-03-30T14:15:01 *** zooko has quit IRC
2842016-03-30T14:16:10 <sipa> instagibbs: ./test_bitcoin --run_tests=test_name
2852016-03-30T14:16:24 <sipa> for example --run_test=crypto_tests
2862016-03-30T14:16:47 <sipa> (use the name from the TEST_SUITE line
2872016-03-30T14:17:27 <instagibbs> awesome thanks
2882016-03-30T14:19:36 *** fengling has quit IRC
2892016-03-30T14:24:08 *** abritoid has quit IRC
2902016-03-30T14:27:06 *** zooko has joined #bitcoin-core-dev
2912016-03-30T14:28:34 *** laurentmt has quit IRC
2922016-03-30T14:30:12 *** ZerownZ has joined #bitcoin-core-dev
2932016-03-30T14:37:19 *** cryptapus has quit IRC
2942016-03-30T14:37:35 *** cryptapus has joined #bitcoin-core-dev
2952016-03-30T14:46:29 *** zooko has quit IRC
2962016-03-30T14:46:31 *** jouke has quit IRC
2972016-03-30T14:46:32 *** jouke has joined #bitcoin-core-dev
2982016-03-30T14:57:28 *** ZerownZ has quit IRC
2992016-03-30T14:57:42 *** ZerownZ has joined #bitcoin-core-dev
3002016-03-30T15:05:00 <wumpus> instagibbs: you can even do --run-test=suite_name/test_name
3012016-03-30T15:05:38 <sipa> ha!
3022016-03-30T15:05:52 <sipa> i had tried various separators, but not /
3032016-03-30T15:07:39 *** xabbix__ is now known as xabbix
3042016-03-30T15:07:43 *** xabbix has joined #bitcoin-core-dev
3052016-03-30T15:07:46 <wumpus> stumbled on it by accident too
3062016-03-30T15:08:39 <instagibbs> heh, I should probably write this up as PR for the testing doc
3072016-03-30T15:09:11 <wumpus> just grepped it, we somehow already documented this in test/README.md
3082016-03-30T15:09:39 <wumpus> never know
3092016-03-30T15:09:43 <wumpus> knew*
3102016-03-30T15:10:03 <instagibbs> wah, I just read the document, didn't see it?
3112016-03-30T15:10:07 <instagibbs> maybe an old version
3122016-03-30T15:10:12 <wumpus> so many things I forget most of it
3132016-03-30T15:10:52 <instagibbs> oh i see, doc/unit-tests.md doesn't mention this
3142016-03-30T15:11:04 <instagibbs> that's what I found and read
3152016-03-30T15:12:09 <wumpus> may make sense to combine them
3162016-03-30T15:12:40 *** Guyver2 has joined #bitcoin-core-dev
3172016-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?
3182016-03-30T15:16:24 <jonasschnelli> paveljanik: what do you mean with "after"?
3192016-03-30T15:16:48 <paveljanik> get cursor down, Enter
3202016-03-30T15:16:53 <paveljanik> type get, ...
3212016-03-30T15:16:59 <jonasschnelli> Yes. It keeps the command...
3222016-03-30T15:17:01 <jonasschnelli> hmm...
3232016-03-30T15:18:44 <jonasschnelli> until i send it again,... than its gone.
3242016-03-30T15:18:48 <jonasschnelli> Needs fixing...
3252016-03-30T15:18:52 <paveljanik> yup
3262016-03-30T15:19:11 <paveljanik> I'll have a look once I finish the rest.
3272016-03-30T15:19:14 <jonasschnelli> Why I did not recognized that in the first place...
3282016-03-30T15:19:27 <jonasschnelli> paveljanik: super. Thanks. Should be easy to implement.
3292016-03-30T15:19:28 <paveljanik> How can I create immediatelly abandonable transaction so I can test #7707 now?
3302016-03-30T15:19:51 <jonasschnelli> paveljanik: set -walletboardcast=0, create a transaction, restart
3312016-03-30T15:19:58 <jonasschnelli> then you can abandone
3322016-03-30T15:20:03 <jonasschnelli> *abandon
3332016-03-30T15:22:13 <paveljanik> jonasschnelli, restart with -walletboardcast=0 again? Probably yes. Still grayed Abandon transaction in the UI
3342016-03-30T15:22:38 <paveljanik> ah, boardcast :-)
3352016-03-30T15:38:56 *** molz has quit IRC
3362016-03-30T15:39:24 *** molz has joined #bitcoin-core-dev
3372016-03-30T15:47:16 *** chris2000 has quit IRC
3382016-03-30T15:53:03 *** laurentmt has joined #bitcoin-core-dev
3392016-03-30T16:12:35 *** zooko has joined #bitcoin-core-dev
3402016-03-30T16:12:57 <instagibbs> btcdrak, once csv cherry-picks are validated, what's the speed at which a release comes?
3412016-03-30T16:13:18 <instagibbs> s/speed/process
3422016-03-30T16:14:47 *** Guyver2 has quit IRC
3432016-03-30T16:17:55 *** fengling has joined #bitcoin-core-dev
3442016-03-30T16:19:46 *** JeromeLegoupil has joined #bitcoin-core-dev
3452016-03-30T16:20:05 *** abritoid has joined #bitcoin-core-dev
3462016-03-30T16:21:34 *** supasonic has joined #bitcoin-core-dev
3472016-03-30T16:22:56 *** fengling has quit IRC
3482016-03-30T16:28:24 *** zooko has quit IRC
3492016-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.
3502016-03-30T16:40:29 <instagibbs> I suppose since it's directly off of 0.12, it doesn't require a long freeze period, etc
3512016-03-30T16:40:46 <instagibbs> enough time for RCs
3522016-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.
3532016-03-30T16:44:09 *** zooko has joined #bitcoin-core-dev
3542016-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
3552016-03-30T16:49:07 *** JeromeLegoupil has quit IRC
3562016-03-30T16:49:10 *** xiangfu has quit IRC
3572016-03-30T16:49:23 <instagibbs> writeups coming in handy, thanks
3582016-03-30T16:56:48 *** laurentmt has quit IRC
3592016-03-30T17:01:12 <GitHub114> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/60db51dcb200...e8a8f3d4b22b
3602016-03-30T17:01:13 <GitHub114> bitcoin/master 65751a3 Pieter Wuille: Add CHECKSEQUENCEVERIFY softfork through BIP9
3612016-03-30T17:01:13 <GitHub114> bitcoin/master 478fba6 BtcDrak: Soft fork logic for BIP113
3622016-03-30T17:01:14 <GitHub114> bitcoin/master 02c2435 BtcDrak: Soft fork logic for BIP68
3632016-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
3642016-03-30T17:03:44 *** laurentmt has joined #bitcoin-core-dev
3652016-03-30T17:04:36 <btcdrak> omg boat party!
3662016-03-30T17:04:36 <Ylbam> \o/
3672016-03-30T17:07:17 <wumpus> o/ \o
3682016-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.
3692016-03-30T17:11:03 *** molly has joined #bitcoin-core-dev
3702016-03-30T17:12:16 *** ZerownZ_ has joined #bitcoin-core-dev
3712016-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.
3722016-03-30T17:13:59 <sipa> it was merged for BIP34
3732016-03-30T17:14:11 <sipa> not for later ones
3742016-03-30T17:14:34 *** molz has quit IRC
3752016-03-30T17:14:49 <wumpus> ok
3762016-03-30T17:15:42 *** ZerownZ has quit IRC
3772016-03-30T17:15:42 <wumpus> in any case there is no pressing reason why they couldn't go
3782016-03-30T17:15:50 *** ZerownZ_ is now known as ZerownZ
3792016-03-30T17:20:16 <ZerownZ> hahaha
3802016-03-30T17:36:13 *** Guyver2 has joined #bitcoin-core-dev
3812016-03-30T17:40:05 <cfields> wumpus: thanks for the explanation, that was very helpful
3822016-03-30T17:42:02 *** JeromeLegoupil has joined #bitcoin-core-dev
3832016-03-30T17:46:24 *** d_t has joined #bitcoin-core-dev
3842016-03-30T17:50:14 *** neha has joined #bitcoin-core-dev
3852016-03-30T17:52:41 *** abritoid has quit IRC
3862016-03-30T17:52:57 *** belcher has quit IRC
3872016-03-30T17:53:49 *** moli has joined #bitcoin-core-dev
3882016-03-30T17:54:38 *** belcher has joined #bitcoin-core-dev
3892016-03-30T17:55:50 *** molly has quit IRC
3902016-03-30T17:56:17 *** zooko has quit IRC
3912016-03-30T18:04:46 <GitHub95> [bitcoin] laanwj pushed 2 new commits to 0.11: https://github.com/bitcoin/bitcoin/compare/0ba7020cf6f9...c251f46bea8f
3922016-03-30T18:04:46 <GitHub95> bitcoin/0.11 12943ad Wladimir J. van der Laan: bump version to 0.11.3...
3932016-03-30T18:04:46 <GitHub95> bitcoin/0.11 c251f46 BtcDrak: Mark p2p alert system as deprecated....
3942016-03-30T18:07:55 *** JeromeLegoupil has quit IRC
3952016-03-30T18:13:09 *** moli has quit IRC
3962016-03-30T18:14:48 *** JeromeLegoupil has joined #bitcoin-core-dev
3972016-03-30T18:14:49 <GitHub76> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/ba80ceef59bdfb7e0a42da4df81335698047fbce
3982016-03-30T18:14:49 <GitHub76> bitcoin/0.12 ba80cee Wladimir J. van der Laan: bump version to 0.12.1
3992016-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
4002016-03-30T18:15:14 <morcos> s/much/enough/
4012016-03-30T18:17:07 <btcdrak> Trolling for review of https://github.com/bitcoin/bitcoin/pull/7707 - we'd like this for 0.12.1
4022016-03-30T18:17:37 <btcdrak> trolling for review/commentary on https://github.com/bitcoin/bitcoin/pull/7568
4032016-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
4042016-03-30T18:18:58 <morcos> btcdrak: we don't want 7707
4052016-03-30T18:19:09 <morcos> we already got the commit we wanted, jonas broke it out separately
4062016-03-30T18:19:17 <btcdrak> morcos: ah
4072016-03-30T18:19:35 <btcdrak> oh right I cant read "#7707 RPC-only (commit 42e945d79fd54ab11ad48978910b42d10c1c7cf8), which is 1 line of code."
4082016-03-30T18:20:16 <btcdrak> yeah, so #7568 wont happen in time. We should consider disabling the warnings instead.
4092016-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
4102016-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.
4112016-03-30T18:21:09 *** fengling has joined #bitcoin-core-dev
4122016-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
4132016-03-30T18:21:34 <btcdrak> morcos: not on our timeline.
4142016-03-30T18:23:28 *** zooko has joined #bitcoin-core-dev
4152016-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.
4162016-03-30T18:23:53 *** moli has joined #bitcoin-core-dev
4172016-03-30T18:23:58 <morcos> i know!
4182016-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.
4192016-03-30T18:25:40 *** zooko has quit IRC
4202016-03-30T18:25:56 *** fengling has quit IRC
4212016-03-30T18:26:06 *** abritoid has joined #bitcoin-core-dev
4222016-03-30T18:26:19 *** zooko has joined #bitcoin-core-dev
4232016-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. :)
4242016-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
4252016-03-30T18:27:01 *** moli has quit IRC
4262016-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
4272016-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
4282016-03-30T18:29:46 <wumpus> but sure, even if sipa were to look at it for 10 minutes that's better than nothing :D
4292016-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
4302016-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.
4312016-03-30T18:32:40 <wumpus> yes you could say that the current handling is so bad that everything is an improvement :)
4322016-03-30T18:33:09 <morcos> right, all we have to do is be confident it will alert LESS often, and its an improvement
4332016-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
4342016-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
4352016-03-30T18:34:11 <wumpus> yes, to be honest I'd rather disable the code until we get it right
4362016-03-30T18:34:27 <btcdrak> wumpus: +1
4372016-03-30T18:34:43 <wumpus> at least on major releases, in master we still have quite some time until a release
4382016-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
4392016-03-30T18:35:07 <wumpus> that sounds like the responsible thing to do
4402016-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
4412016-03-30T18:35:26 <morcos> disabling sounds like its also bad to me, thats still a code change to be merged
4422016-03-30T18:35:48 <btcdrak> disabling is easy code though.
4432016-03-30T18:36:37 <wumpus> it is a very predictable and safe change
4442016-03-30T18:39:27 *** Guyver2 has quit IRC
4452016-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
4462016-03-30T18:40:40 *** moli has joined #bitcoin-core-dev
4472016-03-30T18:40:50 *** Guyver2 has joined #bitcoin-core-dev
4482016-03-30T18:41:18 <paveljanik> who will win #7777? ;-)
4492016-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
4502016-03-30T18:42:27 <morcos> roger. paging sipa. :) ok got to run
4512016-03-30T18:43:15 <wumpus> yes, gtg in a bit too. later!
4522016-03-30T18:43:55 *** moli has quit IRC
4532016-03-30T18:51:36 *** moli has joined #bitcoin-core-dev
4542016-03-30T18:53:15 *** frankenmint has joined #bitcoin-core-dev
4552016-03-30T18:54:13 *** achow101 has joined #bitcoin-core-dev
4562016-03-30T18:57:07 *** frankenmint has quit IRC
4572016-03-30T19:03:59 *** frankenmint has joined #bitcoin-core-dev
4582016-03-30T19:05:18 *** frankenmint has quit IRC
4592016-03-30T19:05:23 *** frankenm_ has joined #bitcoin-core-dev
4602016-03-30T19:06:22 *** frankenmint has joined #bitcoin-core-dev
4612016-03-30T19:44:31 *** achow101 has quit IRC
4622016-03-30T19:47:38 *** achow101 has joined #bitcoin-core-dev
4632016-03-30T19:49:19 *** laurentmt has quit IRC
4642016-03-30T19:55:55 *** molz has joined #bitcoin-core-dev
4652016-03-30T19:56:36 *** jannes has quit IRC
4662016-03-30T19:58:52 *** moli has quit IRC
4672016-03-30T20:00:08 *** molly has joined #bitcoin-core-dev
4682016-03-30T20:02:37 *** molz has quit IRC
4692016-03-30T20:04:49 *** ryan-c has quit IRC
4702016-03-30T20:05:11 *** zooko has quit IRC
4712016-03-30T20:09:16 *** ryan-c has joined #bitcoin-core-dev
4722016-03-30T20:15:14 *** zooko has joined #bitcoin-core-dev
4732016-03-30T20:15:51 *** cryptapus has quit IRC
4742016-03-30T20:24:26 *** fengling has joined #bitcoin-core-dev
4752016-03-30T20:28:42 *** Don_John has joined #bitcoin-core-dev
4762016-03-30T20:29:16 *** fengling has quit IRC
4772016-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
4782016-03-30T20:56:50 *** zooko has quit IRC
4792016-03-30T20:57:32 *** cryptapus_ is now known as cryptapus
4802016-03-30T20:59:21 <gmaxwell> Meni's point is really good.
4812016-03-30T20:59:35 <gmaxwell> I think we _must_ reduce the false positives ASAP, even if it means turning off the functionality.
4822016-03-30T20:59:46 <gmaxwell> We're destroying the future utility by producing false positives now.
4832016-03-30T21:00:24 <sipa> i think i can implement meni's proposal easily though
4842016-03-30T21:01:13 <gmaxwell> we also need the too few blocks warning to go away immediately, not after 4 hours.
4852016-03-30T21:01:27 <gmaxwell> or it produces another kind of false positive.
4862016-03-30T21:01:37 <sipa> though, to be correct, it would actually need to check every 4 hours
4872016-03-30T21:01:43 <sipa> not just every 24 blocks
4882016-03-30T21:02:14 <sipa> i guess it can just happen based on clock/adjusted timr
4892016-03-30T21:02:24 <gmaxwell> yes.
4902016-03-30T21:12:52 *** arubi has quit IRC
4912016-03-30T21:16:10 *** arubi has joined #bitcoin-core-dev
4922016-03-30T21:23:27 *** frankenmint has quit IRC
4932016-03-30T21:29:59 *** frankenmint has joined #bitcoin-core-dev
4942016-03-30T21:34:27 *** frankenmint has quit IRC
4952016-03-30T21:46:24 *** zooko has joined #bitcoin-core-dev
4962016-03-30T21:50:28 <Luke-Jr> hmm, so trying to update BIP 145, but VB doesn't have GBT support yet..
4972016-03-30T21:50:55 *** frankenmint has joined #bitcoin-core-dev
4982016-03-30T21:51:27 <gmaxwell> VB?
4992016-03-30T21:51:37 <Luke-Jr> versionbits
5002016-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
5012016-03-30T21:55:29 <sipa> nVersion is interpreted as an integer; bits in that integer are being set
5022016-03-30T21:55:46 <sipa> how those map to byte position is a block serialization issue, which is unchanged
5032016-03-30T21:56:00 <Luke-Jr> so yes
5042016-03-30T21:56:19 <sipa> i have no idea what you mean
5052016-03-30T21:57:22 <sipa> nVersion is a little-endian 32-bit signed integer
5062016-03-30T21:57:30 <sipa> in the block header serialization
5072016-03-30T21:57:45 <sipa> so the lowest 8 bits map to the first byte
5082016-03-30T21:58:22 <Lightsword> Luke-Jr, is your issue with it just the format?
5092016-03-30T21:59:16 <Luke-Jr> Lightsword: ? just clarifying
5102016-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?
5112016-03-30T21:59:47 <sipa> sounds correct to me!
5122016-03-30T22:00:00 <sipa> indeed, i notice that there is no 2^N anymore in the text
5132016-03-30T22:01:04 *** ZerownZ has quit IRC
5142016-03-30T22:01:24 <Luke-Jr> would 2^N be a better way to phrase that?
5152016-03-30T22:01:32 <sipa> i don't care :)
5162016-03-30T22:01:54 <Luke-Jr> curiously, I observe that << is more universal than ^ in syntax
5172016-03-30T22:02:04 <sipa> actually, the code snippet inside bip9 does define the behaviour fully
5182016-03-30T22:02:14 *** PaulCape_ has joined #bitcoin-core-dev
5192016-03-30T22:02:14 <gmaxwell> Luke-Jr: the stream operator?
5202016-03-30T22:02:16 <sipa> though clarifying in the text makes sense..
5212016-03-30T22:02:19 <Luke-Jr> gmaxwell: nevermind :P
5222016-03-30T22:02:30 <gmaxwell> (screw you C++)
5232016-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?
5242016-03-30T22:02:46 <Luke-Jr> simple*
5252016-03-30T22:03:00 <Luke-Jr> bip-number:bit-number
5262016-03-30T22:03:25 <Luke-Jr> where bit-number is true when ACTIVE
5272016-03-30T22:03:35 *** JeromeLegoupil has quit IRC
5282016-03-30T22:04:03 <Luke-Jr> ⦠{} instead of [] in JSON
5292016-03-30T22:04:15 <Lightsword> canât the stratum server/miner just decode that itself from the version number?
5302016-03-30T22:04:23 <sipa> Luke-Jr: VB does not identify deployments by bip number
5312016-03-30T22:04:37 <Luke-Jr> sipa: does it identify them at all?
5322016-03-30T22:04:51 <Luke-Jr> Lightsword: not without teaching every client about the VB options..
5332016-03-30T22:05:03 <sipa> Luke-Jr: they get a name in getblockchaininfo
5342016-03-30T22:05:05 <Luke-Jr> Lightsword: and median time past etc
5352016-03-30T22:05:16 <Luke-Jr> sipa: that name isn't in the BIP afaict
5362016-03-30T22:05:22 <Luke-Jr> sipa: shall I add it?
5372016-03-30T22:05:44 <Luke-Jr> (considering that GBT will need to keep it in the list basically forever, smaller might be best?)
5382016-03-30T22:05:44 *** PaulCapestany has quit IRC
5392016-03-30T22:06:12 *** zooko has quit IRC
5402016-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?
5412016-03-30T22:06:25 <Luke-Jr> Lightsword: no such RPC exists in GBT spec
5422016-03-30T22:06:49 <Lightsword> why does it have to be in GBT?
5432016-03-30T22:07:23 <Luke-Jr> Lightsword: how else will the client and server negotiate rules?
5442016-03-30T22:07:41 <sipa> i still think that trying to replicate the consensus rules in the mining client is folly
5452016-03-30T22:07:42 <Lightsword> it can issue other RPC calls
5462016-03-30T22:07:53 <sipa> if you want to be able to modify the transaction, run a bitcoind yourself
5472016-03-30T22:08:03 <Lightsword> IMO best not to try and stuff too much into GBT
5482016-03-30T22:08:16 <Luke-Jr> sipa: still need to figure out the union of what the local bitcoind and remote are
5492016-03-30T22:08:18 <sipa> but i don't oppose adding some string list of extra rules that are active to GBT
5502016-03-30T22:08:36 <sipa> Luke-Jr: no, you tell the bitcoind "this is the coinbase txn i want, give me a block"
5512016-03-30T22:08:41 <sipa> no merging
5522016-03-30T22:09:19 <Luke-Jr> that may be a better approach, but it's not how GBT works
5532016-03-30T22:09:49 <sipa> does anyone in the world actually have code that can even do txn merging over GBT?
5542016-03-30T22:10:03 <Luke-Jr> there is a fork of libblkmaker that can
5552016-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
5562016-03-30T22:11:55 <Lightsword> canât it infer that?
5572016-03-30T22:11:57 <Luke-Jr> which is needed even without merging, for eg truncation
5582016-03-30T22:12:01 <Luke-Jr> Lightsword: infer it how?
5592016-03-30T22:12:31 <Lightsword> if thereâs both a hash and txid and a defaultwitnesscommitment available?
5602016-03-30T22:13:51 <Luke-Jr> defaultwitnesscommitment is not even part of GBT spec
5612016-03-30T22:14:05 <sipa> txid/hash are
5622016-03-30T22:14:19 <Luke-Jr> anyway, inferring it can't reliably be expected to work for other softforks
5632016-03-30T22:14:23 <Lightsword> Luke-Jr, is defaultwitnesscommitment going to be in the final version of GBT?
5642016-03-30T22:14:35 <Luke-Jr> Lightsword: no (but maybe in bitcoind's implementation)
5652016-03-30T22:14:53 <sipa> i'm not opposed to adding some list to the GBT output that lists the active consensus rules
5662016-03-30T22:15:21 <sipa> maybe BIP145 should specify that every BIP9 softfork should also list a canonical name?
5672016-03-30T22:15:29 <Luke-Jr> sipa: so should VB add a name, or does BIP number work?
5682016-03-30T22:15:59 <sipa> the deployment being considered now is called "csv", and it activates the rules specified by bip68, bip112, and bip113
5692016-03-30T22:16:06 <Luke-Jr> oh
5702016-03-30T22:16:09 <Luke-Jr> right
5712016-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
5722016-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
5732016-03-30T22:19:52 <Luke-Jr> # The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. <-- ACK?
5742016-03-30T22:21:23 *** abritoid has quit IRC
5752016-03-30T22:27:31 *** fengling has joined #bitcoin-core-dev
5762016-03-30T22:32:16 *** fengling has quit IRC
5772016-03-30T22:33:21 *** cryptapus is now known as cryptapus_afk
5782016-03-30T22:33:47 *** JeromeLegoupil has joined #bitcoin-core-dev
5792016-03-30T22:36:32 *** d_t has quit IRC
5802016-03-30T22:37:46 *** AaronvanW has quit IRC
5812016-03-30T22:38:37 *** arubi has quit IRC
5822016-03-30T22:41:03 *** frankenmint has quit IRC
5832016-03-30T22:43:37 *** arubi has joined #bitcoin-core-dev
5842016-03-30T22:53:27 *** cguida has joined #bitcoin-core-dev
5852016-03-30T22:57:04 *** p15 has quit IRC
5862016-03-30T23:01:39 *** ghtdak has quit IRC
5872016-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
5882016-03-30T23:11:00 *** JeromeLegoupil has quit IRC
5892016-03-30T23:12:43 *** Guyver2 has quit IRC
5902016-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.
5912016-03-30T23:26:08 *** zooko has joined #bitcoin-core-dev
5922016-03-30T23:34:38 *** belcher has quit IRC
5932016-03-30T23:49:41 *** randy-waterhouse has joined #bitcoin-core-dev
5942016-03-30T23:55:05 *** zooko has quit IRC