1 2015-05-27 00:00:24 <bad_duck> should I add a comment in the pull request (which is already merged), should I create a issue?
  2 2015-05-27 00:01:26 <bad_duck> Should I submit a pull request with a "fix" (removing the const declaration removes the warning, but I don't know anything else about what this part of the code does or not)?
  3 2015-05-27 00:36:42 <petertodd> sdaftuar: here
  4 2015-05-27 01:24:24 <PRab> Whats the best way to be informed about a new release getting tagged? Usually see something committed to the gitian.sigs repository or see somebody talking about it here.
  5 2015-05-27 01:24:43 <PRab> The main thing I want to do is fire up my gitian builder.
  6 2015-05-27 01:25:32 <gmaxwell> I've thought it would be neat to have some kind of feed that triggers builders; but ... right now a bad code update can compromise your builder so that seemed unwise. :)
  7 2015-05-27 01:27:15 <PRab> My thought is that my gitian builder is only saying "I preformed a deterministic build of some code and here are there hashes of the results". If somebody thinks that implies that I read, verified, or otherwise inspected the code, they are mistaken.
  8 2015-05-27 01:28:20 <PRab> I run entire gitian build process in a VM, so even if it ends up somehow triggering an arbitrary code exploit in the build system its no great loss to me.
  9 2015-05-27 02:29:15 <midnightmagic> PRab: how do you run a gitian inside a VM? does your VM let you run VMs inside it?
 10 2015-05-27 02:30:00 <PRab> midnightmagic: It must. I boot debian inside of virtualbox on a windows host.
 11 2015-05-27 02:30:30 <midnightmagic> huh. LXC afaik does not allow nested lxc.
 12 2015-05-27 02:44:14 <Luke-Jr> midnightmagic: KVM does
 13 2015-05-27 02:44:25 <Luke-Jr> LXC inside KVM or KVM inside KVM are both fine
 14 2015-05-27 02:46:49 <midnightmagic> i think it can only do it in accelerated fashion if the cpu and kernel support nesting...?
 15 2015-05-27 03:21:28 <phantomcircuit> midnightmagic, vm inside vm works perfectly fine
 16 2015-05-27 03:22:29 <phantomcircuit> midnightmagic, and yes it needs to be supported by both cpu and kernel
 17 2015-05-27 03:22:43 <phantomcircuit> http://kashyapc.com/2012/01/14/nested-virtualization-with-kvm-intel/
 18 2015-05-27 03:35:29 <Squidicc> it's virtual machines all the way down
 19 2015-05-27 04:01:33 <jzk> my last reading of the AMD manual impressed upon me that a VM could not be run inside a VM as far as the hardware is concerned
 20 2015-05-27 04:12:04 <jzk> e6aa9abd738 arch/x86/kvm/svm.c (Joerg Roedel               2009-08-07 11:49:33 +0200   94) struct nested_state {
 21 2015-05-27 04:12:06 <jzk> but that'll do it
 22 2015-05-27 04:17:42 <phantomcircuit> jzk, irc it's supported by kvm
 23 2015-05-27 04:17:54 <jzk> yup
 24 2015-05-27 04:42:41 <gmaxwell> Hm. RPCs no longer work when starting up a node that was behind (but caught up on headers); they all retruen "-28: Activating best chain...") which is a bit obnoxious when it's on a slow host and it's going to take it a half hour to fully catch up.
 25 2015-05-27 04:47:51 <Luke-Jr> gmaxwell: return or throw? O.o
 26 2015-05-27 04:48:15 <gmaxwell> throw
 27 2015-05-27 06:42:38 <wumpus> gmaxwell: starting up can take a while when it first has zillions of blocks to conncet
 28 2015-05-27 06:44:04 <gmaxwell> yea, now that you mention it, seems that I was misreading the behavior.  (testing on a slow PPC host)
 29 2015-05-27 06:44:09 <wumpus> it's not so much about being caught up on headers, but it may have received a lot of blocks ahead, and notices it has the intermediate block, so it can suddenly connect the whole sequence
 30 2015-05-27 06:44:37 <gmaxwell> It had taken so long I thought it was going to refuse to answer RPC until it got to the headers-tip.
 31 2015-05-27 06:44:40 <gmaxwell> But seems not.
 32 2015-05-27 06:44:56 <wumpus> indeed, it has nothing to do with networking, that isn't even active by that point
 33 2015-05-27 06:45:47 <wumpus> it used to be that RPC didn't listen at all yet, the RPC-is-active-during-setup is a recent addition
 34 2015-05-27 08:03:13 <paveljanik> what do you think about -prune (if used without argument) to default to MIN_DISK_SPACE_FOR_BLOCK_FILES/1024/1024 ie. the min. allowed value?
 35 2015-05-27 08:05:11 <wumpus> no, IMO the user should make an explicit choice
 36 2015-05-27 08:05:29 <wumpus> defaults are always a drag
 37 2015-05-27 08:07:50 <wumpus> also the option is irreversible, it's easy to accidentally add -prune, so forcing the user to think twice makes sense
 38 2015-05-27 08:09:07 <paveljanik> OK, thanks for this insight. I agree (the second argument is more important here).
 39 2015-05-27 08:13:13 <wumpus> well the first is too, but in the big picture. Defaults always result in discussion. The less defaults we define the better.
 40 2015-05-27 08:16:54 <paveljanik> well, MIN_DISK_SPACE_FOR_BLOCK_FILES was already chosen... So the "user should think first" is more important here ;-)
 41 2015-05-27 08:18:13 <wumpus> no, it's a *MINIMUM*, not a default
 42 2015-05-27 08:18:24 <paveljanik> the default for a minimum
 43 2015-05-27 08:18:27 <wumpus> no
 44 2015-05-27 08:22:18 <gmaxwell> The minimum is the "severe danger of getting stuck begins here" point, it's probably not a sensible default. Sustainability of the network likely requires that at a minimum the last couple weeks of blocks be available at most nodes.
 45 2015-05-27 08:27:46 <gmaxwell> here was some analysis about how deep peers on the public network were fetching blocks: https://people.xiph.org/~greg/fetches.png
 46 2015-05-27 08:29:28 <gmaxwell> red is the observed data, I modeled it (eyeball fit?) as a laplace plus a constant (rate of IBDs during the time).
 47 2015-05-27 08:30:48 <gmaxwell> as you can see the fetches back in history decline down until about two weeks where it transistions into mostly just IBD load (the constant part).
 48 2015-05-27 08:30:53 <wumpus> oh cool someone did research on the number of requests versus depth?
 49 2015-05-27 08:31:01 <jonasschnelli> gmaxwell: din't expect that traffic is that low at depth tip-1000!
 50 2015-05-27 08:31:06 <gmaxwell> there is also a definite cycle at one day ish.
 51 2015-05-27 08:31:35 <gmaxwell> wumpus: kinda...
 52 2015-05-27 08:31:36 <gmaxwell> jonasschnelli: it's probably higher now. this data is from ~two weeks in april 2013.
 53 2015-05-27 08:31:48 <Jouke> Hmm, me neither.
 54 2015-05-27 08:31:55 <gmaxwell> When we first discussed having pruned nodes with partial data sets.
 55 2015-05-27 08:32:03 <jonasschnelli> gmaxwell: ah. Okay. Chart missed a timestamp somewhere. :)
 56 2015-05-27 08:32:28 <jonasschnelli> gmaxwell: is it possible for you to rerun the data gathering?
 57 2015-05-27 08:32:33 <gmaxwell> Have not collected recently (do not run any general ipv4 listening nodes right now... plan to soon).
 58 2015-05-27 08:32:36 <gmaxwell> jonasschnelli: absolutely.
 59 2015-05-27 08:32:57 <jonasschnelli> would be nice to have a more recent chart to get more info about pruned block relying.
 60 2015-05-27 08:33:17 <gmaxwell> My vague prediction is that the intermittent usage behavior is stronger. But we'll see.
 61 2015-05-27 08:33:48 <jonasschnelli> tell me if i can assist somewhere in generating chart/gathering data.
 62 2015-05-27 08:33:56 <gmaxwell> in any case, we really want to have most nodes holding enough to cover the transition into constant. At that point holding more unless you hold everything does basically no good for the network.
 63 2015-05-27 08:35:47 <gmaxwell> Assuming more recent measurements look like the old data, I'd suggest that that the interesting threshold is about 2016 blocks. Which was why I was suggesting we use a service bit for that. (and perhaps another service bit for 288, which is also the minimum and also covers an interesting 'threshold' (the hump around 20-200 blocks) too).
 64 2015-05-27 08:37:24 <jonasschnelli> recently i was thinking about a case, where pruned nodes could also keep a random (or somehow network caluclated) range of older blocks below the prune target (lets say prunetarget divided by 10) to increase network health. But maybe a bad idea.
 65 2015-05-27 08:37:38 <gmaxwell> omitted from that graph is requests at height 0... which was totally off the chart, at a kazabillionty times that level. :)
 66 2015-05-27 08:38:17 <gmaxwell> jonasschnelli: it's a great idea IMO,  but the trick is efficiently signaling what you've got. And also picking that range uniform and potentially changing it as the chain grows to keep it uniform.
 67 2015-05-27 08:38:33 <gmaxwell> There is a thread on bitcoin-development about that.
 68 2015-05-27 08:39:02 <gmaxwell> It seems likely that we could signal nothing more than a 32bit seed and a size paramter and efficiently know which blocks a peer will be keeping.
 69 2015-05-27 08:39:54 <gmaxwell> I say fantastic because it means that all the IBD traffic wouldn't half to be sholdered by a few large disk nodes, with a modest amount of additional disk per node we could have many distributed copies.
 70 2015-05-27 08:42:20 <gmaxwell> fwiw, that parameterization what I said before was '<gmaxwell> the rational I'd give for it being log-normal ish is "node outages are are be power-law-ish distributed"'
 71 2015-05-27 08:42:44 <jonasschnelli> is there a ways of generating a statistic about block-keeping/pruned-nodes? It would be good to see how many of the available nodes can server blocks down to genesis.
 72 2015-05-27 08:43:28 <gmaxwell> jonasschnelli: they all can right now, pruning disables NETWORK_NODE at the moment and there is not yet an equal NETWORK_PRUNED that signals that it can do anything else.
 73 2015-05-27 08:44:31 <jonasschnelli> gmaxwell: maybe extend the crawler (dns-crawler) so that it try to get the genesis block and if done, assume the node can server all blocks?
 74 2015-05-27 08:44:58 <jonasschnelli> maybe also try to factor out spv node (over useragent string?)
 75 2015-05-27 08:45:04 <jonasschnelli> *nodes
 76 2015-05-27 08:45:12 <gmaxwell> jonasschnelli: there is no need to.  Already they tell you, thats what the nodeflags are for!
 77 2015-05-27 08:45:29 <gmaxwell> (other than just lying/broken)
 78 2015-05-27 08:46:23 <jonasschnelli> gmaxwell: right. But maybe it would be nice to distinct between normal SPV (! NETWORK_NODE) nodes and bitcoin core nodes with prune enabled. A way of detecting this (with a rate of false positives) would be over the useragent string
 79 2015-05-27 08:48:15 <gmaxwell> Right now, until we define a service bit for it, requesting anything from a one of those nodes is really not polite and should get you banned.
 80 2015-05-27 08:48:27 <gmaxwell> There will eventually be service bits for this.
 81 2015-05-27 08:50:00 <jonasschnelli> Agreed.
 82 2015-05-27 10:51:19 <intx> can i extract my private key from a wallet.dat file without the blockchain?
 83 2015-05-27 10:52:36 <wumpus> yes
 84 2015-05-27 10:53:12 <wumpus> (but I see you also asked in #bitcoin, so lets keep it there where it is more appropriate)
 85 2015-05-27 12:16:10 <jtimon> seriously, guys, what's stopping  #6063 from being merged?
 86 2015-05-27 12:17:41 <wumpus> lack of reviewers
 87 2015-05-27 12:18:04 <wumpus> (same as for any pull request that isn't merged)
 88 2015-05-27 12:18:28 <wumpus> about to merge #5669 though
 89 2015-05-27 13:01:36 <jtimon> great
 90 2015-05-27 13:02:21 <jtimon> well, petertodd was about to do almost exactly the same, doesn't that count as an ack? ;)
 91 2015-05-27 13:03:22 <jtimon> I believe maaku has something similar in some of his branches too
 92 2015-05-27 13:04:23 <paveljanik> jtimon, why do you "unrolled" BOOST_FOREACH? Is there some consensus on not using it?
 93 2015-05-27 13:04:59 <jtimon> libconsensus shouldn't depend on boost
 94 2015-05-27 13:05:26 <paveljanik> ah, sure.
 95 2015-05-27 13:05:27 <paveljanik> thx
 96 2015-05-27 13:06:24 <jtimon> I mean, certainly I could have done that after the moveonly, but it still seemed such as small change...
 97 2015-05-27 13:07:58 <wumpus> the rationale for using BOOST_FOREACH was always that it was easy to replace by some c++11 construct when we were going to use it
 98 2015-05-27 13:09:33 <wumpus> (a range-based for loop)
 99 2015-05-27 13:14:42 <wumpus> going from iterator-based loops to index-based loops seems like a step backward, in that regard
100 2015-05-27 13:19:28 <jtimon> I like C++11 more as well
101 2015-05-27 13:20:08 <wumpus> so I think keeping the BOOST_FOREACHes for now makes sense, to eventually replace them all at once
102 2015-05-27 13:20:35 <jtimon> maybe I should move to iterators (real ones, not i indexes) when removing the boost dependency
103 2015-05-27 13:22:04 <wumpus> I don't think a dependency on BOOST_FOREACH is very bad, isn't it just a macro?
104 2015-05-27 13:22:12 <wumpus> in any case it's a header-only dependency
105 2015-05-27 13:22:30 <jtimon> when doing things like: https://github.com/jtimon/bitcoin/commit/1546b9aa4d3c16fd4c94b4b24df07d8c0ec0c69d
106 2015-05-27 13:23:02 <jtimon> I was just repeating what we did for the scripts, maybe cfields has a stronger opinion
107 2015-05-27 13:23:35 <wumpus> (or, alternatively, can't we define our own FOREACH? BITCOIN_FOREACH? lol)
108 2015-05-27 13:23:39 <jtimon> as said, we can always use real iterators instead of boost
109 2015-05-27 13:24:00 <wumpus> that's hardly better; the advantage of BOOST_FOREACH is that it's easy to find, when we want to replace them with c++11 code
110 2015-05-27 13:24:04 <jtimon> what's inside the loop wouldn't change
111 2015-05-27 13:24:23 <jtimon> yeah, that makes sense
112 2015-05-27 13:24:24 <wumpus> that's, as said, always been the rationale for using BOOST_FOREACH, as a marker
113 2015-05-27 13:24:44 <paveljanik> Just put // BOOST_FOREACH before for cycle...
114 2015-05-27 13:24:49 <wumpus> (there's also a Qt foreach, which does a similar thing)
115 2015-05-27 13:25:02 <jtimon> (I was just saying that iterators share that property without the boost dependency)
116 2015-05-27 13:25:07 <wumpus> I just don't agree there is such a hurry to get rid of BOOST_FOREACH
117 2015-05-27 13:26:47 <jtimon> I don't really have a strong opinion, if the dependency makes libconsensus much bigger, we can do as you say and have our own BOOST_FOREACH macro for libconsensus
118 2015-05-27 13:27:30 <wumpus> as said it's simple a header-only dependency, just a small helper, I'm fairly sure it doens't make libconsensus any bigger
119 2015-05-27 13:27:40 <jtimon> should I change #6063 then?
120 2015-05-27 13:29:03 <wumpus> depends on how quickly #6183 is mergable, as it contains the important parts of #6063
121 2015-05-27 13:29:59 <wumpus> (in any case, they conflict)
122 2015-05-27 13:30:33 <jtimon> yeah, I doubt it too, I would be surprised if their macro is much bigger than the one we would do ourselves (something along the lines of https://github.com/jtimon/preann/blob/master/src/common/util.h#L36 )
123 2015-05-27 13:31:37 <jtimon> well, 6183 could just incorporate 6063 (as an independent commit or squashed, I don't really care, mostly care about the naming to avoid rebasing my consensus branches)
124 2015-05-27 13:33:37 <jtimon> anyway, I'm happy to remove the boost change from 6063 if people prefer that
125 2015-05-27 13:39:03 <jtimon> done
126 2015-05-27 13:39:41 <jtimon> it cannot get more trivial than this...
127 2015-05-27 13:48:16 <jtimon> #5975 is quite trivial too and it also has a couple of ut ACK (#6061 is similar)
128 2015-05-27 13:49:52 <jtimon> all of them dependencies for #6051
129 2015-05-27 13:58:30 <Diablo-D3> https://store.boingboing.net/giveaways/the-surface-3-giveaway?gid=2040483
130 2015-05-27 14:23:23 <jonasschnelli> hmm,... why is travis ignoring https://github.com/bitcoin/bitcoin/pull/6193 ... there is no [skip-ci] text-part within the commit?!
131 2015-05-27 14:24:31 <harding> jonasschnelli: GitHub/Travis have been showing the CI box very slowly lately.
132 2015-05-27 14:25:04 <jonasschnelli> harding: hmm... on a newer pr is already there. (https://github.com/bitcoin/bitcoin/pulls)
133 2015-05-27 14:25:08 <harding> It took almost 30 minutes for the CI box to show on a bitcoin.org PR two days ago.
134 2015-05-27 14:25:28 <jonasschnelli> harding: okay. This sounds after the issue i'm facing... thanks!
135 2015-05-27 14:27:38 <harding> jonasschnelli: np.
136 2015-05-27 14:31:19 <jonasschnelli> (harding: maybe it happens when you force-push to many times)
137 2015-05-27 14:33:24 <harding> jonasschnelli: the PR I saw it on did have it happen on a force-push, so that could be the case
138 2015-05-27 14:46:10 <temujin> what is the standard best-practice to uniquely identify transactions? (txid can be malleated in the mempool via signature 0-padding, and other methods)
139 2015-05-27 14:56:10 <jonasschnelli> temujin: Aren't 0-conf txid unique? If you face a "malleated" tx it's somehow a new tx and your app should probably detect this.
140 2015-05-27 14:59:32 <temujin> how is it possible to detect it?
141 2015-05-27 15:00:01 <temujin> that's the essence of my question - what is the best way to identify a transaction, if i can't identify it by txid?
142 2015-05-27 15:00:02 <harding> temujin: to detect mutated transactions, you look for any transaction that spends the same input as a previous transaction.
143 2015-05-27 15:00:22 <harding> previously-seen transaction*
144 2015-05-27 15:01:47 <temujin> okay, so for example i can hash the spent inputs and use that hash to identify the transaction?
145 2015-05-27 15:02:19 <temujin> (as long as the inputs have some confirms, and can't be mutated themselves)
146 2015-05-27 15:02:44 <harding> temujin: no.  As jonasschnelli said, the thing that identifies a particular transaction is the txid.
147 2015-05-27 15:04:13 <temujin> correct, however, once i broadcast that transaction anyone can mutate the txid by changing the signature
148 2015-05-27 15:04:42 <temujin> so i have to use the inputs of that transaction to identify it, yeah?
149 2015-05-27 15:06:09 <harding> temujin: yes, the spending app can confirm that the transaction was spent if its inputs are used as outpoints on the block chain.  A receiving app can confirm the payment was received if there are outputs on the block chain that match its pubkeys/addresses.
150 2015-05-27 15:06:54 <temujin> my case is a lot more simple than that, i'm trying to track my own OP_RETURN in the testnet and i need to protect against mutated txid attacks
151 2015-05-27 15:07:24 <temujin> basically creating a mapping of txid to OP_RETURN in a database
152 2015-05-27 15:07:37 <temujin> well, for now, it's 1:1 at least ...
153 2015-05-27 15:12:32 <harding> temujin: if nobody but you can remove an input, then you can track by input (assuming you trust yourself).
154 2015-05-27 15:17:48 <sdaftuar> jtimon: regarding the unused variable warning someone mentioned in 6055, i'm pretty sure it was my fault in #5976
155 2015-05-27 15:18:15 <sdaftuar> is it better to delete the unused variable from SendMessages, or pass it through to GetBlockTimeout so that GetBlockTimeout isn't calling Params() directly?
156 2015-05-27 15:19:07 <jtimon> sdaftuar oh, I just commented on it, it's another variable in SendMessages
157 2015-05-27 15:20:08 <jtimon> oh, I see, then yes, it's better to pass it to GetBlockTimeout, I didn't know about this new function
158 2015-05-27 15:20:33 <sdaftuar> got it, thanks i'll PR the fix
159 2015-05-27 15:21:16 <jtimon> great, can you also point to your PR on https://github.com/bitcoin/bitcoin/pull/6055#discussion_r31144466 ?
160 2015-05-27 15:21:28 <sdaftuar> sure thing
161 2015-05-27 15:21:40 <jtimon> thanks
162 2015-05-27 15:42:17 <harding> jonasschnelli: maybe there really is something wrong with Travis and your PR.  :-(  The problem I saw didn't take two hours to resolve itself.
163 2015-05-27 16:44:27 <Rozal> is there a way to see each dev's contribution to btc core? is there like a top 5 of who contributes the most?
164 2015-05-27 16:44:38 <hearn> github shows you that
165 2015-05-27 16:44:42 <hearn> assuming by contribute you mean commits
166 2015-05-27 16:44:46 <hearn> click graphs on the github page
167 2015-05-27 16:47:41 <bad_duck> I just read this on another non bitcoin chan:
168 2015-05-27 16:47:43 <bad_duck> "Hey guys, SourceForge is adding spyware to the Bitcoin installer for windows. Any word on it from someone? http://sourceforge.net/u/sf-editor1/profile/"
169 2015-05-27 16:47:59 <bad_duck> " http://sourceforge.net/projects/bitcoin/ you can see sf-editor1 as a owner of the bitcoin project"
170 2015-05-27 16:50:43 <Rozal> thanks hearn
171 2015-05-27 16:50:55 <Rozal> id tip you if someone would integrate change tip in IRC
172 2015-05-27 16:53:42 <gavinandresen> I just removed sf-editor1 from the admin group, no idea how it got there.
173 2015-05-27 16:54:49 <bad_duck> gavinandresen: "I downloaded a exe and nothing suspicious was detected, but my computer isn't windows. Spyware was detected on GIMP, after the sf-editor1 user was added to the GIMP account on sf. Worth investigating, me thinks"
174 2015-05-27 16:55:12 <gavinandresen> I’m checking the windows .exes now…
175 2015-05-27 16:57:19 <gavinandresen> … windows 0.10.2 exes from sourceforge match binaries on bitcoin.org/bin/
176 2015-05-27 16:59:32 <bad_duck> ok, nice
177 2015-05-27 17:01:04 <bad_duck> gavinandresen: thx
178 2015-05-27 17:06:49 <ajweiss> it's been there for quite a while, i remember seeing it at least a few months ago, if not longer
179 2015-05-27 17:07:08 <ajweiss> (sf-editor1, that is)
180 2015-05-27 17:12:02 <ajweiss> looks like it was added 2014-04-29
181 2015-05-27 17:12:41 <bad_duck> and he's also in some other bitoin project (electrum, multibit)
182 2015-05-27 17:14:16 <bad_duck> sourceforge is a shitty website btw.. lots of ads, some that looks like a download link
183 2015-05-27 17:17:57 <ajweiss> oh yuck.  what a mess.
184 2015-05-27 17:19:09 <zooko> Yeah, it's absolutely terrible.
185 2015-05-27 17:19:20 <zooko> And it actively prevents sending users to HTTPS downloads.
186 2015-05-27 17:19:25 <zooko> I.e. forces them to HTTP.
187 2015-05-27 17:20:15 <ajweiss> mirroring open source binaries and repackaging with ads is pretty desperate
188 2015-05-27 17:27:34 <zooko> The fact that a lot of the ads are designed to mislead people into downloading something else is pretty worrisome.
189 2015-05-27 17:27:46 <zooko> How many people do you think end up downloading some random malware when they were trying to download bitcoind?
190 2015-05-27 17:28:04 <zooko> Speaking of which, this just came on my twitter stream: https://plus.google.com/+gimp/posts/cxhB1PScFpe
191 2015-05-27 17:28:08 <ajweiss> well hopefully they aren't going there for discovery
192 2015-05-27 17:28:09 <wumpus> who is still downloading bitcoind from soruceforge anyway?
193 2015-05-27 17:28:11 <zooko> "
194 2015-05-27 17:28:12 <zooko> 
195 2015-05-27 17:28:12 <zooko> It appears that +SourceForge took over the control of the 'GIMP for Windows' account and is now distributing an ads-enabled installer of GIMP. They also locked out original owner of the account, Jernej Simončič, who has been building the Windows versions of GIMP for our project for years.
196 2015-05-27 17:28:14 <zooko> So far they haven't replied to provide explanations. Therefore, we remind you again that GIMP only provides builds for WIndows via its official Downloads page."
197 2015-05-27 17:28:24 <ajweiss> yeah that's what i was yucking about
198 2015-05-27 17:28:30 <wumpus> we've been publishing executables on bitcoin.org for ages, and only link there from release announcements
199 2015-05-27 17:28:30 <zooko> ajweiss: Oh.
200 2015-05-27 17:28:45 <zooko> wumpus: Oh.
201 2015-05-27 17:29:11 <wumpus> also https://bitcoin.org/en/download, obviously, links to bitcoin.org for the binaries
202 2015-05-27 17:29:13 <bad_duck> it simple:  2,187 Downloads (This Week)
203 2015-05-27 17:29:24 <bad_duck> http://sourceforge.net/projects/bitcoin/files/stats/timeline
204 2015-05-27 17:29:50 <wumpus> I think it's better to remove the executables from sourceforge
205 2015-05-27 17:29:58 <bad_duck> +1
206 2015-05-27 17:29:59 <ajweiss> wumpus: agree
207 2015-05-27 17:30:35 <wumpus> I wasn't even aware they were still being uploaded there
208 2015-05-27 17:30:40 <bad_duck> removing files from sourceforce is a good idea, a link to bitcoin.org / github is enough
209 2015-05-27 17:31:29 <wumpus> thought it was just the old, obsolete versions there.
210 2015-05-27 17:31:33 <zooko> wumpus: +1
211 2015-05-27 17:32:24 <ajweiss> so i read somewhere that they're mirroring projects that aren't hosted there
212 2015-05-27 17:32:39 <ajweiss> to build a "directory"
213 2015-05-27 17:33:07 <ajweiss> http://sourceforge.net/mirror/
214 2015-05-27 17:35:13 <zooko> brb
215 2015-05-27 17:39:44 <ajweiss> interesting.  it looks like they might be mirroring and hosting binaries for projects that have abandoned them in order to drive ad traffic.
216 2015-05-27 17:40:23 <denisx> can I unban an ip-address without restarting bitcoind?
217 2015-05-27 17:41:00 <denisx> my own relaynetworkclient got banned which runs on the same ip-address like bitcoind itself
218 2015-05-27 17:43:14 <harding> denisx: please ask in #bitcoin, which is the tech support channel
219 2015-05-27 18:48:37 <jonasschnelli> denisx: you can't unban (but your banned node gets automatically unbanned after some hours). There is a recent patch that would allow this: https://github.com/bitcoin/bitcoin/pull/6158
220 2015-05-27 18:48:53 <jonasschnelli> denisx: feel free to help testing and get this merged soon
221 2015-05-27 18:50:03 <jonasschnelli> harding: i re-force-pushed the branch which made travis start building. Maybe some race-condition during force-pushing multiple times.
222 2015-05-27 19:00:36 <kevdev> Hey there! Anyone around? I think I have a really solid idea using Bitcoin
223 2015-05-27 19:00:46 <kevdev> Could use some feedback on pros and cons
224 2015-05-27 19:02:11 <kevdev> For a while now I've wanted to create an escrow service similar to Craigslist, to make it more secure, my only downfall was maintaining security while providing security, and now with blockchain i think this is doable, but before I spent precious programming hours building this, it'd be helpful to get some constructive criticism
225 2015-05-27 19:02:36 <kevdev> maintaining anonymity*
226 2015-05-27 19:02:59 <Bootvis> removing the binaries could give them an excuse to replace the binaries with adware-laden bins. They want to provide this mirroring service after all, removing would give an excuse...
227 2015-05-27 19:03:07 <Bootvis> a weak one, but an excuse
228 2015-05-27 19:03:55 <ajweiss> kevdev: you'll have better luck in #bitcoin
229 2015-05-27 19:04:25 <gmaxwell> We should first figure out whats directing people to the old download links. There are some old web websites out there.
230 2015-05-27 19:04:45 <kevdev> thanks ajweiss
231 2015-05-27 19:05:10 <ajweiss> gmaxwell: there's loads of stuff on stackoverflow, etc
232 2015-05-27 19:05:36 <ajweiss> perhaps the better solution would be better documentation around verifying release signatures
233 2015-05-27 19:05:51 <Bootvis> at risk people don't
234 2015-05-27 19:06:41 <jonasschnelli> is there even a (end user friendly) documentation on how one does check if a gitian build is valid?
235 2015-05-27 19:06:56 <gmaxwell> ajweiss: virtually no one does and likely will continue to not do with more instructions.
236 2015-05-27 19:07:06 <ajweiss> i went hunting for one.  found stuff on stackoverflow that pointed to sourceforge :(
237 2015-05-27 19:08:17 <ajweiss> couldn't find anything on bitcoin.org except for the signatures themselves
238 2015-05-27 19:14:10 <jonasschnelli> ajweiss: maybe harding can put something on bitcoin.org? Something based on this http://www.reddit.com/r/Bitcoin/wiki/verifying_bitcoin_core?
239 2015-05-27 19:15:07 <pigeons> tor has https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification
240 2015-05-27 19:20:13 <gmaxwell> ajweiss: What we should ultiamtely include with the software is a tool that users that already have the software can use to download and verify updates. Initial download is going to be inherently dicy.  I talked to tor project people and tails and also found that basically no one verifies. :(
241 2015-05-27 19:22:48 <jonasschnelli> gmaxwell: i'm ready to write a nice qt tool (or cmd) for this. One could verify the tools with gpg/openssl in the shell.
242 2015-05-27 19:22:49 <Bootvis> hopefully this can be solved in the future by better out of the box support in the base OS
243 2015-05-27 19:23:40 <jonasschnelli> s/tools/tool
244 2015-05-27 20:05:20 <iwilcox> gmaxwell: Found how?
245 2015-05-27 20:30:55 <michagogo> 20:39:40 <ajweiss> interesting.  it looks like they might be mirroring and hosting binaries for projects that have abandoned them in order to drive ad traffic.
246 2015-05-27 20:31:02 <michagogo> Eww. Reminds me of Wikia.
247 2015-05-27 20:31:24 <michagogo> If you run a big wiki on Wikia, you essentially can't move away from them
248 2015-05-27 20:32:19 <michagogo> Because it's CC-BY-SA or whatever, you can't take away the content, and I've heard it said that if a community tries to abandon a big wiki they actually pay people to take over and maintain it
249 2015-05-27 20:32:37 <michagogo> And because they're so big, they'll ~always be higher in search results
250 2015-05-27 20:34:50 <harding> jonasschnelli: I would like to add better documentation to bitcoin.org about verifying the binaries.  It's on my mental todo list, but with low priority---as gmaxwell says, very few people do it and more documentation probably won't improve that much.
251 2015-05-27 20:36:05 <jonasschnelli> harding: Agreed. A check should be possible with the current installed bitcoind (or a new additional binary tool).
252 2015-05-27 20:36:25 <harding> Yes, that would be awesome.
253 2015-05-27 20:36:35 <jonasschnelli> the question is more, how one can check a fresh downloaded bitcoin-core (where no previous version was installed)?
254 2015-05-27 20:36:39 <harding> I was told Lighthouse has something lke that built in.
255 2015-05-27 20:37:12 <Luke-Jr> well, a fresh downloading user won't have our PGP keys either..
256 2015-05-27 20:37:18 <jonasschnelli> harding: could be. But Lighthouse is probably not built deterministic and has probably not multiple signatures.
257 2015-05-27 20:38:25 <jonasschnelli> harding, Luke-Jr: maybe a new, from core separated tool, could do the verify job. The tool itself could/must be verified with gpg
258 2015-05-27 20:38:26 <Luke-Jr> it would be nice, if there was an independent program that could check any website for software updates and display a list of verified signers
259 2015-05-27 20:38:40 <Luke-Jr> I suppose this would essentially be a gitian-smart package manager for Mac/Windows :p
260 2015-05-27 20:39:27 <jonasschnelli> Yes. This would probably end up in a gitian-app-store... :)
261 2015-05-27 20:44:18 <jonasschnelli> how would a such tool find the relation between https://bitcoin.org/bin/bitcoin-core-0.10.2/ and https://github.com/bitcoin/gitian.sigs?
262 2015-05-27 20:44:44 <Luke-Jr> jonasschnelli: it would probably need some kind of packaging standard
263 2015-05-27 20:45:32 <Luke-Jr> but in the end, as this only affects inherently-compromised systems (Mac/Windows), I'm not sure how important it is
264 2015-05-27 20:45:46 <jonasschnelli> Luke-Jr: why not linux?
265 2015-05-27 20:45:52 <Luke-Jr> jonasschnelli: Linux already has package managers.
266 2015-05-27 20:46:49 <jonasschnelli> Luke-Jr: going over a linux package manager, isn't that somehow centralized and doesn't that bypass the gitian sigs?
267 2015-05-27 20:47:20 <jonasschnelli> or lets say bypass the verifying of the gitian signatures.
268 2015-05-27 20:48:33 <Luke-Jr> jonasschnelli: yes, each package manager ideally needs to be taught about gitian
269 2015-05-27 20:48:49 <harding> Hmm.  This just got me thinking about the magnet links we now promote.  It seems the URN they use is just a SHA1 hash; should we be worried about somebody making a compromised torrent with the same hash?
270 2015-05-27 20:48:49 <Luke-Jr> that's probably even more work
271 2015-05-27 20:49:12 <Luke-Jr> harding: doesn't matter, since it's not meant to be secure at that level?
272 2015-05-27 20:49:30 <Luke-Jr> harding: git also uses SHA1, so if it is so easily compromised, we have bigger issues anyway
273 2015-05-27 20:50:26 <harding> Luke-Jr: I agree the user is supposed to verify the signature belongs to real wumpus (the sig file is in the torrent), but I doubt any more of them do it correctly than do it for downloads from bitcoin.org.
274 2015-05-27 20:51:55 <Luke-Jr> maybe some day we should build a simple Qt app that displays "If this was a real malware, you'd be infected. Check signatures before installing any software on your Bitcoin system!" and put it up with bad sigs
275 2015-05-27 20:52:26 <harding> I've heard that a sha1 collision is a low-millions-USD attack, which might not be worth it for git (which is only used by developers), but which might be worth it for releases if magnetting ever got popular among holders of high bitcoin values.
276 2015-05-27 20:53:15 <helo> there is nothing that can be put in a blockchain torrent that isn't validated
277 2015-05-27 20:53:26 <harding> (I don't think that's the case today.  My seed ratio for the 0.10.2 torrent is only at 15 so far.)
278 2015-05-27 20:53:59 <harding> helo: Talking about the Bitcoin Core binaries, not the torrent.  See the magnet link here: https://bitcoin.org/en/download
279 2015-05-27 20:54:10 <helo> oh, my mistake
280 2015-05-27 20:55:01 <Luke-Jr> harding: releases come from git
281 2015-05-27 20:56:11 <harding> Luke-Jr: yes, but all of the gitian signers have their own histories, so (hopefully) corruption would be noticed.
282 2015-05-27 20:56:33 <Luke-Jr> harding: histories are tracked by SHA1 hash; I don't think anyone would notice.
283 2015-05-27 20:57:28 <harding> Luke-Jr: yes, but if an attacker changed history on GitHub using a collision, your git wouldn't download it because it has the same hash as data you already have.
284 2015-05-27 20:57:45 <harding> The people who did download it would get different gitian hashes than you.
285 2015-05-27 20:58:00 <Luke-Jr> I suppose
286 2015-05-27 21:12:03 <BlueMatt> is there an rpc to get the p2sh address for an arbitrary script?
287 2015-05-27 21:15:08 <Luke-Jr> BlueMatt: there shouldn't be.. :p
288 2015-05-27 21:24:22 <gmaxwell> BlueMatt: decodescript
289 2015-05-27 21:24:55 <gmaxwell> Luke-Jr: it's a very useful tool to verify the contract you're paying to is the one you think you're paying to.
290 2015-05-27 21:25:23 <Luke-Jr> gmaxwell: yes, but it isn't a tool that has any need of being remote
291 2015-05-27 21:27:33 <gmaxwell> Luke-Jr: indeed, not beyond the fact that RPC is the only kind of FFI that many developers today know how to use.
292 2015-05-27 21:34:31 <temujin> gmaxwell: FFI?
293 2015-05-27 21:37:59 <gmaxwell> Foreign function interface, e.g. how you call software written in another language from your PHP or Rails app.
294 2015-05-27 21:45:10 <ahmed_> does anyone know how i can get the raw block from the hash?
295 2015-05-27 21:45:26 <ahmed_> without RPC
296 2015-05-27 21:53:24 <BlueMatt> gmaxwell: is there a way to get the hash160 of the script's p2sh (or any address, i suppose)
297 2015-05-27 21:53:44 <gmaxwell> BlueMatt: I don't think there is any rpc mechenism for that.
298 2015-05-27 21:54:53 <BlueMatt> :(
299 2015-05-27 21:56:59 <temujin> BlueMatt: doesn't the python-bitcoinlib library have a Hash160 function?
300 2015-05-27 21:57:10 <BlueMatt> probably
301 2015-05-27 22:03:28 <ahmed_> anyone?
302 2015-05-27 22:04:23 <gmaxwell> ahmed_: getblock <blockhash> false
303 2015-05-27 22:04:38 <ahmed_> gmaxwell: i need to do it without RPC though
304 2015-05-27 22:04:53 <gmaxwell> I misread, though you said without p2p.
305 2015-05-27 22:05:09 <ahmed_> or if i could generate it from mining.notify and mining.submit responses then that would be fine. I'm storing that data in my db
306 2015-05-27 22:05:23 <gmaxwell> ahmed_: you've not said what with.  Shall I recommend you saccrifice a goat to summon a deamon to ask it?
307 2015-05-27 22:06:48 <ahmed_> haha. Basically im working on a way to tell what a pool is mining (from a miners perspective). So basically ive been recording the mining.notify and mining.submit responses in my db and i want to either construct the block from that. or from the blockhash that i submit to the pool.
308 2015-05-27 22:47:57 <Bitswim> Anyone familiar with pybitcointools able to help me add my blockchain.info api key to get it to use that so my requests stop timing out?
309 2015-05-27 23:03:25 <sythaeryn> can you use the bitcoin daemon to send payments on any other ports? isp blocks 8333
310 2015-05-27 23:06:54 <belcher> im not 100% but you could listen on port 80 and ask someone to connect to you
311 2015-05-27 23:06:57 <belcher> or go over tor
312 2015-05-27 23:07:12 <belcher> or there might exist nodes already listening on another port and you just connect to them
313 2015-05-27 23:08:38 <sythaeryn> wait
314 2015-05-27 23:09:02 <sythaeryn> if i set up a daemon to listen on port XYZ and the 'sender' sent on port xyz could my client receive legit, and resend?
315 2015-05-27 23:09:23 <s7r> yes
316 2015-05-27 23:09:27 <sythaeryn> ok
317 2015-05-27 23:09:55 <s7r> but if you have 8333 blocked, you won't be able to connect to many other nodes.
318 2015-05-27 23:10:16 <s7r> why don't you use it over Tor. secondly, this is a #bitcoin question, not -dev ;)
319 2015-05-27 23:10:16 <sythaeryn> s7r: i have a server setup and running, how can i create a wallet and receive / send from it at linux command prompt
320 2015-05-27 23:10:48 <sythaeryn> im trying to dev a process for people in hotels that block 8333
321 2015-05-27 23:40:12 <Bitswim> Anyone familiar with pybitcointools able to help me add my blockchain.info api key to get it to use that so my requests stop timing out?