1 2016-03-30 03:03:24	0|GitHub66|[13bitcoin] 15RHavar opened pull request #7768: Clarify outdated text in comment (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/7768
  2 2016-03-30 03:27:09	0|GitHub15|[13bitcoin] 15RHavar closed pull request #7768: Clarify outdated text in comment (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/7768
  3 2016-03-30 07:32:22	0|GitHub101|13bitcoin/06master 14e1523ce 15mruddy: P2P: add maxtimeadjustment command line option
  4 2016-03-30 07:32:22	0|GitHub101|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5131005e5b26...352fd577291e
  5 2016-03-30 07:32:23	0|GitHub101|13bitcoin/06master 14352fd57 15Wladimir J. van der Laan: Merge #7573: P2P: add maxtimeadjustment command line option...
  6 2016-03-30 07:32:27	0|GitHub196|[13bitcoin] 15laanwj closed pull request #7573: P2P: add maxtimeadjustment command line option (06master...06trust-system-clock) 02https://github.com/bitcoin/bitcoin/pull/7573
  7 2016-03-30 07:32:28	0|GitHub196|[13bitcoin] 15laanwj closed pull request #7573: P2P: add maxtimeadjustment command line option (06master...06trust-system-clock) 02https://github.com/bitcoin/bitcoin/pull/7573
  8 2016-03-30 08:29:29	0|wumpus|cfields: no particular reason, that was just the simplest to do, and every proxy seems to support it
  9 2016-03-30 08:32:08	0|wumpus|cfields: really don't want DNS leakage so we don't aim to support proxies that cannot support connecting by name
 10 2016-03-30 08:33:43	0|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.
 11 2016-03-30 08:33:56	0|wumpus|converting it to a string*
 12 2016-03-30 08:35:18	0|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
 13 2016-03-30 09:25:47	0|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?
 14 2016-03-30 09:26:20	0|jonasschnelli|What about using something similar than BIP32 to derive the session id, symmetric cipher key from the ecdh secret?
 15 2016-03-30 09:26:57	0|jonasschnelli|SHA512_hmac from both pubkeys (or the requesting pubkey), use the ecdh as SHA512 mac
 16 2016-03-30 09:27:36	0|jonasschnelli|wumpus: how do i pass a -g into the gitian build? Just a -g for the ./gbuild command?
 17 2016-03-30 09:30:22	0|jonasschnelli|or do i need to change the descriptor?
 18 2016-03-30 09:33:32	0|sipa|jonasschnelli: sha512 and ecdh are not macs
 19 2016-03-30 09:35:53	0|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"), ...
 20 2016-03-30 09:36:55	0|sipa|jonasschnelli: i've been playing with chacha20-poly1305, and it's so fast... ~5 cycles per byte or so
 21 2016-03-30 09:37:23	0|sipa|i don't think i can get aes128-gcm below 80 cycles per byte without using assembly
 22 2016-03-30 09:38:02	0|sipa|in theory, aes128-gcm, on very modern hardware should be doable in ~1 cycle per byte, with aes-ni and carryless multiplication instructions
 23 2016-03-30 09:41:23	0|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)
 24 2016-03-30 09:49:00	0|jonasschnelli|sipa: Thanks. Your HMAC make sense and is already possible with our codebase.
 25 2016-03-30 09:49:26	0|jonasschnelli|sipa: I think I drop the AES-GCM cipersuite  in the BIP any only cover chacha20-poly1305
 26 2016-03-30 09:49:43	0|jonasschnelli|(still allows AES256-GCM in a later BIP update or another BIP)
 27 2016-03-30 09:57:13	0|sipa|our current sha256 implementation is around 16 c/b, so using chacha20-poly1305 would actually be faster than our current checksumming
 28 2016-03-30 10:02:40	0|wumpus|jonasschnelli: just change the descriptor
 29 2016-03-30 10:05:00	0|sipa|jonasschnelli: or HMAC-SHA512, which we already have, and can provide larger keys at once
 30 2016-03-30 10:05:01	0|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
 31 2016-03-30 10:05:28	0|wumpus|I think I just added CPPFLAGS="-g" to CONFIGFLAGS
 32 2016-03-30 10:05:29	0|wumpus|I think I just added CPPFLAGS="-g" to CONFIGFLAGS
 33 2016-03-30 10:05:54	0|wumpus|(which is a hack, but CPPFLAGS are passed to both g++ and gcc, without overriding the current C*FLAGS optimizations etc)
 34 2016-03-30 10:14:58	0|sipa|jonasschnelli: perhaps it makes sense to refer to this document: https://github.com/jhcloos/openssh-chacha-poly1305/blob/master/PROTOCOL.chacha20poly1305
 35 2016-03-30 10:17:21	0|sipa|or https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.chacha20poly1305
 36 2016-03-30 10:17:40	0|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)
 37 2016-03-30 10:28:17	0|jonasschnelli|wumpus: thanks. Will try. What speaks again releasing with symbols as long as we are bellow <v1.0?
 38 2016-03-30 10:28:55	0|wumpus|jonasschnelli: it'd waste a lot of space - remember we're static linking every executable, and have quite a lot of executables
 39 2016-03-30 10:29:18	0|wumpus|https://github.com/bitcoin/bitcoin/issues/7770 is a better solution I think
 40 2016-03-30 10:29:52	0|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)
 41 2016-03-30 10:37:05	0|jonasschnelli|Right. 7770 makes sense!
 42 2016-03-30 10:41:56	0|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 :)
 43 2016-03-30 10:43:23	0|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
 44 2016-03-30 10:44:47	0|jonasschnelli|Indeed. Lets remove those.
 45 2016-03-30 10:45:00	0|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
 46 2016-03-30 10:46:16	0|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
 47 2016-03-30 10:46:41	0|wumpus|probably the first is best, other distributions may want to make their own decision about what to ship
 48 2016-03-30 10:46:50	0|wumpus|OTOH they don't need to get built either
 49 2016-03-30 10:47:44	0|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.
 50 2016-03-30 10:47:45	0|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.
 51 2016-03-30 10:50:21	0|CodeShark|wumpus: yeah, that's a good idea
 52 2016-03-30 10:59:36	0|CodeShark|is it pretty safe to say CSV will be merged in the next couple weeks?
 53 2016-03-30 11:00:13	0|CodeShark|specifically, https://github.com/bitcoin/bitcoin/pull/7648
 54 2016-03-30 11:00:14	0|CodeShark|specifically, https://github.com/bitcoin/bitcoin/pull/7648
 55 2016-03-30 11:06:38	0|btcdrak|CodeShark: I would hope it gets merged this week. It's a very trivial PR with a ton of tested ACKs already
 56 2016-03-30 11:19:50	0|btcdrak|wumpus: is there any news on the clion licenses?
 57 2016-03-30 11:32:26	0|wumpus|jonasschnelli: ah we can already --disable-bench
 58 2016-03-30 11:32:31	0|wumpus|btcdrak: no, no reply on that yet
 59 2016-03-30 11:32:53	0|sipa|what is clion?
 60 2016-03-30 11:33:15	0|btcdrak|sipa: https://www.jetbrains.com/clion/
 61 2016-03-30 11:34:06	0|btcdrak|sipa: and we're also applying for https://www.jetbrains.com/pycharm/
 62 2016-03-30 11:35:09	0|sipa|hmm, why?
 63 2016-03-30 11:36:27	0|btcdrak|sipa: some of us can't survive with vim :-p
 64 2016-03-30 11:36:51	0|wumpus|it's free for open source projects so why not
 65 2016-03-30 11:37:03	0|wumpus|I'm happy with vim myself
 66 2016-03-30 11:37:59	0|sipa|ah, i see
 67 2016-03-30 11:38:18	0|sipa|it would license anyone to use it for the purpose of developing bitcoin core?
 68 2016-03-30 11:39:22	0|wumpus|I think we get a limited number of licenses, to be distributed over people developing bitcoin core
 69 2016-03-30 11:39:55	0|wumpus|the license allows using it for developing any open source software
 70 2016-03-30 11:40:09	0|btcdrak|sipa: yes. Personally, I love the IDE and debugger features.
 71 2016-03-30 11:40:33	0|btcdrak|API autocomplete in itself is gold for me.
 72 2016-03-30 11:46:05	0|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
 73 2016-03-30 11:47:03	0|btcdrak|sipa: I was an Eclipse fan until I discovered JetBrains. They are remarkably good.
 74 2016-03-30 11:48:33	0|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.
 75 2016-03-30 11:48:59	0|kinlo|vim ftw :p
 76 2016-03-30 11:49:23	0|sipa|mcedit!
 77 2016-03-30 11:49:24	0|wumpus|it's like an OS in itself. I'm old-fashioned and just like opening the editor on separate files
 78 2016-03-30 11:49:45	0|kinlo|sipa: heh, I actually use that aswell, you're an mc user?
 79 2016-03-30 11:49:59	0|sipa|yeah
 80 2016-03-30 11:50:00	0|kinlo|sipa: there aren't enough mc users in this world :)
 81 2016-03-30 11:50:18	0|wumpus|I used 'joe' editor a long time
 82 2016-03-30 11:50:19	0|wumpus|I used 'joe' editor a long time
 83 2016-03-30 11:50:29	0|sipa|i like bluescreens
 84 2016-03-30 11:50:33	0|sipa|;)
 85 2016-03-30 11:50:40	0|kinlo|haha :)
 86 2016-03-30 11:52:00	0|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.
 87 2016-03-30 11:52:10	0|btcdrak|Sublime is fun.
 88 2016-03-30 11:53:25	0|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?
 89 2016-03-30 11:54:17	0|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 :)
 90 2016-03-30 11:55:36	0|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??
 91 2016-03-30 11:57:21	0|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
 92 2016-03-30 11:58:21	0|jl2012|wumpus: just for studying purpose. Logging of fee of each tx, for example, could also be done in ConnectBlock?
 93 2016-03-30 11:59:05	0|jl2012|I'm self-learning C++
 94 2016-03-30 11:59:07	0|wumpus|yes, I think so, it should have all the information available there
 95 2016-03-30 11:59:17	0|jl2012|thanks
 96 2016-03-30 12:01:02	0|wumpus|the fee/block reward computation should also be somewhere areound those parts
 97 2016-03-30 12:02:01	0|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
 98 2016-03-30 12:02:33	0|wumpus|wow
 99 2016-03-30 12:02:54	0|wumpus|obviously that's not fast enough and we should do an asm implementation *ducks*
100 2016-03-30 12:04:31	0|sipa|AES-NI + CLMUL based implementations can do AES-GCM in 1 c/b; without those, 22 c/b, without SIMD, 35 c/b
101 2016-03-30 12:04:32	0|sipa|AES-NI + CLMUL based implementations can do AES-GCM in 1 c/b; without those, 22 c/b, without SIMD, 35 c/b
102 2016-03-30 12:06:07	0|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!
103 2016-03-30 12:06:52	0|sipa|on the sending side, that's inevitable, as the checksum goes before the actual data
104 2016-03-30 12:07:06	0|sipa|but on the receiver side we could in theory compute it while receiving the data, in the network thread
105 2016-03-30 12:07:15	0|wumpus|sipa: right, for receiving we could certainly use a CHashWriter there
106 2016-03-30 12:07:36	0|sipa|not that it matters much for 1 MB messages, but it does indicate that there is a downside to having large p2p messages
107 2016-03-30 12:07:38	0|wumpus|for sending all the data is processed at once anyway
108 2016-03-30 12:08:00	0|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
109 2016-03-30 12:08:01	0|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
110 2016-03-30 12:08:28	0|wumpus|well the networking thread receives messages entirely right? so it could still do the computation there
111 2016-03-30 12:09:01	0|sipa|no the networking thread receives whatever recv() returns
112 2016-03-30 12:09:15	0|sipa|the message handler receives entire messages
113 2016-03-30 12:09:17	0|wumpus|just leave it blank initially then fill it in before sending it to the wire
114 2016-03-30 12:09:21	0|wumpus|no, I'm talking about sending
115 2016-03-30 12:09:46	0|wumpus|messages could be queued up without checksum, then the network thread fills in the checksum before actually dispatching them on the wire
116 2016-03-30 12:10:08	0|sipa|that doesn't change the latency, but it can take some load of the message handler thread, indeed
117 2016-03-30 12:10:17	0|sipa|*off
118 2016-03-30 12:10:28	0|wumpus|well, sure, there's a good point for adding the checksum at the end
119 2016-03-30 12:10:33	0|sipa|jonasschnelli: ^
120 2016-03-30 12:10:37	0|wumpus|and using a cheaper to compute one in the first place
121 2016-03-30 12:10:38	0|wumpus|and using a cheaper to compute one in the first place
122 2016-03-30 12:10:52	0|sipa|jonasschnelli: in the encrypted p2p protocol, the authentication tag (produced by poly1305) goes at the end :)
123 2016-03-30 12:14:06	0|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
124 2016-03-30 12:14:31	0|wumpus|(also because of memory usage and buffers)
125 2016-03-30 12:17:49	0|sipa|indeed
126 2016-03-30 12:48:26	0|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?
127 2016-03-30 12:49:15	0|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
128 2016-03-30 12:49:16	0|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
129 2016-03-30 12:51:27	0|jonasschnelli|sipa: so using poly1305 as mac (hash replacement) would make the transmission process faster because chacha20+poly1305 requires less cycles then sha256?
130 2016-03-30 12:51:41	0|sipa|jonasschnelli: yup
131 2016-03-30 12:51:54	0|jonasschnelli|That is an argument.
132 2016-03-30 12:52:02	0|sipa|or rather: naive implementation of chacha20+poly1305 is faster than naive implementation of sha256
133 2016-03-30 12:52:16	0|sipa|both can be made a small multiple faster with SIMD code etc
134 2016-03-30 12:52:40	0|sipa|i'm not saying we should do that
135 2016-03-30 12:53:08	0|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
136 2016-03-30 12:53:14	0|jonasschnelli|SIMD?
137 2016-03-30 12:53:26	0|jonasschnelli|Yes.
138 2016-03-30 12:54:39	0|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"?
139 2016-03-30 12:55:30	0|sipa|jonasschnelli: because the sizes leak privacy
140 2016-03-30 12:56:33	0|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
141 2016-03-30 12:56:49	0|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?
142 2016-03-30 12:58:09	0|sipa|jonasschnelli: sure, stream analysis may still leak information, but leaking sizes is just giving away potentially private information without reason
143 2016-03-30 12:58:37	0|sipa|jonasschnelli: read the link to openssh's document about it
144 2016-03-30 12:59:10	0|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?
145 2016-03-30 12:59:35	0|jonasschnelli|howevery,... i need to check the openssl docs first.
146 2016-03-30 13:00:22	0|sipa|OpenSSH, not OpenSSL
147 2016-03-30 13:00:40	0|jonasschnelli|arg. right.
148 2016-03-30 13:00:41	0|jonasschnelli|arg. right.
149 2016-03-30 13:00:47	0|sipa|jonasschnelli: yes, chacha20 is a stream cipher, so it can encrypt things of any byte size
150 2016-03-30 13:00:52	0|sipa|without expanding them
151 2016-03-30 13:00:53	0|sipa|without expanding them
152 2016-03-30 13:01:09	0|sipa|it's essentially just xoring the data with the output of a deterministic PRNG
153 2016-03-30 13:01:15	0|sipa|which is seeded by the key
154 2016-03-30 13:03:17	0|jonasschnelli|sipa: what do you think about an approach where each message could contain arbitrary pseudo-random data padded?
155 2016-03-30 13:07:39	0|sipa|sure
156 2016-03-30 13:07:51	0|sipa|that's orthogonal, i think
157 2016-03-30 13:09:54	0|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.
158 2016-03-30 13:09:57	0|jonasschnelli|*size
159 2016-03-30 13:45:05	0|GitHub27|13bitcoin/06master 147d5e31a 15Jonas Schnelli: [Qt] remove trailing output-index from transaction-id...
160 2016-03-30 13:45:05	0|GitHub27|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/352fd577291e...60db51dcb200
161 2016-03-30 13:45:06	0|GitHub27|13bitcoin/06master 1460db51d 15Wladimir J. van der Laan: Merge #7761: [Qt] remove trailing output-index from transaction-id...
162 2016-03-30 13:45:17	0|GitHub38|[13bitcoin] 15laanwj closed pull request #7761: [Qt] remove trailing output-index from transaction-id (06master...062016/03/ui_txid) 02https://github.com/bitcoin/bitcoin/pull/7761
163 2016-03-30 14:13:32	0|instagibbs|is there a way to run individual unit tests instead of all?
164 2016-03-30 14:16:10	0|sipa|instagibbs: ./test_bitcoin --run_tests=test_name
165 2016-03-30 14:16:24	0|sipa|for example --run_test=crypto_tests
166 2016-03-30 14:16:47	0|sipa|(use the name from the TEST_SUITE line
167 2016-03-30 14:17:27	0|instagibbs|awesome thanks
168 2016-03-30 15:05:00	0|wumpus|instagibbs: you can even do --run-test=suite_name/test_name
169 2016-03-30 15:05:38	0|sipa|ha!
170 2016-03-30 15:05:52	0|sipa|i had tried various separators, but not /
171 2016-03-30 15:07:46	0|wumpus|stumbled on it by accident too
172 2016-03-30 15:08:39	0|instagibbs|heh, I should probably write this up as PR for the testing doc
173 2016-03-30 15:09:10	0|wumpus|just grepped it, we somehow already documented this in test/README.md
174 2016-03-30 15:09:39	0|wumpus|never know
175 2016-03-30 15:09:43	0|wumpus|knew*
176 2016-03-30 15:10:03	0|instagibbs|wah, I just read the document, didn't see it?
177 2016-03-30 15:10:07	0|instagibbs|maybe an old version
178 2016-03-30 15:10:12	0|wumpus|so many things I forget most of it
179 2016-03-30 15:10:52	0|instagibbs|oh i see, doc/unit-tests.md doesn't mention this
180 2016-03-30 15:11:04	0|instagibbs|that's what I found and read
181 2016-03-30 15:12:09	0|wumpus|may make sense to combine them
182 2016-03-30 15:15:52	0|paveljanik|jonasschnelli, in the GUI, after using the autocomplete in the console tab, what do you have in the entry line?
183 2016-03-30 15:16:24	0|jonasschnelli|paveljanik: what do you mean with "after"?
184 2016-03-30 15:16:48	0|paveljanik|get cursor down, Enter
185 2016-03-30 15:16:53	0|paveljanik|type get, ...
186 2016-03-30 15:16:58	0|jonasschnelli|Yes. It keeps the command...
187 2016-03-30 15:17:01	0|jonasschnelli|hmm...
188 2016-03-30 15:18:44	0|jonasschnelli|until i send it again,... than its gone.
189 2016-03-30 15:18:48	0|jonasschnelli|Needs fixing...
190 2016-03-30 15:18:52	0|paveljanik|yup
191 2016-03-30 15:19:11	0|paveljanik|I'll have a look once I finish the rest.
192 2016-03-30 15:19:14	0|jonasschnelli|Why I did not recognized that in the first place...
193 2016-03-30 15:19:27	0|jonasschnelli|paveljanik: super. Thanks. Should be easy to implement.
194 2016-03-30 15:19:28	0|paveljanik|How can I create immediatelly abandonable transaction so I can test #7707 now?
195 2016-03-30 15:19:51	0|jonasschnelli|paveljanik: set -walletboardcast=0, create a transaction, restart
196 2016-03-30 15:19:58	0|jonasschnelli|then you can abandone
197 2016-03-30 15:20:03	0|jonasschnelli|*abandon
198 2016-03-30 15:22:13	0|paveljanik|jonasschnelli, restart with -walletboardcast=0 again? Probably yes. Still grayed Abandon transaction in the UI
199 2016-03-30 15:22:38	0|paveljanik|ah, boardcast :-)
200 2016-03-30 16:12:57	0|instagibbs|btcdrak, once csv cherry-picks are validated, what's the speed at which a release comes?
201 2016-03-30 16:13:18	0|instagibbs|s/speed/process
202 2016-03-30 16:39:43	0|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.
203 2016-03-30 16:40:29	0|instagibbs|I suppose since it's directly off of 0.12, it doesn't require a long freeze period, etc
204 2016-03-30 16:40:46	0|instagibbs|enough time for RCs
205 2016-03-30 16:42:48	0|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.
206 2016-03-30 16:44:22	0|btcdrak|instagibbs: actually there are a couple tickets still see https://bitcoincore.org/en/meetings/2016/03/17/#features-for-0121-besides-bip-9
207 2016-03-30 16:49:23	0|instagibbs|writeups coming in handy, thanks
208 2016-03-30 17:01:12	0|GitHub114|[13bitcoin] 15laanwj pushed 7 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/60db51dcb200...e8a8f3d4b22b
209 2016-03-30 17:01:13	0|GitHub114|13bitcoin/06master 14478fba6 15BtcDrak: Soft fork logic for BIP113
210 2016-03-30 17:01:13	0|GitHub114|13bitcoin/06master 1465751a3 15Pieter Wuille: Add CHECKSEQUENCEVERIFY softfork through BIP9
211 2016-03-30 17:01:14	0|GitHub114|13bitcoin/06master 1402c2435 15BtcDrak: Soft fork logic for BIP68
212 2016-03-30 17:01:17	0|GitHub193|[13bitcoin] 15laanwj closed pull request #7648: BIP9 versionbits softfork for BIP68, BIP112 and BIP113 (06master...06vb_68_112_113_1) 02https://github.com/bitcoin/bitcoin/pull/7648
213 2016-03-30 17:04:36	0|btcdrak|omg boat party!
214 2016-03-30 17:04:36	0|Ylbam|\o/
215 2016-03-30 17:07:17	0|wumpus|o/ \o
216 2016-03-30 17:10:14	0|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.
217 2016-03-30 17:13:28	0|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.
218 2016-03-30 17:13:59	0|sipa|it was merged for BIP34
219 2016-03-30 17:14:11	0|sipa|not for later ones
220 2016-03-30 17:14:49	0|wumpus|ok
221 2016-03-30 17:15:42	0|wumpus|in any case there is no pressing reason why they couldn't go
222 2016-03-30 17:20:16	0|ZerownZ|hahaha
223 2016-03-30 17:40:05	0|cfields|wumpus: thanks for the explanation, that was very helpful
224 2016-03-30 18:04:45	0|GitHub95|13bitcoin/060.11 1412943ad 15Wladimir J. van der Laan: bump version to 0.11.3...
225 2016-03-30 18:04:45	0|GitHub95|[13bitcoin] 15laanwj pushed 2 new commits to 060.11: 02https://github.com/bitcoin/bitcoin/compare/0ba7020cf6f9...c251f46bea8f
226 2016-03-30 18:04:46	0|GitHub95|13bitcoin/060.11 14c251f46 15BtcDrak: Mark p2p alert system as deprecated....
227 2016-03-30 18:14:49	0|GitHub76|13bitcoin/060.12 14ba80cee 15Wladimir J. van der Laan: bump version to 0.12.1
228 2016-03-30 18:14:49	0|GitHub76|[13bitcoin] 15laanwj pushed 1 new commit to 060.12: 02https://github.com/bitcoin/bitcoin/commit/ba80ceef59bdfb7e0a42da4df81335698047fbce
229 2016-03-30 18:15:04	0|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
230 2016-03-30 18:15:14	0|morcos|s/much/enough/
231 2016-03-30 18:17:06	0|btcdrak|Trolling for review of https://github.com/bitcoin/bitcoin/pull/7707 - we'd like this for 0.12.1
232 2016-03-30 18:17:36	0|btcdrak|trolling for review/commentary on https://github.com/bitcoin/bitcoin/pull/7568
233 2016-03-30 18:17:37	0|btcdrak|trolling for review/commentary on https://github.com/bitcoin/bitcoin/pull/7568
234 2016-03-30 18:18:34	0|btcdrak|morcos: actually, since these are master, it seems unlikely these could be reviewed and backported in time for 0.12.1
235 2016-03-30 18:18:58	0|morcos|btcdrak: we don't want 7707
236 2016-03-30 18:19:09	0|morcos|we already got the commit we wanted, jonas broke it out separately
237 2016-03-30 18:19:16	0|btcdrak|morcos: ah
238 2016-03-30 18:19:35	0|btcdrak|oh right I cant read "#7707 RPC-only (commit 42e945d79fd54ab11ad48978910b42d10c1c7cf8), which is 1 line of code."
239 2016-03-30 18:20:16	0|btcdrak|yeah, so #7568 wont happen in time. We should consider disabling the warnings instead.
240 2016-03-30 18:20:40	0|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
241 2016-03-30 18:20:59	0|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.
242 2016-03-30 18:21:17	0|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
243 2016-03-30 18:21:34	0|btcdrak|morcos: not on our timeline.
244 2016-03-30 18:23:46	0|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.
245 2016-03-30 18:23:57	0|morcos|i know!
246 2016-03-30 18:23:58	0|morcos|i know!
247 2016-03-30 18:25:35	0|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.
248 2016-03-30 18:25:36	0|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.
249 2016-03-30 18:26:27	0|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.  :)
250 2016-03-30 18:26:44	0|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
251 2016-03-30 18:27:32	0|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
252 2016-03-30 18:29:04	0|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
253 2016-03-30 18:29:46	0|wumpus|but sure, even if sipa were to look at it for 10 minutes that's better than nothing :D
254 2016-03-30 18:29:48	0|GitHub0|[13bitcoin] 15paveljanik opened pull request #7772: Clear the input line after activating autocomplete (06master...0620160330_completer_clean_input_line) 02https://github.com/bitcoin/bitcoin/pull/7772
255 2016-03-30 18:29:49	0|GitHub0|[13bitcoin] 15paveljanik opened pull request #7772: Clear the input line after activating autocomplete (06master...0620160330_completer_clean_input_line) 02https://github.com/bitcoin/bitcoin/pull/7772
256 2016-03-30 18:30:40	0|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.
257 2016-03-30 18:32:39	0|wumpus|yes you could say that the current handling is so bad that everything is an improvement :)
258 2016-03-30 18:33:09	0|morcos|right, all we have to do is be confident it will alert LESS often, and its an improvement
259 2016-03-30 18:33:15	0|wumpus|and at least if we can rule out that it causes crashes or reversions outside the immediate area of chain-alerts
260 2016-03-30 18:33:47	0|morcos|terrible way to code a project though...   incremental improvements without caring that they are right... :)  its like monkeys typing shakespeare
261 2016-03-30 18:34:11	0|wumpus|yes, to be honest I'd rather disable the code until we get it right
262 2016-03-30 18:34:26	0|btcdrak|wumpus: +1
263 2016-03-30 18:34:43	0|wumpus|at least on major releases, in master we still have quite some time until a release
264 2016-03-30 18:34:57	0|btcdrak|disable for 0.12.1, then if we fix it properly in master, we can backport it to 0.12.2
265 2016-03-30 18:35:07	0|wumpus|that sounds like the responsible thing to do
266 2016-03-30 18:35:10	0|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
267 2016-03-30 18:35:11	0|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
268 2016-03-30 18:35:26	0|morcos|disabling sounds like its also bad to me, thats still a code change to be merged
269 2016-03-30 18:35:48	0|btcdrak|disabling is easy code though.
270 2016-03-30 18:36:36	0|wumpus|it is a very predictable and safe change
271 2016-03-30 18:39:33	0|GitHub155|[13bitcoin] 15btcdrak opened pull request #7773: Fix comments in tests (06master...06csv-comments) 02https://github.com/bitcoin/bitcoin/pull/7773
272 2016-03-30 18:41:17	0|paveljanik|who will win #7777? ;-)
273 2016-03-30 18:41:32	0|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
274 2016-03-30 18:42:27	0|morcos|roger.  paging sipa.  :)  ok got to run
275 2016-03-30 18:43:15	0|wumpus|yes, gtg in a bit too. later!
276 2016-03-30 20:37:56	0|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
277 2016-03-30 20:59:21	0|gmaxwell|Meni's point is really good.
278 2016-03-30 20:59:35	0|gmaxwell|I think we _must_ reduce the false positives ASAP, even if it means turning off the functionality.
279 2016-03-30 20:59:46	0|gmaxwell|We're destroying the future utility by producing false positives now.
280 2016-03-30 21:00:24	0|sipa|i think i can implement meni's proposal easily though
281 2016-03-30 21:01:13	0|gmaxwell|we also need the too few blocks warning to go away immediately, not after 4 hours.
282 2016-03-30 21:01:26	0|gmaxwell|or it produces another kind of false positive.
283 2016-03-30 21:01:37	0|sipa|though, to be correct, it would actually need to check every 4 hours
284 2016-03-30 21:01:43	0|sipa|not just every 24 blocks
285 2016-03-30 21:02:14	0|sipa|i guess it can just happen based on clock/adjusted timr
286 2016-03-30 21:02:24	0|gmaxwell|yes.
287 2016-03-30 21:50:28	0|Luke-Jr|hmm, so trying to update BIP 145, but VB doesn't have GBT support yet..
288 2016-03-30 21:51:27	0|gmaxwell|VB?
289 2016-03-30 21:51:37	0|Luke-Jr|versionbits
290 2016-03-30 21:53:24	0|Luke-Jr|are we still numbering bits 24..31, 16..23, 8..15, 0..7? not entirely clear from BIP 9 :x
291 2016-03-30 21:55:29	0|sipa|nVersion is interpreted as an integer; bits in that integer are being set
292 2016-03-30 21:55:46	0|sipa|how those map to byte position is a block serialization issue, which is unchanged
293 2016-03-30 21:56:00	0|Luke-Jr|so yes
294 2016-03-30 21:56:19	0|sipa|i have no idea what you mean
295 2016-03-30 21:57:22	0|sipa|nVersion is a little-endian 32-bit signed integer
296 2016-03-30 21:57:30	0|sipa|in the block header serialization
297 2016-03-30 21:57:45	0|sipa|so the lowest 8 bits map to the first byte
298 2016-03-30 21:58:22	0|Lightsword|Luke-Jr, is your issue with it just the format?
299 2016-03-30 21:59:16	0|Luke-Jr|Lightsword: ? just clarifying
300 2016-03-30 21:59:27	0|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?
301 2016-03-30 21:59:47	0|sipa|sounds correct to me!
302 2016-03-30 22:00:00	0|sipa|indeed, i notice that there is no 2^N anymore in the text
303 2016-03-30 22:01:24	0|Luke-Jr|would 2^N be a better way to phrase that?
304 2016-03-30 22:01:32	0|sipa|i don't care :)
305 2016-03-30 22:01:54	0|Luke-Jr|curiously, I observe that << is more universal than ^ in syntax
306 2016-03-30 22:02:04	0|sipa|actually, the code snippet inside bip9 does define the behaviour fully
307 2016-03-30 22:02:14	0|gmaxwell|Luke-Jr: the stream operator?
308 2016-03-30 22:02:16	0|sipa|though clarifying in the text makes sense..
309 2016-03-30 22:02:19	0|Luke-Jr|gmaxwell: nevermind :P
310 2016-03-30 22:02:30	0|gmaxwell|(screw you C++)
311 2016-03-30 22:02:42	0|Luke-Jr|so to throw in a simply GBT section, how about "bips_supported":[141:28],"bips_required":[] ? does that seem practically complete?
312 2016-03-30 22:02:46	0|Luke-Jr|simple*
313 2016-03-30 22:02:59	0|Luke-Jr|bip-number:bit-number
314 2016-03-30 22:03:25	0|Luke-Jr|where bit-number is true when ACTIVE
315 2016-03-30 22:04:03	0|Luke-Jr|… {} instead of [] in JSON
316 2016-03-30 22:04:14	0|Lightsword|can’t the stratum server/miner just decode that itself from the version number?
317 2016-03-30 22:04:15	0|Lightsword|can’t the stratum server/miner just decode that itself from the version number?
318 2016-03-30 22:04:23	0|sipa|Luke-Jr: VB does not identify deployments by bip number
319 2016-03-30 22:04:37	0|Luke-Jr|sipa: does it identify them at all?
320 2016-03-30 22:04:51	0|Luke-Jr|Lightsword: not without teaching every client about the VB options..
321 2016-03-30 22:05:02	0|sipa|Luke-Jr: they get a name in getblockchaininfo
322 2016-03-30 22:05:03	0|sipa|Luke-Jr: they get a name in getblockchaininfo
323 2016-03-30 22:05:05	0|Luke-Jr|Lightsword: and median time past etc
324 2016-03-30 22:05:16	0|Luke-Jr|sipa: that name isn't in the BIP afaict
325 2016-03-30 22:05:22	0|Luke-Jr|sipa: shall I add it?
326 2016-03-30 22:05:44	0|Luke-Jr|(considering that GBT will need to keep it in the list basically forever, smaller might be best?)
327 2016-03-30 22:06:12	0|Lightsword|Luke-Jr, can’t the miner/stratum server just issue a getblockchaininfo rpc call if it actually needs fork status info?
328 2016-03-30 22:06:25	0|Luke-Jr|Lightsword: no such RPC exists in GBT spec
329 2016-03-30 22:06:48	0|Lightsword|why does it have to be in GBT?
330 2016-03-30 22:06:49	0|Lightsword|why does it have to be in GBT?
331 2016-03-30 22:07:23	0|Luke-Jr|Lightsword: how else will the client and server negotiate rules?
332 2016-03-30 22:07:41	0|sipa|i still think that trying to replicate the consensus rules in the mining client is folly
333 2016-03-30 22:07:42	0|Lightsword|it can issue other RPC calls
334 2016-03-30 22:07:52	0|sipa|if you want to be able to modify the transaction, run a bitcoind yourself
335 2016-03-30 22:07:53	0|sipa|if you want to be able to modify the transaction, run a bitcoind yourself
336 2016-03-30 22:08:03	0|Lightsword|IMO best not to try and stuff too much into GBT
337 2016-03-30 22:08:16	0|Luke-Jr|sipa: still need to figure out the union of what the local bitcoind and remote are
338 2016-03-30 22:08:18	0|sipa|but i don't oppose adding some string list of extra rules that are active to GBT
339 2016-03-30 22:08:36	0|sipa|Luke-Jr: no, you tell the bitcoind "this is the coinbase txn i want, give me a block"
340 2016-03-30 22:08:41	0|sipa|no merging
341 2016-03-30 22:09:19	0|Luke-Jr|that may be a better approach, but it's not how GBT works
342 2016-03-30 22:09:49	0|sipa|does anyone in the world actually have code that can even do txn merging over GBT?
343 2016-03-30 22:10:03	0|Luke-Jr|there is a fork of libblkmaker that can
344 2016-03-30 22:10:47	0|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
345 2016-03-30 22:11:55	0|Lightsword|can’t it infer that?
346 2016-03-30 22:11:57	0|Luke-Jr|which is needed even without merging, for eg truncation
347 2016-03-30 22:12:01	0|Luke-Jr|Lightsword: infer it how?
348 2016-03-30 22:12:31	0|Lightsword|if there’s both a hash and txid and a defaultwitnesscommitment available?
349 2016-03-30 22:13:50	0|Luke-Jr|defaultwitnesscommitment is not even part of GBT spec
350 2016-03-30 22:13:51	0|Luke-Jr|defaultwitnesscommitment is not even part of GBT spec
351 2016-03-30 22:14:05	0|sipa|txid/hash are
352 2016-03-30 22:14:19	0|Luke-Jr|anyway, inferring it can't reliably be expected to work for other softforks
353 2016-03-30 22:14:23	0|Lightsword|Luke-Jr, is defaultwitnesscommitment going to be in the final version of GBT?
354 2016-03-30 22:14:35	0|Luke-Jr|Lightsword: no (but maybe in bitcoind's implementation)
355 2016-03-30 22:14:53	0|sipa|i'm not opposed to adding some list to the GBT output that lists the active consensus rules
356 2016-03-30 22:15:21	0|sipa|maybe BIP145 should specify that every BIP9 softfork should also list a canonical name?
357 2016-03-30 22:15:29	0|Luke-Jr|sipa: so should VB add a name, or does BIP number work?
358 2016-03-30 22:15:59	0|sipa|the deployment being considered now is called "csv", and it activates the rules specified by bip68, bip112, and bip113
359 2016-03-30 22:16:06	0|Luke-Jr|oh
360 2016-03-30 22:16:09	0|Luke-Jr|right
361 2016-03-30 22:16:30	0|sipa|and they are intentionally being rolled out at once, as the alternative would mean testing way more combinations of their interactions
362 2016-03-30 22:16:49	0|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
363 2016-03-30 22:19:52	0|Luke-Jr|# The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. <-- ACK?
364 2016-03-30 23:06:18	0|GitHub77|[13bitcoin] 15mruddy opened pull request #7774: RPC: BIP9 version bits related, format version as hex in getblock and getblockheader (06master...06hexver) 02https://github.com/bitcoin/bitcoin/pull/7774
365 2016-03-30 23:14:25	0|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.