1 2012-10-30 00:09:59 <BlueMatt> Azelphur: bitcoinj even has an example which does that (if you dont mind java...)
2 2012-10-30 00:10:14 <Azelphur> BlueMatt: got a link? :)
3 2012-10-30 00:10:49 <sipa> ;;google bitcoinj
4 2012-10-30 00:10:50 <gribble> bitcoinj - A Java implementation of a Bitcoin client-only node ...: <http://code.google.com/p/bitcoinj/>; GettingStarted - bitcoinj - An introduction to using the library - A Java ...: <http://code.google.com/p/bitcoinj/wiki/GettingStarted>; Bitcoin for beginners, Part 3: The BitCoinJ API - JavaWorld: <http://www.javaworld.com/javaworld/jw-01-2012/120110-bitcoin-for-beginners-3.html>
5 2012-10-30 00:11:33 <BlueMatt> hmm...nope the example doesnt do quite that...it does a bit more, should be easy enough to hack though
6 2012-10-30 00:12:42 <Azelphur> ACTION shrugs
7 2012-10-30 00:35:20 <Azelphur> Luke-Jr: hmm, I'm running that python node, I'm connected to it via jsonrpc, it says that the number of blocks in the longest block chain is -1
8 2012-10-30 00:35:30 <Azelphur> and I can't really see any json calls for live monitoring of transactions in here
9 2012-10-30 00:35:53 <Luke-Jr> I've never used/touched it so far. I imagine you'd be hacking the code, not using JSONRPC
10 2012-10-30 00:36:02 <Azelphur> ah
11 2012-10-30 00:36:14 <Azelphur> seems like it's a little broken anyway
12 2012-10-30 00:38:58 <Azelphur> oh hey, blockchain.info looks like it has easy apis for this, guess I'll use that
13 2012-10-30 00:43:27 <BlueMatt> bleh
14 2012-10-30 01:37:50 <optimator> gmaxwell: how do the stuck testnet blocks get "unstuck" is ultraprune for the blockchain or just blockexplorer.com
15 2012-10-30 01:44:24 <gmaxwell> optimator: if blockexplorer.com ran an early version of ultraprune it would explain it being stuck.
16 2012-10-30 01:44:58 <gmaxwell> If thats the case it won't ever become unstuck without manual intervention (reindex or deleting the database). Does that answer your question?
17 2012-10-30 01:51:46 <optimator> gmaxwell: database meaning their db, right?
18 2012-10-30 02:05:49 <gmaxwell> Correct.
19 2012-10-30 02:06:04 <gmaxwell> er, wait what do you mean by 'their'?
20 2012-10-30 02:06:12 <gmaxwell> I mean the database that is part of their bitcoin node.
21 2012-10-30 02:06:19 <gmaxwell> Not everyone elses bitcoin nodes. :P
22 2012-10-30 02:10:44 <optimator> got it. thanks!
23 2012-10-30 03:40:50 <midnightmagic> "post-tropical cyclone" doesn't seem to be having any effect on hashrate.
24 2012-10-30 03:41:00 <robbak> If anyone has getblock stuff, could someone find transaction "22833cb67cc407b8d443c89575cee4a086ee5a24fa3304acc33121e911623816"?
25 2012-10-30 03:41:06 <midnightmagic> so much for 1.5-2m homes without power. Clearly nobody mines over there.
26 2012-10-30 03:41:31 <Luke-Jr> lol
27 2012-10-30 03:41:35 <robbak> OH, and as someone from tropical N Queensland, who has seen 3 cyclones, how is it going?
28 2012-10-30 03:41:38 <midnightmagic> robbak: no information available about transaction.
29 2012-10-30 03:41:53 <robbak> Yeah, can't find it on blockexplorer.
30 2012-10-30 03:42:06 <midnightmagic> robbak: It's only a cat 1, the main problem seems to be storm surge. And massive electrical explosions.
31 2012-10-30 03:42:40 <midnightmagic> On the other hand, I'm on the other side of the continent (where the huge earthquake that did very little human damage) was.
32 2012-10-30 03:43:50 <midnightmagic> The hilarious part was that Hawaii massively overreacted. I don't know who they rely on for their emergency warnings, but when a few hundred miles south has barely a tsunami watch, and 15cm waves are reported at beaches a tad further south, there's not really any reason to think a giant wave is slamming across the ocean towards you. :(
33 2012-10-30 03:44:14 <midnightmagic> Better safe than sorry, I guess!
34 2012-10-30 03:44:14 <robbak> midnightmagic: the thing that get's me is how far north it is!. I guess the gulf stream has something to do with it.
35 2012-10-30 03:44:31 <midnightmagic> robbak: You ever heard of The Bloop?
36 2012-10-30 03:44:57 <robbak> No, I havn't. What is it?
37 2012-10-30 03:45:24 <midnightmagic> A weird noise detected in 1997 that some people thought was a sea monster. (Myself included.)
38 2012-10-30 03:45:34 <midnightmagic> Turns out it's just ice!
39 2012-10-30 03:45:55 <midnightmagic> Giant icebergs of doom pinwheeling on patagonia etc.
40 2012-10-30 03:47:16 <midnightmagic> .. and the world becomes a little less magical, as my friend put it. :)
41 2012-10-30 03:48:20 <robbak> Ah, yes I had heard of it. But I'm never dissapointed by an explanation.
42 2012-10-30 03:49:56 <midnightmagic> Neither I nor my friend. But with all the iceberg studies going on, they've recorded a pile of new datasets and built some software for analyzing them. And they're going to publish a paper soon!
43 2012-10-30 03:50:13 <midnightmagic> Very exciting.
44 2012-10-30 03:50:32 <midnightmagic> bioacoustics is one freaky new field!
45 2012-10-30 03:50:38 <midnightmagic> new-ish..
46 2012-10-30 03:51:36 <robbak> On the subject of Tsunamis, we were put on a watch a few years ago. The authorities didn't panic, but some of the public and media did!
47 2012-10-30 03:54:09 <robbak> All very silly, all we should have done was listen to announcements and be ready to react if you lived on the shoreline, but the highways to the tablelands (1000+ feet altitude!) were all choked with idiots!
48 2012-10-30 04:30:24 <jgarzik> picocoin is now hashing tx's and block's like a champ. building and validating block merkle tree too.
49 2012-10-30 04:31:19 <jgarzik> with the P2P piece and blockchain db piece already written, time to hook everything together
50 2012-10-30 04:51:38 <gmaxwell> ugh. chrome pulling in git master?
51 2012-10-30 05:39:37 <slush> Luke-Jr: I don't know what you need for scrypt from proxy, but reasonable pull requests will be accepted...
52 2012-10-30 05:40:03 <Luke-Jr> slush: I don't, some user is reporting the proxy serving it scrypt work when he just wants Bitcoin
53 2012-10-30 05:40:39 <slush> Luke-Jr: eh? Proxy has nothing about scrypt right now
54 2012-10-30 05:40:52 <Luke-Jr> odd
55 2012-10-30 05:42:36 <Luke-Jr> slush: https://bitcointalk.org/index.php?topic=78192.msg1306171#msg1306171 fwiw
56 2012-10-30 05:42:57 <Luke-Jr> guess I'll have to install Twisted garbage to try to reproduce :<
57 2012-10-30 06:17:32 <da2ce7> hello.
58 2012-10-30 06:17:59 <da2ce7> https://en.bitcoin.it/wiki/BIP_0032 , the 'k' value is of-course arbartary. correct?
59 2012-10-30 06:19:24 <da2ce7> so if somebody posts the 'external' wallet chain... I can pick a random 256bit? number for 'k' correct... to get a seemingly random individual public key;
60 2012-10-30 06:20:24 <da2ce7> then I can then send btc to this address... I cannot ever spend these coins (as I don't have the internal chain)..
61 2012-10-30 06:20:43 <da2ce7> but the ower of the Internal cannot spend thes coins untill I provide k to her?
62 2012-10-30 06:53:32 <slush1> Luke-Jr: I still don't see any relation between scrypt and proxy. That guy isn't even using Stratum.
63 2012-10-30 06:54:28 <Luke-Jr> slush1: err, he isn't? he said "BTC Guild via stratum proxy"
64 2012-10-30 06:55:07 <senseless> Does anyone have any experience with opencl that wants to make a few coins answering some noob questions? (unrelated to bitcoin)
65 2012-10-30 06:57:26 <slush1> Luke-Jr: oh, he wrote one message on previous page... "Detected scrypt algorithm" - I don't think it has anything to do with proxy itself. I even don't know what scrypt needs in getwork response.
66 2012-10-30 06:59:39 <Luke-Jr> [00:37:46] <Luke-Jr> sipa: in theory, the only way to do it is to send "algorithm": /scrypt/ in the JSON response to getwork
67 2012-10-30 07:06:42 <slush1> Luke-Jr: proxy definitely don't send anything scrypt related...
68 2012-10-30 07:27:45 <ThomasV> is someone else experiencing problems with cinfu?
69 2012-10-30 07:31:31 <sipa> da2ce7: the subkey identifier is a 32-bit number in BIP32
70 2012-10-30 07:31:58 <da2ce7> sipa: is it possible to make it such a large number that you couldn't search throogh all the possiblityies?
71 2012-10-30 07:32:24 <sipa> da2ce7: yes, but what advantage does that have?
72 2012-10-30 07:32:45 <sipa> da2ce7: just add two keys together if you want something like that
73 2012-10-30 07:33:44 <da2ce7> sipa: I pick a random k 256bit value (for your external wallet chain), send bitcoin to that address.... I send you the hash of k. you sign "you are the first to send this (hash k)"
74 2012-10-30 07:33:54 <da2ce7> then I send you k, any you can spend these coins.
75 2012-10-30 07:33:58 <da2ce7> *and
76 2012-10-30 07:34:32 <da2ce7> so I can prove later that I was the original owner of the coins.
77 2012-10-30 07:34:49 <sipa> hmmz
78 2012-10-30 07:35:22 <da2ce7> you don't know you have a payment... untill I send you k
79 2012-10-30 07:35:33 <da2ce7> but I cannot spend the coins... only you can.
80 2012-10-30 07:42:01 <sipa> da2ce7: but it also means the receiver has to trust the sender
81 2012-10-30 07:42:10 <sipa> as the sender can double spend the coins from under him
82 2012-10-30 07:43:43 <da2ce7> sipa: woundt that be impossible, since the sender dosn't have the private component of the wallet chain?
83 2012-10-30 07:44:05 <da2ce7> only picks the k vaule, that is public anyway.
84 2012-10-30 07:44:33 <sipa> oh, right
85 2012-10-30 07:44:52 <sipa> still, no need for BIP32 here
86 2012-10-30 07:45:07 <sipa> use two public keys - one of the sender, one of the receiver, and combine them
87 2012-10-30 07:45:41 <sipa> and i suppose a multisig transaction could achieve the same
88 2012-10-30 07:46:12 <da2ce7> sipa: my dream is a payment address... where since 'k' is a shared secert, nobody can relate the payments you receive. yet you don't need to generate a new payment address for every client.
89 2012-10-30 07:46:26 <da2ce7> rarther let the client pick k.
90 2012-10-30 07:47:05 <sipa> that isn't too hard, i believe something like that was described on the forum 1-2 years ago
91 2012-10-30 07:49:27 <da2ce7> the bitcoin client could do it automaticly, from any public key.... once you know a public key, send a encripted message to the owner of that key "I'm using a k of (random 256 bit number)" then every "payment" to a bitcoin address will look (to outside observers) completely inderpendant.
92 2012-10-30 07:49:53 <sipa> sure, but you still need to communicate with the sender
93 2012-10-30 07:50:12 <sipa> so at that point you could just send a newly generated address
94 2012-10-30 07:50:34 <sipa> anyway, have to go
95 2012-10-30 07:50:39 <da2ce7> thx anyway.
96 2012-10-30 07:50:41 <da2ce7> :)
97 2012-10-30 08:45:35 <justinm001> hey can one of you smart folks help me :)
98 2012-10-30 08:45:52 <justinm001> using bt-qt 7.0 i get a msg saying i may need to upgrade or other nodes may need to upgrade
99 2012-10-30 08:45:54 <justinm001> and this in the logs
100 2012-10-30 08:45:55 <justinm001> ERROR: AcceptBlock() : AddToBlockIndex failed
101 2012-10-30 08:46:04 <justinm001> and it wont download any new blocks from yesterday
102 2012-10-30 10:32:31 <abrkn> can someone explain a transaction on blockchain.info for me? https://gist.github.com/3979674 <- i sent 1 satoshi + txn fee to 1dice... how should i be reading the input/output numbers?
103 2012-10-30 10:54:22 <abrkn> https://npmjs.org/package/blockchain <-- you're welcome.
104 2012-10-30 11:01:28 <SomeoneWeird> abrkn, why use optimist?
105 2012-10-30 11:02:59 <abrkn> i got all confused about argv[0] vs arg[v]1 etc
106 2012-10-30 11:03:17 <abrkn> like argv[0] was 'node' and argv[1] was script name
107 2012-10-30 11:03:28 <abrkn> wasnt sure how that would act if people just run ./blockchain
108 2012-10-30 11:03:50 <abrkn> if you can explain i can remove the dep
109 2012-10-30 11:06:30 <SomeoneWeird> ./blockchain will still be [ 'node', 'blockchain' ]
110 2012-10-30 11:12:26 <abrkn> ok thanks
111 2012-10-30 11:34:16 <abrkn> https://npmjs.org/package/instawallet <-- you're welcome
112 2012-10-30 12:02:34 <Luke-Jr> ACTION gives up trying to figure out how to get stratum proxy working
113 2012-10-30 14:44:28 <bitcoin> can someone explain the confirmation value (briefly) in the "sendfrom" method
114 2012-10-30 14:45:38 <sipa> it limits the transaction to only use inputs with at least that number of confirmations (IIRC)
115 2012-10-30 14:47:04 <bitcoin> buy why would you want to send unconfirmed coins
116 2012-10-30 14:48:54 <sipa> you never send unconfirmed coins
117 2012-10-30 14:49:07 <sipa> unless they are change or send-to-self
118 2012-10-30 14:49:46 <helo> you do send "greater than zero confirmed" coins though
119 2012-10-30 14:50:48 <bitcoin> so why is "confirmations" and option in the method
120 2012-10-30 14:51:13 <helo> so if you've received some coin from someone you don't trust not to double-spend, and you want to be sure you don't include that coin until it has 6 confirmations, you can use that parameter
121 2012-10-30 14:51:41 <bitcoin> helo is that a question or a statement
122 2012-10-30 14:52:29 <helo> statement. if you send coin with one confirmation to a 3rd party, and the person that sent to you pulls off a double-spend on it, then your transaction to the 3rd party will be undone
123 2012-10-30 14:55:10 <bitcoin> helo:ahhh... so it like a green address. Say I'm sending coins to myself and sending the off to another account I can spend these coins as soon as they hit my wallet
124 2012-10-30 14:55:13 <bitcoin> ?
125 2012-10-30 14:56:49 <helo> yes, that sounds right
126 2012-10-30 14:58:41 <bitcoin> thx
127 2012-10-30 15:26:30 <jgarzik> blocknam style
128 2012-10-30 15:52:14 <BlueMatt> ACTION wonders why jgarzik is so obsessed with gangnam style...
129 2012-10-30 16:02:55 <sipa> gmaxwell: pretty convinced that 257.585 bit per leaf node of the partial tree is the theoretic minimum; i guess i can live with 258 :)
130 2012-10-30 16:03:48 <gmaxwell> sipa: yea, I was ignoring the hash and thats why I was horrified. :P
131 2012-10-30 16:04:39 <sipa> haha
132 2012-10-30 16:04:48 <Eliel> so, two bits of data plus the hash? :)
133 2012-10-30 16:05:07 <sipa> well, leaf nodes of the partial tree need a hash
134 2012-10-30 16:05:23 <sipa> the number of total nodes is leaf_nodes*2-1
135 2012-10-30 16:05:39 <sipa> and there is one bit of metadata for every node currently
136 2012-10-30 16:06:13 <sipa> however, 1.585 (=log2(3)) bits per internal node suffices
137 2012-10-30 16:06:22 <Eliel> reminds me that I wrote an implementation of huffman tree compression algorithm and saved the tree using 8+2 bits per node :)
138 2012-10-30 16:06:53 <Eliel> um, the 8 was only for leaf nodes
139 2012-10-30 16:07:38 <sipa> ACTION will however not bother with complicating the algorithm tremendously for gaining up to 200 bytes per 1 MiB block in the worst case
140 2012-10-30 16:07:40 <Eliel> I don't remember how the 2 bits were used though :)
141 2012-10-30 16:08:50 <gmaxwell> sipa: Agreed. it doesn't need to be optimal. Just not bleedingly inefficient. Anything could just use a flag to special case sending the whole thing and avoid those 200 bytes trivially in any case.
142 2012-10-30 16:13:09 <Eliel> oh, I misremembered, it only used one bit per node.
143 2012-10-30 16:13:45 <Eliel> basically, did a left first treewalk and output a zero bit on non-leaf nodes and one bit on leaf nodes.
144 2012-10-30 16:13:45 <sipa> BlueMatt: does mentioning something once imply obsession?
145 2012-10-30 16:13:57 <BlueMatt> sipa: see: his G+
146 2012-10-30 16:14:00 <sipa> ah
147 2012-10-30 16:34:45 <EnasQ> hi
148 2012-10-30 16:35:11 <EnasQ> any one here to help me on having open transaction working
149 2012-10-30 16:35:18 <EnasQ> the server and client
150 2012-10-30 16:35:21 <EnasQ> please
151 2012-10-30 16:44:59 <EnasQ> ?
152 2012-10-30 16:45:09 <EnasQ> is this sleeping group?
153 2012-10-30 16:45:27 <kjj_> well, this is not Opentransactions-dev, if that's what you meant by sleeping
154 2012-10-30 16:45:52 <EnasQ> ok where to go then?
155 2012-10-30 16:46:07 <EnasQ> Open Transaction is not built over bitcoin?
156 2012-10-30 16:46:18 <EnasQ> or to coomplement Bitcoin?
157 2012-10-30 16:46:31 <kjj_> heh, no, totally different thing, but a few people are working on ways to make OT handle bitcoin transactions automatically
158 2012-10-30 16:46:40 <EnasQ> Is there channel named Opentransactions-dev?
159 2012-10-30 16:47:05 <kjj_> no idea. does the OT documentation mention IRC at all? I know some of them read the forums
160 2012-10-30 16:47:15 <EnasQ> I want to do such thing, I created my own currency using multicoin
161 2012-10-30 16:47:29 <EnasQ> and wanna enable trading of that coins via OT
162 2012-10-30 16:47:58 <EnasQ> but I dunnu know how to get OT server starting it asks me about server ID
163 2012-10-30 16:48:05 <kjj_> OT just lets you trade cryptographically signed receipts
164 2012-10-30 16:48:06 <EnasQ> which I have no clue about it.
165 2012-10-30 16:48:36 <kjj_> fellow traveller has put a lot of time and energy into it, but it hasn't really caught on. I don't think there are many servers, nor people that know how to run OT servers
166 2012-10-30 16:49:22 <EnasQ> mmm
167 2012-10-30 16:49:31 <EnasQ> :(
168 2012-10-30 16:49:39 <EnasQ> please some one help me
169 2012-10-30 16:49:46 <gmaxwell> kjj_: it's also very hard to sort out the vague grand vision stuff with which is actually possible to do securely now.
170 2012-10-30 16:50:23 <kjj_> I don't know that anyone in this channel has actually ever run the software, or knows anything about it
171 2012-10-30 16:50:43 <kjj_> again, because I don't think that more than a dozen people in the world have ever done it
172 2012-10-30 16:52:33 <jgarzik> "So why do Java coders turn to Eclipse? 'Because [of] a combination of shortcomings in the Java compiler and Java's OO nature,' explains Faler, 'we end up with lots and lots of small files for every interface and class in our system. On any less than trivial Java system, development quickly turns into a game of code- and file-system navigation rather than programming and code editing."
173 2012-10-30 16:56:22 <Diablo-D3> jgarzik: no
174 2012-10-30 16:56:35 <Diablo-D3> jgarzik: his answer gets a B- at the most
175 2012-10-30 16:56:58 <amiller> uh, the simple answer is #opentransactions which is a busy channel
176 2012-10-30 16:57:00 <amiller> meh he's gone
177 2012-10-30 16:57:09 <Diablo-D3> its because eclipse has a built in java compiler
178 2012-10-30 16:57:24 <BlueMatt> jgarzik: I quite liked that idea
179 2012-10-30 16:57:56 <BlueMatt> Diablo-D3: well the fact that java sucks is certainly a part of it (though there are other reasons to use an IDE)
180 2012-10-30 16:58:02 <jrmithdobbs> Diablo-D3: seems like a pretty good answer to me
181 2012-10-30 16:58:08 <Diablo-D3> well
182 2012-10-30 16:58:10 <Diablo-D3> java DOES suck
183 2012-10-30 16:58:18 <Diablo-D3> but thats not why java coders use eclipse
184 2012-10-30 16:58:18 <jrmithdobbs> Diablo-D3: have you ever tried to build a project thrown together in eclipse *outside of eclipse*
185 2012-10-30 16:58:22 <jrmithdobbs> jesus christ fuck that shit
186 2012-10-30 16:58:44 <Diablo-D3> jrmithdobbs: well, I use the maven eclipse plugin
187 2012-10-30 16:58:48 <Diablo-D3> and not the eclipse build system
188 2012-10-30 16:58:53 <Diablo-D3> so all of it works for me fine
189 2012-10-30 16:59:02 <Eliel> Diablo-D3: since you obviously know better, can you share what's the real reason then? :P
190 2012-10-30 16:59:20 <Diablo-D3> well, having a java compiler in eclipse means you have full access to the AST
191 2012-10-30 16:59:24 <jrmithdobbs> Diablo-D3: eclipse just gens ant configs, so it "works" it's just a matter of figuring out all the magical default eclipse environment settings
192 2012-10-30 16:59:38 <Diablo-D3> code complete, realtime error checking, etc, all right in eclipse
193 2012-10-30 16:59:45 <Diablo-D3> cant do it with javac, sadly
194 2012-10-30 16:59:50 <Diablo-D3> otherwise vim would already
195 2012-10-30 16:59:55 <Diablo-D3> jrmithdobbs: basically
196 2012-10-30 17:00:00 <Diablo-D3> which is why I hate eclipse
197 2012-10-30 17:00:07 <daybyter> Java? Here!
198 2012-10-30 17:00:08 <Diablo-D3> I did java dev on purpose for an entire year
199 2012-10-30 17:00:14 <Diablo-D3> and you know what?
200 2012-10-30 17:00:34 <daybyter> I do java dev since ver. 1.0.2 ...
201 2012-10-30 17:00:40 <Diablo-D3> I like the syntax mostly, I fucking hate the community, eclipse, anything javaee, and oracle's close sourcing of java via patents
202 2012-10-30 17:00:43 <jrmithdobbs> Diablo-D3: i hate eclipse because it's slower and more obsfucated than boreland c++'s ide was 20 years ago on hardware exponentially faster and with insane ammounts of ram
203 2012-10-30 17:01:00 <Diablo-D3> jrmithdobbs: yeah, vim after I load it up is slower too
204 2012-10-30 17:01:08 <Diablo-D3> so that comparison means jack shit
205 2012-10-30 17:01:13 <daybyter> I just use emacs and ant...no eclipse and such...
206 2012-10-30 17:01:14 <Diablo-D3> eclipse's problem is _its written in java_
207 2012-10-30 17:01:24 <Diablo-D3> daybyter: emacs cant code complete effectively
208 2012-10-30 17:01:38 <jrmithdobbs> daybyter: i use vim and not java and don't have issues with my editor getting bogged down
209 2012-10-30 17:02:03 <daybyter> I don't want the editor to code...I'm the coder...
210 2012-10-30 17:02:23 <daybyter> I just use the editor to enter the sources...
211 2012-10-30 17:02:25 <Diablo-D3> I want the _language_ to code
212 2012-10-30 17:02:26 <jrmithdobbs> I don't like that code completing crap either =/
213 2012-10-30 17:02:27 <Diablo-D3> not the editor
214 2012-10-30 17:02:43 <Diablo-D3> java sorta almost got it, but not really
215 2012-10-30 17:03:19 <daybyter> I write cryptocoin trading stuff in Java and looking for contributors...
216 2012-10-30 17:03:20 <jrmithdobbs> i've seen some kind of useful stuff with textmate as far as quickly jumping to the source file for a given function and things like that, but never understood the code completion stuff it gets it wrong more often than right no matter the IDE and just gets in the way
217 2012-10-30 17:15:35 <Diablo-D3> jrmithdobbs: depends on your ide settings
218 2012-10-30 17:16:35 <jrmithdobbs> Diablo-D3: i dunno, bash and too many open editor stopped job abuse works well enough for me ;p
219 2012-10-30 17:17:11 <Diablo-D3> no, I mean, eclipse code complete is annoying as fuck until you tell it to shut the hell up
220 2012-10-30 17:19:51 <jrmithdobbs> they should turn the shit off by default then
221 2012-10-30 17:20:16 <Diablo-D3> its eclipse
222 2012-10-30 17:20:21 <Diablo-D3> its trying to pretend to be visual studio
223 2012-10-30 17:21:00 <_dr> it's the only obvious reason people use eclipse
224 2012-10-30 17:21:15 <_dr> because they're too stupid to remember all their funky java methods :)
225 2012-10-30 17:21:26 <Diablo-D3> yeah pretty much
226 2012-10-30 17:21:26 <jgarzik> "For the coinbase (first) transaction, scriptSig length must be 2-100"
227 2012-10-30 17:21:28 <jgarzik> huh
228 2012-10-30 17:21:30 <jgarzik> never knew that
229 2012-10-30 17:21:32 <Diablo-D3> java is the only language that NEEDS code complete
230 2012-10-30 17:21:47 <jgarzik> trying to work on block and TX validation
231 2012-10-30 17:21:49 <_dr> Diablo-D3: so true
232 2012-10-30 17:21:53 <jgarzik> reading through https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages
233 2012-10-30 17:22:13 <_dr> https://plus.google.com/105201233571140699617/posts/1QhcnQizuPc
234 2012-10-30 17:22:17 <jgarzik> some of those are clearly implementation-based
235 2012-10-30 17:22:18 <gmaxwell> jgarzik: be careful to check it against the source, it's been wrong sometimes.
236 2012-10-30 17:22:21 <jgarzik> not really rules
237 2012-10-30 17:22:24 <Luke-Jr> jgarzik: for practical purposes, it's 4-100 now (incl height)
238 2012-10-30 17:22:58 <gmaxwell> e.g. it's been sloppy over things like > vs >=
239 2012-10-30 17:23:17 <jgarzik> ACTION was getting that feeling, yeah
240 2012-10-30 17:24:02 <jgarzik> ACTION needs to figure out the time rules
241 2012-10-30 17:24:08 <jgarzik> e.g. median time, not more than 2 hours in the future, etc.
242 2012-10-30 17:25:10 <jgarzik> some of /Protocol_rules appears to be pre-ultraprune
243 2012-10-30 17:25:24 <jgarzik> transcribing old C++ -> English, without much thought
244 2012-10-30 17:31:10 <gmaxwell> funny.
245 2012-10-30 17:31:16 <gmaxwell> the median time rule there is wrong.
246 2012-10-30 17:31:32 <gmaxwell> I fixed it but lost a word in my edit ( :( ) and sipa broke it back again.
247 2012-10-30 17:31:55 <gmaxwell> The time must be after the median, it can't _be_ the median.
248 2012-10-30 17:32:24 <gmaxwell> e.g. median()+1 is good. median() is bad.
249 2012-10-30 17:35:17 <BlueMatt> how many blocks is the median again?
250 2012-10-30 17:35:22 <BlueMatt> 11?
251 2012-10-30 17:35:26 <gmaxwell> 11.
252 2012-10-30 17:38:09 <Diablo-D3> 9000
253 2012-10-30 17:40:03 <BlueMatt> hmm...that needs way more thorough testing in the block creator...(it does only one test, using the block's timestamp of 5 blocks ago with each block having a timestamp +1 of the previous one...)
254 2012-10-30 17:41:40 <gmaxwell> testnet3 has a bunch of blocks with the minimum allowed timestamps, but obviously none below that.
255 2012-10-30 18:04:19 <jgarzik> OK
256 2012-10-30 18:04:22 <jgarzik> incoming payment detection
257 2012-10-30 18:05:09 <jgarzik> 1) is a key fixed at compressed or uncompressed at birth, never changing? or must I search for both compressed and uncompressed keys?
258 2012-10-30 18:05:21 <jgarzik> 2) does one /search/ or /execute/ a script, to find incoming payments?
259 2012-10-30 18:07:53 <gavinandresen> 1) if I were you, I'd search for both compressed and uncompressed, in both <pubkey> CHECKSIG and DUP HASH160 <hash_pubkey>... transactions
260 2012-10-30 18:08:13 <gmaxwell> gavinandresen: really? I was going to give the opposite answer.
261 2012-10-30 18:08:14 <gavinandresen> 2) and you search for scriptPubKeys that you can understand.
262 2012-10-30 18:08:17 <sipa> you never expect a payment to an address that was not created
263 2012-10-30 18:08:35 <gmaxwell> In the reference client keys are compressed or uncompressed at birth and you only reconize the matching kind.
264 2012-10-30 18:08:53 <gavinandresen> jgarzik: will you allow importing keys from elsewhere?
265 2012-10-30 18:08:57 <sipa> if you only create compressed pubkeys and their corresponding addresses, you never need to look for payments to uncompressed ones
266 2012-10-30 18:09:29 <sipa> abd the base58 format for private keys contains a flag to tell you whether the corresponding pubkey is compressed
267 2012-10-30 18:09:46 <gmaxwell> Generally people should never expect that they can manipulate a script and have the far end detect it, unless they're explicitly told this is okay.
268 2012-10-30 18:09:47 <gavinandresen> Looking for payments, I'd code it to look for both compressed and uncompressed. But on import, I'd always convert to compressed and always generate addresses/transactions based on compressed.
269 2012-10-30 18:10:10 <sipa> gavinandresen: on import you need to be careful!
270 2012-10-30 18:10:15 <sipa> not the other way around
271 2012-10-30 18:10:16 <gmaxwell> gavinandresen: uh. if you convert on import you're going to get a different address than expected.
272 2012-10-30 18:10:32 <gmaxwell> This is going to make people who are importing because they wanted to use some vanity address quite happy. :P
273 2012-10-30 18:10:56 <gavinandresen> gmaxwell: I wouldn't support importing uncompressed vanity addresses....
274 2012-10-30 18:11:17 <sipa> exactly
275 2012-10-30 18:11:18 <sipa> if you generated they privkey, you know what address you may have generated from it.
276 2012-10-30 18:11:19 <gavinandresen> (well, I would, but they'd get compressed and wouldn't be vanity any more)
277 2012-10-30 18:11:37 <gmaxwell> then you can just refuse to import any privkey without the compressed flag.
278 2012-10-30 18:11:49 <gavinandresen> jgarzik: or, in other words: "it depends on what you want to support"
279 2012-10-30 18:11:54 <gmaxwell> (though yea, I do generally agree with moving away from non compressed pubkeys.
280 2012-10-30 18:11:57 <gmaxwell> )
281 2012-10-30 18:13:13 <gmaxwell> A lot of users are still generating non-compressed pubkeys because of how walletupgrade works.
282 2012-10-30 18:13:30 <gmaxwell> perhaps 0.8 should also force a wallet upgrade to 0.7 ?
283 2012-10-30 18:15:14 <sipa> i'm beginning to regret my very first contribution to bitcoin
284 2012-10-30 18:15:38 <sipa> (storing a bitvector of spentness in wallet transactions)
285 2012-10-30 18:16:14 <jgarzik> well, picocoin is new
286 2012-10-30 18:16:24 <jgarzik> so I'm all for (a) fixed at birth and (b) compressed by default
287 2012-10-30 18:16:44 <sipa> no need to store that information in the wallet, it can be derived easily anway
288 2012-10-30 18:16:58 <jgarzik> just want to make sure I follow accepted standards for finding payments-to-my-keys
289 2012-10-30 18:17:16 <sipa> jgarzik: fixed-at-birth is perfectly fine imho
290 2012-10-30 18:17:27 <gmaxwell> sipa: there was recently some potential bug that I noticed was prevented by the wallet spentness check.
291 2012-10-30 18:17:35 <gmaxwell> Be damned if I can remember what it was.
292 2012-10-30 18:18:06 <jgarzik> gavinandresen: no initial plans to permit importing keys
293 2012-10-30 18:18:14 <jgarzik> but it seems like a feature users might request, of an SPV
294 2012-10-30 18:18:52 <sipa> BlueMatt: poke me if you're interested in discussing the encoding of partial merkle trees
295 2012-10-30 18:20:34 <BlueMatt> sipa: sure, lemme look at what you wrote...
296 2012-10-30 18:21:34 <jgarzik> So a client only recognizes incoming payments by pattern-matching script layouts?
297 2012-10-30 18:21:47 <sipa> what needs to be stored: 1) number of txn in block 2) a number N 3) 2*N-1 bits 4) N hashes
298 2012-10-30 18:21:50 <jgarzik> i.e. it only knows a set of standard scripts, rather than $anyscript ?
299 2012-10-30 18:22:01 <jgarzik> and thus will not recognize complex payments-to-me by default?
300 2012-10-30 18:23:46 <sipa> jgarzik: you don't expect a payment to a complex script involving one of your keys without you knowing about it (i.e., participating in creation of said multisig)
301 2012-10-30 18:24:01 <sipa> jgarzik: for P2SH it's entirely impossible whatsoever
302 2012-10-30 18:24:32 <jgarzik> OK. pattern matching is definitely doable.
303 2012-10-30 18:29:04 <jgarzik> EC_KEY_new_by_curve_name(NID_secp256k1) ; EC_KEY_generate_key(pkey) ; EC_KEY_set_conv_form(pkey, POINT_CONVERSION_COMPRESSED)
304 2012-10-30 18:29:12 <jgarzik> that is the correct magic, in the correct order?
305 2012-10-30 18:31:57 <sipa> the two last ones can be swapped, i believe
306 2012-10-30 18:31:59 <sipa> but yes
307 2012-10-30 18:32:27 <jgarzik> ACTION was following the order from bitcoind source code
308 2012-10-30 18:32:50 <jgarzik> it calls SetCompressedPubKey() after key generation
309 2012-10-30 18:45:06 <sipa> BlueMatt: makes sense?
310 2012-10-30 18:46:58 <BlueMatt> sipa: yea...simple enough algorithm, seems like dealing with it could be kinda ugly though...not that I can think of an effecient enough alternative though
311 2012-10-30 18:47:38 <BlueMatt> (if Im reading the description right, its ideal in terms of minimum possible set of hashes stored ignoring the vBits stuff, right?)
312 2012-10-30 18:48:21 <runeks> what is an easy way to print out a CDataStream as hex?
313 2012-10-30 18:49:57 <BlueMatt> use HexStr(CDataStream.begin(), CDataStream.end()).c_str() iirc
314 2012-10-30 18:50:02 <BlueMatt> printf ("%s", ...)
315 2012-10-30 18:50:15 <runeks> thanks! I'll try
316 2012-10-30 18:51:13 <BlueMatt> sipa: meh, looks pretty close to ideal to me (vector<bool> is serialized as bits, not bytes iirc, right?)
317 2012-10-30 18:51:42 <BlueMatt> or...no its only stored that way in memory...what about getting it to serialize that way
318 2012-10-30 19:01:55 <sipa> BlueMatt: writing a manual serializer isn't hard, but a few bytes isn't the problem, so preferrably something that's easy enough to implement in several languages
319 2012-10-30 19:02:43 <BlueMatt> TD: not sure if you've been paying attention, but we just stared discussing sipa's partial merkle tree stuff (https://github.com/sipa/bitcoin/commit/3006e4e2d0774eee888f62caa44206050f5f3be9)
320 2012-10-30 19:02:54 <TD> he showed it to me earlier
321 2012-10-30 19:02:55 <sipa> BlueMatt: already told him about it :)
322 2012-10-30 19:03:04 <BlueMatt> ok...guess Im too far behind
323 2012-10-30 19:03:11 <TD> needs more work :)
324 2012-10-30 19:03:25 <gmaxwell> hm? there is no reason to use anything inefficient for just packing a few bits. Since high speed isn't needed (we're only talking a few hundred bits tops) even a trivial bitpacker will be acceptable.
325 2012-10-30 19:03:34 <BlueMatt> sipa: if you want really, really easy, just replace hashes that you dont need with 0-length vectors, but that wastes a lot of space (potentially)
326 2012-10-30 19:03:47 <sipa> BlueMatt: huh?
327 2012-10-30 19:03:50 <BlueMatt> gmaxwell: yep, I was just wondering
328 2012-10-30 19:04:01 <BlueMatt> sipa: ship the whole merkle tree vector and drop things you dont need
329 2012-10-30 19:04:08 <BlueMatt> but thats way worse (and grows too fast)
330 2012-10-30 19:04:30 <sipa> BlueMatt: there's no reason to throw away what i wrote, i hope...
331 2012-10-30 19:04:50 <sipa> BlueMatt: it already computes the minimal list of hashes needed
332 2012-10-30 19:04:52 <BlueMatt> sipa: no, yours is definately better, I was just giving an example way down the line of easier to implement but worse space
333 2012-10-30 19:05:50 <sipa> right, sure, it's a balance, but i think the algorithm is simple enough now (yell if you think it isn't...), so the only question is how to store that list of bits and hashes
334 2012-10-30 19:08:21 <BlueMatt> it seems simple and Im hungry and tired, so it must be fine :)
335 2012-10-30 19:09:37 <sipa> BlueMatt: anyway, i don't even know whether satoshi's serialize.h can deal with vector<bool> (i see no special casing for it, so i doubt it)
336 2012-10-30 19:10:16 <BlueMatt> Id assume it would end up writing then per-byte? I dont remember that code too well
337 2012-10-30 19:10:23 <BlueMatt> one-bool-per-byte that is
338 2012-10-30 19:10:33 <sipa> i think it will break :)
339 2012-10-30 19:10:39 <BlueMatt> ahh, ok...
340 2012-10-30 19:10:52 <BlueMatt> well, writing per-byte sounds good to me (unless you really wanna get fancy...)
341 2012-10-30 19:11:26 <sipa> BlueMatt: anyway, what about this: { uint32 nTransactions; uint32 nLeafNodes; byte[(nLeafNodes*2-1+7)/8] vBits; uint256[nLeafNodes] vHash }
342 2012-10-30 19:12:12 <BlueMatt> I was under the impression nLeafNodes is trivially calculateable from nTransactions?
343 2012-10-30 19:12:17 <BlueMatt> calculable*
344 2012-10-30 19:12:21 <sipa> no
345 2012-10-30 19:12:50 <sipa> it cannot be derived from the total number of transactions, and not from the number of matched transactions
346 2012-10-30 19:12:56 <BlueMatt> oh, one is the number of txn you have, one is the total #?
347 2012-10-30 19:13:07 <BlueMatt> yea, sorry misunderstood
348 2012-10-30 19:13:11 <sipa> nTransactions is the total number of transactions in the block
349 2012-10-30 19:13:35 <sipa> nLeafNodes is the number of leaf nodes in the partial merkle tree (which do not necessarily correspond to txid's, by the way)
350 2012-10-30 19:13:53 <BlueMatt> yea
351 2012-10-30 19:13:53 <sipa> as in, you can have leaf nodes at a height>0
352 2012-10-30 19:14:01 <BlueMatt> yep
353 2012-10-30 19:14:38 <sipa> but you need the total number of transaction in order to know the shape of the tree (mostly to deal with the oddness at the end of the vector in case of an odd number of elements)
354 2012-10-30 19:15:01 <BlueMatt> why not just let standard serialization code work its magic with a varint for the vector size? { uint32 nTransactions; byte[(nLeafNodes*2-1+7)/8] vBits; varint nLeafNodes; uint256[nLeafNodes] vHash }
355 2012-10-30 19:15:27 <sipa> ok, sure
356 2012-10-30 19:15:44 <sipa> the bytes would need to be afterwards then, as you need to know nLeafNodes
357 2012-10-30 19:15:45 <BlueMatt> seems more like our standard
358 2012-10-30 19:15:56 <BlueMatt> oh, sorry, yea
359 2012-10-30 19:16:19 <sipa> or i don't mind storing them as a standard char array, and adding another varint for the number of bytes in front
360 2012-10-30 19:16:21 <BlueMatt> or...also be lazy for vBits and let it put a varint there too, but...
361 2012-10-30 19:16:25 <sipa> that it probably even more standard
362 2012-10-30 19:16:33 <Luke-Jr> ???
363 2012-10-30 19:16:56 <Luke-Jr> sipa: so now we have 3 ways to encode numbers
364 2012-10-30 19:16:58 <Luke-Jr> ?
365 2012-10-30 19:17:00 <sipa> >
366 2012-10-30 19:17:02 <sipa> ?
367 2012-10-30 19:17:14 <BlueMatt> throwing in a few extra bytes to be lazy and use standard vector<?> encoding seems reasonable to me
368 2012-10-30 19:17:22 <sipa> uint32, varint, ... what else, Luke-Jr?
369 2012-10-30 19:17:47 <Luke-Jr> sipa: bigint
370 2012-10-30 19:18:02 <sipa> well, sure, but how is that related to this?
371 2012-10-30 19:18:12 <sipa> it's not like we're inventing a new format
372 2012-10-30 19:18:31 <Luke-Jr> I'm not really paying attention, just expressing dislike of adding yet more number encodings; maybe I misunderstood something
373 2012-10-30 19:18:48 <sipa> Luke-Jr: we're encoding a few numbers, a vector of hashes and a bitvector
374 2012-10-30 19:19:38 <sipa> we need a way of encoding that bitvector, and the question is whether to do it efficiently (as we know how many bits it will have), or do it satosh-like :)
375 2012-10-30 19:20:25 <BlueMatt> I prefer satoshi-like
376 2012-10-30 19:20:36 <BlueMatt> (doesnt apply to bitcoinj, but may to others)
377 2012-10-30 19:20:57 <sipa> BlueMatt: anyway, turning it into a vector<unsigned char> by packing the bits into bytes, and then use standard encoding for that vector is fine by me
378 2012-10-30 19:21:15 <BlueMatt> that or byte-per-bit is fine either way
379 2012-10-30 19:21:28 <sipa> that'd be a waste :)
380 2012-10-30 19:21:43 <sipa> it could be up to a few kilobytes
381 2012-10-30 19:21:54 <BlueMatt> true, bitset it is then
382 2012-10-30 19:24:27 <Luke-Jr> if we know how many bits it will have??? why encode length at all? <.<
383 2012-10-30 19:24:44 <BlueMatt> because its more bitcoin-standard
384 2012-10-30 19:25:12 <BlueMatt> ACTION votes for length-in-bits, btw
385 2012-10-30 19:25:17 <BlueMatt> ehh...has to be
386 2012-10-30 19:25:21 <sipa> heh?
387 2012-10-30 19:25:26 <sipa> that's completely pointless
388 2012-10-30 19:25:44 <sipa> then you have the disadvantage of extra bytes + not being able to reuse serialization code
389 2012-10-30 19:25:53 <BlueMatt> sorry, yea
390 2012-10-30 19:25:59 <BlueMatt> ACTION is way too distracted
391 2012-10-30 19:26:00 <Luke-Jr> ACTION votes whoever writes the code arbitrarily decides
392 2012-10-30 19:27:05 <sipa> ACTION introduces a range encoder to store the tree in an information-theoretically perfect way, gaining 0.415 bits per node
393 2012-10-30 19:27:24 <Luke-Jr> ._.
394 2012-10-30 19:27:54 <sipa> ok, kidding, ...
395 2012-10-30 19:28:23 <kjj_> meh. I'll just slap Burrows-Wheeler in front of your encoding and gain 5% more
396 2012-10-30 19:28:47 <sipa> ACTION explains Shannon's theorem to kjj_
397 2012-10-30 19:29:13 <kjj_> ACTION explains humor to sipa
398 2012-10-30 19:29:36 <sipa> ACTION fails to understand
399 2012-10-30 19:30:25 <BlueMatt> oh god...oh god
400 2012-10-30 19:31:13 <kjj_> ha! Not like Disney could do any worse with it than Lucas did
401 2012-10-30 19:31:26 <helo> might as well milk it for what it's worth
402 2012-10-30 19:31:36 <helo> economic growth ftw!
403 2012-10-30 19:31:39 <BlueMatt> kjj_: how much do you want to bet?
404 2012-10-30 19:31:52 <BlueMatt> bad 3d?
405 2012-10-30 19:31:59 <BlueMatt> oh, wait...lucas did do that
406 2012-10-30 19:32:22 <kjj_> nothing. at this point, I don't even care. I'm quite content to let Star Wars die
407 2012-10-30 19:44:08 <Diablo-D3> lol someone punked theverge
408 2012-10-30 19:44:10 <Diablo-D3> bwhahahaha
409 2012-10-30 19:44:16 <Diablo-D3> disney couldnt afford lucasfilm to begin with
410 2012-10-30 19:44:34 <Diablo-D3> and spoilers: there was no star wars 7, 8, 9
411 2012-10-30 19:44:45 <Diablo-D3> george lucas admitted he lied about it
412 2012-10-30 19:46:12 <gavinandresen> I'm going to wait for Star Wars 11.
413 2012-10-30 19:49:15 <sipa> Star Wars 11: Return of the Jedi, Again!
414 2012-10-30 19:50:22 <jgarzik> and I will pay money for it
415 2012-10-30 19:50:29 <jgarzik> like a sucker
416 2012-10-30 19:51:47 <BlueMatt> we all will
417 2012-10-30 19:52:00 <jgarzik> punked? http://mediadecoder.blogs.nytimes.com/2012/10/30/disney-buying-lucas-films-for-4-billion/
418 2012-10-30 19:52:40 <jgarzik> it's on CNN and ABC too
419 2012-10-30 19:52:58 <jgarzik> and Reuters
420 2012-10-30 20:08:11 <Tykling> can I get bitcoind to fire an event when it receives a transaction somehow ?
421 2012-10-30 20:08:18 <phantomcircuit> lol ATT
422 2012-10-30 20:08:29 <phantomcircuit> they call me and say UVERSE IS AVAILABLE IN YOUR AREA!!!
423 2012-10-30 20:08:47 <phantomcircuit> the fastest connection they offer is slower than the slowest connection from comcast
424 2012-10-30 20:08:52 <phantomcircuit> what is wrong with them
425 2012-10-30 20:08:56 <jgarzik> Tykling: do you mean, for the mempool?
426 2012-10-30 20:09:07 <jgarzik> Tykling: bitcoind has -blocknotify, which you can then scan for tx's
427 2012-10-30 20:09:17 <Tykling> jgarzik: like when someone transfers btc to one of my addresses
428 2012-10-30 20:09:39 <phantomcircuit> jgarzik, have to say that always seemed like a bad idea
429 2012-10-30 20:10:51 <jgarzik> Tykling: nothing so specific and pluggable, unfortunately. you can watch blocks, and scan them for your own transactions. or watch the debug.log, to see when it notices some wallet activity.
430 2012-10-30 20:10:55 <jgarzik> phantomcircuit: which?
431 2012-10-30 20:11:15 <Luke-Jr> replace debug.log with a fifo <.<
432 2012-10-30 20:11:27 <phantomcircuit> jgarzik, -blocknotify
433 2012-10-30 20:11:43 <jgarzik> phantomcircuit: why?
434 2012-10-30 20:11:57 <phantomcircuit> unspecified feeling of anxiety whenever system() is used
435 2012-10-30 20:11:58 <phantomcircuit> :P
436 2012-10-30 20:12:27 <Luke-Jr> ???
437 2012-10-30 20:12:38 <Luke-Jr> iow, "no reason, just paranoia"?
438 2012-10-30 20:12:51 <phantomcircuit> yes pretty much
439 2012-10-30 20:13:01 <phantomcircuit> oh wait i know
440 2012-10-30 20:13:10 <phantomcircuit> if you're running bitcoind as it's own user
441 2012-10-30 20:13:25 <Luke-Jr> ???
442 2012-10-30 20:13:25 <phantomcircuit> specifying that will run the command as the bitcoind user
443 2012-10-30 20:13:30 <Luke-Jr> of course?
444 2012-10-30 20:13:33 <phantomcircuit> which is probably not the wanted behavious
445 2012-10-30 20:13:36 <phantomcircuit> behavious*
446 2012-10-30 20:13:41 <phantomcircuit> lol
447 2012-10-30 20:13:43 <phantomcircuit> I CAN DO THIS
448 2012-10-30 20:13:46 <phantomcircuit> behaviour*
449 2012-10-30 20:15:20 <phantomcircuit> i guess it's just a general feeling that bitcoind should be isolated as much as possible from the rest of the system and only interact using well defined network protocols
450 2012-10-30 20:16:47 <gmaxwell> Interprocess communication is hard, lets go shopping instead.
451 2012-10-30 20:17:13 <phantomcircuit> lol
452 2012-10-30 20:17:26 <Luke-Jr> phantomcircuit: -blocknotify='socat someoptions'
453 2012-10-30 20:17:58 <phantomcircuit> Luke-Jr, yes because that's what bitcoin needs
454 2012-10-30 20:17:59 <phantomcircuit> more hacks
455 2012-10-30 20:18:02 <phantomcircuit> ACTION runs
456 2012-10-30 20:18:13 <sipa> clearly it needs SMTP support
457 2012-10-30 20:18:34 <Luke-Jr> phantomcircuit: since there's no sensible network protocol, -blocknotify lets you plug in any :P
458 2012-10-30 20:18:45 <Luke-Jr> including the traditional UNIX signals
459 2012-10-30 20:18:58 <Luke-Jr> which is probably what everyone is still using
460 2012-10-30 20:19:54 <jgarzik> Ouch. Best case for restoring flooded NYC subway tunnels is 29 days. 7 of 10 under-river tunnels are flooded.
461 2012-10-30 20:25:24 <jurov> what about blocking RPC read instead of blocknotify?
462 2012-10-30 20:25:40 <sipa> ;;bc,estimate
463 2012-10-30 20:25:41 <gribble> 3510777.77282495
464 2012-10-30 20:25:51 <sipa> ;;bc,stats
465 2012-10-30 20:25:53 <gribble> Current Blocks: 205765 | Current Difficulty: 3304356.3929903 | Next Difficulty At Block: 207647 | Next Difficulty In: 1882 blocks | Next Difficulty In About: 1 week, 5 days, 9 hours, 27 minutes, and 38 seconds | Next Difficulty Estimate: 3510777.77282495 | Estimated Percent Change: 6.24694661485
466 2012-10-30 20:29:20 <jurov> have a rpc command named, like, 'blockwait' that will return only after next block arrives
467 2012-10-30 20:29:31 <jurov> maybe with some timeout
468 2012-10-30 20:33:13 <phantomcircuit> jgarzik, well given there was like 2ft of water in midtown that seems pretty reasonable actually
469 2012-10-30 20:33:40 <jrmithdobbs> jurov: that's not safe. there's a myriad of things on the network (as in, your not the bitcoin p2p network) that could cause the connection to drop before the block actually arrived
470 2012-10-30 20:34:18 <phantomcircuit> jurov, not to mention there is basically no reason to do that
471 2012-10-30 20:34:44 <jurov> jrmithdobbs, client can clearly distinguish that.. ok, just an idea
472 2012-10-30 20:35:09 <phantomcircuit> just call listsinceblock in a loop
473 2012-10-30 20:35:27 <phantomcircuit> er
474 2012-10-30 20:35:51 <phantomcircuit> yeah
475 2012-10-30 20:35:58 <jrmithdobbs> just use blocknotify
476 2012-10-30 20:36:20 <phantomcircuit> bleh
477 2012-10-30 20:36:27 <phantomcircuit> i still think that's an ugly hack
478 2012-10-30 20:36:39 <jrmithdobbs> better than polling rpc constantly
479 2012-10-30 20:37:27 <jrmithdobbs> just set -blocknotify='echo %s > ~bitcoin/.bitcoin/bestblock'; and use api of your choice to wait for it to change
480 2012-10-30 20:37:29 <jurov> in fact i was unaware of blocknotify, am using the polling
481 2012-10-30 20:38:23 <jrmithdobbs> jurov: eg, you could do tail -n 0 --follow=name ~bitcoin/.bitcoin/bestblock; to get the behaviour you wanted with the rpc call
482 2012-10-30 20:38:28 <jrmithdobbs> (on the local system, at least)
483 2012-10-30 20:39:43 <jrmithdobbs> (actually I don't know if that'll work, i forget if blocknotify uses system() or not, but you get the idea)
484 2012-10-30 20:40:00 <jurov> thx, i don't need it so much in realtime.
485 2012-10-30 20:41:00 <jurov> except maybe when people want urgent deposit to coinbr, lol
486 2012-10-30 20:41:02 <phantomcircuit> jrmithdobbs, not really
487 2012-10-30 20:41:09 <phantomcircuit> getinfo is a very cheap rpc call
488 2012-10-30 21:14:48 <an3k> wth is going on with the btc network? still have zero confirmations for a transaction made one hour ago :(
489 2012-10-30 21:15:04 <an3k> are there really 90% of all btc users located in new york? :)
490 2012-10-30 21:34:48 <weex> no. not new york. atlantic city.
491 2012-10-30 21:36:51 <jouke> No, off the coast of africa somewhere
492 2012-10-30 21:38:25 <Luke-Jr> an3k: how much fee?
493 2012-10-30 21:39:13 <an3k> Luke-Jr: dunno, where can i see that? i'm just receiving the coins
494 2012-10-30 21:40:28 <jouke> Do you have the tx-id?
495 2012-10-30 21:43:21 <an3k> yes jouke
496 2012-10-30 21:48:33 <Luke-Jr> an3k: doubleclick on it in your txn list
497 2012-10-30 21:49:11 <Luke-Jr> total up all the CTxIn, and subtract all the CTxOut
498 2012-10-30 21:49:16 <Luke-Jr> difference is the fee
499 2012-10-30 21:51:19 <an3k> i'm using bitcoin-qt ... only see the credit and net amount but it looks like there is no fee :(
500 2012-10-30 21:55:56 <runeks> the one-byte hash type that is appended to the end of scriptSig is not pushed to the stack, right?
501 2012-10-30 21:59:14 <runeks> i mean: the one-byte hash type that is appended to the end of the signature (in scriptSig)... is this pushed to the stack as well?
502 2012-10-30 22:21:00 <sipa> runeks: it's part of the signature , as far as bitcoin is concerned
503 2012-10-30 22:21:14 <sipa> so it's part of the byte sequence pushed on the stack by the input script
504 2012-10-30 22:21:26 <runeks> ok. good.
505 2012-10-30 22:23:47 <runeks> would there be any reason that bitcoin-qt would stop printing to debug.log when encountering a printf statement? it worked fine before. but doesn't any longer...
506 2012-10-30 22:24:02 <sipa> is your disk full?
507 2012-10-30 22:25:39 <runeks> nope. 2.3 GB available.
508 2012-10-30 22:26:18 <Luke-Jr> is the file > 2 GB?
509 2012-10-30 22:26:33 <runeks> no
510 2012-10-30 22:26:50 <runeks> hmm. wait a minute. I might be wrong here.
511 2012-10-30 22:28:02 <sipa> BlueMatt: crap, just realized: the nice rule that nBits = 2*nHashes-1 is only guaranteed if nTransaction is a power of two, otherwise it can be a bit off due to the odd-number-of-hashes rule
512 2012-10-30 22:28:10 <sipa> but not a problem actually
513 2012-10-30 22:29:23 <runeks> I'm trying to submit a transaction using sendrawtransaction. I get an error (code -22, "TX rejected") and I'm trying to figure out why it's happening.
514 2012-10-30 22:29:30 <runeks> debug.log says: "ERROR: ConnectInputs() : c9b6970ac8 VerifySignature failed"
515 2012-10-30 22:29:44 <Luke-Jr> sipa: just changes the rule slightly
516 2012-10-30 22:29:53 <runeks> I have a printf in CKey::Verify that doesn't get triggered (first line in the function)
517 2012-10-30 22:30:32 <runeks> hmm... does bitcoin-qt store failed signature checks? and if so, in what file?
518 2012-10-30 22:30:51 <sipa> no
519 2012-10-30 22:31:10 <sipa> only in the signature cache, but that's memory-only
520 2012-10-30 22:31:20 <runeks> odd
521 2012-10-30 22:31:54 <runeks> so there's no reason CKey::Verify wouldn't get called when submitting a transaction via sendrawtransaction?
522 2012-10-30 22:32:20 <jgarzik> runeks: well it might fail encoding or otherwise encounter an error before hitting that function
523 2012-10-30 22:32:21 <sipa> it can certainly fail before reaching that stage
524 2012-10-30 22:32:30 <jgarzik> yes
525 2012-10-30 22:32:30 <runeks> oh...
526 2012-10-30 22:32:35 <sipa> runeks: what kind of output does it spend?
527 2012-10-30 22:33:41 <runeks> sipa: 'DUP HASH160 20:d6b55bdb9d192f8c05b5eda8b0982d5088018189 EQUALVERIFY CHECKSIG
528 2012-10-30 22:34:07 <runeks> mind you, I'm "handcrafting" the hex transaction in Python...
529 2012-10-30 22:34:21 <sipa> first of all, is the pubkey correct?
530 2012-10-30 22:34:39 <sipa> if that were not the case, the equalverify will fail, and you'll never reach the checksig
531 2012-10-30 22:36:07 <runeks> I think I know what's happening. VerifySignature is failing at comparing txin.prevout.hash and txFrom.GetHash()
532 2012-10-30 22:36:32 <runeks> so it doesn't get to checking the signature
533 2012-10-30 22:51:01 <Luke-Jr> I don't suppose anyone thinks it'd be a good idea to show pdifficulty in bitcoind/getinfo or Bitcoin-Qt?
534 2012-10-30 22:53:03 <sipa> pdifficulty?
535 2012-10-30 22:54:34 <Luke-Jr> sipa: pool difficulty
536 2012-10-30 22:54:47 <Luke-Jr> ie, target measured by zero bits instead of the odd compressed version
537 2012-10-30 22:55:27 <sipa> meh, just divide by 1.000015
538 2012-10-30 22:56:25 <Luke-Jr> :P
539 2012-10-30 23:48:45 <runeks> OK. So I've modified key.cpp to print out debug information about the signature, hash and public key that goes into it. it returns 0 (bad signature). I've then taken the output it prints to debug.log and fed into the ecdsa_ssl python module from here: https://github.com/runeksvendsen/brutus
540 2012-10-30 23:49:10 <sipa> oops
541 2012-10-30 23:49:18 <runeks> it says the signature is good! I can't figure out why bitcoin-qt says the sig is bad and the Python script says it's good (the Python script uses OpenSSL as well)
542 2012-10-30 23:49:37 <runeks> these are then changes and the output: http://pastebin.com/jz54iJjM
543 2012-10-30 23:51:02 <sipa> can you copy paste the signature here?
544 2012-10-30 23:51:40 <runeks> 3046022100965dcef5b41c023d4b9558acd5a27ce8d61b02c2c5a82b94af5ebe1cb7dc5429022100f45ace1565098bb7a3360ef4c57b41af22babf14cae429e512c0cf965ab1007b
545 2012-10-30 23:54:32 <sipa> looks properly encoded
546 2012-10-30 23:55:18 <runeks> verify() from here says the signature is good too: https://github.com/runeksvendsen/brutus/blob/master/ecdsa_ssl.py#L78
547 2012-10-30 23:55:29 <runeks> ECDSA_verify in key.cpp says it's not
548 2012-10-30 23:55:38 <runeks> hash is 21e1b0cbef85ab6fea897385b61ed7033fd1f5b5b1394d654ac7a72bd304048a
549 2012-10-30 23:55:50 <runeks> public key is 0475724b51b6b73ac8c0182a60db23a7b2e59258099e195b0a6f2bb0324e0f1c6e2d46c3b0ed19fe38674c3f2165e28468ffa3fb90ee2b368826f11ae43c6e6413
550 2012-10-30 23:56:39 <runeks> could it be something related to byte order?
551 2012-10-30 23:59:31 <sipa> doubt that