--- Day changed Wed Mar 30 2016
00:17 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]
00:32 < GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5131005e5b26...352fd577291e
00:32 < GitHub101> bitcoin/master e1523ce mruddy: P2P: add maxtimeadjustment command line option
00:32 < GitHub101> bitcoin/master 352fd57 Wladimir J. van der Laan: Merge #7573: P2P: add maxtimeadjustment command line option...
00:32 < GitHub196> [bitcoin] laanwj closed pull request #7573: P2P: add maxtimeadjustment command line option (master...trust-system-clock) https://github.com/bitcoin/bitcoin/pull/7573
00:40 -!- jarret [~jarret@162.216.46.119] has quit [Ping timeout: 244 seconds]
00:42 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Remote host closed the connection]
01:00 -!- AaronvanW [~ewout@202pc230.sshunet.nl] has joined #bitcoin-core-dev
01:00 -!- AaronvanW [~ewout@202pc230.sshunet.nl] has quit [Changing host]
01:00 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:03 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer]
01:04 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kofsoblsqwiqihcv] has joined #bitcoin-core-dev
01:04 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
01:08 -!- MarcoFalke [05c7b6cb@gateway/web/cgi-irc/kiwiirc.com/ip.5.199.182.203] has joined #bitcoin-core-dev
01:17 -!- cjcj [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [Ping timeout: 250 seconds]
01:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Ping timeout: 250 seconds]
01:29 < wumpus> cfields: no particular reason, that was just the simplest to do, and every proxy seems to support it
01:32 < wumpus> cfields: really don't want DNS leakage so we don't aim to support proxies that cannot support connecting by name
01:33 < 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.
01:33 < wumpus> converting it to a string*
01:35 < 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
01:40 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
01:40 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
01:44 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Ping timeout: 246 seconds]
01:44 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Ping timeout: 240 seconds]
01:50 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
02:01 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
02:16 -!- MarcoFalke [05c7b6cb@gateway/web/cgi-irc/kiwiirc.com/ip.5.199.182.203] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
02:25 < 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?
02:26 < jonasschnelli> What about using something similar than BIP32 to derive the session id, symmetric cipher key from the ecdh secret?
02:26 < jonasschnelli> SHA512_hmac from both pubkeys (or the requesting pubkey), use the ecdh as SHA512 mac
02:27 < jonasschnelli> wumpus: how do i pass a -g into the gitian build? Just a -g for the ./gbuild command?
02:28 -!- jarret [~jarret@162.216.46.119] has joined #bitcoin-core-dev
02:30 < jonasschnelli> or do i need to change the descriptor?
02:33 < sipa> jonasschnelli: sha512 and ecdh are not macs
02:35 < 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"), ...
02:36 < sipa> jonasschnelli: i've been playing with chacha20-poly1305, and it's so fast... ~5 cycles per byte or so
02:37 < sipa> i don't think i can get aes128-gcm below 80 cycles per byte without using assembly
02:38 < sipa> in theory, aes128-gcm, on very modern hardware should be doable in ~1 cycle per byte, with aes-ni and carryless multiplication instructions
02:41 < 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)
02:48 -!- sturles_ is now known as sturles
02:49 < jonasschnelli> sipa: Thanks. Your HMAC make sense and is already possible with our codebase.
02:49 < jonasschnelli> sipa: I think I drop the AES-GCM cipersuite  in the BIP any only cover chacha20-poly1305
02:49 < jonasschnelli> (still allows AES256-GCM in a later BIP update or another BIP)
02:57 < sipa> our current sha256 implementation is around 16 c/b, so using chacha20-poly1305 would actually be faster than our current checksumming
03:02 < wumpus> jonasschnelli: just change the descriptor
03:04 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 248 seconds]
03:05 < sipa> jonasschnelli: or HMAC-SHA512, which we already have, and can provide larger keys at once
03:05 < 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
03:05 < wumpus> I think I just added CPPFLAGS="-g" to CONFIGFLAGS
03:05 < wumpus> (which is a hack, but CPPFLAGS are passed to both g++ and gcc, without overriding the current C*FLAGS optimizations etc)
03:06 -!- chris2000 [~chris2000@customer-static-225-38.wobline-ip.de] has joined #bitcoin-core-dev
03:07 -!- gevs_ [~greg@ip-83-134-233-91.dsl.scarlet.be] has quit [Ping timeout: 260 seconds]
03:08 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
03:08 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
03:12 -!- chris2000 [~chris2000@customer-static-225-38.wobline-ip.de] has quit [Remote host closed the connection]
03:13 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
03:14 -!- cjcj [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-core-dev
03:15 < sipa> jonasschnelli: perhaps it makes sense to refer to this document: https://github.com/jhcloos/openssh-chacha-poly1305/blob/master/PROTOCOL.chacha20poly1305
03:17 < sipa> or https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.chacha20poly1305
03:17 < 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)
03:24 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
03:28 < jonasschnelli> wumpus: thanks. Will try. What speaks again releasing with symbols as long as we are bellow <v1.0?
03:28 < wumpus> jonasschnelli: it'd waste a lot of space - remember we're static linking every executable, and have quite a lot of executables
03:29 < wumpus> https://github.com/bitcoin/bitcoin/issues/7770 is a better solution I think
03:29 < 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)
03:37 < jonasschnelli> Right. 7770 makes sense!
03:41 < 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 :)
03:43 < 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
03:44 < jonasschnelli> Indeed. Lets remove those.
03:45 < 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
03:46 < 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
03:46 < wumpus> probably the first is best, other distributions may want to make their own decision about what to ship
03:46 < wumpus> OTOH they don't need to get built either
03:47 < 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.
03:50 < CodeShark> wumpus: yeah, that's a good idea
03:59 < CodeShark> is it pretty safe to say CSV will be merged in the next couple weeks?
04:00 < CodeShark> specifically, https://github.com/bitcoin/bitcoin/pull/7648
04:06 < btcdrak> CodeShark: I would hope it gets merged this week. It's a very trivial PR with a ton of tested ACKs already
04:09 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
04:19 < btcdrak> wumpus: is there any news on the clion licenses?
04:32 < wumpus> jonasschnelli: ah we can already --disable-bench
04:32 < wumpus> btcdrak: no, no reply on that yet
04:32 < sipa> what is clion?
04:33 < btcdrak> sipa: https://www.jetbrains.com/clion/
04:34 < btcdrak> sipa: and we're also applying for https://www.jetbrains.com/pycharm/
04:35 < sipa> hmm, why?
04:36 < btcdrak> sipa: some of us can't survive with vim :-p 
04:36 < wumpus> it's free for open source projects so why not
04:37 < wumpus> I'm happy with vim myself
04:38 < sipa> ah, i see
04:38 < sipa> it would license anyone to use it for the purpose of developing bitcoin core?
04:39 < wumpus> I think we get a limited number of licenses, to be distributed over people developing bitcoin core
04:39 < wumpus> the license allows using it for developing any open source software
04:40 < btcdrak> sipa: yes. Personally, I love the IDE and debugger features.
04:40 < btcdrak> API autocomplete in itself is gold for me.
04:41 -!- gevs [~greg@ip-83-134-234-147.dsl.scarlet.be] has joined #bitcoin-core-dev
04:41 -!- gevs [~greg@ip-83-134-234-147.dsl.scarlet.be] has quit [Changing host]
04:41 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
04:41 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
04:42 -!- chris2000 [~chris2000@customer-static-225-38.wobline-ip.de] has joined #bitcoin-core-dev
04:43 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
04:43 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
04:46 < 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
04:47 < btcdrak> sipa: I was an Eclipse fan until I discovered JetBrains. They are remarkably good.
04:48 < 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.
04:49 < kinlo> vim ftw :p
04:49 < sipa> mcedit!
04:49 < wumpus> it's like an OS in itself. I'm old-fashioned and just like opening the editor on separate files
04:49  * sipa hides
04:49 < kinlo> sipa: heh, I actually use that aswell, you're an mc user?
04:50 < sipa> yeah
04:50 < kinlo> sipa: there aren't enough mc users in this world :)
04:50 < wumpus> I used 'joe' editor a long time
04:50 < sipa> i like bluescreens
04:50 < sipa> ;)
04:50 < kinlo> haha :)
04:52 < 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.
04:52 < btcdrak> Sublime is fun.
04:53 < 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?
04:54 < 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 :)
04:55 < 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??
04:57 < 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
04:58 < jl2012> wumpus: just for studying purpose. Logging of fee of each tx, for example, could also be done in ConnectBlock?
04:59 < jl2012> I'm self-learning C++
04:59 < wumpus> yes, I think so, it should have all the information available there
04:59 < jl2012> thanks
05:01 < wumpus> the fee/block reward computation should also be somewhere areound those parts
05:02 < 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
05:02 < wumpus> wow
05:02 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
05:02 < wumpus> obviously that's not fast enough and we should do an asm implementation *ducks*
05:03 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
05:04 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
05:04 < sipa> AES-NI + CLMUL based implementations can do AES-GCM in 1 c/b; without those, 22 c/b, without SIMD, 35 c/b
05:06 < 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!
05:06 < sipa> on the sending side, that's inevitable, as the checksum goes before the actual data
05:07 < sipa> but on the receiver side we could in theory compute it while receiving the data, in the network thread
05:07 < wumpus> sipa: right, for receiving we could certainly use a CHashWriter there
05:07 < sipa> not that it matters much for 1 MB messages, but it does indicate that there is a downside to having large p2p messages
05:07 < wumpus> for sending all the data is processed at once anyway
05:08 < 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
05:08 < wumpus> well the networking thread receives messages entirely right? so it could still do the computation there
05:09 < sipa> no the networking thread receives whatever recv() returns
05:09 < sipa> the message handler receives entire messages
05:09 < wumpus> just leave it blank initially then fill it in before sending it to the wire
05:09 < wumpus> no, I'm talking about sending
05:09 < wumpus> messages could be queued up without checksum, then the network thread fills in the checksum before actually dispatching them on the wire
05:09 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
05:10 < sipa> that doesn't change the latency, but it can take some load of the message handler thread, indeed
05:10 < sipa> *off
05:10 < wumpus> well, sure, there's a good point for adding the checksum at the end
05:10 < sipa> jonasschnelli: ^
05:10 < wumpus> and using a cheaper to compute one in the first place
05:10 < sipa> jonasschnelli: in the encrypted p2p protocol, the authentication tag (produced by poly1305) goes at the end :)
05:14 < 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
05:14 < wumpus> (also because of memory usage and buffers)
05:15 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
05:17 < sipa> indeed
05:23 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
05:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:36 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
05:37 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
05:39 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
05:43  * jonasschnelli is back at keyboard and reads backlog
05:48 < 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?
05:49 < 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
05:51 < jonasschnelli> sipa: so using poly1305 as mac (hash replacement) would make the transmission process faster because chacha20+poly1305 requires less cycles then sha256?
05:51 < sipa> jonasschnelli: yup
05:51 < jonasschnelli> That is an argument.
05:52 < sipa> or rather: naive implementation of chacha20+poly1305 is faster than naive implementation of sha256
05:52 < sipa> both can be made a small multiple faster with SIMD code etc
05:52  * jonasschnelli is looking over to wumpus asm skills... 
05:52 < sipa> i'm not saying we should do that
05:53 < 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
05:53 < jonasschnelli> SIMD?
05:53 < jonasschnelli> Yes.
05:54 < 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"?
05:55 < sipa> jonasschnelli: because the sizes leak privacy
05:56 < 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
05:56 < 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?
05:58 < sipa> jonasschnelli: sure, stream analysis may still leak information, but leaking sizes is just giving away potentially private information without reason
05:58 < sipa> jonasschnelli: read the link to openssh's document about it
05:59 < 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?
05:59 < jonasschnelli> howevery,... i need to check the openssl docs first.
06:00 < sipa> OpenSSH, not OpenSSL
06:00 < jonasschnelli> arg. right.
06:00 < sipa> jonasschnelli: yes, chacha20 is a stream cipher, so it can encrypt things of any byte size
06:00 < sipa> without expanding them
06:01 < sipa> it's essentially just xoring the data with the output of a deterministic PRNG
06:01 < sipa> which is seeded by the key
06:03 < jonasschnelli> sipa: what do you think about an approach where each message could contain arbitrary pseudo-random data padded?
06:07 < sipa> sure
06:07 < sipa> that's orthogonal, i think
06:09 < 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.
06:09 < jonasschnelli> *size
06:12 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
06:19 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Quit: Conversation terminated!]
06:20 -!- cryptapus [~cyptapus@66.119.84.15] has joined #bitcoin-core-dev
06:20 -!- cryptapus [~cyptapus@66.119.84.15] has quit [Changing host]
06:20 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
06:20 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
06:20 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-vjccyxmljydosypa] has quit [Ping timeout: 248 seconds]
06:21 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
06:23 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-ewsxkjvafvmqgppd] has joined #bitcoin-core-dev
06:45 < GitHub27> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/352fd577291e...60db51dcb200
06:45 < GitHub27> bitcoin/master 7d5e31a Jonas Schnelli: [Qt] remove trailing output-index from transaction-id...
06:45 < GitHub27> bitcoin/master 60db51d Wladimir J. van der Laan: Merge #7761: [Qt] remove trailing output-index from transaction-id...
06:45 < 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
06:50 -!- d_t [~textual@212.144.253.35] has joined #bitcoin-core-dev
06:52 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
06:52 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
06:53 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
06:55 -!- d_t [~textual@212.144.253.35] has quit [Ping timeout: 240 seconds]
06:56 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 250 seconds]
07:03 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
07:09 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
07:13 < instagibbs> is there a way to run individual unit tests instead of all?
07:14 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
07:15 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Ping timeout: 252 seconds]
07:16 < sipa> instagibbs: ./test_bitcoin --run_tests=test_name
07:16 < sipa> for example --run_test=crypto_tests
07:16 < sipa> (use the name from the TEST_SUITE line
07:17 < instagibbs> awesome thanks
07:19 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
07:24 -!- abritoid [~abritoid@mail.abrites.com] has quit [Quit: Zzz…]
07:27 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
07:28 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
07:30 -!- ZerownZ [AdiIRC@187.105.90.203] has joined #bitcoin-core-dev
07:37 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Quit: Conversation terminated!]
07:37 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
07:46 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 250 seconds]
07:46 -!- jouke [~jouke@a83-163-42-163.adsl.xs4all.nl] has quit [Changing host]
07:46 -!- jouke [~jouke@unaffiliated/komkommer] has joined #bitcoin-core-dev
07:57 -!- ZerownZ [AdiIRC@187.105.90.203] has quit [Excess Flood]
07:57 -!- ZerownZ [AdiIRC@187.105.90.203] has joined #bitcoin-core-dev
08:05 < wumpus> instagibbs: you can even do --run-test=suite_name/test_name
08:05 < sipa> ha!
08:05 < sipa> i had tried various separators, but not /
08:07 -!- xabbix__ is now known as xabbix
08:07 -!- xabbix [~xabbix@bzq-79-176-85-172.red.bezeqint.net] has quit [Changing host]
08:07 -!- xabbix [~xabbix@unaffiliated/xabbix] has joined #bitcoin-core-dev
08:07 < wumpus> stumbled on it by accident too
08:08 < instagibbs> heh, I should probably write this up as PR for the testing doc
08:09 < wumpus> just grepped it, we somehow already documented this in test/README.md
08:09 < wumpus> never know
08:09 < wumpus> knew*
08:10 < instagibbs> wah, I just read the document, didn't see it?
08:10 < instagibbs> maybe an old version
08:10 < wumpus> so many things I forget most of it
08:10 < instagibbs> oh i see, doc/unit-tests.md doesn't mention this
08:11 < instagibbs> that's what I found and read
08:12 < wumpus> may make sense to combine them
08:12 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
08:15 < paveljanik> jonasschnelli, in the GUI, after using the autocomplete in the console tab, what do you have in the entry line?
08:16 < jonasschnelli> paveljanik: what do you mean with "after"?
08:16 < paveljanik> get cursor down, Enter
08:16 < paveljanik> type get, ...
08:17 < jonasschnelli> Yes. It keeps the command...
08:17 < jonasschnelli> hmm...
08:18 < jonasschnelli> until i send it again,... than its gone.
08:18 < jonasschnelli> Needs fixing...
08:18 < paveljanik> yup
08:19 < paveljanik> I'll have a look once I finish the rest.
08:19 < jonasschnelli> Why I did not recognized that in the first place... 
08:19 < jonasschnelli> paveljanik: super. Thanks. Should be easy to implement.
08:19 < paveljanik> How can I create immediatelly abandonable transaction so I can test #7707 now?
08:19 < jonasschnelli> paveljanik: set -walletboardcast=0, create a transaction, restart
08:20 < jonasschnelli> then you can abandone
08:20 < jonasschnelli> *abandon
08:22 < paveljanik> jonasschnelli, restart with -walletboardcast=0 again? Probably yes. Still grayed Abandon transaction in the UI
08:22 < paveljanik> ah, boardcast :-)
08:38 -!- molz [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
08:39 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
08:47 -!- chris2000 [~chris2000@customer-static-225-38.wobline-ip.de] has quit []
08:53 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
09:12 -!- zooko [~user@50.141.118.223] has joined #bitcoin-core-dev
09:12 < instagibbs> btcdrak, once csv cherry-picks are validated, what's the speed at which a release comes?
09:13 < instagibbs> s/speed/process
09:14 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
09:17 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
09:19 -!- JeromeLegoupil [~textual@46-127-102-197.dynamic.hispeed.ch] has joined #bitcoin-core-dev
09:20 -!- abritoid [~abritoid@84.40.68.253] has joined #bitcoin-core-dev
09:21 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
09:22 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
09:28 -!- zooko [~user@50.141.118.223] has quit [Remote host closed the connection]
09:39 < 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.
09:40 < instagibbs> I suppose since it's directly off of 0.12, it doesn't require a long freeze period, etc
09:40 < instagibbs> enough time for RCs
09:42 < 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.
09:44 -!- zooko [~user@50.141.118.223] has joined #bitcoin-core-dev
09:44 < btcdrak> instagibbs: actually there are a couple tickets still see https://bitcoincore.org/en/meetings/2016/03/17/#features-for-0121-besides-bip-9
09:49 -!- JeromeLegoupil [~textual@46-127-102-197.dynamic.hispeed.ch] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
09:49 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Quit: leaving]
09:49 < instagibbs> writeups coming in handy, thanks
09:56 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
10:01 < GitHub114> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/60db51dcb200...e8a8f3d4b22b
10:01 < GitHub114> bitcoin/master 65751a3 Pieter Wuille: Add CHECKSEQUENCEVERIFY softfork through BIP9
10:01 < GitHub114> bitcoin/master 478fba6 BtcDrak: Soft fork logic for BIP113
10:01 < GitHub114> bitcoin/master 02c2435 BtcDrak: Soft fork logic for BIP68
10:01 < 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
10:03 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
10:04 < btcdrak> omg boat party!
10:04 < Ylbam> \o/
10:07 < wumpus> o/ \o
10:10 < 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.
10:11 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
10:12 -!- ZerownZ_ [AdiIRC@187.105.90.203] has joined #bitcoin-core-dev
10:13 < 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.
10:14 < sipa> it was merged for BIP34
10:14 < sipa> not for later ones
10:14 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
10:14 < wumpus> ok
10:15 -!- ZerownZ [AdiIRC@187.105.90.203] has quit [Ping timeout: 248 seconds]
10:15 < wumpus> in any case there is no pressing reason why they couldn't go
10:15 -!- ZerownZ_ is now known as ZerownZ
10:20 < ZerownZ> hahaha
10:36 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
10:40 < cfields> wumpus: thanks for the explanation, that was very helpful
10:42 -!- JeromeLegoupil [~textual@46-127-102-197.dynamic.hispeed.ch] has joined #bitcoin-core-dev
10:46 -!- d_t [~textual@212.144.253.35] has joined #bitcoin-core-dev
10:50 -!- neha [~narula@mint-square.mit.edu] has joined #bitcoin-core-dev
10:52 -!- abritoid [~abritoid@84.40.68.253] has quit [Quit: Zzz…]
10:52 -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
10:53 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
10:54 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
10:55 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
10:56 -!- zooko [~user@50.141.118.223] has quit [Ping timeout: 260 seconds]
11:04 < GitHub95> [bitcoin] laanwj pushed 2 new commits to 0.11: https://github.com/bitcoin/bitcoin/compare/0ba7020cf6f9...c251f46bea8f
11:04 < GitHub95> bitcoin/0.11 12943ad Wladimir J. van der Laan: bump version to 0.11.3...
11:04 < GitHub95> bitcoin/0.11 c251f46 BtcDrak: Mark p2p alert system as deprecated....
11:07 -!- JeromeLegoupil [~textual@46-127-102-197.dynamic.hispeed.ch] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
11:13 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
11:14 -!- JeromeLegoupil [~textual@46-127-102-197.dynamic.hispeed.ch] has joined #bitcoin-core-dev
11:14 < GitHub76> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/ba80ceef59bdfb7e0a42da4df81335698047fbce
11:14 < GitHub76> bitcoin/0.12 ba80cee Wladimir J. van der Laan: bump version to 0.12.1
11:15 < 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
11:15 < morcos> s/much/enough/
11:17 < btcdrak> Trolling for review of https://github.com/bitcoin/bitcoin/pull/7707 - we'd like this for 0.12.1
11:17 < btcdrak> trolling for review/commentary on https://github.com/bitcoin/bitcoin/pull/7568
11:18 < btcdrak> morcos: actually, since these are master, it seems unlikely these could be reviewed and backported in time for 0.12.1
11:19 < morcos> btcdrak: we don't want 7707
11:19 < morcos> we already got the commit we wanted, jonas broke it out separately
11:19 < btcdrak> morcos: ah
11:19 < btcdrak> oh right I cant read "#7707 RPC-only (commit 42e945d79fd54ab11ad48978910b42d10c1c7cf8), which is 1 line of code."
11:20 < btcdrak> yeah, so #7568 wont happen in time. We should consider disabling the warnings instead.
11:20 < 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
11:21 < 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.
11:21 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
11:21 < 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
11:21 < btcdrak> morcos: not on our timeline.
11:23 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
11:23 < 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.
11:23 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:23 < morcos> i know!
11:25 < 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.
11:25 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Remote host closed the connection]
11:25 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
11:26 -!- abritoid [~abritoid@84.40.68.253] has joined #bitcoin-core-dev
11:26 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
11:26 < 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.  :)
11:26 < 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
11:27 -!- moli [~molly@unaffiliated/molly] has quit [Client Quit]
11:27 < 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
11:29 < 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
11:29 < wumpus> but sure, even if sipa were to look at it for 10 minutes that's better than nothing :D
11:29 < 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
11:30 < 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.
11:32 < wumpus> yes you could say that the current handling is so bad that everything is an improvement :)
11:33 < morcos> right, all we have to do is be confident it will alert LESS often, and its an improvement
11:33 < wumpus> and at least if we can rule out that it causes crashes or reversions outside the immediate area of chain-alerts
11:33 < morcos> terrible way to code a project though...   incremental improvements without caring that they are right... :)  its like monkeys typing shakespeare
11:34 < wumpus> yes, to be honest I'd rather disable the code until we get it right
11:34 < btcdrak> wumpus: +1
11:34 < wumpus> at least on major releases, in master we still have quite some time until a release
11:34 < btcdrak> disable for 0.12.1, then if we fix it properly in master, we can backport it to 0.12.2
11:35 < wumpus> that sounds like the responsible thing to do
11:35 < 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
11:35 < morcos> disabling sounds like its also bad to me, thats still a code change to be merged
11:35 < btcdrak> disabling is easy code though.
11:36 < wumpus> it is a very predictable and safe change
11:39 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
11:39 < GitHub155> [bitcoin] btcdrak opened pull request #7773: Fix comments in tests (master...csv-comments) https://github.com/bitcoin/bitcoin/pull/7773
11:40 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:40 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
11:41 < paveljanik> who will win #7777? ;-)
11:41 < 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
11:42 < morcos> roger.  paging sipa.  :)  ok got to run
11:43 < wumpus> yes, gtg in a bit too. later!
11:43 -!- moli [~molly@unaffiliated/molly] has quit [Client Quit]
11:51 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:53 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
11:54 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
11:57 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
12:04 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
12:05 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Read error: Connection reset by peer]
12:05 -!- frankenm_ [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
12:06 -!- frankenm_ [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Read error: Connection reset by peer]
12:06 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
12:44 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Read error: Connection reset by peer]
12:47 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
12:49 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
12:55 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:56 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
12:58 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 268 seconds]
13:00 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
13:02 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
13:04 -!- ryan-c [~ryan@srv1.turboslow.net] has quit [Quit: ZNC - http://znc.sourceforge.net]
13:05 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Remote host closed the connection]
13:09 -!- ryan-c [~ryan@srv1.turboslow.net] has joined #bitcoin-core-dev
13:15 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
13:15 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
13:24 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
13:28 -!- Don_John [~Don@250-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev
13:29 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
13:37 < 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
13:56 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Ping timeout: 268 seconds]
13:57 -!- cryptapus_ is now known as cryptapus
13:59 < gmaxwell> Meni's point is really good.
13:59 < gmaxwell> I think we _must_ reduce the false positives ASAP, even if it means turning off the functionality.
13:59 < gmaxwell> We're destroying the future utility by producing false positives now.
14:00 < sipa> i think i can implement meni's proposal easily though
14:01 < gmaxwell> we also need the too few blocks warning to go away immediately, not after 4 hours.
14:01 < gmaxwell> or it produces another kind of false positive.
14:01 < sipa> though, to be correct, it would actually need to check every 4 hours
14:01 < sipa> not just every 24 blocks
14:02 < sipa> i guess it can just happen based on clock/adjusted timr
14:02 < gmaxwell> yes.
14:12 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 260 seconds]
14:16 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
14:23 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
14:30 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
14:34 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 248 seconds]
14:46 -!- zooko [~user@50.141.118.144] has joined #bitcoin-core-dev
14:50 < Luke-Jr> hmm, so trying to update BIP 145, but VB doesn't have GBT support yet..
14:50 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
14:51 < gmaxwell> VB?
14:51 < Luke-Jr> versionbits
14:53 < Luke-Jr> are we still numbering bits 24..31, 16..23, 8..15, 0..7? not entirely clear from BIP 9 :x
14:55 < sipa> nVersion is interpreted as an integer; bits in that integer are being set
14:55 < sipa> how those map to byte position is a block serialization issue, which is unchanged
14:56 < Luke-Jr> so yes
14:56 < sipa> i have no idea what you mean
14:57 < sipa> nVersion is a little-endian 32-bit signed integer
14:57 < sipa> in the block header serialization
14:57 < sipa> so the lowest 8 bits map to the first byte
14:58 < Lightsword> Luke-Jr, is your issue with it just the format?
14:59 < Luke-Jr> Lightsword: ? just clarifying
14:59 < 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?
14:59 < sipa> sounds correct to me!
15:00 < sipa> indeed, i notice that there is no 2^N anymore in the text
15:01 -!- ZerownZ [AdiIRC@187.105.90.203] has quit [Ping timeout: 240 seconds]
15:01 < Luke-Jr> would 2^N be a better way to phrase that?
15:01 < sipa> i don't care :)
15:01 < Luke-Jr> curiously, I observe that << is more universal than ^ in syntax
15:02 < sipa> actually, the code snippet inside bip9 does define the behaviour fully
15:02 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
15:02 < gmaxwell> Luke-Jr: the stream operator?
15:02 < sipa> though clarifying in the text makes sense..
15:02 < Luke-Jr> gmaxwell: nevermind :P
15:02 < gmaxwell> (screw you C++)
15:02 < Luke-Jr> so to throw in a simply GBT section, how about "bips_supported":[141:28],"bips_required":[] ? does that seem practically complete?
15:02 < Luke-Jr> simple*
15:03 < Luke-Jr> bip-number:bit-number
15:03 < Luke-Jr> where bit-number is true when ACTIVE
15:03 -!- JeromeLegoupil [~textual@46-127-102-197.dynamic.hispeed.ch] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
15:04 < Luke-Jr> … {} instead of [] in JSON
15:04 < Lightsword> can’t the stratum server/miner just decode that itself from the version number?
15:04 < sipa> Luke-Jr: VB does not identify deployments by bip number
15:04 < Luke-Jr> sipa: does it identify them at all?
15:04 < Luke-Jr> Lightsword: not without teaching every client about the VB options..
15:05 < sipa> Luke-Jr: they get a name in getblockchaininfo
15:05 < Luke-Jr> Lightsword: and median time past etc
15:05 < Luke-Jr> sipa: that name isn't in the BIP afaict
15:05 < Luke-Jr> sipa: shall I add it?
15:05 < Luke-Jr> (considering that GBT will need to keep it in the list basically forever, smaller might be best?)
15:05 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 260 seconds]
15:06 -!- zooko [~user@50.141.118.144] has quit [Ping timeout: 276 seconds]
15:06 < Lightsword> Luke-Jr, can’t the miner/stratum server just issue a getblockchaininfo rpc call if it actually needs fork status info?
15:06 < Luke-Jr> Lightsword: no such RPC exists in GBT spec
15:06 < Lightsword> why does it have to be in GBT?
15:07 < Luke-Jr> Lightsword: how else will the client and server negotiate rules?
15:07 < sipa> i still think that trying to replicate the consensus rules in the mining client is folly
15:07 < Lightsword> it can issue other RPC calls
15:07 < sipa> if you want to be able to modify the transaction, run a bitcoind yourself
15:08 < Lightsword> IMO best not to try and stuff too much into GBT
15:08 < Luke-Jr> sipa: still need to figure out the union of what the local bitcoind and remote are
15:08 < sipa> but i don't oppose adding some string list of extra rules that are active to GBT
15:08 < sipa> Luke-Jr: no, you tell the bitcoind "this is the coinbase txn i want, give me a block"
15:08 < sipa> no merging
15:09 < Luke-Jr> that may be a better approach, but it's not how GBT works
15:09 < sipa> does anyone in the world actually have code that can even do txn merging over GBT?
15:10 < Luke-Jr> there is a fork of libblkmaker that can
15:10 < 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
15:11 < Lightsword> can’t it infer that?
15:11 < Luke-Jr> which is needed even without merging, for eg truncation
15:12 < Luke-Jr> Lightsword: infer it how?
15:12 < Lightsword> if there’s both a hash and txid and a defaultwitnesscommitment available?
15:13 < Luke-Jr> defaultwitnesscommitment is not even part of GBT spec
15:14 < sipa> txid/hash are
15:14 < Luke-Jr> anyway, inferring it can't reliably be expected to work for other softforks
15:14 < Lightsword> Luke-Jr, is defaultwitnesscommitment going to be in the final version of GBT?
15:14 < Luke-Jr> Lightsword: no (but maybe in bitcoind's implementation)
15:14 < sipa> i'm not opposed to adding some list to the GBT output that lists the active consensus rules
15:15 < sipa> maybe BIP145 should specify that every BIP9 softfork should also list a canonical name?
15:15 < Luke-Jr> sipa: so should VB add a name, or does BIP number work?
15:16 < sipa> the deployment being considered now is called "csv", and it activates the rules specified by bip68, bip112, and bip113
15:16 < Luke-Jr> oh
15:16 < Luke-Jr> right
15:16 < sipa> and they are intentionally being rolled out at once, as the alternative would mean testing way more combinations of their interactions
15:16 < 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
15:19 < Luke-Jr> # The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. <-- ACK?
15:21 -!- abritoid [~abritoid@84.40.68.253] has quit [Quit: Zzz…]
15:27 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
15:32 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
15:33 -!- cryptapus is now known as cryptapus_afk
15:33 -!- JeromeLegoupil [~textual@46-127-102-197.dynamic.hispeed.ch] has joined #bitcoin-core-dev
15:36 -!- d_t [~textual@212.144.253.35] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:37 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
15:38 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 260 seconds]
15:41 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
15:43 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
15:53 -!- cguida [~chris@162.216.46.195] has joined #bitcoin-core-dev
15:57 -!- p15 [~p15@45.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 240 seconds]
16:01 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Quit: WeeChat 1.4-dev]
16:06 < 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
16:11 -!- JeromeLegoupil [~textual@46-127-102-197.dynamic.hispeed.ch] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
16:12 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
16:14 < 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.
16:26 -!- zooko [~user@2601:281:8001:26aa:759f:a191:9026:e4fa] has joined #bitcoin-core-dev
16:34 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
16:49 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
16:55 -!- zooko [~user@2601:281:8001:26aa:759f:a191:9026:e4fa] has quit [Ping timeout: 250 seconds]
17:16 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]
17:30 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
17:35 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
18:00 -!- p15 [~p15@33.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev
18:01 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kofsoblsqwiqihcv] has quit [Quit: Connection closed for inactivity]
18:09 -!- zooko [~user@2601:281:8001:26aa:759f:a191:9026:e4fa] has joined #bitcoin-core-dev
18:16 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev
18:37 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
19:31 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
19:53 < GitHub72> [bitcoin] maneotrix opened pull request #7775: 0.12 (master...0.12) https://github.com/bitcoin/bitcoin/pull/7775
19:56 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
19:57 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
20:09 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Read error: Connection reset by peer]
20:15 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
20:24 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:32 -!- CodeShark_ [sid126576@gateway/web/irccloud.com/x-cdgauumfyfimwahl] has joined #bitcoin-core-dev
20:32 -!- baldur [~baldur@pool-72-69-12-130.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds]
20:32 -!- da2ce7_mobile [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 246 seconds]
20:32 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-mwjdjgsntuuptsod] has quit [Ping timeout: 246 seconds]
20:33 -!- Bootvis [bob@baltar.lan.endoria.net] has quit [Ping timeout: 246 seconds]
20:33 -!- CodeShark_ is now known as CodeShark
20:33 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Quit: Leaving]
20:34 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 246 seconds]
20:34 -!- jron [~okok@ec2-54-161-129-226.compute-1.amazonaws.com] has quit [Ping timeout: 246 seconds]
20:34 -!- Bootvis [bob@baltar.lan.endoria.net] has joined #bitcoin-core-dev
20:34 -!- jron [~okok@ec2-54-161-129-226.compute-1.amazonaws.com] has joined #bitcoin-core-dev
20:34 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined #bitcoin-core-dev
20:34 -!- da2ce7_mobile [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev
20:34 -!- baldur [~baldur@pool-72-69-12-130.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
20:35 -!- zooko [~user@2601:281:8001:26aa:759f:a191:9026:e4fa] has quit [Ping timeout: 248 seconds]
20:38 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
20:48 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:49 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:51 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
21:13 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:14 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:21 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 248 seconds]
21:23 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
21:26 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
21:44 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 240 seconds]
21:47 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
22:03 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:04 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:09 -!- d_t [~textual@212.144.253.35] has joined #bitcoin-core-dev
22:10 -!- d_t [~textual@212.144.253.35] has quit [Client Quit]
22:19 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:20 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:34 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
23:14 < GitHub136> [bitcoin] laanwj closed pull request #7775: 0.12 (master...0.12) https://github.com/bitcoin/bitcoin/pull/7775
23:15 -!- Don_John [~Don@250-223-114-134.nat.resnet.nau.edu] has quit [Read error: Connection reset by peer]
23:18 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Ping timeout: 240 seconds]
23:45 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rfdlxuidtiqycfts] has joined #bitcoin-core-dev
23:54 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
23:56 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]