1 2012-07-23 00:00:05 <jgarzik> now to apply that to the mempool...
  2 2012-07-23 02:01:32 <gribble> New news from bitcoinrss: fanquake opened pull request 1622 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1622>
  3 2012-07-23 02:20:54 <zveda> hello
  4 2012-07-23 02:20:59 <zveda> are deterministic wallets safe ?
  5 2012-07-23 02:29:11 <gmaxwell> "maybe"
  6 2012-07-23 02:29:30 <gmaxwell> You're asking far too broad a question what kind of determinstic wallet, and safe against what?
  7 2012-07-23 02:50:24 <Ferroh> do you guys know if libboost 1.33 is good enough to compile satoshi client 0.6.1?
  8 2012-07-23 02:50:30 <Ferroh> or do I need something more recent
  9 2012-07-23 02:51:56 <Ferroh> nvm apparently something more recent is required.
 10 2012-07-23 03:00:09 <Ferroh> Can someone help me figure out how to build the satoshi client?
 11 2012-07-23 03:00:10 <Ferroh> http://pastebin.com/GLJEmxhu
 12 2012-07-23 03:00:14 <Ferroh> ^^ build output
 13 2012-07-23 03:00:33 <Ferroh> I'm doing this in a jailshell so I have limited access to the system, but I can request modifications.
 14 2012-07-23 03:00:48 <Ferroh> I just had them install libboost and berkeleydb
 15 2012-07-23 03:01:13 <jgarzik> are all scripts in the blockchain tokenize-able?
 16 2012-07-23 03:01:51 <jgarzik> i.e. they are all valid opcodes, if you include the data component of PUSHDATA ops as part of the opcode?
 17 2012-07-23 03:02:04 <jgarzik> no garbage following the end of a script, or anything?
 18 2012-07-23 03:02:08 <doublec> Ferroh: where are the boost header files on your system?
 19 2012-07-23 03:02:27 <Ferroh> doublec: I dont know.
 20 2012-07-23 03:02:54 <doublec> Ferroh: you need the answer to that question for further help
 21 2012-07-23 03:03:01 <Ferroh> ok, thanks
 22 2012-07-23 03:03:08 <doublec> np
 23 2012-07-23 03:04:16 <Ferroh> maybe I can get away with compiling on a different machine, and then just running the binary on this machine
 24 2012-07-23 03:30:02 <Ferroh> doublec, supposed I know the location of the boost header files, can you tell me what the next step would be?
 25 2012-07-23 03:30:05 <Ferroh> *suppose
 26 2012-07-23 03:30:38 <doublec> Ferroh: possibly
 27 2012-07-23 03:30:52 <Ferroh> i meant now :P
 28 2012-07-23 03:31:03 <Ferroh> that's ok, i'll wait to hear back about the header files first
 29 2012-07-23 03:31:18 <doublec> Ferroh: try: BOOST_INCLUDE_PATH=/usr/local/include make -f makefile.unix bitcoind
 30 2012-07-23 03:31:30 <doublec> where /usr/local/include is replaced with your actual path
 31 2012-07-23 03:31:35 <Ferroh> ok excellent, thankyou
 32 2012-07-23 03:32:02 <Ferroh> I tried to run the binary but ran into the issue where it couldnt find the version of GLIBCXX it wanted
 33 2012-07-23 03:32:44 <Ferroh> http://pastebin.com/xvc7s4E6
 34 2012-07-23 03:32:50 <Ferroh> I assume a fresh build will solve that.
 35 2012-07-23 03:33:07 <doublec> yep
 36 2012-07-23 03:35:17 <Ferroh> mmm I think I found boost
 37 2012-07-23 03:36:42 <Ferroh> in /usr/include/boost
 38 2012-07-23 03:37:33 <Ferroh> but doing "BOOST_INCLUDE_PATH=/usr/include/boost make -f makefile.unix bitcoind" does not change the output of make
 39 2012-07-23 03:37:42 <doublec> is that the old boost or the new one they installed?
 40 2012-07-23 03:38:15 <doublec> is there a foreach.hpp in there?
 41 2012-07-23 03:38:25 <Ferroh> durr no there isn't
 42 2012-07-23 03:38:31 <Ferroh> ok sorry for wasting your time with that dumb question :)
 43 2012-07-23 03:38:37 <Ferroh> I will get a newer libboost installed
 44 2012-07-23 03:38:57 <doublec> you can built and install it locally
 45 2012-07-23 03:39:02 <doublec> to a directory you  control
 46 2012-07-23 03:39:07 <doublec> it's a bit of a mission though
 47 2012-07-23 03:39:31 <Ferroh> its ok, the sysadmin will do it for me
 48 2012-07-23 03:39:42 <Ferroh> who knows what dependency issues i might run into trying to build boost myself
 49 2012-07-23 03:40:00 <Ferroh> also as you can tell, im not exactly a linux expert here
 50 2012-07-23 03:40:39 <doublec> yeah, probably wise. It can be a pain.
 51 2012-07-23 03:40:49 <doublec> sysadmin's have a high tolerance for that :)
 52 2012-07-23 03:48:39 <jgarzik> lovely
 53 2012-07-23 03:49:05 <jgarzik> some miner started introducing totally broken coinbase scripts in block #143000 or so
 54 2012-07-23 03:49:18 <jgarzik> they don't even parse as coinbase scripts
 55 2012-07-23 03:49:25 <MagicalTux> lol
 56 2012-07-23 03:49:40 <Diablo-D3> heh
 57 2012-07-23 03:49:43 <MagicalTux> the 0 coinbase ?
 58 2012-07-23 03:50:08 <jgarzik> yeah
 59 2012-07-23 03:50:21 <MagicalTux> saw it too and got the name of the pool doing that
 60 2012-07-23 03:50:24 <MagicalTux> forgot which one it was
 61 2012-07-23 03:50:52 <jgarzik> Scanned 177000 blocks (4460/4460 failures)
 62 2012-07-23 03:51:04 <jgarzik> given that much data, shouldn't be too hard to track down, even if you didn't that have
 63 2012-07-23 03:51:06 <jgarzik> *have that
 64 2012-07-23 03:51:36 <jgarzik> out of 177,000 blocks, 4460 coinbase scriptSig's failed to parse
 65 2012-07-23 03:57:32 <Ferroh> https://blockchain.info/address/1DkyBEKt5S2GDtv7aQw6rQepAvnsRyHoYM
 66 2012-07-23 03:57:50 <Ferroh> someone registered a .com:
 67 2012-07-23 03:58:24 <Ferroh> Is that final balance correct?
 68 2012-07-23 03:58:34 <Ferroh> 447835 BTC :/
 69 2012-07-23 03:58:42 <jgarzik> Scanned 190000 blocks (8082/8082 failures)
 70 2012-07-23 03:58:44 <jgarzik> so
 71 2012-07-23 03:59:04 <jgarzik> 8082 script parse failures in the entire blockchain
 72 2012-07-23 03:59:20 <jgarzik> 100% of which are in coinbase txin scriptSig
 73 2012-07-23 04:14:17 <gribble> New news from bitcoinrss: Diapolo opened pull request 1623 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1623>
 74 2012-07-23 04:22:45 <KingKatari> hey is there a command i can issue to bitcoin-qt to make it update because it is not showing the new blocks that have a conf for a transaction of mine
 75 2012-07-23 04:24:19 <gribble> New news from bitcoinrss: Diapolo opened pull request 1624 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1624>
 76 2012-07-23 06:37:38 <jeremias> EXCEPTION: 11DbException
 77 2012-07-23 06:37:45 <jeremias> getting that error on startup
 78 2012-07-23 07:11:47 <cande> do you know davout?
 79 2012-07-23 07:30:38 <OneEyed> cande: you mean in real life?
 80 2012-07-23 07:32:32 <OneEyed> cande: he is one of the guys in charge of Paymium, a French company that develops Paytunia and, if I remember correctly, acquired bitcoin-central.net and instawallet
 81 2012-07-23 07:34:34 <epscy> how long does the blockchain take to download these days?
 82 2012-07-23 07:37:09 <edcba> maybe try installing a new client in vm ?
 83 2012-07-23 07:39:06 <epscy> i have started a new client on a raspberry pi
 84 2012-07-23 07:39:23 <epscy> just wondering how long it might take
 85 2012-07-23 07:40:20 <edcba> i did read some settings in db make it faster
 86 2012-07-23 07:40:22 <edcba> but i don't know for init
 87 2012-07-23 07:40:24 <edcba> you should just download a old blockchain
 88 2012-07-23 07:40:33 <edcba> and let the client finish the remaining
 89 2012-07-23 07:40:51 <epscy> yeah, i think that is what i am going to do
 90 2012-07-23 07:41:12 <epscy> all i need is the blk files right?
 91 2012-07-23 07:41:23 <edcba> don't remember
 92 2012-07-23 07:41:35 <edcba> i think there is some forum post about it
 93 2012-07-23 07:41:57 <edcba> http://eu1.bitcoincharts.com/blockchain/
 94 2012-07-23 07:42:01 <edcba> must be there
 95 2012-07-23 07:42:17 <edcba> 3GB...
 96 2012-07-23 07:42:30 <edcba> i wonder how much data by day
 97 2012-07-23 07:42:49 <epscy> 3GB?
 98 2012-07-23 07:42:53 <epscy> really?
 99 2012-07-23 07:43:04 <epscy> i thought it was about 1 GB
100 2012-07-23 07:43:41 <epscy> it would have been good to have something in the protocol relating the size of a transaction to a fee
101 2012-07-23 07:44:02 <epscy> to stop a tradgedy of the commons type situation
102 2012-07-23 07:44:09 <edcba> hmm
103 2012-07-23 07:44:30 <edcba> trying to remember the thing
104 2012-07-23 07:44:45 <edcba> but indeed something is wrong
105 2012-07-23 07:45:09 <edcba> since the miner can stuff the thing and it doesn't cost him
106 2012-07-23 07:45:45 <epscy> some people do mine blocks and not include any transactions
107 2012-07-23 07:45:50 <epscy> i have seen a few of those
108 2012-07-23 07:46:20 <edcba> yes some constraints on tx # and/or size may be welcome
109 2012-07-23 07:46:59 <edcba> ok someone must have already suggested that on forum
110 2012-07-23 07:47:19 <epscy> yeah, well the constraint should be flexible, if enough fees are paid large blocks are fine
111 2012-07-23 07:47:27 <epscy> difficult to enforce that in the protocol though
112 2012-07-23 07:49:18 <epscy> i think the blockchain is about 1.5GB
113 2012-07-23 07:49:25 <edcba> but the fee should be substracted to reward
114 2012-07-23 07:49:53 <edcba> hmm
115 2012-07-23 07:50:15 <edcba> ok it's not an easy problem lol
116 2012-07-23 07:50:30 <edcba> having incentives rights on that...
117 2012-07-23 07:51:03 <epscy> i can see a time when almost all miners require fees
118 2012-07-23 07:51:34 <epscy> and then satoshidice type txes will never get confirmed
119 2012-07-23 07:52:50 <sturles> Eh?  No.
120 2012-07-23 07:53:54 <sturles> Almost all miners require fees now for transactions outside of a relatively small free block.  And satoshidice includes a fee.
121 2012-07-23 07:56:33 <sturles> One could of course have a fee ladder.  A cheap blockpart in addidtion to the free part of a block, and more expensive parts after that until the block is full.
122 2012-07-23 07:58:15 <Ferroh> How do I specify the berkeley DB include path when building the satoshi client?
123 2012-07-23 07:58:44 <Ferroh> XXXX_INCLUDE_PATH=/usr/etc/etc make -f makefile.unix
124 2012-07-23 07:58:47 <Ferroh> what should XXXX be?
125 2012-07-23 07:59:15 <edcba> so the chain grows about 4.8MB a day ?
126 2012-07-23 08:00:35 <edcba> do we have a blockchain size historic graph ?
127 2012-07-23 08:01:22 <edcba> https://blockchain.info/charts/blocks-size
128 2012-07-23 08:02:46 <Joric> geez, what happened in the end of april
129 2012-07-23 08:03:15 <Joric> it went to super-exponential
130 2012-07-23 08:03:27 <Joric> ah, that https://bitcointalk.org/index.php?topic=77870.0
131 2012-07-23 08:03:29 <Ferroh> Joric, satoshidice.
132 2012-07-23 08:14:53 <Ferroh> Does anyone know why my satoshi client build is failing? http://pastebin.com/94yNExEV
133 2012-07-23 08:15:35 <Ferroh> whoops wrong paste :/
134 2012-07-23 08:16:27 <Ferroh> here we go:
135 2012-07-23 08:36:37 <ersi> Ferroh: Uh, are you really building bitcoind? Or are you building boost?
136 2012-07-23 08:36:47 <Ferroh> ersi, what?
137 2012-07-23 08:36:50 <Ferroh> im building bitcoind
138 2012-07-23 08:37:04 <Ferroh> " BOOST_INCLUDE_PATH=/opt/redux/boost_1_50_0/ OPENSSL_INCLUDE_PATH=/opt/redux/openssl-1.0.1c/include/ BDB_INCLUDE_PATH=/opt/redux/db-5.3.21/ make -f makefile.unix bitcoind"
139 2012-07-23 08:37:15 <Ferroh> that is the command im running
140 2012-07-23 08:37:50 <ersi> Which source are you building? trunk/master from github?
141 2012-07-23 08:37:58 <ersi> or one of the tags? like 0.6.3
142 2012-07-23 08:38:01 <Ferroh> the one on the bitcoin.org page
143 2012-07-23 08:38:02 <Ferroh> 0.6.3
144 2012-07-23 08:38:29 <Ferroh> i am doing this in a jailshell, I've asked the sysadmin to build berkeleyDB 5.1 for me, in case that's the issue
145 2012-07-23 08:38:58 <Ferroh> i cant really think of anything else
146 2012-07-23 08:39:22 <Ferroh> the sysadmin built berkeley 5.3 for me, could he have messed it up somehow? :/
147 2012-07-23 08:42:33 <ersi> I don't know what the problem is, but perhaps you're using a too new version of some or one of the dependencies
148 2012-07-23 08:43:32 <ersi> boost seems to be not too happy in that output
149 2012-07-23 08:55:54 <Ferroh> damn it
150 2012-07-23 08:56:01 <Ferroh> identical error with berkeley 5.1
151 2012-07-23 08:56:17 <Ferroh> well almost identical
152 2012-07-23 08:57:29 <Ferroh> http://pastebin.com/jFFGzAWU
153 2012-07-23 08:57:31 <Ferroh> :(
154 2012-07-23 10:00:01 <doublec> Ferroh: bitcoin docs say to use libdb 4.8
155 2012-07-23 10:00:07 <doublec> Ferroh: 5.3/5.1 are probably too new
156 2012-07-23 10:06:07 <Ferroh> nah I've built it a bunch of times with 5.1
157 2012-07-23 11:10:34 <t7> whats the easiest way to get a transaction into the network anonymouse-ly ?
158 2012-07-23 11:12:05 <tcatm> t7: Multicast it to a few random nodes.
159 2012-07-23 12:03:40 <t7> can someone with bitcoind running for more than a few days tell me their current memory usage, please?
160 2012-07-23 12:06:10 <tcatm> 1705 bitcoin   20   0 1346m 705m 6208 S  2.0  4.4 112:13.18 bitcoind
161 2012-07-23 12:08:11 <doublec> mines about the same
162 2012-07-23 12:12:14 <t7> 700 meg of ram!
163 2012-07-23 12:12:28 <t7> i dont think this is gonna work on my raspberry pi when i get it
164 2012-07-23 12:12:43 <t7> maybe flash is fast enough for swapping
165 2012-07-23 12:13:07 <D34TH> t7 might i recommend electrum instead?
166 2012-07-23 12:14:40 <t7> D34TH: does it have a local api?
167 2012-07-23 12:15:15 <D34TH> i do not think so
168 2012-07-23 12:20:28 <t7> maybe i should just buy a linode again as i got a payrise
169 2012-07-23 12:20:44 <t7> but i just upgraded my home broadband and i might aswel use that...
170 2012-07-23 12:20:46 <t7> life is hard
171 2012-07-23 12:23:24 <t7> kids in war torn africa dont have these troubles...
172 2012-07-23 12:25:14 <TimothyA> t7: you were seriously considering running bitcoind on a flash stick?
173 2012-07-23 12:25:55 <Joric> may i run it on SSD?
174 2012-07-23 12:26:04 <TimothyA> I would not recommend it
175 2012-07-23 12:26:10 <TimothyA> it's like putting a pagefile on an SSD - but worse
176 2012-07-23 12:28:44 <jgarzik> Joric: if you are running a full node, SSD is recommended over rotational drives, IMO
177 2012-07-23 12:28:55 <TD> t7: consider bitcoinj
178 2012-07-23 12:29:07 <TD> t7: it may provide the API you need, albiet at the cost of not being fully verifying
179 2012-07-23 12:29:14 <jgarzik> SSDs are great for bitcoind, which must do a -ton- of seeking
180 2012-07-23 12:29:30 <jgarzik> writes are infrequent, if you exclude the log
181 2012-07-23 12:29:45 <TD> jgarzik: yeah, hmm, i thought that too. except that bitcoin seems to be slower on my SSD laptop than my hdd desktops, and it isn't cpu bottlenecked
182 2012-07-23 12:29:49 <TD> there's something weird going on there.
183 2012-07-23 12:30:13 <TD> it _should_ be true and probably is true. but it may be that there's something we're doing that's not optimal
184 2012-07-23 12:30:30 <jgarzik> TD: SSD != "all flash drives"...  I'm not talking about $10 2GB sticks
185 2012-07-23 12:30:38 <jgarzik> cheap sticks will not perform
186 2012-07-23 12:30:40 <TD> the SSD in my laptop should be pretty high end
187 2012-07-23 12:30:47 <TD> given what the device costs! :)
188 2012-07-23 12:30:51 <jgarzik> indeed
189 2012-07-23 12:30:53 <TD> but you may be right. potentially it's rubbish
190 2012-07-23 12:31:15 <TD> is sipas DNS seed offline?
191 2012-07-23 12:31:31 <jgarzik> 15312 jgarzik   39  19  910m 147m 3652 S  0.3  3.7  21:03.88 bitcoind
192 2012-07-23 12:31:42 <TD> for some reason both sipas and BlueMatts DNS seeds appear to be down :(
193 2012-07-23 12:32:03 <jgarzik> BlueMatt: ^
194 2012-07-23 12:32:31 <gmaxwell> Bluematt's has been down for some time, he's aware of it. (unless he recently got it back up again)
195 2012-07-23 12:34:17 <TD> :(
196 2012-07-23 12:34:40 <jgarzik> anybody know a highly reliable, DDoS resistant DNS service... with (a) an API and (b) permits multiple A records for a name being updated through said API
197 2012-07-23 12:35:27 <TD> sigh. if we'd made the discovery protocol use HTTP this would all be a lot simpler
198 2012-07-23 12:35:58 <jgarzik> TD: not sure I follow
199 2012-07-23 12:36:23 <jgarzik> TD: DNS is only used for one-time bootstrapping.  HTTP would surely require DNS, which gets us back to the same problem.
200 2012-07-23 12:36:36 <TD> there are lots of scalable, DDoS resistant hosting services that makes it easy to serve lists of things
201 2012-07-23 12:36:39 <TD> for very cheap
202 2012-07-23 12:36:46 <TD> (which also handle DNS for you)
203 2012-07-23 12:38:32 <jgarzik> TD: and are willing to host pages which "run a botnet"?  takedowns are very easy
204 2012-07-23 12:38:42 <jgarzik> TD: still, HTTP bootstrapping would not be difficult to add
205 2012-07-23 12:39:28 <epscy> is this the zerigo outage?
206 2012-07-23 12:39:59 <jgarzik> sipa vacation outage I think
207 2012-07-23 12:40:19 <TD> hmm, true
208 2012-07-23 12:40:40 <TD> yeah we lost half our DNS seeds due to vacation+being busy :(
209 2012-07-23 12:41:07 <t7> namecoin?
210 2012-07-23 12:41:26 <TD> what's the relevance?
211 2012-07-23 12:41:34 <t7> whats the dns seed for?
212 2012-07-23 12:42:05 <gmaxwell> Nothing relevant to namecoin, for sure!
213 2012-07-23 12:42:07 <TD> helping new nodes (and bitcoinj clients) find peers to connect to
214 2012-07-23 12:42:18 <t7> also, did anyone see that huge pull request for google DB?
215 2012-07-23 12:42:24 <gmaxwell> TD: you really need to fix bitcoinj to not be so dependant on it.
216 2012-07-23 12:42:31 <TD> i know
217 2012-07-23 12:42:35 <TD> along with many, many other things that need fixing
218 2012-07-23 12:42:38 <gmaxwell> t7: no, no one saw that.
219 2012-07-23 12:42:41 <TD> bitcoin implementation == big pile of work
220 2012-07-23 12:43:08 <gmaxwell> :)
221 2012-07-23 12:43:16 <t7> sircasm?
222 2012-07-23 12:43:30 <t7> i have no spell check either so sorry if i fluff up words
223 2012-07-23 12:43:31 <TD> t7: i think most of us saw it. myself and justmoon made it
224 2012-07-23 12:43:40 <TD> t7: it was announced on the dev mailing list
225 2012-07-23 12:43:49 <BlueMatt> jgarzik: there are a ton of them (using the standard bind update notification things)
226 2012-07-23 12:44:11 <BlueMatt> gmaxwell: yea...sorry, Im on vacation, but Ill see if I can get it back up later in the week when I get back
227 2012-07-23 12:44:11 <jgarzik> MemPool: blk.vtx.sz 256, neverseen 1, poolsz 248
228 2012-07-23 12:44:11 <jgarzik> MemPool: blk.vtx.sz 67, neverseen 1, poolsz 176
229 2012-07-23 12:44:29 <jgarzik> sometimes blocks come through with a -bunch- of TX's that have never been broadcast to the network
230 2012-07-23 12:44:32 <TD> BlueMatt: don't worry too much. there are other seeds.
231 2012-07-23 12:44:34 <jgarzik> not saying that's wrong... just noting
232 2012-07-23 12:44:46 <BlueMatt> TD: its been down for a while...
233 2012-07-23 12:44:50 <TD> BlueMatt: yeah
234 2012-07-23 12:45:07 <TD> jgarzik: maybe your memory pool just isn't getting all of the ones other memory pools are. we've always sort of assumed the flood fill works
235 2012-07-23 12:45:11 <TD> but i guess it's not been measured precisely
236 2012-07-23 12:45:29 <jgarzik> anything's possible
237 2012-07-23 12:46:06 <jgarzik> most blocks seem to reliably snarf known TX's, so my guess is miner policy
238 2012-07-23 12:46:13 <jgarzik> rather than my implementation
239 2012-07-23 12:46:39 <TD> hmm
240 2012-07-23 12:46:58 <TD> payout transactions of some kind?
241 2012-07-23 12:47:04 <jgarzik> that's my first guess
242 2012-07-23 12:47:08 <tcatm> How many dns seeds do we have?
243 2012-07-23 12:47:24 <TD> 4, i think
244 2012-07-23 12:47:28 <jgarzik> {"bitcoin.sipa.be", "seed.bitcoin.sipa.be"},
245 2012-07-23 12:48:01 <jgarzik> bitseed.xf2.org is -highly- unlikely to ever go down, but its results are largely static and may be stale
246 2012-07-23 12:48:25 <tcatm> Do seeds need to keep a copy of the chain?
247 2012-07-23 12:48:32 <jgarzik> tcatm: no
248 2012-07-23 12:48:45 <jgarzik> tcatm: they just need to return a list of A's records, corresponding to bitcoin P2P nodes
249 2012-07-23 12:48:54 <jgarzik> tcatm: pure DNS service
250 2012-07-23 12:49:21 <jgarzik> tcatm: dns lookup "myseed.example.com" returns a list of P2P node addresses
251 2012-07-23 12:49:42 <tcatm> Yep, but what's required on the server side to collect those A records?
252 2012-07-23 12:50:28 <jgarzik> tcatm: whatever you can come up with :)
253 2012-07-23 12:50:55 <jgarzik> lovely
254 2012-07-23 12:50:59 <jgarzik> http://bitcoin.sipa.be/seeds.txt is blank, too
255 2012-07-23 12:51:28 <tcatm> So no "download this tarball, make install and configure bind like this"?
256 2012-07-23 12:52:01 <jgarzik> tcatm: sipa wrote https://github.com/sipa/bitcoin-seeder
257 2012-07-23 12:52:26 <jgarzik> tcatm: which is a hybrid dns server / P2P walker, IIUC.  something that probes the P2P network directly, and collects addresses.
258 2012-07-23 12:52:49 <jgarzik> tcatm: I've always thought a simple bitcoind patch to return a bunch of addresses would be easier.  JSON -> bind update from there.
259 2012-07-23 12:54:11 <tcatm> That would be cool.
260 2012-07-23 12:55:33 <tcatm> Let's try it :)
261 2012-07-23 12:58:13 <BlueMatt> jgarzik: you still need to crawl the nodes and test them, cant just put them in dns just based on appearing in the addr db
262 2012-07-23 12:59:21 <jgarzik> BlueMatt: https://github.com/sipa/bitcoin-seeder/blob/master/README
263 2012-07-23 12:59:31 <jgarzik> "Bitcoin-seeder is a crawler for the Bitcoin network, which exposes a list
264 2012-07-23 12:59:32 <jgarzik> of reliable nodes via a built-in DNS server."
265 2012-07-23 12:59:34 <tcatm> Hrm. Segfault :/
266 2012-07-23 12:59:55 <BlueMatt> jgarzik: yea, I thought you were suggesting not crawl and just patch bitcoind to dump from addr db
267 2012-07-23 13:00:30 <jgarzik> BlueMatt: random fresh addresses from addr db + test should be fine
268 2012-07-23 13:00:54 <BlueMatt> random fresh addresses from addr db that have been tested would be better
269 2012-07-23 13:01:04 <BlueMatt> and not much harder to implement
270 2012-07-23 13:02:06 <jgarzik> bitcoind need only be patched to return random fresh addresses.  a simple python script that verifies a 'version' message response would suffice from there.
271 2012-07-23 13:02:36 <BlueMatt> well, ok that works too
272 2012-07-23 13:03:02 <BlueMatt> https://github.com/TheBlueMatt/bitcoin/commits/bloom <-- bloom filter of tx inv messages in bitcoind, implementation in bitcoinj: http://code.google.com/r/bluemattme-bitcoinj/source/list?name=bloomfilter
273 2012-07-23 13:03:42 <jgarzik> BlueMatt: neat!
274 2012-07-23 13:03:46 <BlueMatt> not really worth much until blocks are transmitted differently, but, whatever
275 2012-07-23 13:04:11 <jgarzik> BlueMatt: serialize is portable, I presume?
276 2012-07-23 13:04:18 <BlueMatt> yea
277 2012-07-23 13:04:47 <BlueMatt> not very space effecient (max size is only 18k, so no big deal, but if someone really wanted that...)
278 2012-07-23 13:04:56 <BlueMatt> efficient
279 2012-07-23 13:05:16 <BlueMatt> (18k is 10,000 items with fp rate < 0.1%)
280 2012-07-23 13:06:00 <tcatm> I can't get bitcoin-seeder to run. (segfault in Lookup; somethings wrong with pszName)
281 2012-07-23 13:06:20 <BlueMatt> jgarzik: the bitcoinj one added a test case which creates and compares serialized object to ones generated by bitcoind, should probably copy that test-case over to bitcoind too...
282 2012-07-23 13:07:15 <jgarzik> BlueMatt: would be nice
283 2012-07-23 13:07:21 <BlueMatt> tcatm: never worked with it, but from what I know, its all just butchered bitcoind code, so it shouldnt be too unfamiliar
284 2012-07-23 13:07:32 <jgarzik> BlueMatt: looks sufficient to easily filter "mempool" P2P command too, which is nice.
285 2012-07-23 13:07:45 <jgarzik> BlueMatt: I agree blocks want filtering.  not too difficult to add.
286 2012-07-23 13:09:11 <BlueMatt> its not that pretty to add, change the block serialization based on version, then you have to put the blocks in a map by missing txes, get the txes, and then process later
287 2012-07-23 13:09:22 <BlueMatt> the issue is the DoS values get kinda wonky at that point
288 2012-07-23 13:09:44 <BlueMatt> would need DoS callbacks...
289 2012-07-23 13:27:02 <TD> BlueMatt: oh, wow, nice!
290 2012-07-23 13:27:29 <TD> BlueMatt: I'm fixing regressions in bcj at the moment
291 2012-07-23 13:27:38 <TD> once i'm done with that and things are stable again, merging some of your patches is my next highest priority
292 2012-07-23 13:27:44 <TD> BlueMatt: btw
293 2012-07-23 13:27:53 <TD> BlueMatt: the guava library we use has an implementation of bloom filters already
294 2012-07-23 13:28:12 <TD> http://docs.guava-libraries.googlecode.com/git-history/v12.0/javadoc/index.html?r=v12.0
295 2012-07-23 13:28:13 <TD> sorry
296 2012-07-23 13:28:18 <TD> i would have mentioned this if you'd said you were going to work on it
297 2012-07-23 13:28:40 <BlueMatt> meh, I would have had to re-implement its hash functions in bitcoind anyway
298 2012-07-23 13:28:46 <TD> sure
299 2012-07-23 13:28:50 <TD> ok
300 2012-07-23 13:28:56 <BlueMatt> the bloom filter stuff is pretty short anyway...
301 2012-07-23 13:29:01 <TD> cool
302 2012-07-23 13:29:45 <BlueMatt> in terms of merging verification stuff...nice! Ill be back on Thursday to fix bugs
303 2012-07-23 13:44:34 <BlueMatt> (bloomfilter.java is only 159 loc, and most of that is the hash function, which is just copied/pasted
304 2012-07-23 13:46:08 <Ferroh> Does anyone see what is wrong with my bitcoind build? :(
305 2012-07-23 13:47:40 <BlueMatt> "g++: Internal error: Killed (program cc1plus)" generally means oom, but some of the other stuff seems to indicate your db++ install or gcc install are messed up
306 2012-07-23 13:48:14 <Ferroh> how much memory does a build use typically? (do you know?)
307 2012-07-23 13:48:24 <BlueMatt> (on bitcoind, the bloom filter cpp file is only 124 loc, and most of that is just the IsTransactionRelevantToContainedHash(tx...)
308 2012-07-23 13:48:46 <BlueMatt> Ferroh: shouldnt be too bad, maybe 512M on -j2, just dont do it on a vps
309 2012-07-23 13:49:04 <Ferroh> I am doing it on a VPS
310 2012-07-23 13:49:10 <BlueMatt> try -j1
311 2012-07-23 13:49:19 <Ferroh> ok
312 2012-07-23 13:49:48 <Ferroh> how do I specify that switch
313 2012-07-23 13:49:55 <Ferroh> or where
314 2012-07-23 13:49:58 <BlueMatt> make -j1
315 2012-07-23 13:50:03 <D34TH> ^
316 2012-07-23 13:50:10 <Ferroh> that didnt work :/
317 2012-07-23 13:50:26 <BlueMatt> did you still get the "g++: Internal error: Killed (program cc1plus)"
318 2012-07-23 13:50:40 <BlueMatt> in any case, looks like your gcc/db++ installs are f'd up
319 2012-07-23 13:50:41 <Ferroh> no i mean, how do I specify both -f and -j1
320 2012-07-23 13:50:43 <BlueMatt> or one of the is
321 2012-07-23 13:50:49 <BlueMatt> make -f makefile.unix -j1
322 2012-07-23 13:51:02 <Ferroh> thanks :) dont laugh at me
323 2012-07-23 13:51:13 <BlueMatt> hey, we all start somewhere
324 2012-07-23 13:51:17 <Ferroh> hmm..
325 2012-07-23 13:51:21 <Ferroh> ok check out this output
326 2012-07-23 13:51:46 <Ferroh> http://pastebin.com/sCDV0kGE
327 2012-07-23 13:52:22 <Ferroh> that seems better
328 2012-07-23 13:52:30 <BlueMatt> does `tail /var/log/syslog` show any oom kills
329 2012-07-23 13:52:56 <Ferroh> there is no syslog in /var/log
330 2012-07-23 13:53:06 <BlueMatt> try dmesg | tail -n20
331 2012-07-23 13:53:17 <Ferroh> lol
332 2012-07-23 13:53:30 <Ferroh> here's the last couple of lines
333 2012-07-23 13:53:37 <BlueMatt> yep...you are out of memory
334 2012-07-23 13:53:43 <Ferroh> ok that's good news
335 2012-07-23 13:53:46 <BlueMatt> try bigger swap space
336 2012-07-23 13:53:53 <BlueMatt> (also, go restart apache, it got killed)
337 2012-07-23 13:53:58 <Ferroh> I can't, due to being in a jailshell
338 2012-07-23 13:54:01 <Ferroh> but I can ask the sysadmin
339 2012-07-23 13:54:10 <drizztbsd> compile it locally and push to the jailshell?
340 2012-07-23 13:54:11 <BlueMatt> you could just compile it locally and upload
341 2012-07-23 13:54:16 <BlueMatt> or use a released binary
342 2012-07-23 13:54:46 <Ferroh> the released binary doesn't run
343 2012-07-23 13:55:01 <Ferroh> I dont know how to replicate this servers conditions closely enough to make locally
344 2012-07-23 13:55:18 <jgarzik> BlueMatt: you should mention your bloom code in the bitcoin-devel thread "New P2P commands for diagnostics, SPV clients"
345 2012-07-23 13:55:36 <Ferroh> running the compiled release binary gives some lines like this:
346 2012-07-23 13:55:37 <Ferroh> ./bitcoind: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./bitcoind)
347 2012-07-23 13:56:28 <BlueMatt> jgarzik: yea, Ill mention it when I actually test it with txes instead of just making sure it builds...
348 2012-07-23 13:56:56 <jgarzik> BlueMatt: bah, that's like Phase Four in the Linus Torvalds scale of testing
349 2012-07-23 13:57:18 <BlueMatt> Ferroh: my guess: figure out when the version of redhat you are using was released, grab a fedora from around that time, run it in a vm locally and build bitcoind in it
350 2012-07-23 13:57:35 <BlueMatt> jgarzik: whats phase 1-3?
351 2012-07-23 13:57:58 <jgarzik> BlueMatt: "it should work", "code exists", "it compiles"
352 2012-07-23 13:58:33 <BlueMatt> ah, well alright, Ill send out an email sometime maybe today
353 2012-07-23 14:05:32 <Ferroh> BlueMatt, it just occurred to me
354 2012-07-23 14:05:48 <Ferroh> BlueMatt, will bitcoin even run, if I can get enough memory to compile it? how much memory does it use?
355 2012-07-23 14:05:58 <Ferroh> it seems that I have like 128mb in this VPS
356 2012-07-23 14:06:14 <luke-jr> http://www.pcworld.com/article/259664/7_reasons_to_beware_bitcoin.html
357 2012-07-23 14:06:37 <Ferroh> well, actually according to top I have 310mb free and 768mb total but I dont know if that is accurate or how VPS works
358 2012-07-23 14:07:48 <luke-jr> looks like misinformation mostly
359 2012-07-23 14:10:59 <D34TH> ferroh
360 2012-07-23 14:11:01 <D34TH> what about htop
361 2012-07-23 14:11:13 <D34TH> or
362 2012-07-23 14:11:14 <D34TH> free -m
363 2012-07-23 14:11:16 <Ferroh> command not found
364 2012-07-23 14:11:23 <Ferroh> free -m says
365 2012-07-23 14:11:29 <Ferroh> the same thing as top pretty much
366 2012-07-23 14:11:41 <Ferroh> total 768mb
367 2012-07-23 14:11:45 <Ferroh> free 337mb
368 2012-07-23 14:11:55 <Ferroh> is that really not enough to do a build? :(
369 2012-07-23 14:11:58 <Ferroh> silly C++
370 2012-07-23 14:12:15 <midnightmagic> cheako: You must be talking about fallocate() that requires support in the filesystem. anyway, It's not nearly so much of a problem for unix-like OSes, if it's a problem at all.
371 2012-07-23 14:12:17 <Eliel_> luke-jr: quite some misinformation indeed.
372 2012-07-23 14:15:47 <BlueMatt> TD: oops, just saw your your filter match email...
373 2012-07-23 14:17:07 <BlueMatt> TD: btw, the way it is now, it just checks each input+output to see if the hash160 of the dest addr, hash160 of the pubkey or hash160 of the p2sh sh matches the filter as-is
374 2012-07-23 14:17:36 <BlueMatt> from your list, I think adding a check to allow adding a specific outpoint to a filter would be nice
375 2012-07-23 14:18:44 <BlueMatt> in terms of data elements in txes, Im not so sure
376 2012-07-23 14:19:16 <BlueMatt> its by no means a bad idea, and it wouldnt be too much overhead, but making filters match 1000 different possible criteria...meh
377 2012-07-23 14:20:47 <BlueMatt> anyway, Ill go write an email because Im off soon, Ill see responses sometime..
378 2012-07-23 15:44:52 <gribble> New news from bitcoinrss: Diapolo opened issue 1625 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1625>
379 2012-07-23 16:29:04 <luke-jr> sounds like we need to get Multibit, Electrum etc to hide their names and just show "Bitcoin" instead everywhere
380 2012-07-23 16:31:15 <luke-jr> sigh
381 2012-07-23 16:32:52 <genjix> luke-jr: how comes?
382 2012-07-23 16:33:21 <genjix> isn't that a bit scummy? i.e false advertisement
383 2012-07-23 16:33:49 <luke-jr> genjix: because the client is a "technical detail" that will confuse users of course https://github.com/bitcoin/bitcoin/pull/1620
384 2012-07-23 16:34:07 <luke-jr> genjix: Bitcoin-Qt 0.7 is going to do it, apparently
385 2012-07-23 16:35:06 <luke-jr> (in reality, this will confuse users into thinking Bitcoin is software, further solidifying the centralization in the Satoshi codebase)
386 2012-07-23 16:39:06 <genjix> luke-jr: i think though, that is a minor point
387 2012-07-23 16:39:29 <genjix> like the least of the worries, and tbh the devs are pretty cool on this subject :D
388 2012-07-23 16:40:37 <luke-jr> I think the centralization in one codebase is one of Bitcoin's bigger problems, and it's disappointing to see Gavin and wumpus encouraging confusion that strengthens it
389 2012-07-23 16:41:57 <genjix> their position is totally understandable, and i can empathise.
390 2012-07-23 16:42:20 <genjix> the question is not a moral one but a practical one: what is best for the user of bitcoin (long term)
391 2012-07-23 16:42:33 <genjix> and short term you need some compromises sometimes
392 2012-07-23 16:42:59 <luke-jr> what is best for the user, is not to increase their confusion.
393 2012-07-23 16:43:12 <luke-jr> now showing "Satoshi" in the titlebar, that would be harmful
394 2012-07-23 16:43:17 <luke-jr> "Bitcoin-Qt" not so much
395 2012-07-23 16:43:33 <genjix> idk this seems a bit like bike-shedding.
396 2012-07-23 16:44:08 <luke-jr> it's a regression that harms Bitcoin. it was better off left alone than now.
397 2012-07-23 16:46:55 <genjix> luke-jr: don't stress it :) it's a small thing. lets try to fight over big things.
398 2012-07-23 16:47:59 <luke-jr> not stressing it really, working on other stuff :p
399 2012-07-23 16:50:14 <gmaxwell> luke-jr: Did they nak that put qt in the title bar? Good. I thought that was silly too.
400 2012-07-23 16:50:44 <genjix> gmaxwell: why are you so hostile all the time?
401 2012-07-23 16:50:55 <genjix> are you really such a burnt up bitter person inside?
402 2012-07-23 16:51:04 <luke-jr> gmaxwell: put the client name*
403 2012-07-23 16:51:08 <gmaxwell> er. I'm not being hostile there at all. I just thought that was a bad idea.
404 2012-07-23 16:51:30 <gmaxwell> -qt is sausage making. I totally agree with the notion of distinguishing one program from all of bitcoin though, -qt isn't a good way to do it.
405 2012-07-23 16:51:30 <luke-jr> gmaxwell: if wumpus doesn't like the client name, he should rename it.
406 2012-07-23 16:51:50 <luke-jr> Bitcoin-Qt has been the name of it since wumpus announced it originally AFAIK
407 2012-07-23 16:52:21 <gmaxwell> luke-jr: It made sense as that announcement because it was the technical feature that distinguished the work, but it's actually a pretty poor name for the maintained gui reference client.
408 2012-07-23 16:52:22 <gavinandresen> I think we should name it UberMegaCoin.  Wait, no, MegaUberCoin.
409 2012-07-23 16:52:32 <luke-jr> lol
410 2012-07-23 16:52:33 <gavinandresen> Wait, no, how do I type capital-u-with-umlaut?
411 2012-07-23 16:52:51 <gmaxwell> ??
412 2012-07-23 16:52:54 <gmaxwell> hm. not quite.
413 2012-07-23 16:52:59 <gmaxwell> ??
414 2012-07-23 16:53:14 <gavinandresen> ??berMegaCoin
415 2012-07-23 16:53:18 <gmaxwell> compose U " for me :)
416 2012-07-23 16:53:29 <gavinandresen> (I cheated and copied/pasted)
417 2012-07-23 16:54:03 <gmaxwell> My general preference is to call it the "reference implementation" or "reference client" but thats also obsecure and doesn't fit well in a title bar.
418 2012-07-23 16:54:57 <gavinandresen> We made the mistake many years ago of naming a software project something godawful, thinking that would FORCE the marketing folks to come up with a better name....
419 2012-07-23 16:54:58 <luke-jr> gmaxwell: well, the codebase is reference. the GUI isn't so much IMO
420 2012-07-23 16:55:12 <luke-jr> gavinandresen: didn't work? XD
421 2012-07-23 16:55:25 <gavinandresen> not so much, they kept the godawful name.
422 2012-07-23 16:55:41 <gmaxwell> Been there, done that.
423 2012-07-23 16:56:22 <gavinandresen> Users will call whatever they're using "bitcoin", like how my mother-in-law calls Safari "The Internet"
424 2012-07-23 16:56:49 <luke-jr> RockBitcoin (as in, rock solid) ? :p
425 2012-07-23 16:57:16 <gavinandresen> I'd call it Bruce, but that's because I was born down under
426 2012-07-23 16:57:33 <luke-jr> O.o
427 2012-07-23 16:58:13 <gavinandresen> speaking of Bruce... we should do a Bruce release candidate one soon
428 2012-07-23 16:58:28 <gavinandresen> (Bruce version 0.7 rc1)
429 2012-07-23 16:58:43 <pickett> how old were you when you moved to the US?
430 2012-07-23 16:58:48 <gavinandresen> pickett: 5 years old
431 2012-07-23 16:59:43 <luke-jr> gavinandresen: don't forget to merge gmp_bip first :/
432 2012-07-23 17:00:22 <gavinandresen> luke-jr: why is that high priority?
433 2012-07-23 17:00:39 <luke-jr> gavinandresen: because it fixes a block-losing bug in anything using GMP
434 2012-07-23 17:01:00 <gavinandresen> luke-jr: which issue is that?
435 2012-07-23 17:01:20 <luke-jr> gavinandresen: without fee and sigop data, they can't avoid producing too-many-sigop blocks
436 2012-07-23 17:02:44 <gavinandresen> mmm.  anybody actually been bitten by that?  doesn't sound like a super high priority bug to me.
437 2012-07-23 17:03:32 <luke-jr> I'm not sure. it's more of an exploit vector
438 2012-07-23 17:03:43 <luke-jr> someone would probably need to try to craft transactions to exploit it
439 2012-07-23 17:04:14 <gavinandresen> I'm looking at the current getmemorypool code, and it calls CreateNewBlock, which does all the transaction counting...
440 2012-07-23 17:04:27 <luke-jr> gavinandresen: right, but p2pool and Eligius add more sigops in the coinbase
441 2012-07-23 17:04:29 <gavinandresen> ... so it would only affect gmp users who add their own transactions?
442 2012-07-23 17:04:58 <luke-jr> p2pool doesn't even require the coinbase outputs use standard script
443 2012-07-23 17:05:28 <luke-jr> so probably the easiest exploit is a p2pool miner that submits each share with a unique 20-sigop output
444 2012-07-23 17:05:36 <luke-jr> or however many sigops they can shove into it
445 2012-07-23 17:06:06 <gavinandresen> so p2pool should require that the coinbase transaction be IsStandard(), it seems to me....
446 2012-07-23 17:06:18 <gmaxwell> p2pool filters the payout scripts now.
447 2012-07-23 17:06:21 <luke-jr> gavinandresen: even then, it just makes the attack a little harder ;)
448 2012-07-23 17:06:25 <gmaxwell> Has for a couple months.
449 2012-07-23 17:06:46 <gmaxwell> It was a sad thing but it was just too attractive a target for trouble making.
450 2012-07-23 17:07:01 <luke-jr> do each share as a 1-of-3 BIP16 output, and make sure you get enough shares&
451 2012-07-23 17:08:04 <luke-jr> anyhow, it's just one fewer patch miners need to apply; no reason NOT to merge it
452 2012-07-23 17:09:42 <gmaxwell> In any case, I wasn't trying to say it's not an issue. It is. I just don't think it's one with too high griefing potential.
453 2012-07-23 17:09:53 <jgarzik> hmmm
454 2012-07-23 17:09:55 <gavinandresen> 100 more lines of code to fix a bug seems excessive
455 2012-07-23 17:11:01 <jgarzik> all coinbases up to block ~143k were well-formed
456 2012-07-23 17:11:03 <jgarzik> and most still are
457 2012-07-23 17:11:36 <gavinandresen> jgarzik: could do, but would cause heartburn for anybody merged mining, right?
458 2012-07-23 17:12:20 <jgarzik> gavinandresen: I wouldn't think so, but maybe I'm missing something.  "well-formed" still includes the ability to push random opaque data
459 2012-07-23 17:13:13 <gavinandresen> luke-jr: is there a standard for what merged mining data looks like in the coinbase txin?
460 2012-07-23 17:13:16 <luke-jr> gavinandresen: it's also BIP 22 compatibility
461 2012-07-23 17:13:21 <luke-jr> gavinandresen: yes
462 2012-07-23 17:13:36 <luke-jr> https://en.bitcoin.it/wiki/Merged_mining_specification
463 2012-07-23 17:14:00 <luke-jr> https://en.bitcoin.it/wiki/Merged_mining_specification#Merged_mining_coinbase specifically
464 2012-07-23 17:14:48 <gavinandresen> so no push-data opcode before the 46 bytes.  That's unfortunate
465 2012-07-23 17:15:09 <gavinandresen> (although adding one won't break stuff, I suppose)
466 2012-07-23 17:15:29 <jgarzik> shouldn't be harmful to require that for ver=2 blocks
467 2012-07-23 17:15:38 <jgarzik> ver=1 blocks behave as current
468 2012-07-23 17:15:42 <jgarzik> luke-jr: agreed
469 2012-07-23 17:15:48 <jgarzik> that's all you need to do
470 2012-07-23 17:16:25 <gavinandresen> jgarzik: sure, won't be harmful but will cause a tiny bit of heartburn for anybody merged mining (have to add the push-46-bytes opcode before the data)
471 2012-07-23 17:17:02 <jgarzik> gavinandresen: yes
472 2012-07-23 17:17:27 <jgarzik> gavinandresen: they will probably have to touch their coinbase anyway, to put height in it
473 2012-07-23 17:17:42 <luke-jr> I think I'll have to redo my height-in-coinbase branch
474 2012-07-23 17:17:48 <gavinandresen> good point
475 2012-07-23 17:18:24 <luke-jr> I mean generally, not relating to jgarzik's suggestion
476 2012-07-23 17:18:32 <luke-jr> serializing requirement is trivial
477 2012-07-23 17:18:44 <jgarzik> gavinandresen: (random change of subject query)  does testnet3 include a full exercising of the script engine, including non-standard transactions?
478 2012-07-23 17:18:56 <luke-jr> I've just changed too much code touched by height-in-coinbase since the original proposal
479 2012-07-23 17:19:13 <eian> I've always been able to avoid using UPnP with the following flag: qmake USE_PNP=-. I'm now seeing "miniupnpc/miniwget.h: No such file or directory"
480 2012-07-23 17:19:32 <luke-jr> eian: you're missing a U
481 2012-07-23 17:19:38 <eian> duh
482 2012-07-23 17:19:39 <eian> thanks
483 2012-07-23 17:19:50 <gavinandresen> jgarzik: pretty close.  I wrote test cases for every opcode, but the CHECKSIG opcodes aren't fully exercised
484 2012-07-23 17:20:20 <jgarzik> gavinandresen: super awesome
485 2012-07-23 17:20:34 <gavinandresen> jgarzik: the test cases embedded in the chain are the ones in JSON format in src/test/data/script_valid.json
486 2012-07-23 17:20:36 <jgarzik> gavinandresen: this was a great idea, putting those test cases in the test chain itself
487 2012-07-23 17:21:07 <gavinandresen> (I have an incredibly hacked-up branch that extends IsStandard() and IsMine() to understand all of those)
488 2012-07-23 17:21:14 <jgarzik> gavinandresen: should help with my pynode testing and verification
489 2012-07-23 17:21:26 <jgarzik> definitely a great cross-platform test solution
490 2012-07-23 17:21:46 <gavinandresen> great, that was the idea....
491 2012-07-23 17:22:58 <eian> Would anyone familiar with scripts mind looking at this quickly: http://www.bitcoinsecurity.org/2012/07/22/7/
492 2012-07-23 17:23:54 <gavinandresen> eian: are you the author?
493 2012-07-23 17:23:58 <eian> my wife is
494 2012-07-23 17:24:10 <eian> We are working on a bitcoin related project for our masters
495 2012-07-23 17:24:22 <gavinandresen> nice!  bitcoin needs more women...
496 2012-07-23 17:24:41 <eian> :) She's a geek - lucky me
497 2012-07-23 17:24:49 <gavinandresen> (and my wife is a different kind of geek)
498 2012-07-23 17:24:57 <poop_> eian: is bitcoinsecurity.org yours?
499 2012-07-23 17:25:05 <eian> yeah
500 2012-07-23 17:25:11 <poop_> neat!
501 2012-07-23 17:25:25 <poop_> I have subscribed and am looking forward to more posts
502 2012-07-23 17:25:34 <eian> cool, thanks
503 2012-07-23 17:34:18 <gavinandresen> eian: scanned through the post quickly, looks OK (I could quibble about stuff like 1-of-2 multisig Scripts are possible that only require 1 signature and 2 pubkeys, but don't want to spend the time)
504 2012-07-23 17:34:44 <eian> gavin, thanks for taking a look
505 2012-07-23 17:35:09 <eian> gavin, I'll mention the multisig stuff to the woman
506 2012-07-23 17:35:11 <eian> :P
507 2012-07-23 17:47:23 <lianj> eian: [sig_s][0??01] i think you mean the hash_type by [0x01]
508 2012-07-23 17:49:47 <eian> lianj, thanks
509 2012-07-23 17:51:49 <lianj> based on that hash type op_checksig for example then decides how to create the signature hash that was signed and verify it then
510 2012-07-23 17:55:47 <lianj> eian: maybe a typo "leading zeroes are kept as single zeroes when conversion happens." ?
511 2012-07-23 17:57:58 <lianj> eian: also, is sig_r and sig_s really pushed in two chunks? i only get one chunk that is the whole sig_r+sig_s
512 2012-07-23 18:01:34 <lianj> ah nevermind about sig_r+sig_s.. everything after [sigLength] is just one pushdata
513 2012-07-23 18:55:04 <jgarzik> what is the current block count for testnet3?
514 2012-07-23 18:55:21 <jgarzik> 8677? 72106? 47476?
515 2012-07-23 18:55:27 <gmaxwell> "blocks" : 8677,
516 2012-07-23 18:55:47 <gmaxwell> 72106/47476 are testnet1 (different forks)
517 2012-07-23 18:55:55 <gmaxwell> er well testnet 2 rather.
518 2012-07-23 18:59:43 <jgarzik> gmaxwell: odd that git HEAD will talk to them, then.  I thought that pchMessageStart differed for each
519 2012-07-23 19:00:35 <gmaxwell> It's not, as that would break tools that speak the network protocol. I don't really like that. but.. meh.
520 2012-07-23 19:03:16 <jgarzik> hum
521 2012-07-23 19:04:11 <gmaxwell> what sort of won me over is that this exposes some misbehavior that we ought to fix... because it could be used maliciously or arise as a result of some other issue.
522 2012-07-23 19:05:09 <gmaxwell> e.g. testnet3 nodes can get totally stuck behind testnet2 nodes and stay like that ~forever.
523 2012-07-23 19:07:09 <jgarzik> makes sense, though the clean separation -- where differing pchMessageStart simply cannot even talk to each other -- is rather nice
524 2012-07-23 19:07:21 <jgarzik> less lingering around uselessly
525 2012-07-23 19:09:06 <D34TH> bluematt: i tried running the script for the first time, it gave me the --help for qmake
526 2012-07-23 19:19:53 <phantomcircuit> hmm
527 2012-07-23 19:20:13 <phantomcircuit> i think i'll make a pretty graph of the processing time for blocks
528 2012-07-23 19:20:18 <TD> eian: yeah the sighash and lock time stuff isn't mentioned. it's discussed on the Contracts page
529 2012-07-23 19:20:42 <jgarzik> can anybody send me some testnet3 coins?
530 2012-07-23 19:20:44 <jgarzik> moudW92PBpiVsds297krs615fMBWjFvSur
531 2012-07-23 19:20:57 <jgarzik> faucet does not seem to be sending me any
532 2012-07-23 19:22:31 <gmaxwell> sure.
533 2012-07-23 19:22:59 <gmaxwell> e5288cbaa80ec27916b260f98a61512c1fdc74b41e5528014df731d465e23b5d
534 2012-07-23 19:29:47 <jgarzik> definitely not seeing that TX
535 2012-07-23 19:30:16 <jgarzik> I'm starting to think that "test confused mix of genesis blocks" test has overridden the basic utility of testnet ;-)
536 2012-07-23 19:30:54 <jgarzik> gmaxwell: is your node on a public IP I may addnode?
537 2012-07-23 19:31:11 <lianj> maybe its the key ^^
538 2012-07-23 19:32:21 <gmaxwell> sure, easiest way is via tor as it has a hidden service address.
539 2012-07-23 19:33:10 <gmaxwell> 6hgmaxwellgpv2oe.onion is the HS address.
540 2012-07-23 19:35:11 <jgarzik> gmaxwell: would you be kind enough to send more coins to the testnet3 address above?
541 2012-07-23 19:35:27 <gmaxwell> jgarzik: Sure, but.. you need more than a thousand? :)
542 2012-07-23 19:35:38 <jgarzik> gmaxwell: don't want to wait 2 hours for retransmit
543 2012-07-23 19:35:42 <gmaxwell> ahh
544 2012-07-23 19:35:54 <jgarzik> gmaxwell: 1 testBTC is fine
545 2012-07-23 19:36:02 <jgarzik> no need for 1000
546 2012-07-23 19:36:45 <gmaxwell> lemme try something
547 2012-07-23 19:39:07 <gmaxwell> darnit, I wanted to try resending it by using sendrawtx but it doesn't seem like gettransaction will get me just the whole serialized thing.
548 2012-07-23 19:39:25 <jgarzik> client sure does waste outgoing connection slots on remote nodes with totally different genesis blocks
549 2012-07-23 19:39:39 <jgarzik> we should either detect the condition or just change pchMessageStart
550 2012-07-23 19:40:04 <jgarzik> gmaxwell: hum, surprising
551 2012-07-23 19:40:08 <luke-jr> gmaxwell: too bad decompositions were reverted&
552 2012-07-23 19:40:36 <jgarzik> heh
553 2012-07-23 19:40:42 <gmaxwell> luke-jr: I'm running a branch with decompositions here. but none seem to do it.
554 2012-07-23 19:40:55 <luke-jr> gmaxwell: yes, I'm not saying it worked, just that it had semantics for that
555 2012-07-23 19:41:04 <jgarzik> according to getpeerinfo, gmaxwell is the only useful peer among 8 outgoing.  all others are testnet1 or testnet2.
556 2012-07-23 19:41:47 <gmaxwell> jgarzik: sipa was brainstorming some on outgoing connection rotation behavior, which would solve this.
557 2012-07-23 19:42:01 <gmaxwell> Basically replacing peers, and using the usefulness of peers as part of the replacement policy.
558 2012-07-23 19:42:30 <jgarzik> gmaxwell: in this case we'd need to probe block #0 before discarding?
559 2012-07-23 19:43:25 <gmaxwell> jgarzik: try doing bitcoind sendrawtransaction 0100000001822e9db318b69b718c2e59eb4277511d0a4a888138b49f6e37730e2e1176048a020000006b48304502207e46c3c2e0b5e28b14420767082ffe677c8eab8ad401009cbaf516f5521ffb4e022100ba1f36f1e58913dd4942c30a827aa335e95c69a76acc17e1734fb5f377e5ba35012102680b39f95d3f4506179d0e253ed8971a3d4f409ef632f79d72d398ae08bd73cdffffffff0200282e8cd10000001976a91498a79e28be87687c1399dd5ac73e2542b4dceb2188ac00e87648170000001976a91
560 2012-07-23 19:43:34 <gmaxwell> (and will we have the first textnet transaction relayed over IRC? :)
561 2012-07-23 19:43:56 <gmaxwell> luke-jr: in the latest git there is now getrawtransaction which actually does what I needed there.
562 2012-07-23 19:43:59 <jgarzik> gmaxwell: TX decode failed ;)
563 2012-07-23 19:44:13 <luke-jr> gmaxwell: does it? :P
564 2012-07-23 19:44:42 <gmaxwell> jgarzik: hm! just worked for me. Did it relay it again?
565 2012-07-23 19:44:47 <jgarzik> gmaxwell: ditto for decoderawtransaction
566 2012-07-23 19:45:05 <gmaxwell> maybe IRC truncated it.. did it end with ac00000000 ?
567 2012-07-23 19:45:19 <jgarzik> gmaxwell: ...976a9a
568 2012-07-23 19:45:29 <jgarzik> gmaxwell: ...976a91
569 2012-07-23 19:45:47 <gmaxwell> yea.. IRC's fault. do you have it now? (I did the send, but I dunno if it will relay again)
570 2012-07-23 19:46:03 <gmaxwell> if not, I'll paste broken up.
571 2012-07-23 19:46:17 <jgarzik> gmaxwell: don't have it yet.  I'd love to try pastebin or similar, as a fun test
572 2012-07-23 19:46:21 <gmaxwell> 0100000001822e9db318b69b718c2e59eb4277511d0a4a888138b49f6e37730e2e1176048a020000006b48304502207e46c3c2e0b5e28b14420767082ffe677c8eab8ad401009cbaf516f5521ffb4e022100ba1f36f1e58913dd4
573 2012-07-23 19:46:25 <jgarzik> gmaxwell: or paste broken up, yeah
574 2012-07-23 19:46:29 <gmaxwell> 942c30a827aa335e95c69a76acc17e1734fb5f377e5ba35012102680b39f95d3f4506179d0e253ed8971a3d4f409ef632f79d72d398ae08bd73cdffffffff
575 2012-07-23 19:46:38 <gmaxwell> 0200282e8cd10000001976a91498a79e28be87687c1399dd5ac73e2542b4dceb2188ac00e87648170000001976a9145c0ae30d731c51eea9ef3ecbb41b14b
576 2012-07-23 19:46:45 <gmaxwell> 6bc53163d88ac00000000
577 2012-07-23 19:46:46 <gmaxwell> there.
578 2012-07-23 19:46:47 <luke-jr> gmaxwell: your IRC client's fault ;)
579 2012-07-23 19:47:07 <luke-jr> Freenode does tell it what the line length limit is
580 2012-07-23 19:47:09 <gmaxwell> the lines should end with dd4 fff b14b 000
581 2012-07-23 19:47:15 <jgarzik> gmaxwell: worked!  ;-)
582 2012-07-23 19:47:54 <gmaxwell> woot.
583 2012-07-23 19:48:21 <gmaxwell> so.. thats good, though the sendrawtx should probably have forced me to relay again.
584 2012-07-23 19:49:10 <gmaxwell> a little worrysome how easy it is to currupt these things.
585 2012-07-23 19:49:27 <gmaxwell> ... these hex objects should probably get hashes/crcs. :(
586 2012-07-23 19:49:57 <lianj> why? parsing the broken tx would fail anyway
587 2012-07-23 19:50:15 <gmaxwell> lianj: no, .. for the truncation it does.. but not for random other errors.
588 2012-07-23 19:50:26 <lianj> and if not parsing then running them
589 2012-07-23 19:50:51 <gmaxwell> lianj: I send you a txn to pay me, it's unsigned. A stray character gets added. You sign it. Opps. Coin gone forever.
590 2012-07-23 19:50:55 <jgarzik> it's completely embarrassing that python's asyncore does not have timer facilities
591 2012-07-23 19:51:08 <jgarzik> I think I'm going to have to fork a process, just to send 1-char wakeups via a pipe fd
592 2012-07-23 19:51:12 <lianj> gmaxwell: ah, i see your point
593 2012-07-23 19:53:42 <lianj> Joric: no twisted?
594 2012-07-23 19:53:48 <lianj> eh jgarzik
595 2012-07-23 19:53:53 <lianj> Joric: sorry
596 2012-07-23 19:54:01 <Joric> no twisted at all
597 2012-07-23 19:54:16 <lianj> hehe
598 2012-07-23 19:57:53 <luke-jr> jgarzik: I had to basically write a networking library for Eloipool
599 2012-07-23 19:58:07 <luke-jr> I started off from asyncore, so maybe it will work for you
600 2012-07-23 19:59:05 <gribble> New news from bitcoinrss: gmaxwell opened issue 1626 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1626>
601 2012-07-23 20:09:25 <gribble> New news from bitcoinrss: jgarzik opened issue 1627 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1627>
602 2012-07-23 20:09:41 <gmaxwell> anyone know what the median txn size is?
603 2012-07-23 20:09:45 <gmaxwell> (in bytes)
604 2012-07-23 20:15:20 <Diablo-D3> gmaxwell: over 9000.
605 2012-07-23 20:15:31 <Joric> cool site http://toolongdidntread.com
606 2012-07-23 20:16:31 <Joric> who are those guys? James Marble / John Russel
607 2012-07-23 20:19:28 <Joric> aha there is a contact page
608 2012-07-23 20:20:38 <jgarzik> lianj: asyncore is built in and easy
609 2012-07-23 20:20:42 <jgarzik> (and perhap that's the problem)
610 2012-07-23 20:20:56 <jgarzik> I've never seen an async networking abstraction without timers/timeouts
611 2012-07-23 20:31:21 <MMavipc> I'm trying to read a wallet.dat from a 3rd party program, I get that public keys are x03keyx41pubkeyhere but I dont understand how private keys are stored in the file, other than they're the data part of the key-data pair could anyone englighten me?
612 2012-07-23 20:32:55 <Joric> how about using a berkeleydb lib
613 2012-07-23 20:34:19 <MMavipc> I am
614 2012-07-23 20:34:28 <MMavipc> To get the key-data pairs
615 2012-07-23 20:34:35 <MMavipc> but they themselves are encoded
616 2012-07-23 20:35:09 <jgarzik> I need 'addnode' and 'bannode' RPCs
617 2012-07-23 20:35:16 <Joric> MMavipc, i maintain https://github.com/joric/pywallet take a look it's all there
618 2012-07-23 20:35:35 <galambo_> anybody want some light reading about bsa/aml/patriot act? http://www.ffiec.gov/bsa_aml_infobase/documents/BSA_AML_Man_2010.pdf
619 2012-07-23 20:37:17 <MMavipc> Joric: when you get the key out of the db it's 238 bytes long, how do I turn that into a 32 byte private key?
620 2012-07-23 20:38:26 <Joric> MMavipc, it's asn1 encoding see http://lapo.it/asn1js/
621 2012-07-23 20:40:12 <luke-jr> anyone want to upload 1.4 GB to SourceForge? (blk0001.dat and pruned blkindex)
622 2012-07-23 20:40:35 <Joric> i don't really remember ssl functions for getting secret from asn.1 I just get it at certain offset (which is different for compressed and uncompressed keys)
623 2012-07-23 20:43:26 <Joric> MMavipc, see PrivKeyToSecret (normally it should be an ASN.1 parser)
624 2012-07-23 20:44:41 <MMavipc> Joric: not familiar with python notation what does the : in 9:9+32 do?
625 2012-07-23 20:44:49 <MMavipc> [9:9+32] to be more precise
626 2012-07-23 20:46:04 <Joric> MMavipc, 32 bytes starting from offset 9
627 2012-07-23 20:50:47 <Joric> it's a very bad practice actually, someone help what's the ssl function to get 32-byte secret from EC_KEY?
628 2012-07-23 20:56:17 <galambo_> has there been an implementation of getauxblock that supports multiple aux chains yet
629 2012-07-23 20:56:33 <galambo_> or is that not worked out yet
630 2012-07-23 20:58:13 <luke-jr> galambo_: getauxblock is for the slave chains
631 2012-07-23 20:58:44 <galambo_> as far as i could read only one slave chain is allowed per bitcoin block
632 2012-07-23 20:59:17 <doublec> merge mining multiple chains works fine
633 2012-07-23 20:59:21 <luke-jr> galambo_: bitcoind does not support merged mining; I have a pullreq at https://github.com/bitcoin/bitcoin/pull/719 , but gave up after months of nobody being willing to pull it
634 2012-07-23 20:59:32 <galambo_> or maybe you talked about that recently i forget
635 2012-07-23 20:59:38 <luke-jr> galambo_: you need something like merged-mine-manager + Eloipool, to do merged mining
636 2012-07-23 20:59:48 <Joric> MMavipc, got it, it's called EC_KEY_get0_private_key
637 2012-07-23 21:00:00 <Joric> MMavipc, returns big number
638 2012-07-23 21:01:24 <galambo_> luke-jr: ok the threads i was reading were from back in 2011 and they said namecoin only supported one chain per bitcoin block. thanks, ill take a look at this pull request.
639 2012-07-23 21:01:40 <luke-jr> galambo_: don't bother, it won't merge with any recent bitcoind
640 2012-07-23 21:01:50 <luke-jr> galambo_: Eloipool+MMM is what works together
641 2012-07-23 21:02:16 <MMavipc> Joric: will it work on both cases? 279 length and 238 length?
642 2012-07-23 21:02:32 <galambo_> are you talking about Ecoinpool?
643 2012-07-23 21:03:07 <galambo_> i was looking at that and it had a "merged mine manager"
644 2012-07-23 21:03:36 <galambo_> oh this is in python
645 2012-07-23 21:04:15 <luke-jr> galambo_: no, I'm talking about Eloipool :P
646 2012-07-23 21:04:17 <galambo_> i guess its not terribly important that the client can't see both chains.
647 2012-07-23 21:04:43 <lianj> MMavipc: it will work on an EC_KEY object
648 2012-07-23 21:05:01 <galambo_> i appreciate this luke-jr. trying to get a handle on how this will be done.
649 2012-07-23 21:05:07 <luke-jr> gitorious.org/bitcoin/eloipool
650 2012-07-23 21:05:35 <lianj> MMavipc: it does nothing besides return key->priv_key
651 2012-07-23 21:06:18 <luke-jr> https://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/blobs/namecoin_mmm/contrib/merged-mine-proxy
652 2012-07-23 21:06:38 <jgarzik> excellent.  bitcoind seems to be mining testnet3
653 2012-07-23 21:06:41 <jgarzik> blocks
654 2012-07-23 21:06:59 <Joric> MMavipc, python code: bn = ssl.EC_KEY_get0_private_key(self.k) mb = ctypes.create_string_buffer(32) ssl.BN_bn2bin(bn, mb) return mb.raw # self.k is EC_KEY object
655 2012-07-23 21:07:00 <wizkid057> just out of curiosity, why doesnt bitcoin have a configure script?
656 2012-07-23 21:09:39 <gavinandresen> wizkid057: because nobody stepped up to write one?
657 2012-07-23 21:10:05 <gavinandresen> (actually,somebody did but it had some issues I didn't understand and died of neglect)
658 2012-07-23 21:10:56 <wizkid057> hmm
659 2012-07-23 21:11:42 <luke-jr> like somethign that scans your code and makes it while offering suggestions on how to improve portability
660 2012-07-23 21:11:57 <wizkid057> there used to be one a lonnnnnng time ago
661 2012-07-23 21:12:13 <wizkid057> that I found on freshmeat
662 2012-07-23 21:12:14 <gavinandresen> let me guess: it died of neglect?
663 2012-07-23 21:12:47 <luke-jr> lol
664 2012-07-23 21:13:03 <wizkid057> pretty much
665 2012-07-23 21:13:59 <gmaxwell> luke-jr: there are lots of lint tools, and they can all suggest portablity things.
666 2012-07-23 21:14:08 <gmaxwell> e.g. splint (though it's more focused on security)
667 2012-07-23 21:14:13 <gmaxwell> And commercially pclint.
668 2012-07-23 21:14:43 <gmaxwell> gcc can also apply more strict standards, e.g. --std=c89 -pedantic
669 2012-07-23 21:15:34 <gavinandresen> I like pedantic compilers.  I just wish all of our dependencies liked them, too
670 2012-07-23 21:16:29 <jgarzik> pynode successfully syncs testnet3 -- if I create a new TX in bitcoind to kickstart python's asyncore, hehe
671 2012-07-23 21:16:47 <jgarzik> not enough activity to trigger my per-message periodic maintenance code
672 2012-07-23 21:17:49 <galambo_> oh, i remember the problem i was worrying about. doesn't the aux chain bitcoind client require an implementation of getauxblock? or is that not important since all the big iron will be using a merged mining proxy.
673 2012-07-23 21:17:59 <luke-jr> gmaxwell: but do they make configure scripts?
674 2012-07-23 21:18:39 <luke-jr> galambo_: no, it requires coinbaser - or you can use Eloipool instead of bitcoind&
675 2012-07-23 21:19:29 <doublec> galambo_: there are patches around to add support to bitcoind
676 2012-07-23 21:20:11 <luke-jr> doublec: I stopped rebasing it a while back
677 2012-07-23 21:21:08 <wizkid057> well anyway, i just figured bitcoin is certainly popular enough to warrant a configure script :P
678 2012-07-23 21:22:53 <Joric> MMavipc, ie. k = EC_KEY_new_by_curve_name(..); i2d_ECPrivateKey(key, <279/238-byte DER/ASN.1 shit>, len); bn = EC_KEY_get0_private_key(k); BN_bn2bin(bn, buf); return buf
679 2012-07-23 21:24:08 <Joric> MMavipc, got it?
680 2012-07-23 21:25:02 <MMavipc> yeah
681 2012-07-23 21:29:40 <Joric> MMavipc, sorry, second function starts from d2i "DER to ..."
682 2012-07-23 21:29:49 <MMavipc> ah, ok
683 2012-07-23 21:29:58 <MMavipc> was about to say... haha
684 2012-07-23 21:33:10 <Joric> it's all for unencrypted keys, encrypted keys are not DER-encoded, they're just crypted 32-byte secret
685 2012-07-23 21:36:46 <MMavipc> EC_KEY_get0_private_key(k) is giving me a null pointer
686 2012-07-23 21:41:15 <t7> whats the best way to access a wallet from multiple computers?
687 2012-07-23 21:41:25 <t7> or is that just really bad practise
688 2012-07-23 21:42:48 <MMavipc> t7: that's more of a #bitcoin question
689 2012-07-23 21:44:01 <Joric> MMavipc, this shit works here http://pastebin.com/fvALeBRz
690 2012-07-23 21:53:07 <MMavipc> nothing is working, I'm still just getting a null pointer. Weird thing is I double chcecked the size and it's 282, not 283. 3 bytes off of 279
691 2012-07-23 21:56:00 <lianj> MMavipc: Joric paste works?
692 2012-07-23 21:56:05 <lianj> *but
693 2012-07-23 21:57:27 <Joric> it should be 214 bytes
694 2012-07-23 21:57:28 <luke-jr> Anyone else want to seed http://luke.dashjr.org/programs/bitcoin/files/blk0001/blk0001.torrent ?
695 2012-07-23 21:57:58 <lianj> Joric: btw, http://pastebin.com/JjqPgwag works too
696 2012-07-23 21:58:01 <Joric> 279 bytes for uncompressed keys, 214 bytes for compressed keys
697 2012-07-23 21:58:50 <MMavipc> Then what are these 282 bytes?
698 2012-07-23 21:59:57 <lianj> 3 bytes too much?
699 2012-07-23 22:00:29 <jgarzik> luke-jr: sure, if I can grab the file quickly
700 2012-07-23 22:00:32 <MMavipc> I tried skipping past them, no dice
701 2012-07-23 22:00:35 <luke-jr> jgarzik: it's 2 GB :P
702 2012-07-23 22:00:46 <luke-jr> jgarzik: you can create most of it easily though
703 2012-07-23 22:01:04 <luke-jr> jgarzik: run a complete node disconnected, then run a second new node that downloads from the first
704 2012-07-23 22:01:09 <lianj> MMavipc: show them :P
705 2012-07-23 22:01:33 <luke-jr> the second node will create the blk0001.dat file, so long as the first remains offline
706 2012-07-23 22:02:12 <luke-jr> the rest is 64 MB
707 2012-07-23 22:02:39 <Joric> MMavipc, try keys from http://brainwallet.org
708 2012-07-23 22:04:26 <MMavipc> http://filesmelt.com/dl/wallet.txt first you have the public address(confirmed correct) then a space, then the raw data for the private key
709 2012-07-23 22:05:54 <yellowhat> luke-jr to seed i would need the exact copy of your blk0001.dat right?
710 2012-07-23 22:06:05 <luke-jr> yellowhat: or create it the way I just described, yes
711 2012-07-23 22:06:13 <Joric> private key there starts from 30 81 offset 0x52
712 2012-07-23 22:07:09 <Joric> oh sorry maybe not ) just search for 0x30
713 2012-07-23 22:08:18 <lianj> yes, the first 3 bytes are too much
714 2012-07-23 22:08:29 <jgarzik> crazy
715 2012-07-23 22:08:49 <jgarzik> sendfrom causes 100% CPU usage, and takes about 60 seconds to complete
716 2012-07-23 22:09:12 <jgarzik> just finished a perf run to see what's going on
717 2012-07-23 22:10:10 <MMavipc> YAY IT'S NOT GIVING ME A NULL POINTER FOR PRIVATE KEY ANYMORE I AM VERY EXCITED
718 2012-07-23 22:10:33 <galambo_> i know the feeling
719 2012-07-23 22:10:37 <t7> calm down dear
720 2012-07-23 22:10:46 <lianj> ^^
721 2012-07-23 22:11:18 <lianj> "ce087c18860dc975550bc31922cc35a99e6c99af1b91b926f4fa313a7291b99" => "1Kkv94t2DLbSkY9Zrm7mjJqyfEsQn5QjuF"
722 2012-07-23 22:12:15 <Joric> nope
723 2012-07-23 22:12:37 <MMavipc> wrong private key
724 2012-07-23 22:12:38 <MMavipc> damnit
725 2012-07-23 22:12:43 <Joric> it's either 1GsvbeweFGvA7h3M82V3fw4osze6Rc2SMq or 1Bh3mfJtJdkCkRDtzeynJ3A1W1fxfgSbnH
726 2012-07-23 22:12:45 <phantomcircuit> luke-jr, first tracker is bad i think
727 2012-07-23 22:12:52 <luke-jr> phantomcircuit: all 4 are bad I think :/
728 2012-07-23 22:13:02 <MMavipc> public key is supposed to be 1HcQEr4H9yovXZQK5BUCr6azw1kdyj2cf9
729 2012-07-23 22:13:08 <luke-jr> know any decent ones? -.-
730 2012-07-23 22:13:17 <phantomcircuit> openbittorrent should just work iirc
731 2012-07-23 22:13:17 <t7> MMavipc: whats your private key?
732 2012-07-23 22:13:31 <MMavipc> t7: that's what we're trying to find out
733 2012-07-23 22:13:53 <MMavipc> t7: http://filesmelt.com/dl/wallet.txt public key, space, private key raw data
734 2012-07-23 22:14:28 <luke-jr> phantomcircuit: apparently not
735 2012-07-23 22:15:46 <lianj> Joric: why is the privkey i posted wrong?
736 2012-07-23 22:16:24 <MMavipc> the pubkey of the privkey you posted is 19CWRy916Qzd1vKVmWHgEV6r4y8jEZQexb
737 2012-07-23 22:16:36 <jgarzik> luke-jr: bleh
738 2012-07-23 22:16:38 <MMavipc> but we already know the pubkey is supposed to be 1h....
739 2012-07-23 22:16:42 <MMavipc> *1H....
740 2012-07-23 22:16:45 <jgarzik> luke-jr: if I could copy your file, I could seed it
741 2012-07-23 22:16:54 <jgarzik> luke-jr: otherwise the world will be slow-boating it until you seed it
742 2012-07-23 22:17:02 <luke-jr> jgarzik: you can get it from me via the torrent :P
743 2012-07-23 22:17:31 <jgarzik> luke-jr: that is what I mean by slow boat
744 2012-07-23 22:17:33 <Joric> MMavipc, it's ce087c18860dc975550bc31922cc35a99e6c99af1b91b926f4fa313ac7291b99 and address is 1HcQEr4H9yovXZQK5BUCr6azw1kdyj2cf9
745 2012-07-23 22:17:36 <phantomcircuit> luke-jr, seems like one of them is now working
746 2012-07-23 22:17:49 <phantomcircuit> lol but none of the peers have any of the data
747 2012-07-23 22:17:52 <luke-jr> jgarzik: I don't know any other way to avoid that, than making it yourself :/
748 2012-07-23 22:17:58 <MMavipc> ah, so it was correct
749 2012-07-23 22:18:08 <luke-jr> phantomcircuit: the first two are intermittant for me
750 2012-07-23 22:18:17 <MMavipc> http://gobittest.appspot.com/Address has a faulty address calculator
751 2012-07-23 22:18:20 <phantomcircuit> i think this is working off of dht alone
752 2012-07-23 22:19:05 <phantomcircuit> luke-jr, what's the seed peer
753 2012-07-23 22:19:16 <Joric> MMavipc, nice address harvester!
754 2012-07-23 22:19:20 <luke-jr> phantomcircuit: me?
755 2012-07-23 22:19:34 <luke-jr> 2001:470:5:265:222:4dff:fe50:4c49
756 2012-07-23 22:19:59 <jgarzik> sigh
757 2012-07-23 22:20:09 <phantomcircuit> luke-jr, lol i think i know what's wrong :)
758 2012-07-23 22:20:10 <luke-jr> I still see zero peers
759 2012-07-23 22:20:16 <jgarzik> yeah really
760 2012-07-23 22:20:18 <phantomcircuit> none of the other peers are ipv6