1 2013-12-14 00:00:37 <sipa> we haven't had a blkindex.dat since 0.8
  2 2013-12-14 00:01:01 <alex_fun> yes
  3 2013-12-14 00:01:06 <alex_fun> its been improved alot
  4 2013-12-14 00:01:09 <alex_fun> I know :)
  5 2013-12-14 00:13:32 <wiretapped> Luke-Jr: whats your opinion of dogecoin
  6 2013-12-14 00:13:44 <Luke-Jr> off-topic
  7 2013-12-14 00:15:39 <sipa> much off-topic, so wow
  8 2013-12-14 00:23:47 <alex_fun> hahaha
  9 2013-12-14 00:24:02 <alex_fun> well  Luke comments attract certain people to him
 10 2013-12-14 01:57:13 <Emcy> someone forked bitcoin and changed all the internal text to comic sans
 11 2013-12-14 01:57:27 <Emcy> maybe that will be a motivator for you guys
 12 2013-12-14 01:57:30 <Emcy> or maybe not
 13 2013-12-14 02:25:57 <BlueMatt> who has an onion seed I can connect to?
 14 2013-12-14 02:26:06 <BlueMatt> sipa/gmaxwell: ^ ?
 15 2013-12-14 02:30:07 <gmaxwell> bitcoinfoec76drk.onion:8333 divd5kytbhwdcyae.onion:8333 fpt6orohw2nuf2kn.onion:8333 gb5ypqt63du3wfhn.onion kjy2eqzk4zwi5zd3.onion qtaio44l2wscnjvf.onion:8333 td7tgof3imei3fm6.onion:8333
 16 2013-12-14 02:31:55 <BlueMatt> hmm...so onions dont magically work in bitcoinj
 17 2013-12-14 02:32:05 <BlueMatt> but at least just regular connections over tor do
 18 2013-12-14 02:32:36 <netg> ich run one under: bitcoin2u5jnjzzz.onion
 19 2013-12-14 02:32:38 <gmaxwell> real bitcoin onion support requires explicit code for onion / v6 mapping.
 20 2013-12-14 02:33:17 <BlueMatt> yea
 21 2013-12-14 02:33:53 <BlueMatt> but just blindly connecting to an onion fails too
 22 2013-12-14 02:34:37 <netg> why you need a seed
 23 2013-12-14 02:34:40 <netg> if u follow
 24 2013-12-14 02:34:42 <netg> https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md#2-run-a-bitcoin-hidden-server
 25 2013-12-14 02:34:45 <netg> it auto connecs
 26 2013-12-14 02:35:15 <BlueMatt> netg: Im writing tor support in bitcoinj
 27 2013-12-14 02:35:17 <BlueMatt> not bitcoind
 28 2013-12-14 02:35:25 <netg> ok sorry
 29 2013-12-14 02:35:28 <netg> sorry
 30 2013-12-14 02:37:31 <gmaxwell> BlueMatt: I suppose it's resolving it directly instead of passing the name on to the socks proxy.
 31 2013-12-14 02:37:34 <gmaxwell> otherwise it would work.
 32 2013-12-14 02:38:20 <BlueMatt> well, some asserts in the code freaked because there was no resolved address (created the socketaddress with createUnresolved())
 33 2013-12-14 02:38:50 <__alp__> for some reason, I cant seem to get gettransaction to work, even though I set txindex=1 and reindexed (twice)
 34 2013-12-14 02:38:54 <__alp__> Anyone got any ideas?
 35 2013-12-14 02:39:16 <__alp__> index dir is 1.5GB, seems like its all there, conf file looks fine, any way to get the options out of bitcoind?
 36 2013-12-14 02:42:23 <gmaxwell> __alp__: gettransaction only returns in wallet transactions. (does what it says in the help)
 37 2013-12-14 02:42:40 <gmaxwell> __alp__: you want getrawtransaction <txid> 1 presumably.
 38 2013-12-14 02:42:46 <__alp__> Thought I read I could reindex to get all transactions with txindex=1
 39 2013-12-14 02:42:55 <__alp__> I am trying to figure out what block a tx is from just based on its hash
 40 2013-12-14 02:43:18 <__alp__> http://bitcoin.stackexchange.com/questions/11759/get-non-wallet-transactions-using-bitcoin-rpc-gettransaction
 41 2013-12-14 02:43:32 <gmaxwell> 18:42 <@gmaxwell> __alp__: gettransaction only returns in wallet transactions. (does what it says in the help)
 42 2013-12-14 02:43:36 <gmaxwell> 18:42 <@gmaxwell> __alp__: you want getrawtransaction <txid> 1 presumably.
 43 2013-12-14 02:43:40 <__alp__> ugh
 44 2013-12-14 02:43:46 <__alp__> Need to learn to read more carefully
 45 2013-12-14 02:43:49 <__alp__> ty as always mr maxswell
 46 2013-12-14 02:44:13 <gmaxwell> Thats okay, copy and paste are cheap. :P
 47 2013-12-14 02:44:39 <__alp__> wasted 2 days reindexing twice
 48 2013-12-14 02:45:35 <__alp__> got another potentially dumb question, maybe I should look at source, but should be quick
 49 2013-12-14 02:46:01 <__alp__> When recalculating difficulty, I presume timestamps are used to determine if it was faster or slower than expected, this correct?
 50 2013-12-14 02:46:29 <gmaxwell> __alp__: yes.
 51 2013-12-14 02:46:48 <__alp__> There some kind of validation to ensure timestamps arent spoofed?  Ive seen timestamps in blocks that were weird
 52 2013-12-14 02:47:19 <gmaxwell> __alp__: yes, they're constrained to be not more than 2 hours into the future and greater than the median of the last 10.
 53 2013-12-14 02:47:22 <gmaxwell> er 11.
 54 2013-12-14 02:48:08 <__alp__> figured there had to be something like that.  2 hours into the future meaning 2 hours from the last block?  or dealing with relaying as the last block?
 55 2013-12-14 02:48:28 <gmaxwell> No. 2 hours into the future meaning 2 hours from your local idea of the time.
 56 2013-12-14 02:48:32 <kjj> from what a given node thinks "now" is
 57 2013-12-14 02:48:47 <gmaxwell> which is why there is so much leeway.
 58 2013-12-14 02:48:52 <__alp__> If I am validating a blockchain from 3 years ago, I have no idea what now was, right?
 59 2013-12-14 02:49:03 <__alp__> So I use median method on old stuff, and know about new blocks?
 60 2013-12-14 02:49:11 <__alp__> treat new blocks differently
 61 2013-12-14 02:49:17 <kjj> doesn't matter.  a timestamp from 2010 is not beyond the 2 hour limit from your node's "now"
 62 2013-12-14 02:49:25 <gmaxwell> No. it's essential that new and old blocks are not treated differently.
 63 2013-12-14 02:49:31 <gmaxwell> There are two boundaries, an upper and a lower.
 64 2013-12-14 02:50:02 <gmaxwell> Upper depends on the current time, which always flows forward (unless you're in a movie) so the test is consistent with old and new blocks. Lower depends only on the chain.
 65 2013-12-14 02:50:34 <__alp__> gotcha, thx
 66 2013-12-14 02:50:43 <__alp__> depends only on the chain meaning after the last block?
 67 2013-12-14 02:51:25 <gmaxwell> __alp__: I am not following your question.
 68 2013-12-14 02:51:29 <kjj> the official rule is "greater than the median of the previous 11"
 69 2013-12-14 02:51:43 <__alp__> ok, thats why I have seen later blocks with earlier timestamps
 70 2013-12-14 02:52:03 <gmaxwell> __alp__: it's perfectly possible to have timestamps go backwards.
 71 2013-12-14 02:52:19 <__alp__> just not too far backwards (before the previous 11 median)
 72 2013-12-14 02:52:34 <gmaxwell> If it weren't someone could irritate miners and create forking by mining a block at now+two hours
 73 2013-12-14 02:52:37 <gmaxwell> __alp__: ah right.
 74 2013-12-14 02:53:46 <__alp__> Miners could also keep the difficulty low by setting the block 1 year in the future, making difficulty drop a ton making it think it took a long time to mine
 75 2013-12-14 02:54:06 <kjj> no.  remember the upper bound?
 76 2013-12-14 02:54:10 <__alp__> Without the bound
 77 2013-12-14 02:54:17 <__alp__> I was wondering how that was accomplished
 78 2013-12-14 02:55:16 <gmaxwell> yep.
 79 2013-12-14 02:55:19 <__alp__> Someone might try to cheat by setting it too far, but cant get too much further.
 80 2013-12-14 02:55:48 <gmaxwell> the boundary means they can only cheat by 0.5% and only once, since cheating this retarget means the diff will be higher in the next one.
 81 2013-12-14 02:55:50 <kjj> now they could try to fake an old block by setting the timestamp ahead, but still in the actual past
 82 2013-12-14 02:56:11 <kjj> but the difficulty will catch that one
 83 2013-12-14 03:00:10 <__alp__> kjj: how do you mean difficulty will catch that one
 84 2013-12-14 03:01:26 <kjj> the current chain has something like 2^74.7 work embedded in it
 85 2013-12-14 03:02:45 <kjj> if you go back to like block 100,000 and start making a fork, you can fudge timestamps to bring the difficulty on your fork way down so you can make a bunch of blocks
 86 2013-12-14 03:03:00 <kjj> but your chain won't have more work than the real chain, so it is just an annoyance
 87 2013-12-14 03:04:36 <__alp__> kjj: thx
 88 2013-12-14 03:37:07 <nifong> Hi there. I have not been able to receive anything on the testnet from faucets. (using bitcoind version 32400) The address I was trying to receive with is mkk1ThMrVUq7zrsbVmFgrkaqSezF6rKKRm Is there anything I should know about that could prevent this from working?
 89 2013-12-14 03:39:37 <BlueMatt> "version 32400"
 90 2013-12-14 03:39:38 <BlueMatt> lol
 91 2013-12-14 03:39:51 <BlueMatt> 0.3.24 is how many years old?
 92 2013-12-14 03:40:41 <nifong> It's old? oops
 93 2013-12-14 03:40:52 <BlueMatt> its ancient and very broken
 94 2013-12-14 03:41:17 <BlueMatt> where did you get it that told you it was recent?
 95 2013-12-14 03:42:02 <nifong> Well, that needs to be addressed! Honestly I'm not sure where it came from. It was just on my system.
 96 2013-12-14 03:42:14 <nifong> Might have come from apt-get at some point maybe
 97 2013-12-14 03:42:30 <BlueMatt> ahhh, thats why...dont trust the shit ubuntu/debian ship you
 98 2013-12-14 03:42:39 <BlueMatt> its usually ancient and, in the case of bitcoin, comes with lots of fun bugs
 99 2013-12-14 03:43:27 <dekiss> if you need develoepr message me
100 2013-12-14 03:43:37 <nifong> Well, sorry I bugged you with that. :P
101 2013-12-14 03:44:07 <BlueMatt> you should file a bug with debian to tell them they're doing it wrong
102 2013-12-14 03:44:22 <BlueMatt> there is a stable branch they should be using, at a minimum...
103 2013-12-14 03:46:17 <pigeons> hmm i checked my debian sources it has a bitcoind/bitcoin-qt in the repo, but on debian unstable at least its bitcoind_0.8.6-1_amd64.deb
104 2013-12-14 03:46:41 <BlueMatt> yes, but not many people use debian unstable
105 2013-12-14 03:47:00 <BlueMatt> and shipping old versions with known bugs without backporting fixes to any release is just irresponsible
106 2013-12-14 03:47:07 <pigeons> yeah
107 2013-12-14 03:48:29 <Luke-Jr> well, it'
108 2013-12-14 03:48:35 <Luke-Jr> well, it's just monopoly money after all!
109 2013-12-14 03:48:36 <Luke-Jr> <.<
110 2013-12-14 03:50:08 <pigeons> i'm not sure there is a bitcoin in debian stable. stable is wheezy right?
111 2013-12-14 03:50:40 <Luke-Jr> stable is squeeze
112 2013-12-14 03:50:45 <Luke-Jr> I think
113 2013-12-14 03:51:11 <Luke-Jr> wait no, squeeze is oldstable now
114 2013-12-14 03:51:29 <Luke-Jr> heh, squeeze-backports has 0.3.24, but nothing at all for wheezy
115 2013-12-14 03:51:33 <Luke-Jr> guess that's an improvement
116 2013-12-14 03:51:44 <Luke-Jr> dunno why backports can't have latest
117 2013-12-14 03:53:10 <pigeons> i think that's also the one where they included a bitcoin.conf with rpcpassword= blank
118 2013-12-14 03:53:49 <Luke-Jr> pigeons: that's fine, bitcoind will refuse to start
119 2013-12-14 03:54:23 <pigeons> let me look they did something, like use the same password for everyone or something
120 2013-12-14 03:58:50 <nifong> great, I'm using the latest version now.
121 2013-12-14 03:59:35 <nifong> So I noticed that the difficulty changes between 1.0 and 121.011 on successive calls to bitcoind getinfo. What's up with that?
122 2013-12-14 04:00:44 <Luke-Jr> nifong: your client hasn't finished bootstrapping itself yet
123 2013-12-14 04:00:52 <Luke-Jr> nifong: it's something like 1 billion now (2013 Dec)
124 2013-12-14 04:01:06 <nifong> I'm referring to the testnet difficulty
125 2013-12-14 04:01:23 <nifong> but still, it's probably still bootstrapping like you said
126 2013-12-14 04:01:40 <BlueMatt> pigeons: used some non-crypto rng for the rpcpassword
127 2013-12-14 04:01:56 <BlueMatt> still, it doesnt matter much unless you let bitcoind rpc listen outside of localhost (which you souldnt)
128 2013-12-14 04:02:07 <pigeons> yeah
129 2013-12-14 04:18:18 <BlueMatt> anyone else noticing a large amount of ntp-sync'd computers getting "time inaccurate" warnings recently?
130 2013-12-14 04:25:31 <Luke-Jr> BlueMatt: Russian sybil thing
131 2013-12-14 04:25:51 <BlueMatt> hmm, fun
132 2013-12-14 05:47:18 <trixisowned> Anyone familiar with p2pool? what would be causing http://pastebin.com/Fp7DC2b6 to happen every block for a scrypt altcoin? It sends payment and adds the block to the list and correctly submits it but it still errors over and over~
133 2013-12-14 05:53:27 <Luke-Jr> trixisowned: this is #bitcoin-dev, not #scamcoin-dev
134 2013-12-14 05:53:36 <trixisowned> hurpdurp
135 2013-12-14 06:25:28 <phantomcircuit> sipa, any opinion on removing the vtxPrev stuff w/o fixing IsConfirmed
136 2013-12-14 11:05:50 <sipa> phantomcircuit: i'm all for removing vtxPrev, but was there nkt some issue with that that you found earlier?
137 2013-12-14 13:36:51 <ThomasV> maaku: how is the utxo hashtree project doing? any progress?
138 2013-12-14 15:57:15 <siritinga> Hi!
139 2013-12-14 15:57:42 <siritinga> I'm reading about bitcoin internals, and there is something I don't understand
140 2013-12-14 15:58:29 <siritinga> If I understand correctly, a transaction are not confirmed until someone closes a block, and that transaction is included in the closed block, right?
141 2013-12-14 16:03:56 <sipa> siritinga: a transaction is confirmed as soon as a miner includes it in a block
142 2013-12-14 16:04:14 <sipa> saying that a block is 'closed' is misleading, though
143 2013-12-14 16:05:02 <Apocalyptic> i think he meant 'mined' for 'closed'
144 2013-12-14 16:06:15 <sipa> maybe, but using the word 'closed' may mean that he believes blocks are just created sequentially, and each block starts when the previous is done
145 2013-12-14 16:06:27 <siritinga> yes, sorry, I meant mined.
146 2013-12-14 16:06:32 <sipa> there is no progress towards creating blocks
147 2013-12-14 16:06:46 <sipa> miners just try all the time, and every attempt is independent
148 2013-12-14 16:07:57 <siritinga> And the miner choses which transactions its block includes?
149 2013-12-14 16:08:43 <sipa> indeed
150 2013-12-14 16:09:14 <siritinga> I see... so transactions without transaction fee may take forever to be confirmed
151 2013-12-14 16:09:36 <sipa> even with fee that may be the case
152 2013-12-14 16:09:58 <sipa> (in theory)
153 2013-12-14 16:10:17 <siritinga> Can a transaction be discarded/lost if not confirmed in some time?
154 2013-12-14 16:12:37 <sipa> yes, wallet software typically keeps broafcasting it until it confirms
155 2013-12-14 16:13:11 <siritinga> Now I see, thanks!
156 2013-12-14 16:13:35 <siritinga> I've been reading about bitcoin for some time without really understanding it.
157 2013-12-14 16:14:06 <siritinga> Now I'm trying to understand it and it's very interesting :)
158 2013-12-14 16:49:46 <easye> Well, managed to get http://svn.macports.org/repository/macports/trunk/dports/finance/bitcoind/Portfile to build a post 0.8.6.  I'd sure like some schooling on the bitcoin release engineering when someone has the time.
159 2013-12-14 17:25:17 <arioBarzan> shouldn't the output of OP_EQUALVERIFY be nothing/false? in the wiki the output is true/false (https://en.bitcoin.it/wiki/Script)
160 2013-12-14 18:06:32 <arioBarzan> shouldn't the output of OP_EQUALVERIFY be nothing/false? it is shown as true/false in http://en.bitcoin.it/wiki/Script
161 2013-12-14 19:16:49 <Snowleaksange> any hints on how to keep pubnub orderbook synchronized?
162 2013-12-14 20:19:28 <kuzetsa> hmm
163 2013-12-14 20:20:05 <kuzetsa> been rather quiet in here for hours
164 2013-12-14 20:22:54 <_-_-_> Hi bitcoin devs,
165 2013-12-14 20:23:07 <_-_-_> I'm trying to run bitcoind on an aws server
166 2013-12-14 20:23:21 <_-_-_> And I keep getting a corrupted wallet after ~ 1h
167 2013-12-14 20:23:23 <_-_-_> CDB() : can't open database file wallet.dat, error -30974
168 2013-12-14 20:23:31 <_-_-_> any ideas why ?
169 2013-12-14 20:23:54 <_-_-_> I don't mind deleting it as it doesn't hold coins yet, but I am a little worried on the long term
170 2013-12-14 20:26:20 <sipa1024> does db.log contain anything more detailed?
171 2013-12-14 20:28:06 <_-_-_> from db.log
172 2013-12-14 20:28:07 <_-_-_> PANIC: fatal region error detected; run recovery
173 2013-12-14 20:28:58 <_-_-_> I just ran bitcoind -salvagewallet and it seems to have exited without errors..
174 2013-12-14 20:29:12 <_-_-_> I'm going to see if it reproduces
175 2013-12-14 20:30:44 <_-_-_> Error: System error: CDB() : can't open database file wallet.dat, error -30974
176 2013-12-14 20:30:44 <_-_-_> when launching bitcoind:
177 2013-12-14 20:30:47 <_-_-_> terminate called after throwing an instance of 'std::runtime_error' what():  CDB() : can't open database file wallet.dat, error -30974
178 2013-12-14 20:30:50 <_-_-_> Bitcoin server starting
179 2013-12-14 20:30:53 <_-_-_> Error: wallet.dat corrupt, salvage failed
180 2013-12-14 20:30:55 <_-_-_> Bitcoin server starting
181 2013-12-14 20:33:42 <_-_-_> sipa any ideas where this came from ?
182 2013-12-14 21:28:26 <Ostkaka> skinnkavaj snygg mundering
183 2013-12-14 21:28:40 <skinnkavaj> Mundering?
184 2013-12-14 21:28:49 <Ostkaka> kavajen :]
185 2013-12-14 21:29:42 <skinnkavaj> tack Ostkaka
186 2013-12-14 21:31:34 <gmaxwell> https://research.microsoft.com/en-us/people/mickens/thesaddestmoment.pdf “How can you make a reliable computer service?” the presenter will ask in an innocent voice before continuing, “It may be difficult if you can’t trust anything and the entire concept of happiness is a lie designed by unseen overlords of endless deceptive power.”
187 2013-12-14 21:32:53 <TD> yes that was an amusing take on it
188 2013-12-14 22:18:26 <RixiM> If I wanted to setup a "gaming house" that only worked in btc, I think it is possible completely with contracts?
189 2013-12-14 22:19:06 <RixiM> err, poorly phrased. Does anyone know of any examples of contracts applied to gaming?
190 2013-12-14 22:27:30 <TD> RixiM: yes, see the recent research paper posted by amiller to the dev forum
191 2013-12-14 22:30:24 <RixiM> Thanks.
192 2013-12-14 22:35:01 <RixiM> TD: this one? http://eprint.iacr.org/2013/784
193 2013-12-14 22:35:13 <TD> yeah
194 2013-12-14 22:37:02 <RixiM> Ah, I am reading it, I think my system is much easier beacuse I am assuming that the fairness of the game can only be determined after the game has been played.
195 2013-12-14 22:37:54 <TD> ok
196 2013-12-14 22:39:33 <tommygunner> so i just made a fee-less transaction at 224 bytes
197 2013-12-14 22:39:40 <tommygunner> raw transaction
198 2013-12-14 22:39:45 <tommygunner> and it basically got confirmed immediately
199 2013-12-14 22:40:06 <tommygunner> safe to say the new fee policy is awesome :>
200 2013-12-14 22:41:57 <TD> well, that may or may not be due to the new policy
201 2013-12-14 22:42:00 <TD> i doubt most miners have upgraded yet
202 2013-12-14 22:43:11 <jsidhu> hey guys im compiling 0.8.5 but my daemon is 80 megs compiled? why?
203 2013-12-14 22:44:30 <gmaxwell> tommygunner: has nothing to do with a fee policy change— thats just how it works when you're spending large amounts of aged coins that have high priority.
204 2013-12-14 22:44:42 <gmaxwell> jsidhu: because you haven't stripped it and it has debugging symbols.
205 2013-12-14 22:45:24 <tommygunner> its very fresh coin
206 2013-12-14 22:45:31 <jsidhu> gmaxwell: would it affect running testnet? it crashes when I send it a message with another node
207 2013-12-14 22:45:41 <jsidhu> the versio nmessage crashes it
208 2013-12-14 22:45:50 <gmaxwell> crashes it?!
209 2013-12-14 22:46:06 <tommygunner> my input has only 173 confirmations
210 2013-12-14 22:46:23 <jsidhu> gmaxwell: yea I run testnet, its fine.. then i run another with addnode to the first and it crashes after init
211 2013-12-14 22:48:37 <gmaxwell> jsidhu: by crashes, do you mean shuts down cleanly with a message that it can't bind the port because the port is already in use?
212 2013-12-14 22:49:14 <jsidhu> no crashes literally
213 2013-12-14 22:49:29 <jsidhu> log doesnt say anything
214 2013-12-14 22:49:53 <jsidhu> when you gt a version message isnt it just at the socket layer in net.cpp?
215 2013-12-14 22:50:06 <jsidhu> i do get a socket rcv error sometimes
216 2013-12-14 22:50:09 <jsidhu> in the log
217 2013-12-14 22:50:16 <gmaxwell> jsidhu: it's not clear to me what you're doing. Have you modified the software? are you running two nodes with the same data directory?
218 2013-12-14 22:50:46 <jsidhu> i modified the software in createblock but i put printf'
219 2013-12-14 22:51:00 <gmaxwell> Needless to say, no one else is reporting it crashing on connect, testnet or otherwise. Also, if you're compiling it — why 0.8.5?
220 2013-12-14 22:51:02 <jsidhu> print's around my changed code and I dont see the print statements so im not reaching that code
221 2013-12-14 22:51:14 <jsidhu> gmaxwell: im forward porting devcoin
222 2013-12-14 22:51:22 <jsidhu> should i be doing it with 0.8.6?
223 2013-12-14 22:51:58 <jsidhu> maybe something with the build? with boost or something?
224 2013-12-14 22:52:15 <jsidhu> I run a compiled version and it works
225 2013-12-14 22:59:06 <RixiM> jsidhu: sounds like your testing method is questionable at best.
226 2013-12-14 23:00:20 <jsidhu> rixim: maybe... just learning :) so to strip out debug symbols would I have to recompile all of the libs for boost/openssl and DB with another flag? i didnt think they were statically linked
227 2013-12-14 23:01:08 <RixiM> jsidhu: i would just compile with no changes, keeping the debugging symbols and see if that works.
228 2013-12-14 23:01:32 <RixiM> then add the smallest "meaningful" change you can, see what happens and repeat.
229 2013-12-14 23:03:13 <jsidhu> RixiM yea I will have to do that :( that sucks but I atleast I'll find the issue
230 2013-12-14 23:37:05 <berndj> jsidhu, have you tried running bitcoind under valgrind? and no, you can strip after the fact with strip(1)
231 2013-12-14 23:40:02 <jsidhu> berndj: Im using mingw64
232 2013-12-14 23:40:11 <jsidhu> can i just call strip bitcoind?
233 2013-12-14 23:41:22 <jsidhu> I started with i0coin (rsnel
234 2013-12-14 23:41:27 <jsidhu> fork and its testnet is broken
235 2013-12-14 23:41:31 <jsidhu> so I inherited the problem
236 2013-12-14 23:41:54 <jsidhu> I need to start from i0coin because it closely resembles devcoin except for reciever file stuff which I added already
237 2013-12-14 23:42:05 <jsidhu> so now I cant really test my devcoin forward porting
238 2013-12-14 23:51:28 <jsidhu> man this sucks
239 2013-12-14 23:51:35 <jsidhu> how do I test my daemon without a testnet?
240 2013-12-14 23:51:57 <jsidhu> im fairly sure it should just work but never know