1 2013-11-13 00:12:54 <TD> devrandom: is there a known issue with coinbase failing to detect transactions?
2 2013-11-13 00:14:50 <Jason> TD: O.O
3 2013-11-13 00:15:00 <TD> never mind. it's just slow for some reason
4 2013-11-13 00:15:23 <Jason> ah
5 2013-11-13 00:15:32 <Jason> TD: i was like, crap, not going to use coinbase
6 2013-11-13 00:15:33 <Jason> lol
7 2013-11-13 00:15:52 <TD> it gave me a progress bar that had to reach full before it'd detect the tx had been sent
8 2013-11-13 00:15:58 <TD> i was expecting it to notice right away
9 2013-11-13 00:19:39 <Jason> ah
10 2013-11-13 00:19:45 <Jason> lol
11 2013-11-13 00:19:45 <Jason> was worried
12 2013-11-13 00:45:24 <devrandom> TD: I don't know much about coinbase
13 2013-11-13 00:46:06 <devrandom> TD: which version of protoc should I compile with?
14 2013-11-13 00:46:14 <TD> 2.5.0
15 2013-11-13 00:46:44 <TD> ACTION -> bed
16 2013-11-13 00:47:21 <devrandom> OK
17 2013-11-13 00:47:23 <devrandom> good night
18 2013-11-13 00:47:26 <devrandom> thank you
19 2013-11-13 01:03:30 <gcX46> can someone please point out why this block is rejected with error: "block height mismatch in coinbase" ? It's height is 128
20 2013-11-13 01:03:33 <gcX46> 020000007c996def2e01000fd163a77775d3bc8f6b87cd54e3fa8827ecbaf3d7000000001d335648349c5a5204d8feae4aa8f19a8a880086c3aee844983ae41734b23de711c98252ffff001d06d7292d0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff15018068656c6c6f20776f726c640000000108000000ffffffff0100f2052a010000001976a914a255e72e084c3423bc52bcce5d8219626ca57c6688ac00000000
21 2013-11-13 01:08:21 <dexX7> bitcoin in ProcessMessages() << what's that?
22 2013-11-13 01:08:21 <dexX7> EXCEPTION: St9bad_alloc
23 2013-11-13 01:08:21 <dexX7> std::bad_alloc
24 2013-11-13 01:29:45 <HaltingState> gmaxwell, I want help "an example break also of the EC with constants chosen by NSA, are in plain view for the public to find. An elegant mathematical object in which XOR commutes with EC has already been dissected at great length," I know he is talking about Dual_EC_DRBG in first sentence; but what is he refering to in second sentence
25 2013-11-13 01:30:01 <HaltingState> he is suggesting that there is possible break in EC
26 2013-11-13 01:30:36 <HaltingState> sipa, do you know?
27 2013-11-13 02:20:17 <imton> ;test
28 2013-11-13 02:28:09 <groglogic> gcX46: the problem is the 8
29 2013-11-13 02:29:52 <gcX46> groglogic: can you be more specific
30 2013-11-13 04:49:42 <dooglus_> my bitcoind hasn't seen the last 14 blocks. it's still online, seeing transactions, etc. what could be wrong?
31 2013-11-13 04:50:11 <dooglus_> the affected bitcoind's debug.log has this as the most recent block: SetBestChain: new best=00000000000000037b71bfe23a48c7b4181511c459ff1b4b5569cd4c17c064cd height=269329 log2_work=73.822942 tx=26948290 date=2013-11-13 03:03:06 progress=0.999998
32 2013-11-13 04:50:14 <gmaxwell> dooglus_: loon in the logs.
33 2013-11-13 04:50:23 <dooglus_> loo?
34 2013-11-13 04:50:33 <gmaxwell> look, but I was a little slow.
35 2013-11-13 04:50:44 <dooglus_> whereas another bitcoind shows SetBestChain: new best=00000000000000057ed3f29b8d6ada349c813059df6e306069ccf3530a057063 height=269344 log2_work=73.825781 tx=26952230 date=2013-11-13 04:47:11 progress=0.999998
36 2013-11-13 04:51:05 <gmaxwell> How many connections (getinfo) ? anything that looks atypical in the log after the last SetBestChain?
37 2013-11-13 04:51:24 <dooglus_> "connections" : 8,
38 2013-11-13 04:51:46 <gmaxwell> grep -i invalid ~/.bitcoin/debug.log
39 2013-11-13 04:53:09 <dooglus_> nothing very interesting afdter the last block. I'll check for 'invalid
40 2013-11-13 04:53:32 <dooglus_> "grep -i invalid ~/.bitcoin/debug.log" finds nothing
41 2013-11-13 04:53:48 <warren> sipa: to answer your earlier question, no, it is not visible in getinfo
42 2013-11-13 04:53:52 <dooglus_> shall I restart bitcoind? or is there anything else you want me to try?
43 2013-11-13 04:53:53 <gmaxwell> getpeerinfo might be somewhat informative.
44 2013-11-13 04:54:03 <gmaxwell> dooglus_: I assume no errors in the getinfo output?
45 2013-11-13 04:54:12 <dooglus_> it lists 8 peers
46 2013-11-13 04:54:19 <gmaxwell> dooglus_: save your getpeerinfo in a file.
47 2013-11-13 04:54:37 <gmaxwell> dooglus_: are the bytesrecv going up for your peers?
48 2013-11-13 04:54:42 <dooglus_> { "version" : 80400, "protocolversion" : 70001, "walletversion" : 60000, "balance" : 484.27121119, "blocks" : 269329, "timeoffset" : -1, "connections" : 8, "proxy" : "", "difficulty" : 510929738.01615179, "testnet" : false, "keypoololdest" : 1383752243, "keypoolsize" : 5001, "paytxfee" : 0.00010000, "errors" : "" }
49 2013-11-13 04:55:33 <gmaxwell> in any case, shut down, copy off your debug.log, go ahead and restart.
50 2013-11-13 04:55:33 <kjj> watch -d "bitcoind getpeerinfo | grep last"
51 2013-11-13 04:56:07 <Apocalyptic> version : 80400, you might want to upgrade that
52 2013-11-13 04:56:10 <gmaxwell> kjj: nice
53 2013-11-13 04:56:25 <gmaxwell> Apocalyptic: indeed, though we didn't fix anything in 805 that should have an impact here.
54 2013-11-13 04:56:27 <dooglus_> only one of the 8 peers seems to have an increasing bytesrecv value
55 2013-11-13 04:56:35 <kjj> I really wish there was a single letter mode for --differences=cumulative
56 2013-11-13 04:58:14 <kjj> RPC commands for peer management would be super handy
57 2013-11-13 04:59:05 <Apocalyptic> gmaxwell, wasn't there some DOS fix that would explain why dooglus_ doesn't have the main chain ?
58 2013-11-13 05:01:31 <MC1984> dooglus_ take those coins offline.....
59 2013-11-13 05:01:45 <dooglus_> I restarted, and now getblockcount shows a higher number each time
60 2013-11-13 05:02:10 <kjj> you had accumulated some lame nodes
61 2013-11-13 05:02:53 <dooglus_> getblockhash 269345 now shows the same on both my nodes
62 2013-11-13 05:03:07 <dooglus_> hmm
63 2013-11-13 05:03:07 <gmaxwell> Apocalyptic: no.
64 2013-11-13 05:04:20 <kjj> blocking the known bogus nodes in my firewall was the best thing I ever did in bitcoin
65 2013-11-13 05:04:48 <gmaxwell> dooglus_: anything interesting about the IPs of your prior peers? they weren't all on one subnet or something were they?
66 2013-11-13 05:05:16 <warren> bitcoind would connect to alll the same subnet?
67 2013-11-13 05:05:19 <Diablo-D3> https://bitcointalk.org/index.php?topic=130117.msg3551633#msg3551633
68 2013-11-13 05:05:23 <Diablo-D3> er wrong channel
69 2013-11-13 05:06:10 <kjj> warren: over time, a normal node will exchange the 8 outgoing connections for 8 incoming
70 2013-11-13 05:06:59 <gmaxwell> kjj: huh. No way.
71 2013-11-13 05:07:03 <kjj> 176.9.144.41, 5.9.0.0/16, 144.76.0.0/16, 46.4.64.21, 88.198.41.74, 91.121.58.230, 199.193.117.231, 178.33.43.149, 129.132.230.73
72 2013-11-13 05:07:20 <gmaxwell> kjj: it should attempt to maintain 8 outgoing regardless of whats up with incoming.
73 2013-11-13 05:08:09 <kjj> gmaxwell: recent change? my long-running node doesn't try to make new outgoing connections while it has enough total connections
74 2013-11-13 05:09:12 <gmaxwell> kjj: if its doing that its a security relevant bug and we sould fix it. (still not applicable to dooglus though, as he had only 8)
75 2013-11-13 05:09:56 <gmaxwell> else if (nInbound >= nMaxConnections - MAX_OUTBOUND_CONNECTIONS)
76 2013-11-13 05:10:00 <gmaxwell> closesocket(hSocket);
77 2013-11-13 05:11:54 <kjj> hmm. I'll check to see if I did anything to my node that would have changed that
78 2013-11-13 05:16:04 <gmaxwell> kjj: in any case, I'm not saying there is couldn't be a bug... the number of outbounds is now mediated by a semaphore that could be leaking or something.
79 2013-11-13 05:16:24 <gmaxwell> But if you have some evidence of it, I'd urgently like to know, since it would be a serious issue if true.
80 2013-11-13 05:17:12 <gmaxwell> I just checked all of mine and I have 8.
81 2013-11-13 05:17:51 <kjj> heh. the node I'm thinking of is running a hacked up version of 0.7
82 2013-11-13 05:18:20 <kjj> when I replace that server, I'll run the current version and set up a script to log peer data
83 2013-11-13 05:19:07 <dooglus_> gmaxwell; you tell me: "132.65.240.100:8333", "139.19.158.227: "130.216.1.23: "128.252.19.19:8333", "88.255.99.250:8333", "188.1.240.186:8333", "88.183.89.76:8333", "114.46.109.111:8333"
84 2013-11-13 05:19:36 <Apocalyptic> that doesn't seem like a single subnet to me
85 2013-11-13 05:20:15 <dooglus_> I tool a copy of debug.log before restarting if you want to know anything more from it
86 2013-11-13 05:20:21 <dooglus_> took*
87 2013-11-13 05:20:59 <gmaxwell> kjj: ah, well 8 out always is not a new feature, but perhaps a local change of yours might have caused it.
88 2013-11-13 05:21:36 <kjj> gmaxwell: I wouldn't be surprised by that at all. I had to hack things up a bit to make sure that a node that restarts frequently always gets reconnected
89 2013-11-13 05:21:42 <dooglus_> I'm running a binary I downloaded from sourceforge. it worked for weeks if not months without issue, without restarting
90 2013-11-13 05:22:40 <gmaxwell> dooglus_: I was commenting on something unrelated kjj saw.
91 2013-11-13 05:22:49 <dooglus_> ok
92 2013-11-13 05:23:29 <dooglus_> so do you have any explanation of how my node was 14 blocks behind the rest of the network?
93 2013-11-13 05:24:00 <gmaxwell> dooglus_: if you want to you can email me that debug.log (it'll have your txids and IP in it, infor about some of your rpc calls but no key material, shouldn't have anything else private) I can flip through it and look for anything suspect, otherwise I don't have anything to suggest at the moment.
94 2013-11-13 05:24:15 <gmaxwell> dooglus_: it sounded like from your watch data that its connections to other nodes were stuck.
95 2013-11-13 05:24:39 <gmaxwell> the network is pretty active so you should have basically seen bytes recieved going up constantly.
96 2013-11-13 05:25:02 <kjj> grep -i reorg debug.log
97 2013-11-13 05:25:35 <kjj> (do on the saved copy, not the current one)
98 2013-11-13 05:25:37 <gmaxwell> dooglus_: can you grep the log for 0000000000000008090ce90151bc ? thats the block after the last one you accepted.
99 2013-11-13 05:26:48 <kjj> gmaxwell: is there a timeout for connections that don't produce traffic?
100 2013-11-13 05:26:54 <dooglus_> no match
101 2013-11-13 05:27:09 <dooglus_> though the new debug.log has "received block 0000000000000008090ce90151bcf3ff4b24f3a240e89981985581ce3463bdba"
102 2013-11-13 05:28:03 <kjj> see, a remote inspection tool would be super handy right now. hit each of your former peers, ask them if they have that block
103 2013-11-13 05:28:18 <dooglus_> kjj> grep -i reorg debug.log : 56 lines match
104 2013-11-13 05:29:22 <gmaxwell> kjj: there is, but its pretty long.
105 2013-11-13 05:29:54 <dooglus_> kjj: http://just-dice.com/reorg.txt
106 2013-11-13 05:30:01 <gmaxwell> (90 minutes)
107 2013-11-13 05:30:56 <kjj> ugh. timestamps man, timestamps!
108 2013-11-13 05:31:05 <gmaxwell> the last connect is at 269203
109 2013-11-13 05:31:09 <gmaxwell> so not interesting.
110 2013-11-13 05:31:57 <kjj> your node was not stuck in a reorg loop. really looks like you just had 8 lame peers (which is a mystery itself)
111 2013-11-13 05:33:09 <dooglus_> the old debug.log was 334586065 bytes long. I expect that represents a long run
112 2013-11-13 05:34:31 <kjj> interesting that all 4 of the reorgs in my current logs are also in yours
113 2013-11-13 05:35:29 <dooglus_> reload that URL - it includes line numbers now
114 2013-11-13 05:35:41 <dooglus_> they are fairly spread out
115 2013-11-13 05:36:19 <gmaxwell> kjj: well, or a local network event goofed up the 8 tcp connections at once.. but I don't know they they didn't get inactivity kicked.
116 2013-11-13 05:36:49 <dooglus_> one of the 8 was still sending bytes
117 2013-11-13 05:37:43 <kjj> I see just over 90 minutes difference in my timestamps between the last block his stuck node saw vs. the block current when he restarted it
118 2013-11-13 05:37:58 <dooglus_> as in one of the 8 shown by getpeerinfo had a 'bytesrecv' value that was higher each time I looked
119 2013-11-13 05:38:48 <kjj> gah. I need to stop hanging out in this channel. my todo list is already beyond my possible lifetime
120 2013-11-13 05:39:16 <dooglus_> while 'stuck', debug.log was still updating with lines line:
121 2013-11-13 05:39:17 <dooglus_> CTxMemPool::accept() : accepted 3f25cb7111664320893daae985d76471e8d82d0501d8e8e7a5cd0fe2bd24601c (poolsz 812)
122 2013-11-13 05:39:22 <dooglus_> and Added 1 addresses from 128.252.19.19: 1880 tried, 14879 new
123 2013-11-13 05:39:51 <kjj> hmm.
124 2013-11-13 05:40:28 <dooglus_> I have a large keypool if that matters: "ThreadRPCServer method=getaccountaddress\nkeypool added key 35127, size=5001"
125 2013-11-13 05:43:06 <gmaxwell> dooglus_: nah, shouldn't matter. Thats not that large.
126 2013-11-13 05:46:24 <kjj> a=`wc -l debug.log | cut -d ' ' -f 1`; b=`grep -n 37b71 -m 1 debug.log | cut -d ':' -f 1` ; c=`echo "$a-$b" | bc` ; tail debug.log -n $c | grep "addresses from"
127 2013-11-13 05:46:36 <kjj> replace debug.log with the proper filename in all 3 places
128 2013-11-13 05:47:28 <kjj> that will fetch all of the "Added x addresses from Y" lines after the last block, which may give some idea of traffic from other peers
129 2013-11-13 05:48:27 <kjj> if you only see 128.252.19.19, that supports Greg's theory of the local network hiccup
130 2013-11-13 05:48:42 <dooglus_> kjj: thousands of lines of output
131 2013-11-13 05:48:57 <dooglus_> 67338 lines
132 2013-11-13 05:49:03 <dooglus_> 46227 lines*
133 2013-11-13 05:49:15 <kjj> redo the command, but add " | grep -v 128.252.19.19" on the end
134 2013-11-13 05:50:00 <dooglus_> still too much output
135 2013-11-13 05:50:22 <kjj> ok, so either my script is buggy, or you were getting non-block messages from at least one other node
136 2013-11-13 05:51:21 <dooglus_> is the "grep -n 37b71" meant to match "106381:CTxMemPool::accept() : accepted 37b7111ccaaaac13e78199df7f44839ba0945768cd049d3b5725906bb0616ab8 (poolsz 1334)"?
137 2013-11-13 05:51:36 <kjj> oh, shit. no
138 2013-11-13 05:51:55 <kjj> try tacking on another digit or two. 37b71bfe
139 2013-11-13 05:52:22 <ryan-c> What would be the best way to generate a BIP0032 address where I want a 256 bit child number? m/29bit value/.../29bit value/24bit value maybe?
140 2013-11-13 05:52:41 <dooglus_> so now it gives 318 lines without the grep -v, and 292 with it
141 2013-11-13 05:53:42 <kjj> add: | cut -d ' ' -f 7 | uniq
142 2013-11-13 05:54:37 <kjj> shit, should be 5 in there instead of 7.
143 2013-11-13 05:54:54 <kjj> and turn timestamps on. :)
144 2013-11-13 05:55:02 <dooglus_> now it says jusy "tried,"
145 2013-11-13 05:55:10 <ryan-c> I want to generate BIP0032 addresses that are derived in part from the sha256 of some data.
146 2013-11-13 05:55:23 <arioBarzan> Why there is no traces of bitcoin binaries earlier than version bitcoin-0.3.24 on sourcefourge obsolete collection of old binaries?
147 2013-11-13 05:55:29 <dooglus_> timestamps should be on by default?
148 2013-11-13 05:55:56 <arioBarzan> http://sourceforge.net/projects/bitcoin/files/Obsolete/
149 2013-11-13 05:56:03 <kjj> arioBarzan: I don't think there was a proper build system before then.
150 2013-11-13 05:56:13 <kjj> I'm not sure about that though, it was before my time
151 2013-11-13 05:56:16 <dooglus_> kjj: are you sure you want the 7th field?
152 2013-11-13 05:56:34 <kjj> dooglus_: should be 5th field if you don't have timestamps on
153 2013-11-13 05:56:37 <dooglus_> lines are like: Added 1 addresses from 139.19.158.227: 1879 tried, 14883 new
154 2013-11-13 05:56:38 <gmaxwell> dooglus_: they're useful for troubleshooting but they create an incentive to go hoovering up logs to trace transactions.
155 2013-11-13 05:57:18 <dooglus_> do you prefer sort -u to uniq?
156 2013-11-13 05:57:36 <dooglus_> otherwise I see stuff like: 114.46.109.111: 88.255.99.250: 114.46.109.111:
157 2013-11-13 05:57:42 <kjj> yeah, that would probably be better
158 2013-11-13 05:58:08 <dooglus_> ok, now I see: 114.46.109.111: 130.216.1.23: 132.65.240.100: 139.19.158.227: 173.52.85.34: 188.1.240.186: 88.183.89.76: 88.255.99.250:
159 2013-11-13 05:58:20 <dooglus_> (on 8 lines)
160 2013-11-13 05:58:27 <kjj> ok, so your box was catching messages from all 8 peers
161 2013-11-13 05:59:02 <kjj> to solve this mystery, someone needs to write a tool that connects to those peers and asks them for their inventory
162 2013-11-13 05:59:25 <gmaxwell> kjj: no need to write anything...
163 2013-11-13 05:59:36 <gmaxwell> you can easily see their starting height.
164 2013-11-13 05:59:43 <gmaxwell> if you just addnode one of them.
165 2013-11-13 06:00:05 <kjj> in that case, someone needs to write a addnode RPC call...
166 2013-11-13 06:00:32 <ryan-c> ACTION wonders if he should just add the keys together rather than try to hack bip0032 into doing what he wants
167 2013-11-13 06:00:37 <gmaxwell> kjj: you mean bluematt a year ago?
168 2013-11-13 06:00:54 <gmaxwell> kjj: someone needs to give you software newer that last century. :P
169 2013-11-13 06:00:59 <kjj> ryan-c: what are you trying to do?
170 2013-11-13 06:02:15 <kjj> gmaxwell: the box I do my work on has a hard enough time compiling 0.7.x. 0.8 damn near killed it.
171 2013-11-13 06:02:16 <ryan-c> I want to publish an address or bip0032 public key and combine it with the output of a hash algorithm to get a new address
172 2013-11-13 06:03:11 <kjj> ryan-c: and what are you trying to accomplish with that?
173 2013-11-13 06:04:36 <kjj> gmaxwell: actually, I had to do a panic upgrade of the RAM in that box to a full gig because of a previous change, I think 0.6->0.7
174 2013-11-13 06:04:50 <ryan-c> generate addresses deterministically based on arbitrary data that can be proved to be receivable by the holder of some root key
175 2013-11-13 06:05:08 <gmaxwell> kjj: there are memory leaks before 0.8.3 that are not friendly.. lastest code should use a lot less memory at runtime.
176 2013-11-13 06:05:18 <kjj> not runtime, compiling
177 2013-11-13 06:05:31 <gmaxwell> kjj: yea, I did qualify for that reason. :)
178 2013-11-13 06:05:53 <ryan-c> ACTION is not doing a good job coming up with a brief explanation
179 2013-11-13 06:06:37 <gmaxwell> ryan-c: have you also invented pay to contract?
180 2013-11-13 06:06:43 <kjj> root@inana:/opt# cat /proc/cpuinfo
181 2013-11-13 06:06:44 <kjj> bogomips : 3031.04
182 2013-11-13 06:06:44 <kjj> cpu MHz : 1533.026
183 2013-11-13 06:06:44 <kjj> model name : AMD Athlon(tm) XP 1800+
184 2013-11-13 06:07:11 <ryan-c> gmaxwell: Maybe? Let me read your bitcoin talk thread.
185 2013-11-13 06:07:51 <gmaxwell> ryan-c: well I'm not the originator of pay to contract... there are a number of threads and a paper on the idea.
186 2013-11-13 06:08:29 <ryan-c> gmaxwell: Yeah, pay-to-contract describes what I want to do.
187 2013-11-13 06:08:40 <ryan-c> mostly
188 2013-11-13 06:09:45 <ryan-c> gmaxwell: So, compute H(contract) and add to the master key's public point, then?
189 2013-11-13 06:09:51 <gmaxwell> okay, well I think you should just be taking in a pubkey and a hash... and the pubkey could possibly but necessarily come from bip32.
190 2013-11-13 06:09:53 <dooglus_> I'm having no luck with 'addnode'. I have 8 connections before and after 'addnode add' or 'addnode remove'
191 2013-11-13 06:11:07 <ryan-c> Alright. I'm pretty familiar with combining keys via addition like that, and that was my initial thought, but I was wondering if there was some reasonable way to use bip32.
192 2013-11-13 06:20:30 <ryan-c> gmaxwell: Thanks for providing search terms.
193 2013-11-13 06:37:14 <tort> anyone know of any guides on BTC and ruby that are worth reading?
194 2013-11-13 06:37:35 <tort> I'm trying to learn about the protocol and how BTC works
195 2013-11-13 06:44:42 <Luke-Jr> tort: you might talk to lianj, he's into ruby..
196 2013-11-13 08:26:01 <swulf--> hmm
197 2013-11-13 08:53:35 <sipa> warren: in nowallet mode, there is no balance, keypoolsize, walletversion, ...
198 2013-11-13 08:57:58 <warren> sipa: ok sure. I just think the previous PR had a multiple people who wanted s/.../!/ and keeping any message there would be more informative than not. The absence of things is harder to see in general.
199 2013-11-13 09:02:17 <sipa> warren: ok then write a patch
200 2013-11-13 09:03:24 <warren> sipa: I did, and it turned out he already repushed it with it.
201 2013-11-13 09:51:00 <graingert> hai
202 2013-11-13 09:51:02 <TD> good morning
203 2013-11-13 09:54:14 <sipa> ohai
204 2013-11-13 09:54:28 <graingert> hmm, I've been mentioned according to my client
205 2013-11-13 09:54:31 <graingert> but I can't find it
206 2013-11-13 09:54:36 <graingert> and grepping my logs fails
207 2013-11-13 09:55:39 <graingert> ah BlueMatt
208 2013-11-13 09:55:41 <Luke-Jr> [Tuesday, November 12, 2013] [6:10:13 PM] <michagogo|cloud> BlueMatt: Are you the only one with access to the ppa?
209 2013-11-13 09:55:42 <Luke-Jr> [Tuesday, November 12, 2013] [6:10:52 PM] <BlueMatt> Im the only one who touches it, but graingert has access as well
210 2013-11-13 09:55:44 <graingert> I was grepping the wrong logs
211 2013-11-13 09:56:17 <Luke-Jr> XD
212 2013-11-13 10:08:22 <cityding0> Hi, for a block's hash - is that just a massive hexadecimal number?
213 2013-11-13 10:08:39 <cityding0> so is it run through sha-256 then just converted to hex? to be less than the target
214 2013-11-13 10:08:47 <Luke-Jr> not really, but in some cases Bitcoin treats it as one
215 2013-11-13 10:08:54 <Luke-Jr> interpreted very weirdly
216 2013-11-13 10:09:35 <cityding0> what would you call it then? im trying to explain to someone the proof of work and how it has to be lower than the target
217 2013-11-13 10:09:42 <cityding0> and the wiki is a bit vague of how it gets turned to a number :(
218 2013-11-13 10:09:48 <Luke-Jr> that's the case where Bitcoin treats it as one
219 2013-11-13 10:09:59 <cityding0> ahh
220 2013-11-13 10:09:59 <Luke-Jr> err, you really don't want to try to explain that
221 2013-11-13 10:10:05 <Luke-Jr> it's insane
222 2013-11-13 10:10:26 <Luke-Jr> as in, mixed-endian
223 2013-11-13 10:10:44 <cityding0> lol
224 2013-11-13 10:10:47 <cityding0> why is it mixed?
225 2013-11-13 10:15:49 <berndj> i'm trying to parse https://en.bitcoin.it/wiki/URI_Scheme#Transfer_amount.2Fsize and the amount=x40 example seems to contradict the implied X4 for hex amounts. which is it?
226 2013-11-13 10:34:28 <Luke-Jr> cityding0: because Satoshi wasn't very bright <.<
227 2013-11-13 10:35:39 <Luke-Jr> berndj: contradicts how? seems consistent to me
228 2013-11-13 10:37:55 <cityding0> lol
229 2013-11-13 10:40:15 <sipa> why does the wiki even mention that encoding? bip20 has been replaced
230 2013-11-13 10:41:01 <Luke-Jr> sipa: the page does mention BIP 21 at the top already; I presume he wants better compatibility
231 2013-11-13 10:41:17 <Luke-Jr> in any case, I'm curious what the apparent contradiction is, as it seems consistent to me
232 2013-11-13 10:41:52 <sipa> right, i completely missed that first line - think others would too :)
233 2013-11-13 10:42:02 <sipa> the consistency issue is of course separate
234 2013-11-13 10:57:52 <berndj> Luke-Jr, if X4 is the default, then isn't x1 = x1X4 = 65536 satoshi, and not 2^32 satoshi?
235 2013-11-13 12:11:45 <berndj> fwiw i just didn't notice the link to BIP 21. i like that one better (i'm writing, not reading, so backward compatibility isn't my problem. not paying attention is)
236 2013-11-13 12:39:04 <kezu> in bitcoind how do i know its done downloading the blockchain?
237 2013-11-13 12:43:10 <kjj> that's tricky
238 2013-11-13 12:44:50 <kjj> some RPC commands will indicate that the download is still in progress
239 2013-11-13 12:46:55 <kjj> on my mining nodes that switch from a backup pool to a local p2pool when everything is running, I iterate the getwork command, searching for the strings "error" and "download". error means it is still starting up, download means it is downloading
240 2013-11-13 12:48:10 <kjj> but that isn't perfect. the download message goes away before it is really done.
241 2013-11-13 12:49:24 <kjj> if you really need your node to be current, you'll need to poll some outside sources and compare
242 2013-11-13 13:00:24 <kezu> does running bitcoin d generate bitcoins?
243 2013-11-13 13:01:04 <matjeh> kezu: as a quick check, i just check the date/time of the last block that it has, and see how old it is
244 2013-11-13 13:01:42 <kezu> matjeh: would that be in the blocks folder or is there a command to run?
245 2013-11-13 13:01:53 <matjeh> date --date @$(bitcoind getblock $(bitcoind getblockhash $(bitcoind getblockcount))|jq '.time')
246 2013-11-13 13:01:56 <matjeh> :p
247 2013-11-13 13:03:50 <kezu> thats to be run in terminal?
248 2013-11-13 13:05:07 <kezu> should the bitcoind getinfo command tell me something? how many blocks are there so far maybe i can compare the number
249 2013-11-13 13:08:23 <kjj> getinfo will tell you how many blocks your node has. getpeerinfo can tell you how many blocks your peers had at the moment you connected to them
250 2013-11-13 13:08:57 <jgarzik> mornin'
251 2013-11-13 13:09:57 <xeroc> matjeh: whats
252 2013-11-13 13:10:02 <xeroc> 'jq' doing?
253 2013-11-13 13:56:40 <cityding0> Are transactions represented in their HEX? or as their sha hash?
254 2013-11-13 13:56:50 <cityding0> I just realized a transaction im looking at is in hex
255 2013-11-13 13:57:01 <kjj> yes
256 2013-11-13 13:57:28 <gingpark> anyone here use minepeon on rpi , cgminer?
257 2013-11-13 13:58:58 <sipa> cityding0: txids are usually represented as hex encoded, as are transactions themself
258 2013-11-13 13:59:13 <sipa> but transactions and transaction ids are not the same...
259 2013-11-13 13:59:33 <cityding0> the transaction id is the hash of the transaction isnt it ?
260 2013-11-13 13:59:49 <sipa> yes
261 2013-11-13 13:59:55 <sipa> double sha256 hash
262 2013-11-13 14:00:36 <jgarzik> until confirmed, transactions are sometimes malleable (and change ids)
263 2013-11-13 14:01:21 <cityding0> why is that? whati nformation would change between confirmations
264 2013-11-13 14:01:25 <sipa> whether that's a different representation of the same transaction, or a different transaction with the same effect is a philophical discussion :)
265 2013-11-13 14:01:52 <sipa> i consider malleability a problem, and doing so a vulnerability
266 2013-11-13 14:02:04 <sipa> eh, an attack
267 2013-11-13 14:02:10 <kjj> the portions of the transaction that are signed are not exactly the same as the portions that are hashed to make the id
268 2013-11-13 14:02:21 <sipa> ^
269 2013-11-13 14:03:04 <kjj> so you can change some parts without breaking the signature, but once in a block, only the version that is listed in the block is "real"
270 2013-11-13 14:05:47 <cityding0> I see, so for example the input of a transaction that contains a signature (verifying that you are authorised to make the payment) - it may not be included in the hash of a transaction?
271 2013-11-13 14:07:18 <matjeh> xeroc: "bitcoind getblock" outputs in JSON format, "jq .time" parses the JSON and returns the value for the "time" key
272 2013-11-13 14:07:38 <matjeh> more robust than grep/etc
273 2013-11-13 14:10:53 <cityding0> but then... is it a vulnerability? if its the signature for the previous hash - then it cant really change anyway (although it could)
274 2013-11-13 14:11:17 <kjj> it isn't exactly like you are thinking
275 2013-11-13 14:11:38 <kjj> we are pretty sure we shouldn't allow it, but so far no one has figured out how to do an attack with it
276 2013-11-13 14:16:06 <cityding0> ok so my understanding is - you get the input and output of the transaction, concantate them together, and double sha hash them. the input includes: (previous hash, index, scriptsig) and this is repeated for each input, and then the output is (value, scriptPubKey) and this is repeated for each output
277 2013-11-13 14:16:28 <cityding0> and i assume the script itself is part of the hash (the commands op_dup etc)
278 2013-11-13 14:16:51 <cityding0> so the part that can change is the scriptSig ?
279 2013-11-13 14:17:05 <cityding0> without affecting the hash
280 2013-11-13 14:17:59 <xeroc> matjeh: thanks .. gonna try find that tool ..
281 2013-11-13 14:18:15 <kezu> is there a command to provide a btc address to bitcoind and get back its balance?
282 2013-11-13 14:18:44 <kjj> there is no balance
283 2013-11-13 14:19:32 <kezu> what is the term?
284 2013-11-13 14:20:59 <kjj> and no, there isn't anything that does that in the reference client
285 2013-11-13 14:21:23 <kjj> if you want that, you'll need to scan the chain yourself
286 2013-11-13 14:22:51 <kezu> can some one in terms explain how blockchain.info gets a wallets 'balance'?
287 2013-11-13 14:23:14 <kezu> and if i can get a wallets 'balance' running a node
288 2013-11-13 14:23:32 <kezu> in noob*^ terms
289 2013-11-13 14:27:02 <kjj> they look at every transaction in every block and add up the ones that can be redeemed by a given key and that haven't already been redeemed
290 2013-11-13 14:32:07 <arioBarzan> kezu: I use an abandoned version of bitcoind which you could find its source code at https://github.com/bitcoin/bitcoin/pull/2121 and then compile it for yourself, to add addresses as watch-only.
291 2013-11-13 14:34:16 <arioBarzan> kezu: it works for only single key addresses (not pay-to-script-hash ones like escrows and multisignature). for p2sh you could try sipa's code at https://github.com/bitcoin/bitcoin/pull/2861
292 2013-11-13 14:36:10 <kezu> arioBarzan: thanks for the pointersd im pretty new to bitcoin back end stuff so i have to read up to understand what you mean
293 2013-11-13 14:36:46 <kezu> i just need a way to read an addresses balance without relying on blockchain.info
294 2013-11-13 14:37:38 <cityding0> i imagine u would need some database to do that
295 2013-11-13 14:37:53 <cityding0> from my naive knowledge - you need to go through the blockchain and record every transaction that has happened
296 2013-11-13 14:38:09 <cityding0> and update each address accordingly
297 2013-11-13 14:38:19 <arioBarzan> kezu: you could try btclook.com
298 2013-11-13 14:38:29 <cityding0> its a massive linked-list so if you want to query it you would need to iterate over it
299 2013-11-13 14:40:41 <kezu> ok im trying not to have to rely on other services
300 2013-11-13 14:40:45 <kezu> that are centralized
301 2013-11-13 14:41:06 <arioBarzan> kezu: for e.g you could check balance from either of http://btclook.com/addr/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX https://coinbase.com/network/addresses/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX http://blockexplorer.com/address/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX http://blockchain.info/address/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX
302 2013-11-13 14:41:07 <kezu> i wonder how big of as database i would have to cook up to do this
303 2013-11-13 14:41:28 <cityding0> i dunno it depends
304 2013-11-13 14:41:38 <cityding0> i imagine - if you are only interested in a small set of addresses
305 2013-11-13 14:41:44 <cityding0> you could just iterate over it for those addresses
306 2013-11-13 14:41:49 <cityding0> not sure how long the look up would take
307 2013-11-13 14:42:07 <cityding0> i could be wrong - but thats how i imagine it works
308 2013-11-13 14:43:27 <kjj> if the key is made in the future, you can do it easily by scanning only new blocks
309 2013-11-13 14:43:59 <cityding0> yeah and that would be very quick
310 2013-11-13 14:44:08 <cityding0> cuz your not verifying them... just looking for them
311 2013-11-13 14:48:27 <arioBarzan> kezu: if you want to not rely on other services, as I said (unfortunately somewhat in complex words) you could run a modified version of bitcoin software which would the thing you are looking for.
312 2013-11-13 14:49:29 <kezu> ario i will look into your suggestion also im just trying to understand how it all works at the moment so ill know what im doing
313 2013-11-13 14:49:37 <kezu> :) i value youre suggestion
314 2013-11-13 14:49:41 <kezu> your*
315 2013-11-13 14:50:03 <kjj> offtopic: the friction preventing arbitrage is really annoying me
316 2013-11-13 14:51:47 <kezu> you mean getting into and out of ezchanges kjj?
317 2013-11-13 14:53:05 <kezu> exchanges*
318 2013-11-13 14:56:42 <kjj> yeah. it is irritating to see a $60+ dollar spread
319 2013-11-13 15:06:20 <JimJones> anyone knows if its possible to limit the bandwidth on bitcoind?
320 2013-11-13 15:07:06 <kjj> internally? no.
321 2013-11-13 15:08:39 <JimJones> kjj, what you mean internally?
322 2013-11-13 15:10:17 <kjj> I mean you can certainly use, for example, the netfilter and the linux traffic shaper to adjust things, but there is no config option for bitcoind that does it for you
323 2013-11-13 15:10:27 <sipa> use -nolisten
324 2013-11-13 15:11:08 <kjj> see extensive discussion here: https://github.com/bitcoin/bitcoin/issues/273
325 2013-11-13 15:11:47 <JimJones> thanks
326 2013-11-13 15:11:57 <kezu> how much does bitcoind use anyway?
327 2013-11-13 15:12:12 <kezu> bandwidth
328 2013-11-13 15:12:13 <kjj> it varies
329 2013-11-13 15:12:20 <kezu> s there a max?
330 2013-11-13 15:12:22 <kezu> is*
331 2013-11-13 15:12:31 <kjj> if you use -nolisten, like sipa said, it uses very little
332 2013-11-13 15:13:34 <kjj> if you are connectable, you'll occasionally send gigs out to bootstrapping new nodes
333 2013-11-13 15:13:45 <JimJones> right now im using average 900k-1.4m /s of upload
334 2013-11-13 15:13:55 <JimJones> connected to 41 peers
335 2013-11-13 15:14:12 <JimJones> yep connectable lol
336 2013-11-13 15:17:32 <cityding0> and when u have a crap connection like me
337 2013-11-13 15:17:38 <cityding0> it takes days to set up ahh
338 2013-11-13 15:17:48 <cityding0> setting up on new laptop and it is taking forever
339 2013-11-13 15:18:53 <kezu> i downloaded the bootstrap.dat torrent
340 2013-11-13 15:19:00 <kezu> sped things up
341 2013-11-13 15:19:10 <JimJones> kjj, can you tell me what -nolisten will do?
342 2013-11-13 15:20:13 <kjj> it tells your node not to accept new incoming connections
343 2013-11-13 15:20:37 <kjj> when a new node starts up, it connects out to a node that accepts connections, then it downloads the blockchain from the first one it connects to
344 2013-11-13 15:21:01 <kjj> by not accepting new connections, you avoid having to transfer gigs up to new nodes
345 2013-11-13 15:24:05 <JimJones> kk
346 2013-11-13 15:29:15 <kezu> kjj will your node still get updated?
347 2013-11-13 15:29:27 <kezu> from the network ?
348 2013-11-13 15:29:51 <kezu> is there a no listen config option?
349 2013-11-13 16:09:26 <kjj> kezu: you will still connect out to other nodes, you just won't accept incoming connections
350 2013-11-13 16:10:31 <kezu> is there a list of all config options? is there a nolisten config option?
351 2013-11-13 16:12:25 <kjj> bitcoind --help
352 2013-11-13 16:46:25 <amiller> bitcoin research workshop deadline is in 11 days http://fc14.ifca.ai/bitcoin/cfp.html
353 2013-11-13 16:46:43 <amiller> it's a workshop cohosted with Financial Cryptography, a ~15 year old academic conference
354 2013-11-13 17:09:11 <devrandom> TD: how does the bloom filter work with p2sh? does it take the script hash instead of the pubkey hash?
355 2013-11-13 17:09:39 <baconfather> can anyone answer a couple basic dev questions?
356 2013-11-13 17:10:13 <devrandom> baconfather: better to just ask ;)
357 2013-11-13 17:10:14 <TD> devrandom: the server node matches the filter against every data element in every script. so yes it matches against the script hash
358 2013-11-13 17:10:49 <devrandom> it matches every data push on stack?
359 2013-11-13 17:11:41 <devrandom> BitcoinJ doesn't do that, right? it just adds pubkey and pubkey hash?
360 2013-11-13 17:12:29 <baconfather> argh being sent out, it'll have to wait, glad i registered though :D
361 2013-11-13 17:14:25 <TD> bitcoinj wallet code does not support P2SH so yes, it adds only keys and key hashes
362 2013-11-13 17:15:48 <devrandom> OK
363 2013-11-13 17:15:50 <devrandom> will work on this today
364 2013-11-13 17:18:59 <TD> devrandom: work on what?
365 2013-11-13 17:19:24 <shamoon> static CBigNum bnProofOfWorkLimit(~uint256(0) >> 32); - is that diff of 1?
366 2013-11-13 17:23:45 <sipa> swulf--: diff 1
367 2013-11-13 17:46:42 <devrandom> TD: on refactoring as you suggested
368 2013-11-13 17:51:28 <TD> devrandom: cool
369 2013-11-13 17:53:53 <swulf--> gmaxwell: around?
370 2013-11-13 17:57:57 <shamoon> to make it WAY easier, couldn't I just do static CBigNum bnProofOfWorkLimit(~uint256(0) >> 4);
371 2013-11-13 17:57:58 <swulf--> sipa: around?
372 2013-11-13 17:58:28 <gmaxwell> swulf--: kinda.
373 2013-11-13 17:58:48 <swulf--> gmaxwell: I just pushed bip32 support into that website I showed you a few days ago. It's surely got a madly designed UI but I was able to successfully receive and spend coins using it. Perhaps you'd take a look when you find time?
374 2013-11-13 17:58:48 <swulf--> s/madly/badly
375 2013-11-13 17:59:41 <gmaxwell> URL again.
376 2013-11-13 17:59:45 <swulf--> http://ms-brainwallet.github.io/
377 2013-11-13 18:02:12 <gmaxwell> swulf--: why not make your package just a comma seperated copy of the extended pubkeys instead of hex?
378 2013-11-13 18:02:12 <swulf--> Could do that
379 2013-11-13 18:02:12 <swulf--> hmm
380 2013-11-13 18:02:17 <swulf--> I wanted the package to look significantly different than the keys
381 2013-11-13 18:02:34 <gmaxwell> swulf--: it's a little kludgy that you adjust an index, click a button, and get directed to the next page. Can you add testnet support?
382 2013-11-13 18:02:45 <swulf--> testnet is a possibility
383 2013-11-13 18:03:30 <gmaxwell> yea, it's trivial, and people really should be encouraged to test this stuff using testnet.
384 2013-11-13 18:03:30 <swulf--> Shouldn't be crazy hard, just change some version bytes here and there
385 2013-11-13 18:03:39 <swulf--> (and probably have mainnet disabled until its been tested thoroughly)
386 2013-11-13 18:05:55 <gmaxwell> It would be neat if you could give it an index range and then get out a single page with the package at the top, and then a table which has the p2sh addresses for each index.
387 2013-11-13 18:05:59 <BlueMattBot> Project Bitcoin build #455: FAILURE in 42 min: http://jenkins.bluematt.me/job/Bitcoin/455/
388 2013-11-13 18:05:59 <swulf--> cool idea
389 2013-11-13 18:06:09 <gmaxwell> swulf--: perhaps a spend page that takes the package and an address and it finds the right index and computes a spending txn.
390 2013-11-13 18:06:09 <swulf--> if the index was, say, >10000
391 2013-11-13 18:06:09 <swulf--> that would be quite computationally expensive, especially in a browser
392 2013-11-13 18:13:16 <swulf--> oh, great idea
393 2013-11-13 18:53:34 <bitnumus> hey, i've compiled and installed berkeleyDB but getting this error on compiling bitcoinsd, any ideas ? > db.h:14:20: fatal error: db_cxx.h: No such file or directory
394 2013-11-13 18:54:45 <kjj> run ldconfig
395 2013-11-13 18:55:06 <kjj> if that doesn't work, you may need to specify the path to your BDB install
396 2013-11-13 18:55:49 <bitnumus> i'll give that a whirl, takes a little while to find out if it'll work in RPI :P
397 2013-11-13 18:56:01 <bitnumus> how do i specify the path during make ?
398 2013-11-13 18:57:32 <kjj> BDB_INCLUDE_PATH=/blah/ make ...
399 2013-11-13 18:57:36 <bitnumus> ah in makefile.unix ?
400 2013-11-13 18:58:11 <bitnumus> BDB_LIB_PATH
401 2013-11-13 18:58:44 <kjj> compiling on/for the PI may be a bit strange, and I've never done it. If I say anything that disagrees with what the guides say, keep that in mind
402 2013-11-13 18:59:32 <kjj> you may need to set both BDB_INCLUDE_PATH and BDB_LIB_PATH. when the compiler can't find a .h file, it is include. when the linker can't find a .so or .a file, it is lib
403 2013-11-13 19:05:31 <bitnumus> kjj, i've only compiled BerkeleyDB.4.8
404 2013-11-13 19:05:42 <bitnumus> is BDB++ totally different?
405 2013-11-13 19:07:32 <kjj> BDB = BerkeleyDB
406 2013-11-13 19:07:48 <kjj> oh, BDB++? Never heard of it
407 2013-11-13 19:07:56 <sipa> BDB++ is the C++ wrapper around BDB
408 2013-11-13 19:08:04 <kjj> that makes sense
409 2013-11-13 19:08:04 <sipa> as bitcoin is C++, it needs that
410 2013-11-13 19:09:06 <kjj> there are extensive guides to building bitcoind on the pi. are you following one of them?
411 2013-11-13 19:09:55 <Apocalyptic> is there somewhere I can get the format specifications of the wallet.dat file ?
412 2013-11-13 19:10:18 <sipa> Apocalyptic: you mean the BDB format, or the key=value pairs we store in it?
413 2013-11-13 19:10:32 <Apocalyptic> both I guess
414 2013-11-13 19:10:44 <sipa> the first: you'll go crazy; it's impossible
415 2013-11-13 19:11:01 <sipa> the second: read walletdb.cpp
416 2013-11-13 19:11:25 <Apocalyptic> i took a look at it yeah
417 2013-11-13 19:11:30 <sipa> (even the BDB people themself cannot replicate the BDB format spec, there is a BDBjava project which uses a _different_ file format)
418 2013-11-13 19:11:47 <kjj> heh
419 2013-11-13 19:12:09 <sipa> that's because afaik BDB files are really just mmap'ed C data structures
420 2013-11-13 19:12:57 <Apocalyptic> isn't that an issue for portability ?
421 2013-11-13 19:13:21 <kjj> nah
422 2013-11-13 19:13:25 <kjj> well, maybe a little
423 2013-11-13 19:13:29 <phantomcircuit> Apocalyptic, only if you want to use bigendian machines
424 2013-11-13 19:15:16 <kjj> the world of computing seems to follow a strict "conservation of stupid" law. if you use a machine with a sane bit/byte order, something else has to be made worse to keep things balanced.
425 2013-11-13 19:16:08 <bitnumus> <kjj> there are extensive guides to building bitcoind on the pi. are you following one of them? < where?
426 2013-11-13 19:16:57 <bitnumus> i might be winning though, seems db_cxx.h was in a different DIR
427 2013-11-13 19:17:04 <bitnumus> got it linked and think its passed that point
428 2013-11-13 19:18:01 <kjj> http://lmgtfy.com/?q=bitcoin+raspberry+pi
429 2013-11-13 19:18:02 <phantomcircuit> bitnumus, what version are you trying to build?
430 2013-11-13 19:18:24 <phantomcircuit> sipa, does the last release use autotools
431 2013-11-13 19:18:58 <phantomcircuit> bitnumus, CPATH="/usr/include" make -f makefile.unix
432 2013-11-13 19:19:06 <phantomcircuit> er
433 2013-11-13 19:19:26 <phantomcircuit> replace /usr/include with the path to db_cxx.h
434 2013-11-13 19:20:32 <bitnumus> yea looks like its working
435 2013-11-13 19:20:36 <bitnumus> building 0.8.5
436 2013-11-13 19:21:00 <phantomcircuit> bitnumus, neat you'll be done in only a few 100s of minutes
437 2013-11-13 19:21:12 <bitnumus> ikr
438 2013-11-13 19:26:21 <sipa> phantomcircuit: 0.8.5 does not, only git head
439 2013-11-13 19:29:40 <shamoon> if i want to make initial mining easier, can I just change to: static CBigNum bnProofOfWorkLimit(~uint256(0) >> 4);
440 2013-11-13 19:33:35 <kjj> if you are tinkering with the difficulty for an altcoin, you should read up on the target polynomial
441 2013-11-13 19:35:30 <beethoven8201> Could a feature be added so that after syncing up with recent transactions, bitcoin-qt allows you to begin trading (electum style), but is in "insecure" mode until the whole blockchain is synced?
442 2013-11-13 19:36:01 <beethoven8201> this might encourage more people to use -qt
443 2013-11-13 19:36:47 <sipa> yes, that'd be very nice
444 2013-11-13 19:36:56 <sipa> but we're far from the point where that is possible
445 2013-11-13 19:37:03 <sipa> technically
446 2013-11-13 19:37:57 <beethoven8201> ok so I guess this is "hard"
447 2013-11-13 19:37:59 <beethoven8201> heh
448 2013-11-13 19:38:55 <MC1984> headers first moves towards that i think
449 2013-11-13 19:39:56 <sipa> indeed
450 2013-11-13 19:42:10 <beethoven8201> headers, MC1984 ?
451 2013-11-13 19:43:20 <MC1984> block headers first like an SPV client
452 2013-11-13 19:43:31 <MC1984> then fill in the chain later
453 2013-11-13 19:45:14 <beethoven8201> yeah
454 2013-11-13 19:45:25 <beethoven8201> it will need a big redesign to support starting midchain
455 2013-11-13 19:45:48 <gmaxwell> beethoven8201: no it won't.
456 2013-11-13 19:45:50 <devrandom> TD: does this look like what you were thinking? https://code.google.com/r/c1devrandom-bitcoinj/source/detail?r=7091f448989274438491c69640dac75c2b84f8fa&name=feature_script_watch
457 2013-11-13 19:46:16 <beethoven8201> gmaxwell: you would know better than me. I've not read the source
458 2013-11-13 19:46:17 <gmaxwell> beethoven8201: it's not quite "midchain" you fundimentally cannot verify bitcoin with a pure midchange start. But you can SPV first.
459 2013-11-13 19:46:31 <gmaxwell> er s/midchange/midchain/
460 2013-11-13 19:46:45 <beethoven8201> yes
461 2013-11-13 19:46:59 <beethoven8201> so what's the challenge then?
462 2013-11-13 19:47:58 <gmaxwell> There isn't any difficult challenge. Things just take time.
463 2013-11-13 19:48:59 <gmaxwell> _Lots_ of little details. First headers first sync, which is needed for parallel block fetching... then when thats mature, the ability to SPV validate just transactions against the headers.
464 2013-11-13 19:49:23 <beethoven8201> gmaxwell: ah
465 2013-11-13 19:49:26 <beethoven8201> okay
466 2013-11-13 19:49:27 <beethoven8201> that's not too bad
467 2013-11-13 19:49:32 <beethoven8201> hopefully it'll be done before there are no nodes
468 2013-11-13 19:50:03 <gmaxwell> we seem to have gained some nodes in the last week.
469 2013-11-13 19:51:41 <MC1984> gmaxwell, how can you tell?
470 2013-11-13 19:52:02 <BlueMatt> TD: are you looking at 0.11 soon? Id still like to push nonetty in there and can get it ready for another round of review soonish if necessary?
471 2013-11-13 19:52:15 <phantomcircuit> there are people walking all of the nodes
472 2013-11-13 19:52:41 <MC1984> phantomcircuit, is there a site somewhere for it
473 2013-11-13 19:52:51 <MC1984> i remember one but it fell into disuse
474 2013-11-13 19:52:57 <phantomcircuit> yeah but i cant remember what it is
475 2013-11-13 19:53:11 <phantomcircuit> i could turn mine back on and setup a website for it
476 2013-11-13 19:53:16 <BlueMatt> TD: it appears really stable, just needs tweaking for api tweaks/comments and the existing one or two bugs integrating the new Peer code with PeerGroup
477 2013-11-13 19:53:25 <phantomcircuit> i actually had one that was logging everything including messages
478 2013-11-13 19:53:29 <MC1984> phantomcircuit, mite b cool
479 2013-11-13 19:53:40 <phantomcircuit> but it was using wayyyy too much disk space
480 2013-11-13 19:55:36 <gmaxwell> MC1984: crawler results.
481 2013-11-13 19:56:28 <BlueMatt> ;;seen TD
482 2013-11-13 19:56:28 <gribble> TD was last seen in #bitcoin-dev 2 hours, 5 minutes, and 10 seconds ago: <TD> devrandom: cool
483 2013-11-13 19:58:21 <phantomcircuit> i should look into what it would cost to do that with some cloud nonsense actually
484 2013-11-13 19:59:56 <sipa> gmaxwell: i have around 4400 well-reachable nodes
485 2013-11-13 20:00:27 <phantomcircuit> that's like 400 more
486 2013-11-13 20:00:46 <sipa> i should put this in graphs
487 2013-11-13 20:19:43 <MC1984> what do you feel would be a good number
488 2013-11-13 20:20:03 <MC1984> before distributed resilience really kicks in
489 2013-11-13 20:20:12 <MC1984> ive always said 100,000
490 2013-11-13 20:20:28 <MC1984> kind of pulled from my ass though
491 2013-11-13 20:23:44 <devrandom> BlueMatt: if you have time for an initial review, I redid the watch feature based on TD's feedback - https://code.google.com/r/c1devrandom-bitcoinj/source/detail?r=7091f448989274438491c69640dac75c2b84f8fa&name=feature_script_watch#
492 2013-11-13 20:24:18 <BlueMatt> TD: Im assuming you missed that scrollback, then?
493 2013-11-13 20:25:17 <TD> i saw it
494 2013-11-13 20:25:20 <TD> i'm cooking that's all
495 2013-11-13 20:25:26 <TD> i have no plans to do a 0.11 any time soon
496 2013-11-13 20:25:36 <TD> so there's plenty of time to get nonetty in
497 2013-11-13 20:25:43 <TD> i want at least the payment protocol implementation
498 2013-11-13 20:26:32 <BlueMatt> ok, I just wanted to make sure given your mail this morning
499 2013-11-13 20:26:35 <TD> i also keep trying to make time to start on deterministic wallets
500 2013-11-13 20:26:43 <TD> but then other stuff keeps coming up
501 2013-11-13 20:27:58 <TD> i try to announce API changes in master as I make them, it's not indicative of an upcoming release
502 2013-11-13 20:27:59 <TD> (of course mostly i forget)
503 2013-11-13 20:28:52 <BlueMatt> ok
504 2013-11-13 20:31:49 <TD> BlueMatt: so will i see another nonetty review req in the coming weeks? :)
505 2013-11-13 20:31:59 <BlueMatt> ehhhh....
506 2013-11-13 20:32:13 <BlueMatt> my "current project" list is a rotating list of like 10 thing, so...we'll see
507 2013-11-13 20:32:16 <TD> heh
508 2013-11-13 20:32:17 <TD> yeah
509 2013-11-13 20:32:32 <TD> once it's merged i'd like to maybe add a bit of code to peergroup to make it check if there's a SOCKS proxy on the normal tor ports
510 2013-11-13 20:32:46 <TD> and then have a setTorEnabled() method that would make it use that instead of regular network
511 2013-11-13 20:32:56 <TD> although i'm not sure tor without nodes-as-hidden-services support is really a good thing
512 2013-11-13 20:33:41 <BlueMatt> well you could just set a socks proxy using regular java system properties stuff, no?
513 2013-11-13 20:33:44 <BlueMatt> why the complication?
514 2013-11-13 20:33:51 <BlueMatt> (aside from nodes-as-hidden-services)
515 2013-11-13 20:37:53 <TD> because most people aren't going to reconfigure their system level proxy to use tor given the transient nature of its usage
516 2013-11-13 20:38:02 <TD> and besides, often routing random apps via tor doesn't make sense anyway
517 2013-11-13 20:38:09 <TD> it should really be a decision app developers make on their own
518 2013-11-13 20:46:08 <BlueMatt> well, if the developer wants to make the decision, can they not call System.setProperty? does that not only apply to the running app?
519 2013-11-13 20:46:15 <BlueMatt> TD: ie pre-PeerGroup.start
520 2013-11-13 20:47:02 <TD> different semantics. setTorEnabled would mean 'try and use if available, otherwise use regular networking'
521 2013-11-13 20:47:12 <TD> if you force the proxy by hand then if tor isn't running, your app just breaks.