1 2015-05-18 03:09:59 <michagogo> !j
  2 2015-05-18 03:10:00 <gribble> Error: "j" is not a valid command.
  3 2015-05-18 04:51:15 <fanquake> ;;blocks
  4 2015-05-18 04:51:17 <gribble> 356937
  5 2015-05-18 07:30:15 <hulkhogan_> wumpus: what did you mean by 'transient failure' in #6141? i'm curious :)
  6 2015-05-18 07:38:19 <wumpus> hulkhogan_: it looks like it got stuck in a loop and eventually timed out
  7 2015-05-18 07:38:34 <wumpus> nothing that can have to do with the change in the pull itself
  8 2015-05-18 07:42:00 <hulkhogan_> wumpus: that is both interesting and bizarre, seeing as how its not reproducible anymore
  9 2015-05-18 07:42:19 <hulkhogan_> i wonder if cfields had any luck with that NPE fix earlier...
 10 2015-05-18 07:42:22 <wumpus> if you want to know the exact error I think it's possible to browse back to previous test results on the travis site
 11 2015-05-18 07:45:19 <hulkhogan_> hmm, having trouble locating the history for pull requests
 12 2015-05-18 07:45:42 <hulkhogan_> but i do see NPE's from at least 2 hours ago
 13 2015-05-18 08:07:43 <fanquake> hulkhogan_ https://travis-ci.org/bitcoin/bitcoin/pull_requests
 14 2015-05-18 08:19:52 <hulkhogan_> fanquake: i saw that, but i only saw one build for 6141 in the past two weeks, so i'm guessing one of the later ones 'overwrote' the earlier build
 15 2015-05-18 08:24:23 <fanquake> hulkhogan_ #6141 was originally #6132. As for build history, all builds/cancellations/faliures should show. See the multiple builds for #6146 over the last 3 days.
 16 2015-05-18 11:35:00 <jonasschnelli> wumpus: nice cleanup session!
 17 2015-05-18 11:36:38 <wumpus> thanks
 18 2015-05-18 11:45:33 <fanquake> wumpus Yes, nice to see all those old/outdated/random tickets getting cleaned up.
 19 2015-05-18 11:49:34 <wumpus> spring cleaning :-)
 20 2015-05-18 11:51:57 <jonasschnelli> hah. Right.
 21 2015-05-18 12:57:53 <michagogo> wumpus: any ETA on the Mac detached sig?
 22 2015-05-18 12:58:41 <michagogo> (Or cfields? I don't really know how that workflow happens)
 23 2015-05-18 13:17:02 <jonasschnelli> michagogo: mac detached sig?
 24 2015-05-18 13:17:28 <michagogo> jonasschnelli: gitian-osx-signer.yml's input
 25 2015-05-18 13:18:14 <jonasschnelli> michagogo: for 0.10.2rc1?
 26 2015-05-18 13:18:26 <michagogo> No, final
 27 2015-05-18 13:22:45 <jonasschnelli> michagogo: Ah. Right. Missed that it the 0.10.2 was final tagged. :)
 28 2015-05-18 13:30:12 <jonasschnelli> s/in the//
 29 2015-05-18 14:10:32 <jrick> is it intentional to be using c++11 brace initialization? I thought the codebase was supposed to be all c++03 right now
 30 2015-05-18 14:10:49 <jrick> there are a couple uses in wallet.cpp and rpcwallet.cpp, perhaps others elsewhere
 31 2015-05-18 14:16:55 <wumpus> it compiles in c++03 mode
 32 2015-05-18 14:17:36 <jrick> COutputEntry output = {address, txout.nValue, (int)i};
 33 2015-05-18 14:17:43 <jrick> that's c++11 isn't it?
 34 2015-05-18 14:18:04 <wumpus> looks like a normal C struct initialization to me
 35 2015-05-18 14:18:33 <wumpus> (e.g. no constructors involved, as would be for the c++11 case)
 36 2015-05-18 14:19:51 <jrick> http://en.cppreference.com/w/cpp/language/list_initialization
 37 2015-05-18 14:19:55 <jrick> #6 ?
 38 2015-05-18 14:20:33 <wumpus> it doesn't even require C++
 39 2015-05-18 14:20:47 <jrick> hmm it is a plain struct though
 40 2015-05-18 14:21:03 <wumpus> right
 41 2015-05-18 14:52:00 <bedeho2> Is a transaction id just the double SHA256 of the raw transaction? No fancy processing of the scripts in any way?
 42 2015-05-18 14:52:56 <jonasschnelli> bedeho2: yes.
 43 2015-05-18 14:53:29 <jonasschnelli> but better say binary serialized raw transaction instead of "raw transaction".
 44 2015-05-18 14:54:05 <jonasschnelli> (or someone thinks double sha256 the hexoutput of a raw transaction over rpc = transaction id)
 45 2015-05-18 14:57:12 <bedeho2> jonasschnelli: thanks
 46 2015-05-18 15:13:45 <gho> Hi, I'm parsing the blockchain.  The early transactions (e.g. first few thousand blocks) - where is the destination public key for the transaction?  it doesn't appear to use P2PKH?
 47 2015-05-18 15:16:19 <jonasschnelli> gho: check https://bitcoin.org/en/developer-guide#pubkey (read above and below)
 48 2015-05-18 15:18:22 <gho> jonasschnelli, OK thanks that helps.  Where then is the public key stored ? is there still a script or is the script the entire public key (unhashed?)
 49 2015-05-18 15:18:59 <jonasschnelli> do you have a example txid?
 50 2015-05-18 15:19:04 <jonasschnelli> gho
 51 2015-05-18 15:20:27 <gho> https://blockchain.info/tx/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
 52 2015-05-18 15:24:51 <gho> jonasschnelli, I know that's the genesis block but the rest seem similar
 53 2015-05-18 15:29:06 <gho> what I'm trying to do is with bitcoinj convert TransactionOutput to an address - but it's balking on these blocks
 54 2015-05-18 15:29:09 <gho> txs even
 55 2015-05-18 15:30:14 <temujin> txids are little endian SHA256 iirc
 56 2015-05-18 15:30:49 <temujin> actually everything is little endian SHA256 in bitcoin (right?)
 57 2015-05-18 15:31:04 <temujin> that might be the issue...
 58 2015-05-18 15:31:25 <gho> sha256 is endian independant as far as I know
 59 2015-05-18 15:32:01 <gho> the exception I'm getting for those blocks is Cannot cast this script to a pay-to-address type
 60 2015-05-18 15:33:03 <bedeho2> jonasschnelli: I am reading how a third party bitcoin library (bitcore from bitpay) computes the transaction id, and it seems to reverse the output of the 2xSHA256, why is this?
 61 2015-05-18 15:34:34 <temujin> *ahem*
 62 2015-05-18 15:35:12 <jonasschnelli> bedeho2: https://bitcoin.org/en/glossary/internal-byte-order
 63 2015-05-18 15:36:25 <temujin> http://bitcoin.stackexchange.com/questions/2063/why-does-the-bitcoin-protocol-use-the-little-endian-notation
 64 2015-05-18 15:39:54 <bedeho2> jonasschnelli: So this is only when communicating with the RPC? W.g. when a transaction is on the wire, the hash portion of an input OutPoint will not be reversed like this?
 65 2015-05-18 15:43:50 <jonasschnelli> bedeho2: you need to be aware of the byte ordering. The p2p serialization uses little endian. Blockexplorers and bitcoind's RPC are using big endian.
 66 2015-05-18 15:44:25 <LeMiner> What do you gents thing of a easy right click -> ban IP option in Bitcoin-QT for full nodes?
 67 2015-05-18 15:44:42 <LeMiner> currently node owners have to manually add ip's to firewall(s)
 68 2015-05-18 15:44:50 <LeMiner> think*
 69 2015-05-18 15:44:57 <bedeho2> jonasschnelli: thanks
 70 2015-05-18 15:45:40 <jonasschnelli> LeMiner: you mean that one? https://github.com/bitcoin/bitcoin/issues/5866
 71 2015-05-18 15:45:58 <LeMiner> ahhh, didn't see that one
 72 2015-05-18 15:45:59 <LeMiner> great
 73 2015-05-18 15:46:45 <LeMiner> ty
 74 2015-05-18 15:46:48 <jonasschnelli> LeMiner: it's just a feature request. Add a +1 if you like this.
 75 2015-05-18 15:46:54 <LeMiner> yep, will do
 76 2015-05-18 15:47:05 <jonasschnelli> LeMiner: i'm soon going to work on this.
 77 2015-05-18 15:47:55 <LeMiner> it'll be easier to ban/kick nodes that do nothing more than monitor as well
 78 2015-05-18 15:48:00 <LeMiner> ty
 79 2015-05-18 15:48:42 <LeMiner> +1'd
 80 2015-05-18 15:52:44 <jonasschnelli> gho: your software should be able to handle different transaction types. Not only P2PK and P2PKH.
 81 2015-05-18 15:57:43 <gho> jonasschnelli, yes I think it's a bitcoinj problem it doesn't appear to extract th address for P2PK scripts.  sadly no one answers in channel.  just writing a script disassembler to understand better
 82 2015-05-18 15:57:49 <gho> thanks anyway
 83 2015-05-18 15:59:40 <jonasschnelli> gho: Yes. Maybe ask here https://bitcointalk.org/index.php?board=138.0 or wait till hearn is online.
 84 2015-05-18 16:00:24 <gho> thanks
 85 2015-05-18 16:03:02 <afk11> gho: think I timed out before my response sent, pay-to-pubkey does not have an address
 86 2015-05-18 16:03:53 <gho> afk11, Yes I think I understand that - but surely one can hash the public key
 87 2015-05-18 16:04:50 <jonasschnelli> gho: https://en.bitcoin.it/wiki/Script#Obsolete_pay-to-pubkey_transaction
 88 2015-05-18 16:05:07 <afk11> if a service used pay-to-pubkey and relied on scripts to come in that form, blockexplorers, and bitcoind would be doing them a disservice by telling users to pay to the address
 89 2015-05-18 16:05:49 <temujin> gho: if you want a functioning script debugger... http://webbtc.com/script/aef4cf7abcd4344ae612d5f27735010a26e5102af20a97a5f43802583d72eb78:0
 90 2015-05-18 16:06:10 <gho> temujin, nice ! thanks.
 91 2015-05-18 16:06:51 <gho> afk11, OK I understand.  When was P2PK abandoned and what happened to all of the coins before that date?
 92 2015-05-18 16:06:54 <mr_burdell> if I want to get zmq notifications from bitcoind, is this the current best implementation: https://github.com/bitcoin/bitcoin/pull/6103
 93 2015-05-18 16:07:22 <gho> afk11, hmm ignore the seoncd part of that question
 94 2015-05-18 16:09:38 <afk11> I'm unsure exactly when they came in. early enough, by 110000 in blocktime?
 95 2015-05-18 16:10:10 <afk11> first two years or so iirc
 96 2015-05-18 16:10:36 <gho> ok thanks. I'm just trying to build a bitcoin graphing tool and hence presently parsing the whole blockchain into a db
 97 2015-05-18 16:10:56 <gho> and finding quite a few holes in my understanding
 98 2015-05-18 16:22:37 <jonasschnelli> mr_burdell: yes. But 6103 is not complete.
 99 2015-05-18 16:23:00 <jonasschnelli> mr_burdell: you could help testing this. But right now this won't compile IIRC
100 2015-05-18 16:24:04 <jonasschnelli> but promag (author of 6103) is currently working on it and did push some commits some minutes ago
101 2015-05-18 16:25:35 <afk11> gho: no probs, I recently had the same question. depending on your purposes, by all means associate the public key and address, as they do represent the same identity. just be aware bitcoind won't always regard them as the same, like compressed pay-to-pubkey-hash vs uncompressed.
102 2015-05-18 16:29:51 <gho> afk11, ok thanks.  I think I've now solved it - just took the pubkey bytes and hashed them and converted to an address and it maps up with blockchain.info - so happy days.  I'll heed your warnings though - cheers.
103 2015-05-18 16:32:57 <Luke-Jr> wumpus: do you actually select coins before entering recipients? I usually do the opposite order myself.
104 2015-05-18 16:42:39 <sdaftuar> wumpus: i think 5875 and 5976 may be suitable for merging for 0.11 (if it's not too late for that)
105 2015-05-18 16:51:01 <dhill> w/in 7
106 2015-05-18 16:51:08 <dhill> can never get that right
107 2015-05-18 16:51:09 <wumpus> Luke-Jr: yes, that's what I usually do, though the other way around is fine too
108 2015-05-18 16:52:33 <Luke-Jr> if we're throwing out last-minute PRs for 0.11, may I suggest 5987 (Fix testnet-in-a-box)? :P
109 2015-05-18 16:53:01 <Luke-Jr> (needs some ACKs first ofc..)
110 2015-05-18 16:54:45 <wumpus> no, we're not going to merge all kind of last-minute stuff this time, although strictly non-feature fixes can still be merged, given that there is more benefit than risk
111 2015-05-18 16:56:18 <wumpus> #5875 and #5976 were already on my list, I'm not sure about the testnet-in-a-box fix, I don't like how it adds an extra chain parameter for example
112 2015-05-18 16:58:03 <Luke-Jr> I don't either, but it's better than nothing (which is the current list of alternative solutions afaik)
113 2015-05-18 17:15:57 <dgenr8> nominate 5881, fixes a test to not depend on random behavior in syncing wallet metadata
114 2015-05-18 17:54:15 <jonasschnelli> cfields: this is again a strange travis issue IMO: https://travis-ci.org/bitcoin/bitcoin/jobs/63008138
115 2015-05-18 17:56:04 <cfields> jonasschnelli: hmm, that's a bit worrisome to me after the recent scheduler tests discussion
116 2015-05-18 17:56:46 <wumpus> dgenr8: does gavin agree to the test now?
117 2015-05-18 17:57:05 <cfields> i don't think i've seen travis stall there, not lately anyway
118 2015-05-18 17:58:38 <wumpus> that's indeed weird, unfortunately it's not possible to see which unit test was hanging
119 2015-05-18 17:59:39 <jonasschnelli> hmm... will do a force push and see if it's reproducable.
120 2015-05-18 18:00:25 <cfields> grr, and these NPEs in the comparison-tool are popping up more and more
121 2015-05-18 18:01:04 <cfields> BlueMatt: ping. I'd like to discuss that issue and try to get it fixed, independent of updating to a later version
122 2015-05-18 18:01:26 <jonasschnelli> hmm... also a strange travis issue: https://travis-ci.org/bitcoin/bitcoin/builds/63016360
123 2015-05-18 18:01:30 <cfields> i have a theory, and if there's a quick+working fix, i'd like to just push it in
124 2015-05-18 18:02:21 <cfields> ok, so 3 travis issues atm. 1: builds taking too long. 2: NPEs, 3, that weird time-out that just came up
125 2015-05-18 18:02:46 <cfields> wumpus: 1 can be solved by clearing all of the old PR caches. Any chance you can take a min to nuke those?
126 2015-05-18 18:03:13 <wumpus> just nuke all caches this time?
127 2015-05-18 18:04:12 <cfields> only the PR- ones need to be. You can kill em all, but that'd make the next PRs take a long time until the cache is rebuilt by a push
128 2015-05-18 18:14:26 <wumpus> there's no way to have it nuke only PR caches, and I don't feel like clicking all ~100 manually
129 2015-05-18 18:14:56 <wumpus> ... so I'll nuke them all from orbit
130 2015-05-18 18:15:46 <cfields> ok. sorry for the travis bloodshed lately. It was on auto-pilot so long, this is frustrating now
131 2015-05-18 18:15:51 <cfields> will try to have it cleaned up asap
132 2015-05-18 18:16:38 <cfields> wumpus: if you're going to delete it all, you'll want to push something into master soonish to get it regen'd
133 2015-05-18 18:16:44 <cfields> everything will build cacheless until then
134 2015-05-18 18:19:02 <wumpus> ok done (thanks jonasschnelli)
135 2015-05-18 18:19:42 <jonasschnelli> Thanks! will do a force push soon.
136 2015-05-18 18:20:23 <cfields> wumpus: thanks
137 2015-05-18 18:28:54 <petertodd> wumpus, sipa, gmaxwell: Any plans to do a 0.9.5 release with the BIP66 soft-fork? Some miners have asked me.
138 2015-05-18 18:30:12 <wumpus> testing my new changelog generation script - phew, 255 pulls merged for 0.11 (that are not in 0.10)
139 2015-05-18 18:30:30 <wumpus> petertodd: if anyone backports the BIP66 changes
140 2015-05-18 18:30:43 <petertodd> wumpus: they're in the v0.9 branch, just not in a release
141 2015-05-18 18:30:54 <wumpus> there's no absolute reason not to do a 0.9.5
142 2015-05-18 18:31:06 <dgenr8> gavinandresen: request review #5881
143 2015-05-18 18:31:06 <wumpus> oh?
144 2015-05-18 18:31:39 <petertodd> wumpus: here's the backport: https://github.com/bitcoin/bitcoin/commit/ab03660824daa2c49379d0da28e1d9cb03f6b995
145 2015-05-18 18:31:59 <wumpus> petertodd: you're right - I'm not sure why I had in my head that that still has to be done
146 2015-05-18 18:34:30 <petertodd> wumpus: cool - I'm talking to some miners now re: upgrading
147 2015-05-18 18:34:37 <petertodd> wumpus: lots still use v0.9
148 2015-05-18 18:35:42 <wumpus> yes let me guess, the usual patch sets that cost time to forward-port
149 2015-05-18 18:35:55 <wumpus> and they haven't bothered yet :)
150 2015-05-18 18:36:02 <petertodd> wumpus: that and extreme conservativism :)
151 2015-05-18 18:36:13 <petertodd> wumpus: upgrading pools is SCARY SHIT :)
152 2015-05-18 18:37:06 <wumpus> anyhow - I'll put up release notes and tag v0.9.5, still remains to be seen if anyone will be interested in gitian building and such
153 2015-05-18 18:37:28 <petertodd> wumpus: thanks - about time I setup a gitian env...
154 2015-05-18 18:37:30 <wumpus> (no one built 0.9.4 IIRC)
155 2015-05-18 18:37:43 <warren> I'll help with gitian buildig.
156 2015-05-18 18:37:46 <wumpus> (not that there was a point, there is now)
157 2015-05-18 18:37:49 <warren> but I won't actually use it.
158 2015-05-18 18:38:25 <petertodd> warren: thanks!
159 2015-05-18 18:50:38 <wumpus> * [new tag]         v0.9.5rc1 -> v0.9.5rc1
160 2015-05-18 19:01:04 <Luke-Jr> [18:30:54] <wumpus> there's no absolute reason not to do a 0.9.5 <-- there's the problem of testing
161 2015-05-18 19:03:24 <Luke-Jr> latest-branch rcs can be sure to get testing, but stable branches not necessarily so. basically need to monitor downloads and/or listening node %s to be sure
162 2015-05-18 19:03:53 <petertodd> Luke-Jr: I'm firing up a new v0.9.5rc1 node right now actually
163 2015-05-18 19:05:05 <petertodd> Luke-Jr: "tell him to fix that shit" - Marshall Long :P
164 2015-05-18 19:05:57 <petertodd> Luke-Jr: I'm at Marshall's place and we're scheming how to get BIP66 adopted so we can start on CLTV :)
165 2015-05-18 19:06:21 <Luke-Jr> hm, does CLTV strictly need BIP66 done?
166 2015-05-18 19:06:21 <michagogo> wumpus: I'm curious: what's the workflow for the OS X detached sig? I've noticed it's always cfields that announces when it's available, and it's at his URL, but I thought you were the one with the keys
167 2015-05-18 19:06:41 <michagogo> Do you sign and send him the signed binary to process or something?
168 2015-05-18 19:06:43 <petertodd> Luke-Jr: mostly yes - there's other ways to do it, but the easiest is probably to just get BIP66 adopted first
169 2015-05-18 19:35:19 <michagogo> Gah, 0.9 still uses an i386 VM?
170 2015-05-18 19:36:36 <michagogo> I guess it's an opportunity to test the new lxc changes in gitian
171 2015-05-18 20:01:48 <cfields> 0.10.2 sig is up: https://bitcoincore.org/cfields/bitcoin-0.10.2/signature.tar.gz
172 2015-05-18 20:03:16 <Luke-Jr> cfields: michagogo would like to know the process to produce that :P
173 2015-05-18 20:03:19 <cfields> michagogo: i sign these days. gavin was doing it before, but he turned it over to me when we added the split-signing, since it required a good bit of debugging to get it working right
174 2015-05-18 20:05:26 <Luke-Jr> hm.
175 2015-05-18 20:05:44 <Luke-Jr> cfields: do we have split signing for Windows too?
176 2015-05-18 20:05:50 <michagogo> Luke-Jr: no
177 2015-05-18 20:06:04 <cfields> Luke-Jr: not yet, but it's on the todo. You can strip the sig off
178 2015-05-18 20:06:16 <cfields> so basically, the same operation in reverse
179 2015-05-18 20:07:09 <Luke-Jr> right
180 2015-05-18 21:00:21 <temujin> question about isValid: if a transaction is mined by a pool that has unique isValid code for a certain OP-code, will full nodes on the network relay that block or no?
181 2015-05-18 21:01:10 <temujin> the question boils down to this, basically: does the logic that decides whether or not a transaction is not relayed by a node differ between transactions and newly mined blocks?
182 2015-05-18 21:02:48 <michagogo> temujin: yes
183 2015-05-18 21:02:56 <michagogo> look for something like IsStandard()
184 2015-05-18 21:03:18 <temujin> okay, i'll go rtfcode :)
185 2015-05-18 21:03:36 <temujin> thanks for the keyword~
186 2015-05-18 21:07:11 <gmaxwell> As you asking about a transaction that the rest of the network considers invalid?
187 2015-05-18 21:07:29 <temujin> yes,
188 2015-05-18 21:08:02 <temujin> i understand that most nodes will not relay it, but if a miner would find it valid and put it in a block, will that block be relayed or not?
189 2015-05-18 21:08:13 <temujin> reading through standard.h right now...
190 2015-05-18 21:08:53 <gmaxwell> temujin: of course not-- the block wouldn't be valid.
191 2015-05-18 21:09:25 <gmaxwell> Bitcoin nodes do not trust anyone else, they verify for themselves; mining is just used to provide a decisive consensus ordering of events. The data still must be valid.
192 2015-05-18 21:09:56 <temujin> gmaxwell: thank you, understood
193 2015-05-18 21:27:54 <Luke-Jr> temujin: at the same time, nodes are free to apply their own policies to what they will relay or not
194 2015-05-18 21:28:24 <Luke-Jr> and *usually* those policies have whitelists on scripts, rate limiting, and other anti-spam measures
195 2015-05-18 23:10:39 <maaku> is bitcoind supposed to work under clang?
196 2015-05-18 23:10:57 <maaku> I get a segmentation fault on the test driver when running 'make check' (works under gcc)
197 2015-05-18 23:11:16 <maaku> Ubuntu clang version 3.6.0-2ubuntu1 (tags/RELEASE_360/final) (based on LLVM 3.6.0) on x64
198 2015-05-18 23:25:10 <BlueMatt> cfields: waiting on a plane, synncup on this tomorrow?
199 2015-05-18 23:25:33 <cfields> BlueMatt: ok
200 2015-05-18 23:26:03 <cfields> maaku: no problems for me, been building with 3.6 all day
201 2015-05-18 23:27:00 <maaku> cfields: hrrm.. ok. unfortunately i got other more pressing things to track down at the moment. i'll just revert to gcc..
202 2015-05-18 23:27:27 <cfields> maaku: are you mixing libstdc++ abi's by any chance? is it gcc 5.0 ?
203 2015-05-18 23:27:43 <maaku> gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2
204 2015-05-18 23:28:53 <cfields> ok. feel free to ping me if/when you want to mess with it
205 2015-05-18 23:29:01 <maaku> i just did an 'apt-get install clang llvm' and then 'CC=clang CXX=clang++ ./configure' on Ubuntu 15.04
206 2015-05-18 23:29:06 <maaku> cfields: sure ok. thanks