1 2015-02-11 00:24:37 <rgenito> anyone know of a reliable javascript library to determine whether or not a bitcoin address is valid?
  2 2015-02-11 00:24:51 <rgenito> i've used 2 so far, and both of them have false negatives. (1 has significantly more false negatives than the other...)
  3 2015-02-11 01:06:52 <SubCreative> <3
  4 2015-02-11 01:10:48 <freewil> rgenito: have you tried this: https://github.com/defunctzombie/bitcoin-address ?
  5 2015-02-11 01:18:36 <rgenito> freewil, heya!
  6 2015-02-11 01:18:54 <rgenito> freewil no i haven't... thank you! i'll check it out
  7 2015-02-11 01:19:19 <rgenito> awww man, this is one of those node.js things, right?
  8 2015-02-11 01:20:11 <freewil> yeah
  9 2015-02-11 01:20:28 <freewil> if you're just looking for a script to include on a webpage you should be able to browserify it
 10 2015-02-11 01:21:35 <rgenito> "browserify" ?
 11 2015-02-11 01:21:52 <rgenito> ahh ok, i thought you meant something special :) you probably just meant "copy/paste the code to your browser app" :D
 12 2015-02-11 01:23:06 <freewil> browserify is a tool to take a node.js module (commonJS) and make it usable in a brower
 13 2015-02-11 01:23:21 <freewil> https://github.com/substack/node-browserify
 14 2015-02-11 01:25:49 <rgenito> wow nice, thanks freewil :)
 15 2015-02-11 01:26:50 <freewil> you're welcome - there the github readme can be confusing
 16 2015-02-11 01:27:04 <freewil> there is a good hello world example http://browserify.org
 17 2015-02-11 01:51:09 <brand0> rgenito, if you browserify, you will probably also need a cors proxy unless you're only running against localhost
 18 2015-02-11 01:52:28 <brand0> rgenito, I use this one personally https://github.com/gr2m/CORS-Proxy
 19 2015-02-11 01:52:35 <akstunt600> heh i just take a break from aglio and api blueprint and see this
 20 2015-02-11 01:52:36 <akstunt600> LMAO
 21 2015-02-11 01:52:58 <akstunt600> >.<
 22 2015-02-11 01:54:10 <brand0> say wuuuutt
 23 2015-02-11 03:23:00 <whitesn> hello, does anyone have reference as to where did the first bitcoin come from?
 24 2015-02-11 03:24:06 <whitesn> I tried to search on wiki and some other references, but they only specified that it is produced from mining, but I thought the people having the transaction are paying the miners for solving the hash problems instead of the money being produced, so I assume that bitcoin is zero sum game?
 25 2015-02-11 03:25:57 <justanotheruser> whitesn: #bitcoin
 26 2015-02-11 03:26:02 <whitesn> according to wiki Satoshi Nakamoto produces the first 50 bitcoins by mining a transaction, but where did this come from? And I also saw there was a flaw in the system resulting on obscene amount of bitcoins being produced, then the transaction was voided. I thought all leverages of bitcoins are being held by each respective owner and can only be modified by the transaction request, how was this being
 27 2015-02-11 03:26:04 <whitesn> solved? Sorry if I'm asking frequent question, I tried to search this and can't seem to find the answer
 28 2015-02-11 03:26:33 <whitesn> justanotheruser: oh, okay thanks for the reference :)
 29 2015-02-11 05:03:33 <earlz> So, I did have gitian building... but then it broke :(
 30 2015-02-11 05:03:35 <earlz> aclocal: couldn't open directory `build-aux/m4': No such file or directory
 31 2015-02-11 05:03:35 <earlz> autoreconf2.50: aclocal failed with exit status: 1
 32 2015-02-11 05:03:37 <earlz> lxc-start: Connection refused - inotify event with no name (mask 32768)
 33 2015-02-11 05:05:52 <earlz> or maybe this is the actual error..
 34 2015-02-11 05:05:53 <earlz> ./bin/gbuild:21:in `system!': failed to run on-target setarch x86_64 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError)
 35 2015-02-11 05:06:07 <earlz> how the hell do you figure out what the actual problem is there?
 36 2015-02-11 05:07:48 <Luke-Jr> that's bitcoin?
 37 2015-02-11 05:12:17 <fanquake> earlz libtool installed?
 38 2015-02-11 05:16:06 <Luke-Jr> fanquake: it's gitian supposedly
 39 2015-02-11 05:32:33 <earlz> bleh I was running into this issue https://github.com/bitcoin/bitcoin/issues/4269
 40 2015-02-11 05:35:01 <earlz> Is there any obvious way to figure out what the problem is when anything in gitian fails?
 41 2015-02-11 05:35:26 <earlz> It seems like any failure I've ever had was the basic "can't execute system!" error, with logs revealing nothing more
 42 2015-02-11 05:36:19 <fanquake> Have you been checking in the build/install logs
 43 2015-02-11 05:39:49 <earlz> var/build.log? yes
 44 2015-02-11 06:16:40 <phantomcircuit> bitcoind on zfs on linux causes a null pointer dereference
 45 2015-02-11 06:16:42 <phantomcircuit> dats not good
 46 2015-02-11 08:16:08 <wumpus> phantomcircuit: can you be more specific?
 47 2015-02-11 08:19:18 <sipa> phantomcircuit: my bitcoind runs on zfs; never had any problems
 48 2015-02-11 09:34:04 <magicien> hello all, quick question for who is using the bitcoin-qt application on Linux: my recent transactions and transactions windows in general are empty and not displaying any data.
 49 2015-02-11 09:34:15 <magicien> Did anybody ever had this issue? wrong libraries? bug?
 50 2015-02-11 09:36:08 <wumpus> not really? how/when did that start happening? are you using a self-compiled version or executables from bitcoin.org?
 51 2015-02-11 09:38:09 <magicien> wumpus: self-compiled and this is an issue that was there since the beginning
 52 2015-02-11 09:38:20 <magicien> at first i thought it did that because it was still syncing the transactions
 53 2015-02-11 09:38:31 <magicien> but all is synced now and it's still happening
 54 2015-02-11 09:38:51 <magicien> it might be because of my windows manager ( fluxbox ), not sure
 55 2015-02-11 09:39:07 <magicien> wumpus: sorry, it's an executable from bitcoin.org!
 56 2015-02-11 10:03:10 <wumpus> magicien: I don't get it, if you have that problem from the beginning, why are you expecting to see any transactions?
 57 2015-02-11 11:07:16 <magicien> wumpus: don't worry, probably a weird issue only affecting me and related to my linux setup :)
 58 2015-02-11 11:09:16 <wumpus> maybe try compiling from source (make sure you grab the right tag from git, e.g. v0.9.4 or v0.10.0rc4 respectively) and see if that makes a difference
 59 2015-02-11 11:30:08 <magicien> wumpus: i will, thanks
 60 2015-02-11 11:30:29 <fanquake> ;;blocks
 61 2015-02-11 11:30:30 <gribble> 342994
 62 2015-02-11 12:54:50 <fanquake> ;;blocks
 63 2015-02-11 12:54:51 <gribble> 343004
 64 2015-02-11 13:13:23 <hearn> good afternoon
 65 2015-02-11 14:00:30 <gdm85> 'afternoon
 66 2015-02-11 14:00:59 <gdm85> any tips to speed up addresses generation? I am testing with keypool=100 (testnet)
 67 2015-02-11 14:02:08 <gdm85> it doesn't seem to be parallel, by the way.
 68 2015-02-11 14:07:31 <paveljanik> gdm85, bitcoind has to do a lot more than generating address...
 69 2015-02-11 14:07:41 <paveljanik> add it to the wallet etc.
 70 2015-02-11 14:07:56 <paveljanik> why do that in bitcoin core?
 71 2015-02-11 14:09:33 <gdm85> paveljanik: mostly because it's ubiquitous in the development environment I use now.
 72 2015-02-11 14:09:56 <gdm85> paveljanik: which wallet(s) do you prefer for real use?
 73 2015-02-11 14:10:23 <paveljanik> this is completely different question, orthogonal one.
 74 2015-02-11 14:10:27 <Jouke> gdm85: if you don't encrypt the wallet, it wil automatically fill the keypool once a new address is used.
 75 2015-02-11 14:10:34 <paveljanik> generating addresses is a job for separate tool.
 76 2015-02-11 14:10:53 <Jouke> So you don't need a big keypool if you don't encrypt it
 77 2015-02-11 14:11:25 <gdm85> Jouke: the idea was to pre-fill the keypool to offset that generation time.
 78 2015-02-11 14:11:39 <Jouke> You do need to create backups more often, but since it is testwallet, in probably doesn't matter that much
 79 2015-02-11 14:16:49 <gdm85> paveljanik: why would it be orthogonal, by the way?
 80 2015-02-11 14:17:07 <gdm85> e.g. (address generation) not related to (wallet software)?
 81 2015-02-11 14:17:23 <paveljanik> it is completely irrelevant in this case, no?
 82 2015-02-11 14:19:43 <paveljanik> you can generate addresses outside of the wallet and import it at the end.
 83 2015-02-11 14:20:20 <paveljanik> by generating addresses one by one and do everything needed for every address, you have to be slower...
 84 2015-02-11 14:47:54 <wumpus> gdm85: batched RPC could help if you're making a lot of newaddress calls
 85 2015-02-11 14:48:39 <wumpus> I wouldn't recommend generating addresses with a third-party tool unless you're very sure of it, as some are known to have randomness issues
 86 2015-02-11 14:49:57 <wumpus> also, if the goal is for all keys to end up in the bitcoin core wallet, importing the keys is going to take approximately the same time
 87 2015-02-11 14:53:32 <gdm85> wumpus: the use-case scenario is (questionably) simple: I am testing an API that uses under the hood a bitcoind wallet. in order to decouple the address generation time (as in production likely bitcoind won't be responsible for this task anyway) from the benchmarking/testing of the API itself, I chose to pre-generate 500 (now reduced to 100) addresses with the keypool=500 option
 88 2015-02-11 14:54:19 <gdm85> I am stretched between using a poor practice for testing/developing, and then later on replace it with the proper solution in production. but experience/common sense tells me that I should just look into the latter now and run baseline tests accordingly.
 89 2015-02-11 14:56:05 <wumpus> but which part is slow? if you provide e.g. keypool=500, it generates the 500 keys on first start, and will deal them out when you ask for a new address
 90 2015-02-11 14:56:13 <gdm85> thanks for the info, btw. yes I am aware of such fancy tools that have questionable practices, although now I was using bitcoind not for its quality of private key generation but rather for the comfortable fact I have it already in the development environment.
 91 2015-02-11 14:56:37 <gdm85> wumpus: it generates about 1 every 1.2 seconds, delaying the time of wallet being online.
 92 2015-02-11 14:57:10 <gdm85> I've seen (experimentally) that it is tied to the /dev/random bits availability.
 93 2015-02-11 14:57:23 <wumpus> strange, the inittial keypool creation was never super-fast here but neither so slow
 94 2015-02-11 14:57:40 <gdm85> possibly my /dev/random has not enough bits?
 95 2015-02-11 14:57:42 <wumpus> I doubt openssl's random generator is bound by that
 96 2015-02-11 14:58:00 <wumpus> though it would explain a few things performance-wise
 97 2015-02-11 14:58:37 <gdm85> I've made a single test of switching with /dev/urandom (ln -sf /dev/urandom /dev/random, SIN!) and it seemed to go faster, but was just a dumb test, nothing I am willing to use not even in development.
 98 2015-02-11 14:59:11 <wumpus> ok
 99 2015-02-11 14:59:22 <gdm85> I will look more into this, it's a development server so *many* pieces of software run at the same time there.
100 2015-02-11 15:03:01 <Jouke> gdm85: let's plug in the hardware rng? :)
101 2015-02-11 15:04:40 <gdm85> Jouke: ? not enough elements to say it's that.
102 2015-02-11 15:05:13 <Jouke> ok
103 2015-02-11 15:05:53 <magicien> i recommend you don't link /dev/random to /dev/urandom
104 2015-02-11 15:05:58 <magicien> unless you were jocking :)
105 2015-02-11 15:06:51 <gdm85> magicien: the proper thing to do is to 1) read how openssl bottlenecks for randomness 2) monitor randomness bits availability under load
106 2015-02-11 15:08:00 <helo> does openssl actually pull from /dev/random?
107 2015-02-11 15:08:10 <helo> oh, wrong channel sorry
108 2015-02-11 15:08:21 <magicien> lsof | grep random
109 2015-02-11 15:12:06 <gdm85> magicien: the thing to not do is link /dev/random *AND* /dev/urandom to /dev/zero. although it would make for a fun exercise, to detect how effects propagates in your systems :)
110 2015-02-11 15:13:14 <magicien> hah
111 2015-02-11 15:13:22 <magicien> i never tried that and i shall not
112 2015-02-11 15:14:09 <magicien> i just remember generating encryption keys generating entropy in /dev/random while furiously moving my mouse around
113 2015-02-11 15:14:17 <magicien> years ago when i was using loop-aes
114 2015-02-11 15:14:55 <magicien> whereas /dev/urandom is more generous on data but perhaps or more certainly less secure than using /dev/random
115 2015-02-11 15:15:30 <magicien> anyway my bitcoin-qt windows are emtpy so i'm not even at that stage yet hah
116 2015-02-11 15:16:15 <gdm85> magicien: in my case the /dev/urandom is bind-mounted (imagine a chroot) from a linux host with proper /dev/random, so overriding /dev/random with /dev/urandom is not what usually would happen on a normal native linux (less catastrophic), but still.. as I said was a quick test.
117 2015-02-11 15:18:27 <magicien> ok so you have this in a container, not the host itself
118 2015-02-11 15:20:52 <gdm85> magicien: yes
119 2015-02-11 15:22:27 <gdm85> VMs/containers are easily subject to degradation of quality/availability of randomness, it's necessary to keep an eye on it. but as always: no fact until measured/proven.
120 2015-02-11 17:51:04 <kethzer> Hi
121 2015-02-11 17:52:02 <kethzer> I would like to know what is the best way to increase entropy for /dev/random
122 2015-02-11 17:52:18 <helo> hardware
123 2015-02-11 17:52:49 <kethzer> ?
124 2015-02-11 17:52:49 <kethzer> I there any software I can use that will get me close enough
125 2015-02-11 17:53:05 <helo> software cannot create entropy
126 2015-02-11 17:53:37 <helo> it can stretch out the entropy it gets from hardware, but that's it
127 2015-02-11 17:53:46 <helo> bah, wrong channel again
128 2015-02-11 17:54:12 <kethzer> Ok thanks helo:
129 2015-02-11 17:59:05 <morcos> is anyone aware of a greater than 1-block reorg in the last couple months?   i'm trying to see how some code behaves during reorg, but not sure there has been one greater than 1 block recently
130 2015-02-11 18:50:29 <hearn> morcos: use regtest mode and see if you can dig out sipa's block blacklisting patch
131 2015-02-11 18:50:34 <hearn> morcos: that's the best way to test re-orgs
132 2015-02-11 18:51:18 <kanzure> qa rpc tests has some regtest testing things that are quite simple in python land
133 2015-02-11 18:51:29 <kanzure> mine some blocks on a separate regtest instance, then sync the instances together
134 2015-02-11 18:51:38 <kanzure> those examples exist and work in the source code
135 2015-02-11 18:57:34 <L_Cranston_Shado> @jonasschnelli, it’s fixed, just an fyi. Unless there’s a good reason to, I’m not touching that branch with a 10 foot pole
136 2015-02-11 18:58:02 <L_Cranston_Shado> not even looking in its general direction… I will cross the street to avoid it
137 2015-02-11 19:00:49 <morcos> hearn: thanks, good idea
138 2015-02-11 19:02:21 <jonasschnelli> L_Cranston_Shado, Okay. Now it looks good.
139 2015-02-11 19:03:06 <L_Cranston_Shado> I have a bunch of phantom forks now too but I’ll wait until this PR gets closed and merged before I clean it up (probably by deleting my whole fork and re-forking)… which sounds very dirty
140 2015-02-11 19:03:55 <jonasschnelli> L_Cranston_Shado, Yes. Try the git pro book once: http://git-scm.com/book/de/v1
141 2015-02-11 19:03:57 <L_Cranston_Shado> presumably, the fork listed on on the PR is the only one actually linked in, but can’t be too careful after the last one got auto-closed
142 2015-02-11 19:04:35 <jonasschnelli> L_Cranston_Shado, you can always have a fresh start by deleting your local bitcoin.git clone and recreating it. You can also remote delete your github branches...
143 2015-02-11 19:05:12 <L_Cranston_Shado> Thanks, I’ll look into it. I’ll probably choose English though since learning German just to learn Git seems kind of the long route
144 2015-02-11 19:05:40 <L_Cranston_Shado> jonasschnelli, is it pretty safe to assume that the branch listed on the PR is the only branch that I have to worry about not deleting?
145 2015-02-11 19:06:12 <L_Cranston_Shado> after the debacle with the last PR, I’m understandably a bit gun shy
146 2015-02-11 19:06:31 <jonasschnelli> hearn, how was you lighthouse presentation yesterday? Couldn't attend unfortunately.
147 2015-02-11 19:06:36 <hearn> hey
148 2015-02-11 19:06:40 <hearn> it went well
149 2015-02-11 19:06:45 <hearn> quite a few people turned up, i was flattered
150 2015-02-11 19:07:06 <jonasschnelli> hearn, hu. Cool.
151 2015-02-11 19:07:07 <L_Cranston_Shado> sorry, be back in a bit, thanks again for your help Jonas
152 2015-02-11 19:07:18 <jonasschnelli> L_Cranston_Shado, thanks for your pull!
153 2015-02-11 19:09:24 <jonasschnelli> Oh. Lighthouse autoupdate. Nice.
154 2015-02-11 19:11:43 <hearn> hmm last update i pushed was last week some time, or earlier :)
155 2015-02-11 19:12:18 <jonasschnelli> hearn, is there no project browsing with the app?
156 2015-02-11 19:12:40 <hearn> jonasschnelli: https://www.vinumeris.com/lighthouse/faq#how-do-i-find-projects
157 2015-02-11 19:12:54 <sipa> hearn, morcos: block blacklisting is in 0.10 and master (though undocumented)
158 2015-02-11 19:13:11 <hearn> ah cool
159 2015-02-11 19:13:16 <hearn> sipa: it's still the blacklistblock rpc?
160 2015-02-11 19:13:30 <sipa> invalidateblock & reconsiderblock
161 2015-02-11 19:13:59 <hearn> cool
162 2015-02-11 19:14:02 <hearn> that's very useful, thanks
163 2015-02-11 19:17:20 <jonasschnelli> hearn, there is a missing core project: "Bitcoin Core add SPV mode and transform to documented library" *duck*
164 2015-02-11 19:17:37 <hearn> hey, if you want to raise money for that, just let me know :)
165 2015-02-11 19:18:01 <hearn> there is a project that alex waters is trying to raise money for, to do bitcointesting.org
166 2015-02-11 19:18:10 <hearn> autobuilding of every open pull request with downloads, etc, plus guide to how to test
167 2015-02-11 19:18:49 <jonasschnelli> hearn, per pull request building is already done: https://builds.jonasschnelli.ch/pulls/
168 2015-02-11 19:19:01 <jonasschnelli> hearn, it currently turned off because of security concerns.
169 2015-02-11 19:19:22 <hearn> builds not sandboxed?
170 2015-02-11 19:19:49 <jonasschnelli> hearn, not really, i mean it's gitian. But the gitian descriptors are also open for a pull request
171 2015-02-11 19:19:57 <jonasschnelli> so first it would need some sanity around it
172 2015-02-11 19:20:01 <hearn> right
173 2015-02-11 19:20:34 <jonasschnelli> and there is also the problem of limited cpu resources. A gbuild with -j 5 takes around 15min (for all three platforms)
174 2015-02-11 19:21:09 <jonasschnelli> basically it only misses basic sanity.
175 2015-02-11 19:22:28 <jonasschnelli> But im not sure if building issues or the capability to build is the bottleneck. I mean it also needs a basic understanding of what you are testing... maybe the bottleneck is a missing of enough devs interested in bitcoin-core
176 2015-02-11 19:23:32 <jonasschnelli> hearn: drag and drop a file into lighthouse app (OSX dock) works, but project does not appears
177 2015-02-11 19:24:21 <hearn> jonasschnelli: huh, ok. what if you drag it onto the window itself?
178 2015-02-11 19:24:35 <hearn> i haven't tested dragging onto the dock icon, just dragging onto the window
179 2015-02-11 19:26:19 <jonasschnelli> hearn, drag'n'drop directly into the window works... Dock not. But low prio. Just stepped over it.
180 2015-02-11 19:26:47 <hearn> hm, ok. i'll have a look. probably it's to do with how i'm listening for the drop
181 2015-02-11 19:26:55 <hearn> perhaps dropping onto the dock icon does things a different way
182 2015-02-11 19:27:13 <jonasschnelli> hearn, could be. But IMO it's a very convenient way of opening files...
183 2015-02-11 19:27:58 <hearn> yes, you're right
184 2015-02-11 19:45:42 <btcflow> http://www.btc-flow.com/r/97d1814a1d
185 2015-02-11 21:32:54 <gdm85> jonasschnelli: have you guys considered using containers for this?
186 2015-02-11 21:33:31 <gdm85> I had already made an automation here: https://github.com/gdm85/tenku/blob/master/docker/scripts/bitcoin-gitian-build.sh
187 2015-02-11 23:48:24 <L_Cranston_Shado> For Gitian does Debian 7.8 work ok or does it have to be 7.7?