1 2015-04-05 00:02:21 <gmaxwell> In any case, for the non-wallet parts of bitcoin core you should be thinking "systems programming" ... more "OS kernel" than "enduser application".  Doesn't mean we couldn't use QT there, but thats not really QT's focus area.
  2 2015-04-05 00:03:47 <xhoch3> yeah, I got what you were saying :P
  3 2015-04-05 00:04:00 <xhoch3> let's see if it builds now
  4 2015-04-05 00:06:19 <xhoch3> there is even boost code int the Qt gui code, now that's creative :P
  5 2015-04-05 00:09:22 <gmaxwell> xhoch3: sure, we use boost for the things we normally use boost for.
  6 2015-04-05 00:09:51 <gmaxwell> (e.g. stuff that will eventually get replaced with native C++ stuff once our build targets catch up with the language)
  7 2015-04-05 00:13:54 <xhoch3> ok, I was lurking at the Qt stuff and it looks quite good. I would change some things, but I'd say I am being overcritical in this point.
  8 2015-04-05 00:14:03 <xhoch3> at least it's readable
  9 2015-04-05 00:15:28 <gmaxwell> The wallet/qt parts of bitcoin core are somewhat starved of attention. Most of us are focused on keeping the network running. We could use more help in the QT/wallet parts.
 10 2015-04-05 00:18:09 <xhoch3> I don't quite understand why you need to have bitcoind linked against the gui? I am unexperienced regarding bitcoins, so forgive me. But from a distance view it all sounds like if were completely unrelated things
 11 2015-04-05 00:19:31 <xhoch3> I know we did this in octave for technical reasons, but it would have been better the octave gui was seperate
 12 2015-04-05 00:20:27 <xhoch3> ok, now buidl went through
 13 2015-04-05 00:23:26 <gmaxwell> xhoch3: bitcoind is completely seperate from the GUI; as mentioned you can build it without a trace of QT on your system, and with none of the files in src/qt/.   The otherway around is not so, mostly due to historical reasons. Originally Bitcoin was a monolithic wxwindows application with the GUI code freely intermixed in the consensus code.  (it was also a much smaller codebase-- I think the first
 14 2015-04-05 00:23:30 <xhoch3> oh yeah, the GUI needs some love
 15 2015-04-05 00:23:32 <gmaxwell> release some something like 15kloc, so this was more excusable)
 16 2015-04-05 00:24:18 <xhoch3> ok, my question was, if bitcoind is running (without Qt)
 17 2015-04-05 00:24:37 <xhoch3> can I make a client interfacing bitcoind using Qt?
 18 2015-04-05 00:24:52 <xhoch3> without having it all in one huge monolithic app
 19 2015-04-05 00:25:55 <xhoch3> the Qt app should be seperate from bitcoind, too
 20 2015-04-05 00:26:53 <Luke-Jr> xhoch3: Qt is realistically a competing programming language vs C++ these days; for most of Bitcoin Core, we chose to use C++ for various reasons, and only do the GUI in Qt
 21 2015-04-05 00:27:14 <xhoch3> Luke-Jr, ?
 22 2015-04-05 00:27:24 <xhoch3> I already got that long ago
 23 2015-04-05 00:27:26 <Luke-Jr> k
 24 2015-04-05 00:27:35 <Luke-Jr> I was catching up
 25 2015-04-05 00:27:36 <xhoch3> I am talking about something entirely different
 26 2015-04-05 00:28:10 <xhoch3> namely what it would take to have the Qt app separated from bitcoind
 27 2015-04-05 00:28:12 <Luke-Jr> xhoch3: having the Qt app separate is a long-term goal for the project, just it's a slow process
 28 2015-04-05 00:29:26 <Luke-Jr> ideally it would be something like libconsensus<->bitcoin node daemon<->bitcoin wallet service<->GUI for example
 29 2015-04-05 00:32:49 <xhoch3> I read bitcoind talks with json rpc
 30 2015-04-05 00:34:16 <xhoch3> so this is what a GUI/CLI should be interfacing: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
 31 2015-04-05 00:36:34 <xhoch3> probably makes sense to package that as a pod: https://github.com/OSSystems/qt-json-rpc
 32 2015-04-05 00:37:02 <sipa> xhoch3: the json RPC isn't really designed for implementing a GUI on top; it misses notifications, asynchronous processing, and is generally not very efficient
 33 2015-04-05 00:37:25 <sipa> the bitcoin core GUI is just an optional module inside the binary right now
 34 2015-04-05 00:38:16 <sipa> (sorry if i'm not making sense; i just chimed in)
 35 2015-04-05 00:38:57 <xhoch3> at some point you will have to do the interfacing part
 36 2015-04-05 00:39:07 <xhoch3> if you want to have it clean
 37 2015-04-05 00:39:42 <xhoch3> and as the json rpc works across networks, it would be an elegant solutions
 38 2015-04-05 00:40:44 <xhoch3> ok, but I'm not out to start a discussion on that, all I can say is that what Luke-Jr said makes sense to me, although the service part is rather a detail of the app impl
 39 2015-04-05 00:41:08 <xhoch3> from a gut feeling I'd say that's the way to head
 40 2015-04-05 00:42:11 <gmaxwell> We'd certantly like to seperate the gui from the rest in the long term, the exact best way to do it is less clear; the current RPC interface is not the right interface for it.
 41 2015-04-05 00:43:01 <gmaxwell> (and in general, json rpc is just orders of magnitude slower than the current communications due to the varrious overheads)
 42 2015-04-05 00:46:00 <lechuga_> really curious to see how the wallet svc gets cut out
 43 2015-04-05 00:47:30 <xhoch3> seems like electrum is two steps further here
 44 2015-04-05 00:47:37 <xhoch3> browsing thei code
 45 2015-04-05 00:47:41 <phantomcircuit> xhoch3, the rpc stuff is orders of magnitude too slow
 46 2015-04-05 00:47:43 <xhoch3> they also use Qt
 47 2015-04-05 00:47:59 <phantomcircuit> oh gmaxwell already said that
 48 2015-04-05 00:48:32 <phantomcircuit> lechuga_, it's actually relatively easy to do, you build an spv client which connects to a trusted full node
 49 2015-04-05 00:48:36 <phantomcircuit> the spv client is the wallet
 50 2015-04-05 00:48:40 <xhoch3> as electrum is that far, maybe it doesn't make sense to develop another GUI at all
 51 2015-04-05 00:48:51 <lechuga_> phantomcircuit: i wasnt sure if thats the architecture that was planned
 52 2015-04-05 00:49:08 <phantomcircuit> lechuga_, that's what's mostly been discussed in the past
 53 2015-04-05 00:49:44 <phantomcircuit> the current wallet code is very conservative and does things like iterate over all the transactions it knows about to calculate your balance instead of just the known unspent transaction outputs
 54 2015-04-05 00:49:50 <phantomcircuit> (caching being hard to get right!)
 55 2015-04-05 00:50:10 <gmaxwell> xhoch3: suggest you try actually running the electrum server softwar and client and come back. :)
 56 2015-04-05 00:50:23 <xhoch3> I do right now, works great
 57 2015-04-05 00:50:33 <xhoch3> and looks very clean
 58 2015-04-05 00:50:54 <xhoch3> v1.9.8
 59 2015-04-05 00:55:17 <gmaxwell> xhoch3: you're not running the server, I assume.
 60 2015-04-05 00:55:28 <gmaxwell> (electrum has a different trust model)
 61 2015-04-05 00:56:25 <xhoch3> no, but still the architecture seems to like what you want to go to sometimes
 62 2015-04-05 00:57:05 <xhoch3> I would definately elaborate if it is possible to work together with these guys to incorporate their code and fix annoyances
 63 2015-04-05 00:57:51 <xhoch3> for example, better inform the user about potential risks at the initial setup stage etc
 64 2015-04-05 00:58:13 <xhoch3> and offer an option to locally run a server, too
 65 2015-04-05 00:59:09 <gmaxwell> They're not interested.
 66 2015-04-05 00:59:21 <Luke-Jr> xhoch3: Electrum's networking is terrible
 67 2015-04-05 00:59:24 <gmaxwell> I tried this years ago, also with armory.
 68 2015-04-05 00:59:40 <Luke-Jr> and the wallet is in their GUI, which is … not really ideal (although a step forward ofc)
 69 2015-04-05 00:59:49 <gmaxwell> also that particular server model has pretty signiciant additional costs.
 70 2015-04-05 01:00:57 <Luke-Jr> I spent a few hours once trying to port Bitcoin Core's GUI to Electrum, and decided it would be more effort than reimplementing Electrum's features in Bitcoin Core..
 71 2015-04-05 01:01:33 <xhoch3> to be honest I would entirely drop bitcoin core's qt client
 72 2015-04-05 01:01:45 <xhoch3> knowingly that there are alternatives
 73 2015-04-05 01:01:54 <xhoch3> and rather pay attention to the core development
 74 2015-04-05 01:01:57 <gmaxwell> xhoch3: there really aren't alternatives.
 75 2015-04-05 01:02:19 <gmaxwell> (There are other things but they have different properties and serve different needs)
 76 2015-04-05 01:03:41 <xhoch3> well guys, it's your limited lifetime. I am not going to waste mine :] The next time you're talking to the electrum guys make sure the first thing you tell isn't "Your networking is terrible" :D
 77 2015-04-05 01:04:00 <phantomcircuit> xhoch3, as i mentioned above the bitcoin core wallet makes a number of extremely conservative design decisions which no other wallet has replicated
 78 2015-04-05 01:04:00 <xhoch3> sounds more like a social than a technical problem
 79 2015-04-05 01:04:09 <phantomcircuit> which makes it unique
 80 2015-04-05 01:04:42 <xhoch3> phantomcircuit, okok I have understood ;) unique
 81 2015-04-05 01:04:57 <xhoch3> have a nice day!
 82 2015-04-05 01:06:04 <phantomcircuit> that was a bit bizarre
 83 2015-04-05 01:07:20 <Apocalyptic> guy still thinks he knows better, not much to be done
 84 2015-04-05 01:08:31 <phantomcircuit> gpg --recv-keys $(gpg --list-sigs|grep -F "User ID not found"|grep -E '[0-9A-F]{8}' -o|sort|uniq)
 85 2015-04-05 01:08:33 <phantomcircuit> that was amusing
 86 2015-04-05 01:08:48 <phantomcircuit> started from peter todds gpg key and ended up with ~30k pubkeys
 87 2015-04-05 01:09:03 <phantomcircuit> hit linus torvalds and things went sideways
 88 2015-04-05 01:11:58 <Luke-Jr> lol
 89 2015-04-05 01:20:06 <phantomcircuit> Luke-Jr, it's interesting to see who has signed whose public key
 90 2015-04-05 01:20:34 <phantomcircuit> and how poorly gpg handles a large trust database
 91 2015-04-05 02:02:12 <Luke-Jr> BlueMatt: all your PGP keys are revoked? O.o
 92 2015-04-05 02:18:26 <phantomcircuit> Luke-Jr, 07DF 3E57 A548 CCFB 7530 7091 89BB B866 3E2E 65CE
 93 2015-04-05 02:18:32 <phantomcircuit> (it's signed by greg)
 94 2015-04-05 02:19:19 <Luke-Jr> ty
 95 2015-04-05 09:38:35 <phantomcircuit> gmaxwell, https://github.com/bitcoin/bitcoin/pull/5971
 96 2015-04-05 09:39:26 <phantomcircuit> gmaxwell, so what exactly should the trickle logic be doing?
 97 2015-04-05 09:39:31 <phantomcircuit> is there consensus there?
 98 2015-04-05 09:43:12 <gmaxwell> So without reference to what it actually does, what I belive is that it for most peers it should delay sending any inv until either its triggered by a randomly selected transaction, or the inventory reaches a max size. It wouldn't be insane to have a high random timeout though I don't think it currently does, and it shouldn't really be needed.
 99 2015-04-05 09:43:45 <Arnavion> ... Doesn't that PR just need to just do wait_for(100ms) instead of timed_wait(current time + 100ms) ?
100 2015-04-05 09:44:32 <gmaxwell> the goal is two fold, to provide some timing cover in propagation by batching for privacy; and reducing the exponential growth of INVs so that fewer invs cross in flight.
101 2015-04-05 09:44:32 <phantomcircuit> Arnavion, maybe i dont have a lot of experience with boost threading stuff
102 2015-04-05 09:45:32 <gmaxwell> (if we wanted to be supper snazzy we might measure the rate of INVs crossing in flight and use that to control the rate of the random triggers; might be fun to expirement with that for a future PR)
103 2015-04-05 09:47:00 <phantomcircuit> Arnavion, wait_for is relatively new (ie debian wheezy doesn't have it)
104 2015-04-05 09:47:06 <gmaxwell> (Crossing in flight can be detected by counting how often a peer INVing you on something you 'already' INVed to it, perhaps taking the median or minimum of all peers to avoid broken nodes screwing up the number)
105 2015-04-05 09:49:48 <Arnavion> Introduced in 1.50, it seems
106 2015-04-05 09:51:34 <gmaxwell> bleh.
107 2015-04-05 09:52:09 <phantomcircuit> Arnavion, debian wheezy is 1.49
108 2015-04-05 09:52:10 <phantomcircuit> heh
109 2015-04-05 09:52:13 <Arnavion> Yeah
110 2015-04-05 09:53:45 <gmaxwell> phantomcircuit: what GCC does that have?
111 2015-04-05 09:54:02 <phantomcircuit> gcc (Debian 4.7.2-5) 4.7.2
112 2015-04-05 09:54:08 <gmaxwell> Sooooo.
113 2015-04-05 09:54:30 <phantomcircuit> this cant be good
114 2015-04-05 09:54:42 <gmaxwell> We were talking about perhaps taking 0.11 to C++11 (our binaries are static.. sooo). C++11 has wait_for; would be interesting to see if it has it in GCC 4.7.2's incomplete C++11 support.
115 2015-04-05 09:54:58 <phantomcircuit> hmm
116 2015-04-05 09:55:03 <phantomcircuit> i have no idea
117 2015-04-05 09:55:24 <gmaxwell> Mixing boost and c++11 locking tools doesn't sound like a receipy for success, however. :)
118 2015-04-05 09:55:46 <phantomcircuit> no it doesn't
119 2015-04-05 09:58:16 <Arnavion> submodule a newer libstdc++ in the bitcoin repo, obviously!
120 2015-04-05 09:58:40 <phantomcircuit> huh
121 2015-04-05 09:58:41 <phantomcircuit> that's unexpected
122 2015-04-05 09:58:42 <phantomcircuit> it looks like acquiring the lock for the conditional is a serious performance blow
123 2015-04-05 09:58:50 <phantomcircuit> Arnavion, you joke but....
124 2015-04-05 09:59:26 <gmaxwell> phantomcircuit: how are you gauging the performance?
125 2015-04-05 09:59:45 <phantomcircuit> gmaxwell, sync time from a node on my lan
126 2015-04-05 09:59:57 <phantomcircuit> not real metrics yet but ... it seems slower
127 2015-04-05 09:59:58 <gmaxwell> hm. seems implausable to me.
128 2015-04-05 10:01:14 <gmaxwell> my guess is that there is some wakeup path that it isn't waking on, and that gross time+100 timeout is sleeping longer than requested (e.g. perhaps it sleeps for 1 second even though you asked for less)
129 2015-04-05 10:02:20 <gmaxwell> obvious thing to try: set the timeout to be huge and see if that slows it down proportionally... if so its waiting on the timeout.
130 2015-04-05 10:03:41 <phantomcircuit> i checked it sleeps for 100 ms just like the old code
131 2015-04-05 10:04:09 <gmaxwell> hm. okay.
132 2015-04-05 10:04:14 <gmaxwell> irritating.
133 2015-04-05 10:04:56 <gmaxwell> I don't know why this would slowdown an ibd, if its really all that slow it should get backlogged and continue through without the 'sleep'.
134 2015-04-05 10:05:15 <phantomcircuit> no scratch that
135 2015-04-05 10:05:21 <phantomcircuit> im just used to local reindex times
136 2015-04-05 10:05:24 <phantomcircuit> horray i was wrong
137 2015-04-05 10:05:33 <gmaxwell> oh yea, reindex is still much faster than a local transfer.
138 2015-04-05 10:05:49 <gmaxwell> (that is in and of itself an interesting question)
139 2015-04-05 10:11:38 <phantomcircuit> sigh stupid old "server"
140 2015-04-05 10:11:58 <phantomcircuit> i really want to get benchmarks with both the synced and the syncing node
141 2015-04-05 10:18:24 <phantomcircuit> gmaxwell, also i still haven't figured out why this stupid node will only connect to onion addresses
142 2015-04-05 10:18:25 <phantomcircuit> http://pastebin.com/raw.php?i=YzV55ws5
143 2015-04-05 10:32:47 <phantomcircuit> gmaxwell, yeah this is definitely faster
144 2015-04-05 10:33:48 <gmaxwell> phantomcircuit: why it will only connect to onion? proxy is set and probably some clown went and got your tor exit banned.
145 2015-04-05 10:34:04 <gmaxwell> phantomcircuit: what is faster than what?
146 2015-04-05 10:35:25 <phantomcircuit> both nodes running the patch is faster than neither or just ibd node
147 2015-04-05 10:35:30 <gmaxwell> hurrah.
148 2015-04-05 10:36:24 <gmaxwell> that'll be a good figure. also might be interesting is to run a half-node and time the gap between sending an inv for a random hash and getting a getdata with a precise timer.
149 2015-04-05 13:27:02 <jgarzik> is there any kind of #network-alerts or #network-monitoring sidechannel discussions for network activity?
150 2015-04-05 13:37:13 <chester`> anyone know exact formula to get pub key from private?
151 2015-04-05 13:38:16 <belcher> pub = G*priv
152 2015-04-05 13:39:00 <belcher> * is EC multiply, G is the generator point
153 2015-04-05 13:56:44 <chester`> is it possible to perform this without a computer?
154 2015-04-05 13:57:29 <chester`> some calculator or something?
155 2015-04-05 13:58:00 <buZz> chester`: http://rss.slashdot.org/~r/Slashdot/slashdot/~3/23dd692f2NA/how-to-make-a-bitcoin-address-with-a-ti-89-calculator
156 2015-04-05 13:58:08 <buZz> posted on slashdot -today-
157 2015-04-05 13:58:19 <chester`> oh thanks
158 2015-04-05 15:37:09 <BlueMatt> Luke-Jr: that is not true....
159 2015-04-05 15:37:17 <BlueMatt> ah, thanks phantomcircuit
160 2015-04-05 17:49:20 <buZz> FYI
161 2015-04-05 17:49:36 <buZz> #bitcoin-nl wanted to cut away the middle men on donating to core dev
162 2015-04-05 17:49:44 <buZz> thus we are now donating through https://mobbr.com/#/task/aHR0cHM6Ly9naXRodWIuY29tL2JpdGNvaW4vYml0Y29pbg
163 2015-04-05 17:50:05 <buZz> which pays to all github submitters through their share of total changes
164 2015-04-05 17:58:07 <jtimon> Luke-Jr can you comment on the latest https://github.com/bitcoin/bitcoin/pull/5595 ?
165 2015-04-05 17:58:44 <Diablo-D3> https://i.imgur.com/tyUS59z.png
166 2015-04-05 18:28:32 <buZz> Diablo-D3: painful
167 2015-04-05 18:28:55 <buZz> there is a lightbulb in the PSU
168 2015-04-05 18:28:56 <buZz> O_o
169 2015-04-05 18:29:00 <Diablo-D3> buZz: okay so
170 2015-04-05 18:29:03 <Diablo-D3> the psu has no cover
171 2015-04-05 18:29:05 <Diablo-D3> its not in the case
172 2015-04-05 18:29:12 <Diablo-D3> hes clipping the atx20 (its not even a 24)
173 2015-04-05 18:29:22 <Diablo-D3> hes doing it with some sort of wire crimper, its not a wire cutter
174 2015-04-05 18:29:27 <Diablo-D3> theres a lightbulb in the psu
175 2015-04-05 18:29:32 <buZz> motherboard looks like a P4
176 2015-04-05 18:29:43 <Diablo-D3> the mobo looks like p1 era, but the case screams p2/p3/p4 era
177 2015-04-05 18:29:46 <buZz> what does his tshirt say?
178 2015-04-05 18:29:56 <Diablo-D3> his tshirt is some out of date reference I dont get
179 2015-04-05 18:29:58 <buZz> technology .. the people
180 2015-04-05 18:29:58 <Diablo-D3> he needs a haircut
181 2015-04-05 18:30:03 <Diablo-D3> and his jeans dont fit properly
182 2015-04-05 18:30:08 <Diablo-D3> everything in that photo is wrong
183 2015-04-05 18:30:39 <buZz> http://extrait.co.uk/about/
184 2015-04-05 18:30:44 <buZz> its a popular pic though
185 2015-04-05 18:31:08 <buZz> http://laptoprepairkl.com/portfolio/#
186 2015-04-05 18:31:13 <buZz> probably creative commons?
187 2015-04-05 18:32:00 <Diablo-D3> no just shitty stock
188 2015-04-05 18:54:37 <livegnik> http://www.reddit.com/r/Bitcoin/comments/31jlej/im_now_funding_all_the_devs_in_the_world_who_are/
189 2015-04-05 18:57:47 <buZz> livegnik: yay \o/
190 2015-04-05 18:58:03 <livegnik> Nou. Ik heb m'n best weer gedaan voor vandaag :P
191 2015-04-05 18:58:27 <livegnik> Alle facebook, skype, IRC-groepen weer gespammed. Op reddit. Stukje worst voor de kleine mss?
192 2015-04-05 18:58:48 <livegnik> Srry. English of course ;)
193 2015-04-05 18:59:26 <livegnik> I've done my job for the day. I've sapmmed all facebook, skype, and IRC-channels with it. Lets see what the community thinks about this idea.
194 2015-04-05 19:10:15 <buZz> good
195 2015-04-05 22:04:04 <phantomcircuit> gmaxwell, neat, sync time to 300k over the network with that patch on both ends only took 3591 seconds
196 2015-04-05 22:26:42 <phantomcircuit> ajweiss, really cpu overhead?
197 2015-04-05 22:39:51 <jgarzik> phantomcircuit, wow
198 2015-04-05 22:41:38 <phantomcircuit> jgarzik, maybe not as impressive as your thinking since i disabled script checking
199 2015-04-05 22:42:01 <phantomcircuit> oh checkpoint is at 295000 anyways
200 2015-04-05 22:42:19 <phantomcircuit> i probably should have used that as the reference point...
201 2015-04-05 22:42:22 <phantomcircuit> shrug
202 2015-04-05 22:51:00 <Newyorkadam> Hey, I’m developing an iOS app that uses the changetip API to reward users for playing well. 1. Do you think using the changetip API is a good way to reward users? 2. What would you guys suggest I do to prevent people from finding exploits to obtain large amounts of btc?
203 2015-04-05 22:52:14 <justanotheruser> 1) you could just pay them in bitcoin 2) that's probably impossible unless the game has crazy complexity and computers can't beat humans like Go
204 2015-04-05 22:58:15 <Newyorkadam> justanotheruser: I want to be able to reward them every time they play though, and with raw bitcoin transactions I need to worry about transaction fees.
205 2015-04-05 22:58:49 <justanotheruser> they need to worry about the fees as well with changetip
206 2015-04-05 22:59:08 <justanotheruser> you could just say they have some balance every time they play and not pay them bitcoins until they withdraw
207 2015-04-05 22:59:43 <Newyorkadam> there are no changetip fees though, except the .0001 btc fee when withdrawing
208 2015-04-05 22:59:51 <Newyorkadam> not a bad idea..
209 2015-04-05 23:00:05 <Newyorkadam> but then they need at least .0001 to withdraw
210 2015-04-05 23:00:12 <justanotheruser> same with changetip
211 2015-04-05 23:00:25 <Newyorkadam> yeah, but with changetip you don’t need to withdraw, you can also tip other users
212 2015-04-05 23:00:55 <justanotheruser> thats true. I'm not a huge fan of changetip just so you know my bias as I'm talking to you.
213 2015-04-05 23:02:42 <justanotheruser> but if you want to use changetip be aware that they could suddenly lose your users money. There is the advantage of free "tipping" once they have funds though.
214 2015-04-05 23:03:31 <Apocalyptic> <Newyorkadam> yeah, but with changetip you dont need to withdraw, you can also tip other users // you seriously expect the majority of users to use the funds won in your app exclusively to tip ?
215 2015-04-05 23:03:34 <Newyorkadam> unrelated, why don’t you like changetip? just curious
216 2015-04-05 23:04:15 <justanotheruser> web wallets tend to not turn out well. Also people pretend its the same as using bitcoin
217 2015-04-05 23:04:17 <Newyorkadam> Apocalyptic: No, but changetip provides functionality that allows users to use btc without needing to have >.0001
218 2015-04-05 23:04:31 <Newyorkadam> but withdrawing straight to the wallet is not a bad idea
219 2015-04-05 23:05:13 <Newyorkadam> .0001=10,000 satoshis
220 2015-04-05 23:06:32 <Newyorkadam> I’m worried that it might take users too long (even if just 10 minutes) to earn .0001, and they’ll lose interest, whereas with changetip they get their btc immediately
221 2015-04-05 23:10:50 <phantomcircuit> Newyorkadam, except they dont really
222 2015-04-05 23:11:27 <Newyorkadam> Maybe in theory they don’t actually get btc, but they essentially do
223 2015-04-05 23:11:46 <Newyorkadam> They get +0.000x to their balance, which they can withdraw for btc
224 2015-04-05 23:12:01 <phantomcircuit> gmaxwell, i suspect the delta between reindex and network ibd times is due to the size of the request queue and network latency (even the <1ms i've got here)
225 2015-04-05 23:12:53 <phantomcircuit> cpu is only truly busy for more recent blocks
226 2015-04-05 23:13:08 <phantomcircuit> and network isn't even close to saturated