1 2012-07-14 00:06:37 <copumpkin> when identifying a transaction by its hash
  2 2012-07-14 00:06:42 <copumpkin> what exactly goes into that?
  3 2012-07-14 00:06:54 <copumpkin> is it sha256twice of the entire structure?
  4 2012-07-14 00:07:11 <luke-jr> copumpkin: of the transaction data, yes
  5 2012-07-14 00:08:24 <lianj> i wonder why genjix leaked the source himself
  6 2012-07-14 00:08:31 <copumpkin> transaction data being which part of it? the entire thing, including version, the tx_in stuff, tx_out stuff, and the lock_time?
  7 2012-07-14 00:09:10 <lianj> copumpkin: yes, the whole payload
  8 2012-07-14 00:10:19 <copumpkin> hmm, my hash isn't matching the one on blockexplorer
  9 2012-07-14 00:10:24 <copumpkin> I must be hashing the wrong thing :)
 10 2012-07-14 00:10:58 <lianj> Digest::SHA256.digest(Digest::SHA256.digest( payload )).reverse.to_hex is what i have
 11 2012-07-14 00:11:14 <copumpkin> .reverse ?
 12 2012-07-14 00:11:30 <copumpkin> oh, mine is correct then
 13 2012-07-14 00:11:32 <copumpkin> just not reversed
 14 2012-07-14 00:11:42 <copumpkin> somehow I missed that detail :P
 15 2012-07-14 00:11:57 <lianj> hehe
 16 2012-07-14 00:12:27 <copumpkin> so that's performed on all double hashes?
 17 2012-07-14 00:12:48 <lianj> copumpkin: no
 18 2012-07-14 00:14:04 <luke-jr> copumpkin: Bitcoin is little-endian (in that respect)
 19 2012-07-14 00:14:08 <luke-jr> copumpkin: humans are big-endian
 20 2012-07-14 00:14:17 <copumpkin> well, hashes don't have an inherent endianness
 21 2012-07-14 00:14:23 <copumpkin> even if you treat them as numbers :P
 22 2012-07-14 00:14:37 <luke-jr> copumpkin: as soon as you treat them as numbers, they do
 23 2012-07-14 00:14:50 <luke-jr> copumpkin: also, SHA256 *does* have inherent endianness :p
 24 2012-07-14 00:15:06 <copumpkin> well, if you look at its implementation
 25 2012-07-14 00:15:10 <copumpkin> either way, I don't care
 26 2012-07-14 00:15:14 <copumpkin> just missed that part in the spec I guess
 27 2012-07-14 00:15:22 <copumpkin> as long as I can replicate dem hashes :)
 28 2012-07-14 00:37:32 <zooko> :-)
 29 2012-07-14 00:37:49 <zooko> I'm too sleepy for anything.
 30 2012-07-14 00:38:03 <zooko> Maybe I'll do some half-assed entertainment like playing Dungeon Crawl for a few minutes.
 31 2012-07-14 01:43:52 <copumpkin> do the hashes in Outpoint need reversing too?
 32 2012-07-14 01:45:41 <lianj> copumpkin: no
 33 2012-07-14 01:46:52 <copumpkin> ah, if I don't reverse the hash before saving it in my hashtable, everything works
 34 2012-07-14 01:46:57 <copumpkin> sweet
 35 2012-07-14 01:47:29 <copumpkin> I'm seeing a lot of outpoints with all-zero transaction references in them for my inputs
 36 2012-07-14 01:47:34 <copumpkin> what's the meaning of those?
 37 2012-07-14 01:52:03 <luke-jr> copumpkin: generation
 38 2012-07-14 01:52:18 <copumpkin> so that just means it's brand new coins from mining?
 39 2012-07-14 01:52:22 <luke-jr> the output index should be -1 too
 40 2012-07-14 01:52:24 <luke-jr> + fees
 41 2012-07-14 01:52:26 <copumpkin> yeah, it is
 42 2012-07-14 01:52:31 <copumpkin> alright :)
 43 2012-07-14 01:52:43 <copumpkin> thanks!
 44 2012-07-14 01:55:37 <copumpkin> wait, it can't be -1
 45 2012-07-14 01:55:39 <copumpkin> it's a uint
 46 2012-07-14 01:55:47 <copumpkin> but it would be -1 if it were signed
 47 2012-07-14 01:56:52 <luke-jr> :
 48 2012-07-14 01:59:17 <copumpkin> how common is it to have bad transaction references in inputs?
 49 2012-07-14 02:10:42 <amiller> whatcha workin on copumpkin
 50 2012-07-14 02:11:01 <copumpkin> making a minimal haskell bitcoin implementation that isn't as ambitious (at least for now) as roconnor's one
 51 2012-07-14 02:11:07 <copumpkin> but is a bit more modular
 52 2012-07-14 02:11:17 <copumpkin> I'm not aiming to make a program but rather a library that lets me throw together analysis tools easily
 53 2012-07-14 02:11:34 <copumpkin> it's also an excuse to learn the inner workings to possibly formalize parts of it in agda
 54 2012-07-14 02:16:55 <copumpkin> hmm, I must have a bug somewhere
 55 2012-07-14 02:21:25 <luke-jr> copumpkin: bad transaction references in inputs? huh?
 56 2012-07-14 02:21:36 <luke-jr> copumpkin: you realize there is already Purecoin in Haskell?
 57 2012-07-14 02:21:39 <copumpkin> yes
 58 2012-07-14 02:21:55 <copumpkin> [00:11:01] <copumpkin> making a minimal haskell bitcoin implementation that isn't as ambitious (at least for now) as roconnor's one
 59 2012-07-14 02:21:58 <copumpkin> :P
 60 2012-07-14 02:22:32 <copumpkin> luke-jr: I must have a bug somewhere in my transaction map
 61 2012-07-14 02:22:41 <copumpkin> or something about looking up past transactions, anyway
 62 2012-07-14 02:37:15 <copumpkin> oh, I think I'm pruning too eagerly
 63 2012-07-14 02:37:53 <copumpkin> oh, http://blockchain.info/address/12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S
 64 2012-07-14 02:38:06 <copumpkin> I thought people said I could prune old addresses as soon as they're used as inputs
 65 2012-07-14 02:38:13 <copumpkin> it looks like that thing sends coins back to itself as change
 66 2012-07-14 02:49:23 <gmaxwell> copumpkin: 'prune old addresses' ... serious misunderstanding detected.
 67 2012-07-14 02:49:48 <gmaxwell> copumpkin: you should be tracking txouts. not 'addresses'.
 68 2012-07-14 02:49:53 <copumpkin> yeah yeah :P
 69 2012-07-14 02:49:54 <copumpkin> misspoke
 70 2012-07-14 02:49:56 <copumpkin> I asked the other day whether I was going to have to be stateful and maintain all old transactions
 71 2012-07-14 02:50:01 <copumpkin> when resolving inputs
 72 2012-07-14 02:50:25 <copumpkin> someone mentioned that when I saw an old outpoint get used as an input, I could prune it
 73 2012-07-14 02:50:42 <luke-jr> copumpkin: that's not reorg-safe
 74 2012-07-14 02:50:58 <copumpkin> so I do have to keep the entire history?
 75 2012-07-14 02:51:04 <gmaxwell> No.
 76 2012-07-14 02:52:02 <gmaxwell> You can discard txouts as you use them, but you need to be able to undo that in order to reorg. So you need to at least keep undo information as far back as you'll plausably reorg.
 77 2012-07-14 02:52:27 <copumpkin> ah, makes sense
 78 2012-07-14 02:52:30 <luke-jr> can probably get by with 100 blocks of undo info imo
 79 2012-07-14 02:52:44 <copumpkin> hmm
 80 2012-07-14 02:52:52 <copumpkin> oh, so in the address I linked to above
 81 2012-07-14 02:53:10 <copumpkin> that's fine because in theory I'd kill it as soon as I saw it as an input before, but I'd put it back in as soon as I see it as an output again
 82 2012-07-14 02:53:19 <copumpkin> which it always is because of the change
 83 2012-07-14 02:53:21 <gmaxwell> copumpkin: er. Serious misunderstanding still detected.
 84 2012-07-14 02:53:46 <copumpkin> oh yeah
 85 2012-07-14 02:53:50 <copumpkin> not indexed by address
 86 2012-07-14 02:53:55 <copumpkin> but by txn hash and index
 87 2012-07-14 02:54:05 <gmaxwell> an address is not a txout. txouts are identified by the transaction id and index. You can't* duplicate a transaction id.  (subject to some idiocy)
 88 2012-07-14 02:54:52 <copumpkin> but my basic point is that what I'm seeing when parsing the blockchain I run into a case with http://blockchain.info/tx-index/186/591e91f809d716912ca1d4a9295e70c3e78bab077683f79350f101da64588073 (that carries that address) where a pruned outpoint gets reused
 89 2012-07-14 02:54:59 <gmaxwell> and you really shouldn't think in terms of addresses at all if you're writing a validation engine. Txns have script pubkeys and script sigs.  You might be able to map many of these to 'addresses' but some are freeform and you can't do so.
 90 2012-07-14 02:55:12 <copumpkin> yeah, I'm really just using that to map to something tangible
 91 2012-07-14 02:55:20 <copumpkin> I don't store addresses as "things" anywhere in the code
 92 2012-07-14 02:55:39 <gmaxwell> A pruned output can not be reused. Because you prune a txn id which cant* be duplicated.
 93 2012-07-14 02:55:54 <gmaxwell> (well txn id : index)
 94 2012-07-14 02:57:43 <gmaxwell> luke-jr: 100 blocks sounds a little risky to me, e.g. a long internet partitioning event outage might cause such a split. Alerts would be sent of course and people would freeze transactions. But the network would heal after... though not if nodes couldn't reorg. A few hundred would be a lot safer.
 95 2012-07-14 02:58:49 <luke-jr> gmaxwell: continuing from a >100 block reorg should require user intervention, and IMO rescanning the blockchain for the inputs you're missing is no big deal then
 96 2012-07-14 02:58:57 <luke-jr> heck, you can do it while waiting for the user to OK
 97 2012-07-14 02:59:26 <gmaxwell> luke-jr: 'rescanning' ? you've deleted the data.
 98 2012-07-14 02:59:33 <luke-jr> gmaxwell: just the index.
 99 2012-07-14 03:00:10 <gmaxwell> luke-jr: It's unlikely anyone would bother pruning in that way.
100 2012-07-14 03:00:22 <luke-jr> gmaxwell: isn't that what all the pruning branches thus far do? O.o
101 2012-07-14 03:00:58 <copumpkin> so how much state is reasonable to expect to need to maintain when traversing the blockchain if we want to be able fully verify it?
102 2012-07-14 03:01:02 <gmaxwell> No, thats not how ultraprune works. (well it currently doesn't delete the block files but they're not actually used for anything)
103 2012-07-14 03:01:39 <luke-jr> gmaxwell: they're there if it wanted to rescan :P
104 2012-07-14 03:01:42 <gmaxwell> copumpkin: right now it on the order of 80mb by the end of the chain.
105 2012-07-14 03:01:55 <copumpkin> ah, that's not so bad
106 2012-07-14 03:01:59 <gmaxwell> luke-jr: they're setup to be deleted, thats why they're written out to freestanding files.
107 2012-07-14 03:02:31 <gmaxwell> and you can't 'rescan' without starting from block 0.
108 2012-07-14 03:02:52 <gmaxwell> which might eventually take weeks of computation.
109 2012-07-14 03:03:12 <gmaxwell> It's just prudent to keep a bit more undo logs.
110 2012-07-14 03:06:11 <copumpkin> so, what I'm seeing is that transaction 591e91f809d716912ca1d4a9295e70c3e78bab077683f79350f101da64588073 is created, then I'm killing it when I see its only output used in transaction 12b5633bad1f9c167d523ad1aa1947b2732a865bf5414eab2f9e5ae5d5c191ba. Then I see 298ca2045d174f8a158961806ffc4ef96fad02d71a6b84d9fa0491813a776160 try to refer to it again
111 2012-07-14 03:06:22 <copumpkin> was that a reorg? I'm not handling that stuff yet
112 2012-07-14 03:06:25 <copumpkin> just doing a linear scan
113 2012-07-14 03:07:07 <gmaxwell> linear scan of what?
114 2012-07-14 03:07:26 <copumpkin> of the blockchain file that my bitcoin-qt is maintaining :)
115 2012-07-14 03:07:27 <gmaxwell> you should probaby start a new node in order to get a clean blocks file.
116 2012-07-14 03:07:45 <gmaxwell> because otherwise you're going to get corrupted all to hell with duplicate and conflicting txn.
117 2012-07-14 03:08:15 <copumpkin> fair enough
118 2012-07-14 03:08:31 <gmaxwell> hm both those txn are in the chain
119 2012-07-14 03:08:43 <gmaxwell> the first spends 591e91f809d716912ca1d4a9295e70c3e78bab077683f79350f101da64588073:1
120 2012-07-14 03:08:51 <gmaxwell> the second spends 591e91f809d716912ca1d4a9295e70c3e78bab077683f79350f101da64588073:0
121 2012-07-14 03:09:09 <gmaxwell> so your issue there is not tracking the indexes.
122 2012-07-14 03:09:31 <gmaxwell> Though your blocks file will have reorgs unless you just made it fresh and shut down before a reorg happened. :)
123 2012-07-14 03:09:43 <copumpkin> hmm, I should be tracking the indices
124 2012-07-14 03:09:49 <copumpkin> maybe it's an indication that I'm doing that wrong :)
125 2012-07-14 03:10:16 <gmaxwell> also you should run a bitcoind node with 0.7 (git master) because then you can run the gettransaction rpc to get nice parses of the transactions
126 2012-07-14 03:10:40 <copumpkin> I've been using blockexplorer's json thingy
127 2012-07-14 03:10:51 <copumpkin> gettransaction makes nicer ones?
128 2012-07-14 03:12:18 <gmaxwell> they're similar but block explorer is usually uselessly slow @#$@# for me.
129 2012-07-14 03:12:38 <copumpkin> also, in theory, for my particular application, I don't actually mind that I'm seeing discarded blocks as long as they're valid
130 2012-07-14 03:12:49 <copumpkin> but I should probably not consider them in most cases
131 2012-07-14 03:13:16 <gmaxwell> yea but they'll invalidate future ones
132 2012-07-14 03:13:47 <gmaxwell> if an orphan block consumes a bunch of txouts well then the real block that follows later is not going to validate for you
133 2012-07-14 03:14:01 <copumpkin> fair enough
134 2012-07-14 03:16:08 <copumpkin> hmm
135 2012-07-14 03:30:54 <copumpkin> gmaxwell: whoops, was pruning the entire transaction only if there were unpruned indices left in it, and was leaving the transaction if all indices had been prunced :P
136 2012-07-14 03:33:33 <copumpkin> hmm, next weirdness on 28204cad1d7fc1d199e8ef4fa22f182de6258a3eaafe1bbe56ebdcacd3069a5f
137 2012-07-14 03:34:05 <lianj> copumpkin: coinbase.com/network/.. has the same json output
138 2012-07-14 03:34:13 <copumpkin> cool!
139 2012-07-14 03:34:14 <copumpkin> thanks
140 2012-07-14 03:34:40 <copumpkin> very handy
141 2012-07-14 03:35:05 <lianj> binary too
142 2012-07-14 03:35:28 <lianj> aw, not yet
143 2012-07-14 03:37:13 <luke-jr> lianj: that your site?
144 2012-07-14 03:37:18 <lianj> no
145 2012-07-14 03:43:08 <cheako> https://en.bitcoin.it/wiki/Base58Check_encoding#Base58_symbol_chart I think the example code contradicts the explanation!  When you divide and append the remainder, you are taking the least significant portion and making it the most.
146 2012-07-14 03:44:01 <cheako> Does that sound correct?  If I have 123456789 and I divide that by 100, the remainder is 89 and if I append that then the 89 becomes the first part of my encoded string.
147 2012-07-14 03:44:48 <lianj> code_string[remainder]
148 2012-07-14 03:47:57 <lianj> cheako: http://pastebin.de/raw/?id=27942
149 2012-07-14 03:48:15 <copumpkin> lianj: so you have a pure ruby implementation of bitcoin?
150 2012-07-14 03:48:34 <lianj> yes
151 2012-07-14 03:48:41 <copumpkin> nice :)
152 2012-07-14 03:49:05 <lianj> was needed to understand it :D
153 2012-07-14 03:49:26 <cheako> Ahh, so the phsudo code is the part that is incorrect.  Prepend VS append.
154 2012-07-14 03:49:58 <cheako> I just can't seam to get it working in perl: http://paste.debian.net/179010/
155 2012-07-14 03:50:43 <lianj> cheako: dont forget the leading_zeros. it slapped me
156 2012-07-14 03:51:08 <cheako> Line 20.
157 2012-07-14 03:51:35 <lianj> ah ok ;)
158 2012-07-14 03:52:06 <lianj> you want to decode?
159 2012-07-14 03:52:28 <cheako> 23 scares me.  I fix up form the base58check to hex chars.
160 2012-07-14 03:52:40 <cheako> Yeah.
161 2012-07-14 03:52:52 <cheako> Well, the module should do both.
162 2012-07-14 03:57:08 <luke-jr> cheako: maybe check out mtve's bitcoin implementation in Perl?
163 2012-07-14 03:57:51 <cheako> ohh, yay.
164 2012-07-14 03:58:15 <luke-jr> http://gitorious.org/bitcoin/bitcoin-pl
165 2012-07-14 03:59:31 <lianj> shoudnt a perler say ohh, my yay?
166 2012-07-14 04:08:29 <lianj> https://github.com/bitcoin/bitcoin/blob/master/src/base58.h#L62 hehe oO
167 2012-07-14 04:14:39 <cheako> lianj: 1;
168 2012-07-14 06:19:01 <TD> BlueMatt: good question
169 2012-07-14 09:21:07 <gribble> New news from bitcoinrss: Diapolo opened pull request 1598 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1598>
170 2012-07-14 10:46:41 <jokc> 
171 2012-07-14 11:32:10 <tcatm> Does anyone have a halfnode patch that works with version checksumming?
172 2012-07-14 12:13:44 <darwin_> i
173 2012-07-14 12:13:46 <darwin_> hi
174 2012-07-14 12:14:02 <darwin_> i'm setting up a php application using the officil bitcoind server
175 2012-07-14 12:14:05 <darwin_> (on gentoo)
176 2012-07-14 12:14:13 <darwin_> but the server crash after a while
177 2012-07-14 12:14:30 <darwin_> here is debug.log http://sprunge.us/XdYZ
178 2012-07-14 12:15:51 <tcatm> doesn't look like a crash
179 2012-07-14 12:16:22 <darwin_> but the server stop responding to rpc request
180 2012-07-14 12:18:57 <darwin_> on the forum i've read something about that, but i haven't found any workaround
181 2012-07-14 12:21:25 <darwin_> i'll try to download the blockchain from a nother source
182 2012-07-14 12:53:21 <ersi> darwin_ should probably compile with -funroll-loops
183 2012-07-14 12:54:39 <tcatm> ?
184 2012-07-14 12:57:07 <ersi> I'm just a jokester.. http://funroll-loops.info/
185 2012-07-14 20:25:50 <cardpuncher> Anyone around that I can bother for like 5 minutes with a few translation related questions?
186 2012-07-14 20:38:48 <davout_> yo
187 2012-07-14 20:40:33 <cardpuncher> Hey davout_, so you consent to be a victim?
188 2012-07-14 20:47:37 <davout> you have 2.45 minutes left
189 2012-07-14 20:48:02 <davout> :)
190 2012-07-14 20:48:10 <cardpuncher> uh oh... thanks :)
191 2012-07-14 21:33:43 <BlueMatt> hmm...heres a fun protocol quirk, if a block is valid but doesnt connect properly/has too big a coinbase output/etc, it, and any blocks after it, will gladly be sent to any node which is either already on that fork, or asks for that block by hash
192 2012-07-14 21:33:56 <BlueMatt> s/is valid/is sane/
193 2012-07-14 21:40:09 <cardpuncher> Corrections for the French translation uploaded to Transifex, thanks a lot for your help davout.