1 2013-09-01 02:51:11 <jorash> Developing efficeint quantum simulation software so we can mine in sublinear time :D
  2 2013-09-01 02:51:55 <jorash> down with SHA hardness tyranny!!!!!
  3 2013-09-01 02:55:20 <jorash> (serious)
  4 2013-09-01 04:38:30 <maaku> you can't get the benefit of quantum hardware through simulation ...
  5 2013-09-01 04:42:22 <jgarzik> you get simulated benefit
  6 2013-09-01 04:42:27 <maaku> heh
  7 2013-09-01 05:06:28 <amiller> jorash, i can't figure out what it is you're recommending or interested in, every secure application in the world will require a secure hash function, interfering with bitcoin mining is the least of the threat of the quantum bogeyman
  8 2013-09-01 05:08:37 <amiller> maybe you're saying there's potentially a better way to specifically speedup bitcoin mining with quantum search, more specifically than just attacking all signatures/secure applications by finding collisions
  9 2013-09-01 06:48:40 <maaku> found a transaciton on testnet that has an invalid push opcode
 10 2013-09-01 06:48:48 <maaku> i'm assuming that I shouldn't be eagerly parsing scripts?
 11 2013-09-01 06:49:06 <gmaxwell> nope, you shouldn't be.
 12 2013-09-01 06:49:12 <gmaxwell> Also don't parse scriptpubkeys at all.
 13 2013-09-01 06:49:18 <gmaxwell> (except at spend time)
 14 2013-09-01 06:49:51 <gmaxwell> maaku: what block is it in?
 15 2013-09-01 06:50:02 <gmaxwell> (e.g. is it in the first 500? if not we may need to improve our test vectors some)
 16 2013-09-01 06:50:56 <maaku> yes it is
 17 2013-09-01 06:51:11 <maaku> block 452
 18 2013-09-01 06:51:30 <gmaxwell> okay, I think everything in the first 500 is in our other testvectors.
 19 2013-09-01 06:51:47 <maaku> ok
 20 2013-09-01 06:51:55 <maaku> this was my code crashing, not bitcoind
 21 2013-09-01 06:52:02 <gmaxwell> ::nods::
 22 2013-09-01 07:17:43 <d34th> i think i made an oopsie
 23 2013-09-01 07:17:51 <d34th> somehow bitcoin is using 6GB of ram
 24 2013-09-01 07:18:08 <gmaxwell> d34th: is it actually using 6GB of ram or is your virt just high?
 25 2013-09-01 07:18:33 <d34th> private is higher than virt
 26 2013-09-01 07:18:41 <d34th> **working set
 27 2013-09-01 07:19:22 <gmaxwell> What OS are you on?
 28 2013-09-01 07:19:30 <d34th> Win 7 64bit
 29 2013-09-01 07:20:12 <d34th> though im running a somewhat old version
 30 2013-09-01 07:20:17 <d34th> maybe i should update
 31 2013-09-01 07:20:21 <gmaxwell> what version?
 32 2013-09-01 07:20:30 <d34th> commit: c4316fefa5f56d62eeceb710ee18313bd9be1128
 33 2013-09-01 07:20:54 <gmaxwell> please don't make me play git sluth.
 34 2013-09-01 07:21:00 <gmaxwell> is that prior to 0.8.2?
 35 2013-09-01 07:21:03 <d34th> ~ july 29th
 36 2013-09-01 07:21:15 <d34th> no
 37 2013-09-01 07:21:18 <d34th> i have leveldb
 38 2013-09-01 07:21:33 <d34th> it was post 0.8.2
 39 2013-09-01 07:21:48 <gmaxwell> well 0.8.2 has nothing to do with leveldb. But okay.
 40 2013-09-01 07:22:00 <d34th> yea i know, leveldb was 0.8.0
 41 2013-09-01 07:22:32 <d34th> its during IBD if that matters
 42 2013-09-01 07:22:40 <d34th> which it probably does
 43 2013-09-01 07:26:31 <gmaxwell> d34th: shouldn't unless you've increased the dbcache.. but perhaps we have an interesting bug.
 44 2013-09-01 07:26:50 <d34th> well like i said, its a really old commit so maybe its patched
 45 2013-09-01 07:26:56 <d34th> i really should update
 46 2013-09-01 07:29:05 <sipa> 0.8.2 is from may 29th, 0.8.3 from june 25th
 47 2013-09-01 07:29:13 <sipa> there are no releases since then
 48 2013-09-01 07:34:09 <sipa> also... windows? our windows binaries are 32-bit, i don't see how they'd ever address more than 3 GiB
 49 2013-09-01 07:34:44 <d34th> ill restart, see if that helps
 50 2013-09-01 07:34:53 <d34th> it shouldnt
 51 2013-09-01 07:34:55 <d34th> but windows
 52 2013-09-01 07:36:38 <sipa> so what version are you running?
 53 2013-09-01 07:38:18 <sipa> oh, that's git head
 54 2013-09-01 07:38:43 <sipa> you compiled it yourself?
 55 2013-09-01 07:39:06 <sipa> it's about a month old
 56 2013-09-01 07:40:00 <sipa> how did you build it?
 57 2013-09-01 07:40:11 <d34th> yea
 58 2013-09-01 07:40:13 <d34th> but the restart fixed it
 59 2013-09-01 07:40:15 <d34th> i used bluematts builds on his jenkins
 60 2013-09-01 07:40:21 <sipa> ic
 61 2013-09-01 07:40:39 <d34th> windows didnt want to let go of the ram after i stopped bitcoin
 62 2013-09-01 07:40:45 <sipa> lol
 63 2013-09-01 07:40:53 <d34th> but now bitcoin is running just fine
 64 2013-09-01 07:41:29 <d34th> sometimes i swear windows needs  more black magic than linux
 65 2013-09-01 07:44:19 <sipa> somestimes?
 66 2013-09-01 10:21:03 <ahf> is there any documentations on the various CCoin* related types and what they optimize?
 67 2013-09-01 10:21:23 <phantomcircuit> ahf, i dont think there is any beyond the code
 68 2013-09-01 10:21:30 <phantomcircuit> which isn't that extensive really
 69 2013-09-01 10:22:39 <ahf> oki, will just go over the code then
 70 2013-09-01 10:23:28 <sipa> ahf: you can ask me :)
 71 2013-09-01 10:23:57 <ahf> sipa: will do. i will skim over the code for the next days and have a look at what is going on
 72 2013-09-01 10:24:23 <sipa> CCoins is a set of unspent outputs for a given transaction
 73 2013-09-01 10:24:24 <ahf> i am getting to the point now with my erlang project that i need to look at how i should do the various indexes
 74 2013-09-01 10:24:50 <sipa> CCoinsView is a (virtual) map of txid to CCoins
 75 2013-09-01 10:24:56 <sipa> with various implementations
 76 2013-09-01 10:25:04 <sipa> some in-memory only, some stored on disk
 77 2013-09-01 10:25:24 <sipa> and technically nothing relating to CCoins is an index
 78 2013-09-01 10:26:11 <sipa> there is a block index (mapping blockid's to disk positions) and optionally a transaction index (mapping txid's to disk position), but they are independent from the chainstate (=CCoinsView)
 79 2013-09-01 10:26:43 <ahf> ahhh, so there is a mapping from transaction id's to transactions in the block store?
 80 2013-09-01 10:26:53 <sipa> only if you enable it
 81 2013-09-01 10:27:04 <ahf> it's disabled by default?
 82 2013-09-01 10:27:05 <sipa> (-txindex=1, default off)
 83 2013-09-01 10:27:06 <sipa> yes
 84 2013-09-01 10:27:09 <ahf> oki.
 85 2013-09-01 10:27:12 <sipa> you don't need it for verification
 86 2013-09-01 10:27:18 <sipa> only for looking up historical transactions
 87 2013-09-01 10:27:22 <ahf> yup
 88 2013-09-01 10:27:38 <ahf> so you would need it if you run a service where you for some reason want to be able to map transaction id's to the actual transaction.
 89 2013-09-01 10:27:41 <ahf> i see.
 90 2013-09-01 10:27:53 <sipa> you shouldn't need that :p
 91 2013-09-01 10:27:59 <ahf> nope, i wont.
 92 2013-09-01 10:28:05 <sipa> but yes, many people implement things in a way that they do
 93 2013-09-01 10:28:09 <sipa> but it is very useful for debugging
 94 2013-09-01 10:28:16 <ahf> the only mapping i have implemented so far is block id -> block in a leveldb database
 95 2013-09-01 10:28:28 <sipa> you store the entire block in leveldb?
 96 2013-09-01 10:28:33 <sipa> or just the position on disk?
 97 2013-09-01 10:28:56 <ahf> worse than that. i store an erlang serialized block term in leveldb as the value
 98 2013-09-01 10:29:05 <sipa> ah :)
 99 2013-09-01 10:29:47 <ahf> so the satoshi client just stores the position on disk of the block as a value and have its own format for the actual blocks?
100 2013-09-01 10:30:05 <sipa> it saves the block in network format on disk
101 2013-09-01 10:30:23 <sipa> as it's immutable data, you don't need it in a high-performance database
102 2013-09-01 10:30:50 <ahf> makes sense, yeah
103 2013-09-01 10:30:54 <sipa> also, you only need blocks when reorganizing, rescanning, or serving to other nodes
104 2013-09-01 10:31:00 <sipa> for everything else, you just need the chainstate
105 2013-09-01 10:31:17 <sipa> (chainstate = set of unspent transaction output + current block id)
106 2013-09-01 10:31:24 <ahf> yeah, so in the end you end up using the chainstate for all your operationrs
107 2013-09-01 10:31:28 <ahf> cool
108 2013-09-01 10:31:50 <ahf> so chain state also contains information on the current block id and its height and such?
109 2013-09-01 10:31:50 <sipa> and/or the mempool, which implements sort of a "diff" on top of the chainstate
110 2013-09-01 10:31:59 <sipa> no, that's the block index
111 2013-09-01 10:32:15 <sipa> that's an in-memory tree structure with all known block headers
112 2013-09-01 10:32:26 <sipa> and some metadata like amount of work, height, number of transactions, ...
113 2013-09-01 10:32:43 <ahf> ah jep, there are multiple class implementations in the txdb.cpp file :o
114 2013-09-01 10:32:49 <ahf> too used to webkit where it's one class per file :o
115 2013-09-01 10:33:04 <sipa> please don't get a heart attack from main.cpp
116 2013-09-01 10:33:10 <ahf> already seen that :o
117 2013-09-01 10:33:24 <ahf> also all the extern's in the headers. took me some time to realize that was how things worked
118 2013-09-01 10:33:41 <phantomcircuit> "worked"
119 2013-09-01 10:33:46 <sipa> anyway, CBlockIndex impleents the block index
120 2013-09-01 10:33:49 <ahf> ok, cool, thanks a lot sipa - that will help me do my little baby
121 2013-09-01 10:33:59 <sipa> defined in main.h, there are some comments explaining it
122 2013-09-01 10:34:01 <ahf> hope to open source it on github as soon as i have this code ready
123 2013-09-01 10:34:05 <ahf> yup
124 2013-09-01 10:43:12 <gmaxwell> ahf: I hope you will not announce a public implementation as usable for other people until it at least passes the bitcoin blocktester tests.
125 2013-09-01 10:49:01 <ahf> gmaxwell: no, that is not open source because i am tired of all the announcement of clients that doesn't even do any kind of block validation or anything that even looks like it
126 2013-09-01 10:49:54 <ahf> gmaxwell: i have not heard of the blocktester tests though. care to elaborate on that?
127 2013-09-01 10:53:06 <gmaxwell> ahf: it's distributed with Bitcoinj, you run your node in regtest mode and it pretends to be a peer and simulates the network moving through all sorts of valid and invalid block sequences, forks and reorgs, etc. Obviously it cannot be exhaustive, but it tests a lot and embodies most of the community knoweldge about the fine boundary conditions of the distributed algorithims rules.
128 2013-09-01 10:53:26 <gmaxwell> (Obviously testing syncing the blockchain and testnet blockchain is insufficient: they only contain valid blocks)
129 2013-09-01 10:53:30 <ahf> oh, cool. i hadn't seen that. i will take a look at that.
130 2013-09-01 10:59:42 <Vinnie_win> sup fellas
131 2013-09-01 11:11:01 <ahf> gmaxwell: are there any other test suites that is publically available, then i would be very much interested in hearing about them :-)
132 2013-09-01 11:32:05 <gmaxwell> BlueMatt: Where is the pulltester?
133 2013-09-01 11:32:39 <sipa> say not that he has falled
134 2013-09-01 11:33:35 <phantomcircuit> rofl
135 2013-09-01 11:34:37 <phantomcircuit> sipa, is there a (good) reason for CWallet and CWalletDB being separate classes?
136 2013-09-01 11:35:26 <phantomcircuit> i guess theoretically it will be easier to change the disk format
137 2013-09-01 11:36:52 <sipa> they're interwoven in weird ways anyway
138 2013-09-01 11:37:04 <sipa> but they should be separate, imho
139 2013-09-01 11:37:27 <phantomcircuit> yeah looking at this all it seems like overall things are much weirder than they would be if just combined
140 2013-09-01 11:37:40 <sipa> though the whole cdb interface is weird; it should be a single object
141 2013-09-01 11:37:54 <phantomcircuit> sipa, i was thinking combine them and then separate them might be easier than trying to isolate them properly all in one go
142 2013-09-01 11:37:58 <phantomcircuit> which i know seems insane...
143 2013-09-01 11:38:00 <sipa> not a proxy that is recreated over and over again
144 2013-09-01 11:38:13 <sipa> meh, i'd only do that when dropping bdb
145 2013-09-01 11:39:16 <phantomcircuit> sipa, even after bdb is dropped some amount of backwards compatible upgrade mechanism will need to be there
146 2013-09-01 11:39:28 <gmaxwell> phantomcircuit: yes, an external BDB importer tool. :P
147 2013-09-01 11:39:28 <phantomcircuit> which will require a proper isolation of CWalletDB
148 2013-09-01 11:39:43 <gmaxwell> "get that crap out of our binary"
149 2013-09-01 11:39:45 <phantomcircuit> gmaxwell, there's just too many people with backups in bdb
150 2013-09-01 11:40:09 <phantomcircuit> the logic to convert from bdb -> something else would be 1000x simpler than actually using it
151 2013-09-01 11:40:12 <gmaxwell> phantomcircuit: yes? so?  you have a wallet.dat_to_wallet.new.exe
152 2013-09-01 11:40:17 <phantomcircuit> since you can dump all of the cache flushing stuff
153 2013-09-01 11:40:52 <phantomcircuit> i cant really tell, is any of the bdb transaction stuff being used by the wallet?
154 2013-09-01 11:41:02 <phantomcircuit> or is it really just being used as a key/value store
155 2013-09-01 11:41:09 <gmaxwell> Considering that compatiblity (and perhaps licensing, now) has stranded us on older bdb version that will eventually become hard to build, isolating it makes sense.
156 2013-09-01 11:42:06 <phantomcircuit> gmaxwell, if the CWalletDB interface was made into a proper interface i suspect you could build a read only implementation for bdb more or less just with the code in ReadKeyValue
157 2013-09-01 11:42:48 <phantomcircuit> which hilariously isn't even part of CWalletDB
158 2013-09-01 11:42:50 <phantomcircuit> :)
159 2013-09-01 11:43:12 <phantomcircuit> dat global function
160 2013-09-01 11:44:51 <phantomcircuit> but still i ask
161 2013-09-01 11:45:14 <phantomcircuit> is bdb being used purely as a key/value store without transactions
162 2013-09-01 11:45:20 <sipa> phantomcircuit: some things need to change if we go to an append-only format
163 2013-09-01 11:45:22 <phantomcircuit> or is the bdb transactions stuff being used at all
164 2013-09-01 11:45:26 <sipa> in the serialization
165 2013-09-01 11:45:33 <sipa> so in any case, you need a conversion tool
166 2013-09-01 11:45:35 <phantomcircuit> sipa, why?
167 2013-09-01 11:45:52 <sipa> vfSpent for example is continuously changed
168 2013-09-01 11:45:58 <sipa> and is part of CWalletTx objects
169 2013-09-01 11:46:08 <sipa> so that would mean N copies of every transaction
170 2013-09-01 11:46:12 <phantomcircuit> ah
171 2013-09-01 11:46:15 <phantomcircuit> yeah i see
172 2013-09-01 11:46:23 <sipa> which is quite ridiculous, as that can just be inferred from the other transactions
173 2013-09-01 11:46:45 <phantomcircuit> not to mention is kind of dangerous
174 2013-09-01 11:46:56 <sipa> and it's a good time to go over all deprecated stuff that nobody uses anymore and make things more sane
175 2013-09-01 11:47:13 <phantomcircuit> being 100% sure you update things like that in every case they could change is hard
176 2013-09-01 11:47:30 <sipa> so i'd vote for a conversion tool (initially, some standalone class in the bitcoin source code, and afterwards a separate binary)
177 2013-09-01 11:47:40 <sipa> rather than trying to make the old and new system expose a compatible API
178 2013-09-01 11:48:20 <phantomcircuit> sipa, i wasn't really thinking an API compatible with old code but rather with old wallets
179 2013-09-01 11:48:50 <phantomcircuit> which is especially easier if we're deprecating things like vfSpent instead of adding new fields
180 2013-09-01 11:49:05 <sipa> that's what i mean
181 2013-09-01 11:49:17 <phantomcircuit> k we're on the same page then
182 2013-09-01 11:49:42 <sipa> if we go to an append-only format, we have a chance to get a sane CWalletDB-like interface
183 2013-09-01 11:49:52 <sipa> that can replace the BDB one
184 2013-09-01 11:50:00 <sipa> but it'll have a very different interface than now
185 2013-09-01 11:50:19 <sipa> and i wouldn't bother trying to retrofit the BDB code into that new interface
186 2013-09-01 11:50:42 <sipa> as all you need is something that iterates of the database once, and converts entry per entry to the new format
187 2013-09-01 11:51:12 <phantomcircuit> that's reasonable
188 2013-09-01 11:51:44 <sipa> there's a huge amount of code for dealing with all kinds of BDB stuff that we don't use anymore
189 2013-09-01 11:51:58 <sipa> that can all go, if it's just iterating over a few fields
190 2013-09-01 11:52:18 <gmaxwell> heck, it can perhaps half look like a recovery tool, also sniffing through the file picking up any keys it can find. (it still has to recover the structured data, but if there are keys it should just take them)
191 2013-09-01 11:52:35 <phantomcircuit> sipa, it seems like a log format wallet could simply be keys and transactions without any metadata at all
192 2013-09-01 11:52:52 <sipa> phantomcircuit: there's more in wallets than that
193 2013-09-01 11:52:54 <sipa> like addresses
194 2013-09-01 11:53:03 <sipa> or the best block seen
195 2013-09-01 11:53:05 <ahmedbodi> hey guys
196 2013-09-01 11:53:16 <phantomcircuit> all of the metadata (except nTimeReceived) can be reconstructed when the wallet is loaded
197 2013-09-01 11:53:18 <sipa> and keypool entries
198 2013-09-01 11:53:32 <phantomcircuit> sipa, i was assuming keys/addresses could be linked in the record
199 2013-09-01 11:53:38 <gmaxwell> phantomcircuit: no it can't be. You going to "reconstruct" my comments?
200 2013-09-01 11:53:40 <sipa> addresses are not just your own
201 2013-09-01 11:53:48 <sipa> and indeed, comments
202 2013-09-01 11:53:57 <sipa> and with the payment protocol, saved acks
203 2013-09-01 11:54:11 <sipa> (not sure if we're actually storing them already, but we should)
204 2013-09-01 11:54:15 <ahmedbodi> is Luke-Jr here?
205 2013-09-01 11:54:18 <gmaxwell> Esp address lists with e.g. third party extended public keys and indexes...
206 2013-09-01 11:54:26 <phantomcircuit> gmaxwell, also fromaccount for the accounts things
207 2013-09-01 11:54:27 <phantomcircuit> hmm
208 2013-09-01 11:54:32 <sipa> and bip32 will only complicate things
209 2013-09-01 11:54:50 <phantomcircuit> sipa, i completely forget about the address book
210 2013-09-01 11:55:04 <phantomcircuit> that should probably be a separate database though
211 2013-09-01 11:55:10 <sipa> maybe
212 2013-09-01 11:55:21 <gmaxwell> sipa: I was only half hidding about cramming in a really basic determinstic key generation in the current structure, just to end the backup bleeding.
213 2013-09-01 11:55:41 <sipa> but comments, keypool stuff, from/to accounts, payment acks, ... belong in the wallet
214 2013-09-01 11:56:04 <sipa> and p2sh stuff
215 2013-09-01 11:56:05 <phantomcircuit> im not even sure where comments are being serialized
216 2013-09-01 11:56:11 <phantomcircuit> doesn't seem to be CWalletTx
217 2013-09-01 11:56:15 <sipa> it is
218 2013-09-01 11:56:21 <phantomcircuit> is it in mapValue?
219 2013-09-01 11:56:24 <sipa> there's a key-value map with extra stuff
220 2013-09-01 11:56:28 <sipa> yeah, i suppose
221 2013-09-01 11:57:24 <phantomcircuit> gmaxwell, tbh i still dont think stuff like that belongs in the same db as keys
222 2013-09-01 11:57:46 <phantomcircuit> it would be a real shame for a bug in comment/accounts handling to break importing someones private key
223 2013-09-01 11:58:12 <sipa> unsure
224 2013-09-01 11:58:15 <gmaxwell> phantomcircuit: break importing? hum?
225 2013-09-01 11:58:25 <gmaxwell> well if they're seperated you'll get users backing up the wrong one.
226 2013-09-01 11:58:32 <sipa> and inconsistencies
227 2013-09-01 11:58:42 <gmaxwell> yep... exposing awesome untestable software bugs.
228 2013-09-01 11:59:23 <phantomcircuit> i'd rather have comments very rarely disappear and simplify the keystorage
229 2013-09-01 11:59:34 <phantomcircuit> but that's possibly going over the top
230 2013-09-01 12:00:44 <sipa> i really like the idea of an append-only log-structured checksummed key-value store
231 2013-09-01 12:01:34 <gmaxwell> I do too. And it couples well with determinstic wallets as the encrypted master key can be up at the top and redundantly coded out the ying yang.. so that corruption is really unlikely to damage it.
232 2013-09-01 12:01:41 <phantomcircuit> sipa, one thing you need to decide on up front is whether you want to try and put keys into 512byte blocks
233 2013-09-01 12:01:41 <sipa> consisting of a bunch of blocks, each with a cryptographic checksum and a timestamp, containing a list update and erase records
234 2013-09-01 12:02:15 <phantomcircuit> since doing that and always writing to sector boundaries effectively guarantees an atomic write
235 2013-09-01 12:02:30 <phantomcircuit> where append -> flush can result in partial records
236 2013-09-01 12:02:33 <sipa> the nice thing with append-only records is that you never overwrite valid data
237 2013-09-01 12:02:49 <phantomcircuit> sipa, hehe theoretically :)
238 2013-09-01 12:02:56 <phantomcircuit> hdd manufacturers disagree
239 2013-09-01 12:03:07 <sipa> so even if your writes aren't sector-aligned, at worst you end up with some garbage at the end or a truncated last record
240 2013-09-01 12:03:09 <gmaxwell> Personally I'd rather make the master key span 256kbytes, so that even a flying erase block won't generally kill it. :P But I'm nuts.
241 2013-09-01 12:03:13 <ahmedbodi>  is anyone here good with eloipool setup's?
242 2013-09-01 12:03:37 <phantomcircuit> gmaxwell, that actually makes a lot of sense
243 2013-09-01 12:04:11 <phantomcircuit> write anything super important multiple times possibly over a period of time (so that file system fragmentation might place it in multiple places)
244 2013-09-01 12:04:30 <sipa> oh, write everything to wallet.dat and wallet.dat.bak :)
245 2013-09-01 12:04:36 <phantomcircuit> lol
246 2013-09-01 12:04:36 <sipa> with a sync in between
247 2013-09-01 12:04:43 <sipa> i'm not kidding
248 2013-09-01 12:04:55 <gmaxwell> I actually put erasure code support support for a master key in a wallet earlier today, though for a totally different reason.
249 2013-09-01 12:05:03 <phantomcircuit> for the record
250 2013-09-01 12:05:44 <phantomcircuit> the CLOB code i've been working on uses a journal with variable length entries not aligned to sectors and a buffered output stream object with occasional flushing
251 2013-09-01 12:06:02 <phantomcircuit> and even after running for several weeks straight i've not had any loss of data
252 2013-09-01 12:06:09 <phantomcircuit> or partial weird writes
253 2013-09-01 12:06:13 <gmaxwell> sipa: encode the master key with a rateless erasure code and write another word of it between every record. :P  "Just grab any 50kbytes of your wallet"
254 2013-09-01 12:06:17 <phantomcircuit> so i suspect that to be hilariously exceptionally rare
255 2013-09-01 12:09:24 <phantomcircuit> fromaccount/spent/n/timesmart (???)/version/comment/to are the values possibly encoded in mapValue
256 2013-09-01 12:09:34 <phantomcircuit> although it appears version never really is
257 2013-09-01 12:09:40 <sipa> what is 'n' ?
258 2013-09-01 12:10:07 <phantomcircuit> nOrderPos
259 2013-09-01 12:10:15 <phantomcircuit>     int64 nOrderPos;  // position in ordered transaction list
260 2013-09-01 12:10:32 <phantomcircuit> looks like it's for accounting entries?
261 2013-09-01 12:10:37 <phantomcircuit> maybe im confusing things
262 2013-09-01 12:10:54 <gmaxwell> it's from the smarttime stuff, it makes listtransaction's ordering determinstic.
263 2013-09-01 12:17:46 <sipa> BlueMatt: how does blocktester send/announce blocks, and how does it check when they're done processing?
264 2013-09-01 12:27:18 <ahmedbodi> anyone?
265 2013-09-01 12:27:44 <sipa> ahmedbodi: Luke-Jr
266 2013-09-01 12:28:27 <sipa> gmaxwell: that correlation between "the debian corruption" and parallel sigchecking is remarkable...
267 2013-09-01 12:28:28 <ahmedbodi> Luke-Jr: how could i solve a http 401 error on bitcoind? i've triple checked all my configs and they all seem okay
268 2013-09-01 12:29:21 <sipa> ahmedbodi: it means you didn't send username/password with the RPC
269 2013-09-01 12:29:32 <sipa> assuming it's bitcoind's RPC serving giving you that
270 2013-09-01 12:29:46 <ahmedbodi> sipa: i've set them in the eloipool config
271 2013-09-01 12:30:10 <sipa> i can't help you with eloipool
272 2013-09-01 12:31:17 <ahmedbodi> its okay no worries
273 2013-09-01 12:31:42 <ahmedbodi> i like eloipool but it can be a pain to configure in comparison to stratum+pushpool
274 2013-09-01 12:41:40 <_dr> is the previous tx reference in the input of a coinbase required to be 0?
275 2013-09-01 12:47:52 <phantomcircuit> sipa, gmaxwell https://github.com/pstratem/bitcoin/commit/5f59aa54752cec8117c55a019e0601e38099cfa3
276 2013-09-01 12:47:53 <_dr> the wiki says "the first input of the first transaction is also called "coinbase" (its content was ignored in earlier versions)", yet here i have the blockparser checking previous tx for zero to determine whether a coinbase or not. seems broken
277 2013-09-01 12:48:13 <phantomcircuit> so aside from the lack of code reuse that's eliminates vtxPrev
278 2013-09-01 12:50:19 <phantomcircuit> std::vector<uint256> ListUnconfirmedSupportingTransactions();
279 2013-09-01 12:50:20 <phantomcircuit> heh
280 2013-09-01 12:52:11 <sipa> _dr: a coinbase has zero as prevtx, and is the only input of the first transaction of a block
281 2013-09-01 12:52:21 <sipa> any other input cannot have zero as prevtx
282 2013-09-01 12:52:38 <sipa> so both are sufficient criteria
283 2013-09-01 13:00:26 <sipa> anyone has a (testnet) blocks directory with many reorganizations?
284 2013-09-01 13:02:35 <_dr> sipa: thanks. i was confused by the wiki saying "content was ignored in earlier versions"
285 2013-09-01 13:03:04 <sipa> _dr: the scriptsig content of coinbase transactions used to be ignored
286 2013-09-01 13:03:39 <_dr> makes sense
287 2013-09-01 13:06:23 <ahmedbodi> hey guys
288 2013-09-01 13:06:36 <ahmedbodi> no Luke-Jr yet
289 2013-09-01 13:06:43 <sipa> patience
290 2013-09-01 13:07:00 <sipa> also, he is not your personal helpdesk
291 2013-09-01 13:07:29 <ahmedbodi> yeah just a quick question, he might have replied during the few mins while i went offline cause my laptop battery died
292 2013-09-01 13:07:51 <ahmedbodi> better me finding out if i missed him than waiting for hours realising he already replied
293 2013-09-01 13:52:44 <Luke-Jr> ahmedbodi: it's a bug in jgarzik_'s python-bitcoinrpc that he's taking forever to fix; find an older version that works
294 2013-09-01 13:53:22 <ahmedbodi> i see, i think i've solved but i get 1 more error, its quite long so should i pm it instead?
295 2013-09-01 13:54:20 <ahmedbodi> Luke-Jr: its something to do with requests, perhaps block submissions?
296 2013-09-01 13:55:13 <Luke-Jr> ahmedbodi: it produces a malformed Authorization header
297 2013-09-01 13:55:32 <ahmedbodi> yeah it required me to change authproxy py by appending .decode()
298 2013-09-01 13:57:36 <ahmedbodi> pm'd you my last error
299 2013-09-01 13:57:47 <Luke-Jr> ahmedbodi: hmm, I don't think I've seen that one before
300 2013-09-01 13:58:07 <ahmedbodi> me neither, no sign of it on the web either
301 2013-09-01 14:08:33 <phantomcircuit> why are functions like bool CWalletTx::AcceptWalletTransaction() in main.cpp?
302 2013-09-01 14:09:55 <sipa> good question!
303 2013-09-01 14:10:18 <phantomcircuit> sipa, can i move them to wallet.cpp ?
304 2013-09-01 14:10:41 <phantomcircuit> i see no reason not to
305 2013-09-01 14:10:42 <sipa> i think with vtxPrev gone, you can just remove them
306 2013-09-01 14:11:11 <phantomcircuit> sipa, nope you still want to try and load chained unconfirmed transactions which are IsMine/IsFromMe
307 2013-09-01 14:11:26 <phantomcircuit> specifically if you spend an unconfirmed change output
308 2013-09-01 14:11:48 <phantomcircuit> otherwise they'll never get into the mempool properly
309 2013-09-01 14:11:49 <sipa> unconfirmed transaction which are IsMine/IsFromMe will be in the wallet
310 2013-09-01 14:12:09 <sipa> no?
311 2013-09-01 14:12:10 <phantomcircuit> sipa, yeah but the order in which they're loaded into the mempool matters
312 2013-09-01 14:12:20 <sipa> right
313 2013-09-01 14:12:23 <phantomcircuit> see https://github.com/bitcoin/bitcoin/pull/2966
314 2013-09-01 14:12:44 <sipa> just move it to wallet then, indeed
315 2013-09-01 14:13:19 <phantomcircuit> sipa, probably i need a new pull request for this?
316 2013-09-01 14:13:25 <phantomcircuit> (beyond just the one function)
317 2013-09-01 14:13:56 <sipa> a separate commit is good enough, i guess
318 2013-09-01 14:14:15 <phantomcircuit> 
ACTION changes pull request title to "fix all the wallet things"

319 2013-09-01 14:15:54 <phantomcircuit> done
320 2013-09-01 14:16:23 <phantomcircuit> i think that's all the itches i wanted to scratch
321 2013-09-01 15:01:59 <phantomcircuit> Luke-Jr, what sort of bitcoin mining power would you expect from an nvidia 780M
322 2013-09-01 15:04:11 <Graet> gtx? ~ 120mh https://en.bitcoin.it/wiki/Mining_hardware_comparison
323 2013-09-01 15:05:18 <phantomcircuit> Graet, iirc it has double the stream processors of a GTX680
324 2013-09-01 15:05:59 <phantomcircuit> this is some weirdness optimus graphics stack
325 2013-09-01 15:06:07 <phantomcircuit> i think im mining on the intel gpu
326 2013-09-01 15:06:13 <phantomcircuit> which is slower than a cpu core
327 2013-09-01 15:06:35 <Diablo-D3> ... but why are you mining at all
328 2013-09-01 15:07:38 <phantomcircuit> Diablo-D3, i accidentally the fee on testnet transactions and would prefer to not wait an eternity to cpu mine 1 block
329 2013-09-01 15:08:04 <Graet> ahh ~200-240then
330 2013-09-01 15:08:07 <phantomcircuit> 2013-09-01 14:54:32 ERROR: CTxMemPool::accept() : not enough fees 45ca0899594486a66ccf9b0565ea9cbce14032e88a264c918d2bd8eefaf33aca, 500000 < 1830000
331 2013-09-01 15:08:09 <phantomcircuit> SO CLOSE
332 2013-09-01 15:11:54 <phantomcircuit> yeah
333 2013-09-01 15:12:00 <phantomcircuit> 1340 khash/s
334 2013-09-01 15:12:34 <sipa> your cpu surely can do more
335 2013-09-01 15:12:41 <phantomcircuit> sipa, it can
336 2013-09-01 15:12:46 <phantomcircuit> nuisance
337 2013-09-01 15:23:32 <phantomcircuit> sipa, 31.2 mh/s in cpu mining powah
338 2013-09-01 15:23:46 <Diablo-D3> lol.
339 2013-09-01 15:24:03 <phantomcircuit> Diablo-D3, keep your panties on
340 2013-09-01 15:24:22 <Diablo-D3> bitch, please
341 2013-09-01 15:24:23 <phantomcircuit> testnet difficulty is currently 1
342 2013-09-01 15:24:28 <Diablo-D3> who says Im wearing clothes at all
343 2013-09-01 15:24:36 <phantomcircuit> so hopefully this doesn't take too long
344 2013-09-01 15:26:54 <sipa> phantomcircuit: 12 seconds :p
345 2013-09-01 15:27:09 <phantomcircuit> sipa, my luck isn't nearly that good
346 2013-09-01 15:29:12 <sipa> also, i think testnet doffoculty is much higher
347 2013-09-01 15:29:28 <sipa> but there's the 20-minutes difficulty-1 block rule
348 2013-09-01 15:29:45 <ahmedbodi> Luke-Jr: is there a sql structure for eloipool?
349 2013-09-01 15:37:04 <phantomcircuit> ahahaha
350 2013-09-01 15:37:10 <phantomcircuit> mined my ridiculous transactions
351 2013-09-01 15:37:11 <phantomcircuit> horray
352 2013-09-01 15:37:56 <phantomcircuit> wat
353 2013-09-01 15:38:01 <phantomcircuit> they're still in the mempool
354 2013-09-01 15:38:06 <phantomcircuit> even though i mined a block
355 2013-09-01 15:38:07 <phantomcircuit> >.>
356 2013-09-01 15:38:08 <phantomcircuit> <.<
357 2013-09-01 15:40:52 <sipa> haha
358 2013-09-01 15:41:27 <phantomcircuit> sipa, also there's more potential deadlocks with relaying transactions
359 2013-09-01 15:41:48 <phantomcircuit> http://pastebin.com/raw.php?i=KwGtPs7e
360 2013-09-01 15:42:02 <phantomcircuit> doesn't seem to actually deadlock though
361 2013-09-01 15:43:11 <phantomcircuit> sipa, yeah it's not including it's own transactions in the block
362 2013-09-01 15:43:17 <phantomcircuit> that's dumb especially for testnet
363 2013-09-01 15:46:20 <ahmedbodi> do any o u guys have an idea why eloipool gives me this error
364 2013-09-01 15:46:21 <ahmedbodi> unsupported operand type(s) for %: 'bytes' and 'tuple'
365 2013-09-01 15:48:03 <phantomcircuit> sipa, huh interesting, it appears that the CreateNewBlock code will refuse to put transaction dependent on each other into a block
366 2013-09-01 15:48:42 <phantomcircuit> 
ACTION patches CreateNewBlock to include the entire mempool

367 2013-09-01 15:50:37 <michagogo> In the past I've noticed chains of dependent transactions confirming 2 per block when mining against bitcoind
368 2013-09-01 15:50:45 <sipa> phantomcircuit: ??
369 2013-09-01 15:51:07 <sipa> it should definitely include dependencies when possible
370 2013-09-01 15:51:14 <phantomcircuit> sipa, something about porphan vOrphan or something is causing this to not mine them
371 2013-09-01 15:51:57 <sipa> did you have a fee?
372 2013-09-01 15:52:05 <phantomcircuit> yeah but not a very large one
373 2013-09-01 15:52:57 <sipa> hmm
374 2013-09-01 15:53:31 <phantomcircuit> sipa, let me throw a bunch of printfs in here....
375 2013-09-01 15:56:52 <phantomcircuit> nBlockSize + nTxSize >= nBlockMaxSize
376 2013-09-01 15:56:56 <phantomcircuit> thars yur problem
377 2013-09-01 15:58:46 <sipa> eh?
378 2013-09-01 15:59:20 <phantomcircuit> sipa, transactions are huge and going above max block size
379 2013-09-01 15:59:23 <phantomcircuit> forget about free space
380 2013-09-01 16:00:21 <michagogo> That doesn't sound like it would explain why, in a chain of testnet transactions that depended on each other, exactly 2 transactions were confirming each block
381 2013-09-01 16:00:34 <michagogo> (when mining with bfgminer against bitcoind)
382 2013-09-01 16:00:40 <phantomcircuit> there we go
383 2013-09-01 16:00:52 <phantomcircuit> michagogo, im guessing weirdness with specific rules
384 2013-09-01 16:01:13 <Luke-Jr> phantomcircuit: 0 Gh/s
385 2013-09-01 16:01:13 <michagogo_> brb
386 2013-09-01 16:01:13 <michagogo_> .....this again?
387 2013-09-01 16:01:13 <phantomcircuit> i literally just changed it to include everything in the mempool
388 2013-09-01 16:01:34 <phantomcircuit> Luke-Jr, im just trying to mine a testnet block with my insane transactions in it
389 2013-09-01 16:01:55 <Luke-Jr> phantomcircuit: ;)
390 2013-09-01 16:01:57 <phantomcircuit> someone should send me an asic so i can break things er... fix things faster
391 2013-09-01 16:02:21 <sipa> i can point 10 GH/s at you for a short term if needed :)
392 2013-09-01 16:02:49 <sipa> i'm sure other have more :p
393 2013-09-01 16:02:52 <sipa> others
394 2013-09-01 16:03:01 <phantomcircuit> this just went back to diff = 1
395 2013-09-01 16:03:06 <phantomcircuit> so maybe not necessary
396 2013-09-01 16:03:24 <gribble> 14.4
397 2013-09-01 16:03:24 <phantomcircuit> ;;calc 8*1.8
398 2013-09-01 16:03:29 <phantomcircuit> with my 14 mh/s
399 2013-09-01 16:04:55 <Luke-Jr> phantomcircuit: about 15 min then
400 2013-09-01 16:05:05 <Luke-Jr> assuming nobody else finds a blocok first
401 2013-09-01 16:05:42 <phantomcircuit> copying to a server as we speak
402 2013-09-01 16:05:42 <phantomcircuit> lol
403 2013-09-01 16:05:58 <michagogo_> I can give you blocks -- just pastebin (or PM if short enough) raw transactions
404 2013-09-01 16:06:15 <michagogo> (I have bitcoind in a VM with the clock 20 mins ahead)
405 2013-09-01 16:06:35 <phantomcircuit> need blocks that another peer will accept
406 2013-09-01 16:06:39 <michagogo> So?
407 2013-09-01 16:06:49 <michagogo> Blocks are valid up to 2 hours into the future
408 2013-09-01 16:07:00 <phantomcircuit> michagogo, the difficulty is still 1
409 2013-09-01 16:07:08 <michagogo> My setup works, it just doesn't work for >6 blocks in a row
410 2013-09-01 16:07:12 <phantomcircuit> no need for shenanigans
411 2013-09-01 16:07:18 <michagogo> phantomcircuit: Oh, really?
412 2013-09-01 16:07:31 <phantomcircuit> it was a second ago
413 2013-09-01 16:07:43 <phantomcircuit> maybe i broke something
414 2013-09-01 16:07:44 <michagogo> getblocktemplate
415 2013-09-01 16:07:45 <michagogo> Erm
416 2013-09-01 16:07:48 <michagogo> Wrong window,
417 2013-09-01 16:07:49 <phantomcircuit> but it would be exactly the same way
418 2013-09-01 16:07:51 <michagogo> window.*
419 2013-09-01 16:07:51 <phantomcircuit> so whatever
420 2013-09-01 16:07:58 <michagogo> No, difficulty isn't 0
421 2013-09-01 16:08:03 <michagogo> target is 0000000000a1e700000000000000000000000000000000000000000000000000
422 2013-09-01 16:08:21 <michagogo> The number that it displays as "difficulty" is actually the difficulty of the last mined block
423 2013-09-01 16:08:24 <phantomcircuit> michagogo, difficulty is 1
424 2013-09-01 16:08:28 <phantomcircuit> oh is it?
425 2013-09-01 16:08:30 <michagogo> It is.
426 2013-09-01 16:08:35 <michagogo> I learned that the hard wat
427 2013-09-01 16:08:37 <michagogo> way*
428 2013-09-01 16:09:17 <michagogo> If difficulty is 1, getblocktemplate returns a target of 00000000ffff0000000000000000000000000000000000000000000000000000
429 2013-09-01 16:09:45 <michagogo> phantomcircuit: If you give me the tx I can mine it for you
430 2013-09-01 16:10:47 <phantomcircuit> michagogo, im not even sure how to get them since getrawtransactions doesn't check the wallet lol
431 2013-09-01 16:11:05 <michagogo> "getrawtransactions doesn't check the wallet"?
432 2013-09-01 16:12:02 <sipa> it doesn't
433 2013-09-01 16:12:13 <sipa> but it does check the mempool
434 2013-09-01 16:12:20 <sipa> and unconfirmed wallet tramsactions should be in the mempool
435 2013-09-01 16:14:29 <michagogo> phantomcircuit: Does getrawtransaction not find it?
436 2013-09-01 16:16:18 <michagogo> (or, what's the txid? I may already have it)
437 2013-09-01 16:16:48 <sipa> unlikely to be relayed, i assume
438 2013-09-01 16:17:17 <phantomcircuit> comically unlikely
439 2013-09-01 16:17:28 <phantomcircuit> my 5 transactions combined are ~900KB
440 2013-09-01 16:17:47 <michagogo> Pastebin em?
441 2013-09-01 16:22:10 <sipa> how much do we expect the hashrate to go up in the next two weeks?
442 2013-09-01 16:22:22 <sipa> (need to adjust some graphs...)
443 2013-09-01 16:22:25 <phantomcircuit> http://pastebin.com/waZ4Fex6 http://pastebin.com/AqRHqdSC http://pastebin.com/3cjTgCdh http://pastebin.com/Y4DUgqqh http://pastebin.com/sPZEGNR3
444 2013-09-01 16:22:46 <phantomcircuit> sipa, can you really point some ridiculous amount of hash power at this server for a minute
445 2013-09-01 16:23:57 <gatz> y0
446 2013-09-01 16:24:00 <gatz> who owns gribble?
447 2013-09-01 16:24:26 <gatz> I just want him at one channel
448 2013-09-01 16:24:28 <michagogo> I'll start my miner
449 2013-09-01 16:24:41 <michagogo> 
ACTION waits for the paste to finish

450 2013-09-01 16:25:13 <phantomcircuit> michagogo, you didn't try to paste that into a bash session did you?
451 2013-09-01 16:25:31 <michagogo> I am.
452 2013-09-01 16:25:31 <phantomcircuit> there's some horrible performance there for very long words
453 2013-09-01 16:25:37 <michagogo> The text is still scrolling by
454 2013-09-01 16:25:53 <TheLordOfTime> gatz:  nanotube owns gribble.  i'm not sure how freely he has gribble join channels
455 2013-09-01 16:26:20 <michagogo> phantomcircuit: It's coming it at about 2 lines per second
456 2013-09-01 16:27:15 <gatz> TheLordOfTime: he also owns this bitcoin one? Yes runs one for sourceforge o_O
457 2013-09-01 16:27:42 <TheLordOfTime> gatz:  your question makes no sense... or maybe i need coffee...
458 2013-09-01 16:27:50 <TheLordOfTime> gatz:  you are asking about gribble the bot which is opped here right?
459 2013-09-01 16:27:51 <michagogo> Hmm
460 2013-09-01 16:28:01 <gatz> TheLordOfTime: yes.
461 2013-09-01 16:28:08 <michagogo> Pasting into the bitcoin-qt console after decoderawtransaction returns this:
462 2013-09-01 16:28:08 <michagogo> TX decode failed (code -22)
463 2013-09-01 16:28:11 <phantomcircuit> michagogo, forget about it
464 2013-09-01 16:28:17 <gatz> there is also gribble for sourceforge things, non-bitcoin one o_O
465 2013-09-01 16:28:27 <phantomcircuit> sipa pointed some massive amount of hashing power at it for me
466 2013-09-01 16:28:30 <michagogo> Ah
467 2013-09-01 16:28:39 <sipa> "massive"
468 2013-09-01 16:29:10 <michagogo> 
ACTION just heard a new block come in

469 2013-09-01 16:29:10 <sipa> i mean, ArtForz had more than this 2 years ago :p
470 2013-09-01 16:29:12 <TheLordOfTime> gatz:  gribble is a fork of supybot, the bitcoin commands and plugins are extra plugins he wrote.  At least, as far as I understand all this, it's a fork of supybot.  I could check on that but no idea when nanotube will wake up
471 2013-09-01 16:29:33 <gatz> TheLordOfTime: yes, thanks, I have this already http://sourceforge.net/apps/mediawiki/gribble/index.php?title=Main_Page
472 2013-09-01 16:29:34 <TheLordOfTime> gatz:  if you just want the gribble bot that is here to join wait for nanotube, if you just want a similar bot iwthout bitcoin functions anyone can spin up a supybot or a supybot fork.
473 2013-09-01 16:29:36 <gatz> :)
474 2013-09-01 16:29:40 <gatz> I just queried him
475 2013-09-01 16:29:51 <gatz> thanks! :)
476 2013-09-01 16:31:04 <michagogo_> ...wth
477 2013-09-01 16:31:12 <michagogo_> I thought I fixed that
478 2013-09-01 16:31:13 <Graet> gatz #gribble
479 2013-09-01 16:33:39 <TheLordOfTime> Graet:  too slow :P
480 2013-09-01 16:33:42 <TheLordOfTime> * gatz (wao@v6.syx.sk) has left #bitcoin-dev
481 2013-09-01 16:35:09 <Graet> oh well
482 2013-09-01 16:43:18 <michagogo> ?
483 2013-09-01 16:43:18 <michagogo> 
ACTION removes the torrent

484 2013-09-01 16:43:18 <michagogo> ...why am I uploading 145 KB/s of the 4.52GB bootstrap.dat to a polish peer
485 2013-09-01 16:44:26 <phantomcircuit> michagogo, if you're careful you can construct bittorrent's which use the same files such that you can serve people looking at older torrents using the same files as newer ones
486 2013-09-01 16:44:47 <michagogo> phantomcircuit: But we don't want people to be downloading and seeding the old one
487 2013-09-01 16:45:18 <phantomcircuit> michagogo, if it was multiple files you would
488 2013-09-01 16:45:18 <phantomcircuit> since that would be better than nothing
489 2013-09-01 16:45:18 <sipa> it's a single file
490 2013-09-01 16:45:27 <sipa> and if you downloaded an earlier one, it gets reused for the new one
491 2013-09-01 16:45:36 <sipa> so you only download the extra part
492 2013-09-01 16:47:00 <phantomcircuit> im thinking it's ListUnconfirmedSupportingTransactions with my insane 1000 input/1000 output transactions
493 2013-09-01 16:47:00 <phantomcircuit> sipa, lol this is problematic
494 2013-09-01 16:47:00 <phantomcircuit> std::bad_alloc
495 2013-09-01 16:47:00 <sipa> you're out of memory...
496 2013-09-01 16:47:06 <phantomcircuit> which are all linked to each other
497 2013-09-01 16:47:20 <phantomcircuit> and then using an std::vector
498 2013-09-01 16:47:34 <phantomcircuit> where it's trying to allocate/release huge blocks of contiguous memory
499 2013-09-01 16:52:24 <phantomcircuit> huh
500 2013-09-01 16:54:50 <phantomcircuit> derp
501 2013-09-01 16:54:50 <phantomcircuit> lol
502 2013-09-01 16:54:50 <phantomcircuit> printf("reverse %s\n", vWorkQueue.size());
503 2013-09-01 16:54:50 <weex> deos anyone know how to turn a ScriptPubKey like this 76a91433bd7500f8e1e91c69f5bc5a978296012d53bd1888ac into an address?
504 2013-09-01 16:55:01 <sipa> pattern match :)
505 2013-09-01 16:55:38 <weex> i think the first 6 and last 4 chars should be discarded
506 2013-09-01 16:55:57 <weex> to match the length of what i see on blockchain.info
507 2013-09-01 16:57:00 <sipa> it decodes to: OP_DUP OP_HASH160 0x33bd7500f8e1e91c69f5bc5a978296012d53bd18 OP_EQUALVERIFY OP_CHECKSIG
508 2013-09-01 16:57:11 <sipa> so it's a boring send-to-pubkey-hash transaction
509 2013-09-01 16:58:00 <weex> so it's the 0x33... bit i'm having a hard time turning into an address
510 2013-09-01 16:58:10 <sipa> put a 0x01 in front
511 2013-09-01 16:58:22 <sipa> append the checksum
512 2013-09-01 16:58:22 <sipa> convert to base58
513 2013-09-01 16:58:25 <sipa> sorry, a 0x00 in front
514 2013-09-01 16:58:29 <weex> oh ok
515 2013-09-01 16:58:31 <weex> great!
516 2013-09-01 16:58:35 <michagogo> (https://en.bitcoin.it/wiki/Base58Check_encoding)
517 2013-09-01 16:59:43 <weex> was trying to use base58_check_encode from http://github.com/weex/addrgen but i think nothing in there does exactly those things
518 2013-09-01 17:47:18 <michagogo> What's the timing usually like in terms of time from rc until release, assuming no changes?
519 2013-09-01 17:49:10 <Luke-Jr> usually faster than this
520 2013-09-01 17:50:35 <michagogo> Ah, just thought of something
521 2013-09-01 17:50:41 <michagogo> 
ACTION checks the tags list

522 2013-09-01 17:50:57 <michagogo> So 0.8.2 was 5 days
523 2013-09-01 17:51:10 <michagogo> 0.8.0 was 12
524 2013-09-01 17:51:31 <michagogo> 0.7.2 was ~14
525 2013-09-01 17:51:45 <michagogo> 0.7.1 was 8
526 2013-09-01 17:52:01 <michagogo> 0.7.0 was 5
527 2013-09-01 17:52:39 <michagogo> So far it's been 12
528 2013-09-01 17:54:37 <Luke-Jr> michagogo: nobody appreciates rushing ;)
529 2013-09-01 17:54:39 <Luke-Jr> it happens when it happenjs
530 2013-09-01 17:54:48 <michagogo> 
ACTION isn't rushing

531 2013-09-01 17:55:06 <michagogo> I was just wondering how this compares with past releases.
532 2013-09-01 18:12:55 <sipa> 
ACTION updates bitcoin.sipa.be to use 'Thash/s' instead of 'Ghash/s'

533 2013-09-01 18:57:50 <ahmedbodi> !seen Luke-Jr
534 2013-09-01 18:57:50 <gribble> Luke-Jr was last seen in #bitcoin-dev 1 hour, 3 minutes, and 11 seconds ago: <Luke-Jr> it happens when it happenjs
535 2013-09-01 20:29:04 <numismatics> is there an easy way to execute OP_CHECKSIG?
536 2013-09-01 20:29:35 <lianj> what do you mean by easy?
537 2013-09-01 20:29:40 <warren> anyone know off hand what version of gcc is in gitian?
538 2013-09-01 20:31:51 <numismatics> hah
539 2013-09-01 20:32:09 <numismatics> i'm compiling libbitcoin now
540 2013-09-01 20:32:32 <numismatics> so, anything short of writing my own program
541 2013-09-01 20:37:07 <sipa> warren: 4.4 afaik
542 2013-09-01 20:41:36 <numismatics> a script would be ideal
543 2013-09-01 20:46:55 <ahmedbodi> hey guys do could any of u give me some advice on eloipool
544 2013-09-01 21:22:49 <warren> ooh, headers-first
545 2013-09-01 21:23:02 <ahmedbodi> #!/bin/bash
546 2013-09-01 21:23:04 <ahmedbodi> cd "$(dirname ${BASH_SOURCE[0]})"
547 2013-09-01 21:23:05 <ahmedbodi> DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
548 2013-09-01 21:23:07 <ahmedbodi> killall eloipool.py > /dev/null
549 2013-09-01 21:23:08 <ahmedbodi> wait
550 2013-09-01 21:23:10 <ahmedbodi> PYTHONPATH=$PYTHONPATH:$DIR/../python-bitcoinrpc/jsonrpc:$DIR/../python-bitcoinrpc/bitcoinrpc:$DIR/../python-base58:$DIR/../$
551 2013-09-01 21:23:11 <ahmedbodi> python3 ../eloipool/eloipool.py ##for debuggin
552 2013-09-01 21:23:13 <ahmedbodi> whoops sorry about that
553 2013-09-01 21:41:19 <gmaxwell> I think we may need to consider backing out the fork warning code: https://bitcointalk.org/index.php?topic=286013.msg3055928;boardseen#new
554 2013-09-01 21:41:33 <gmaxwell> I keep seeing it trigger for people when they're having local problems and there is no fork.
555 2013-09-01 21:41:37 <gmaxwell> It's crying wolf.
556 2013-09-01 22:04:57 <gmaxwell> sipa: edam reports reliable failure with parallel checking, reliable success with par.
557 2013-09-01 22:07:16 <gmaxwell> BlueMatt: hm, this pulltester failure appears to have nothing to do with the commit: https://github.com/bitcoin/bitcoin/pull/2945#issuecomment-23628298
558 2013-09-01 22:28:53 <phantomcircuit> <gmaxwell> sipa: edam reports reliable failure with parallel checking, reliable success with par.
559 2013-09-01 22:28:55 <phantomcircuit> wat
560 2013-09-01 22:36:52 <phantomcircuit> gmaxwell, where is min() normally defined?
561 2013-09-01 22:37:45 <phantomcircuit> gmaxwell, iirc that should be std::min()