1 2013-07-20 00:00:01 <Diablo-D3> what it DOES do
  2 2013-07-20 00:00:15 <Diablo-D3> is use a COMPATIBLE hardware protocol and nearly identical PHYs
  3 2013-07-20 00:00:28 <Diablo-D3> SAS controllers can speak SATA because of the shared physical interface and PHYs
  4 2013-07-20 00:00:31 <kuzetsa> Diablo-D3: not sure if jgarzik is the same person I'm thinking of (had something to do with libata dev and/or maintaining at some point)
  5 2013-07-20 00:00:37 <Diablo-D3> SATA cant speak SAS, however
  6 2013-07-20 00:01:06 <kuzetsa> right. because SAS is "more properly SCSI" from a protocol standpoint
  7 2013-07-20 00:01:17 <Diablo-D3> yes, its SCSI over serial
  8 2013-07-20 00:01:24 <kuzetsa> 
ACTION nods

  9 2013-07-20 00:01:30 <Diablo-D3> btw, it gets even more fun
 10 2013-07-20 00:01:39 <Diablo-D3> ATAPI is basically raw scsi commands over IDE
 11 2013-07-20 00:01:47 <kuzetsa> haha I know
 12 2013-07-20 00:01:51 <Diablo-D3> its used for optical drives
 13 2013-07-20 00:01:54 <kuzetsa> yeah
 14 2013-07-20 00:01:59 <Diablo-D3> well, was, SATA has all that shit as part of the protocol now
 15 2013-07-20 00:02:11 <kuzetsa> :/
 16 2013-07-20 00:02:19 <Diablo-D3> and it matches the equivalent SAS commands, so plugging a SATA dvd drive into a SAS controllerworks
 17 2013-07-20 00:02:36 <kuzetsa> wow
 18 2013-07-20 00:02:50 <Diablo-D3> Im not sure why they bothered going ahead with SATA to be honest
 19 2013-07-20 00:02:53 <kuzetsa> that's intense
 20 2013-07-20 00:03:25 <Diablo-D3> they should have just went with SAS on both market segments and then added a SAS enterprise feature that does all the shit you actually need SAS for
 21 2013-07-20 00:03:43 <Diablo-D3> like multiplexing, multiple interfaces to a single drive, etc
 22 2013-07-20 00:03:43 <kuzetsa> :)
 23 2013-07-20 00:04:09 <kuzetsa> sorry I asked in here
 24 2013-07-20 00:04:16 <Diablo-D3> well, it answered your question
 25 2013-07-20 00:04:17 <kuzetsa> it's not on topic for #bitcoin-dev
 26 2013-07-20 00:04:19 <kuzetsa> yeah
 27 2013-07-20 00:06:38 <kuzetsa> http://www.gentoo.org/doc/en/kernel-config.xml <--- really doesn't help that they're perpetuating the confusion: (quote) (section 3.) Common problems and areas of confusion (subheading) "SATA disks are SCSI"
 28 2013-07-20 00:07:03 <kuzetsa> "code-reuse kludge in the old API / syscall / linux driver subsystems"
 29 2013-07-20 00:07:05 <kuzetsa> not the same thing lol
 30 2013-07-20 00:07:11 <Diablo-D3> kuzetsa: well in linux
 31 2013-07-20 00:07:14 <kuzetsa> haha
 32 2013-07-20 00:07:15 <Diablo-D3> its all the same subsystem now
 33 2013-07-20 00:07:17 <Diablo-D3> even for ide
 34 2013-07-20 00:07:21 <kuzetsa> oh, right.
 35 2013-07-20 00:07:25 <kuzetsa> crap. it is.
 36 2013-07-20 00:07:27 <Diablo-D3> its why parallel ide drives are /dev/sdx
 37 2013-07-20 00:08:15 <kuzetsa> yeah
 38 2013-07-20 00:08:50 <Diablo-D3> its easier to treat IDE drives as just a SCSI variant, especially given how many SCSI commands are used
 39 2013-07-20 00:09:14 <kuzetsa> you mean IDE optical drives?
 40 2013-07-20 00:09:22 <Diablo-D3> no even non-optical ones
 41 2013-07-20 00:09:26 <kuzetsa> I wasn't aware PATA hard disks... really?
 42 2013-07-20 00:09:29 <kuzetsa> well that's new
 43 2013-07-20 00:09:37 <kuzetsa> I haven't used one in years so I didn't know.
 44 2013-07-20 00:10:03 <Diablo-D3> a lot of stuff related to smart and other drive inquiries use the raw scsi command set
 45 2013-07-20 00:10:21 <kuzetsa> oh
 46 2013-07-20 00:10:32 <Diablo-D3> and stuff like command queueing and DMA isnt well suited to pre-ATA IDE
 47 2013-07-20 00:10:33 <kuzetsa> well I feel like a dumbass for never having been curious about how SMART works
 48 2013-07-20 00:11:18 <Diablo-D3> basically, ATA tries to normalize the protocol on IDE to be more like SCSI without being incompatible with older IDE
 49 2013-07-20 00:11:35 <Diablo-D3> its quite entirely possible you've never owned a pre-ATA IDE drive
 50 2013-07-20 00:11:55 <Diablo-D3> and IDE itself is fucking wonky
 51 2013-07-20 00:11:57 <kuzetsa> in the 90s I had an 80 gig hard disk
 52 2013-07-20 00:12:04 <Diablo-D3> its basically an 8 bit ISA bus
 53 2013-07-20 00:12:11 <kuzetsa> I don't have it anymore, it's long-since dead
 54 2013-07-20 00:12:35 <Diablo-D3> and you'd buy drives that plug into a HBA dedicated to that drive that plugs into the 8 bit ISA bus with an actual card
 55 2013-07-20 00:12:57 <Diablo-D3> then they minaturized the card and slapped it on a full height 5.25" drive, which is why all drive controllers are on the drive itself now
 56 2013-07-20 00:12:58 <kuzetsa> I think I donated / recycled it to an educational workshop for people wanting to learn how to work on computers without a budget for risking damage to brand-new hardware
 57 2013-07-20 00:13:16 <Diablo-D3> and then they used a modified 8 bit ISA bus and a high level protocol on top of it to communicate
 58 2013-07-20 00:13:37 <kuzetsa> 
ACTION jaw-drops

 59 2013-07-20 00:13:39 <Diablo-D3> that protocol was eventually standardized as IDE
 60 2013-07-20 00:14:03 <Diablo-D3> which gets really weird when you realize how this relates to PCMCIA
 61 2013-07-20 00:14:22 <Diablo-D3> and how PCMICA isnt actually a 16 bit ISA bus, but actually a modified form of IDE that still can speak ISA
 62 2013-07-20 00:14:53 <Diablo-D3> ergo, plugging stuff in like a CompactFlash -> PCMCIA bridge in basically converts pins and power, but nothing else
 63 2013-07-20 00:15:11 <kuzetsa> I haven't messed with low-level hard disk stuff since that one time I wrote a bit of boot sector code on a floppy to poke around with "INT 0x13" for totally legit purposes back in the late 90s
 64 2013-07-20 00:15:25 <Diablo-D3> oh and heres the other fun part
 65 2013-07-20 00:15:28 <kuzetsa> totally legit
 66 2013-07-20 00:15:32 <kuzetsa> I swear >.<
 67 2013-07-20 00:15:34 <Diablo-D3> CompactFlash is IDE in a non-compatible form factor
 68 2013-07-20 00:15:41 <kuzetsa> I know
 69 2013-07-20 00:15:43 <Diablo-D3> you can plug it right into IDE with a dummy plug
 70 2013-07-20 00:15:45 <kuzetsa> PIO mode if I remember right
 71 2013-07-20 00:15:53 <Diablo-D3> they have UDMA ones too
 72 2013-07-20 00:15:59 <kuzetsa> really? that's new...
 73 2013-07-20 00:16:06 <Diablo-D3> yeah, in the past 2-3 years
 74 2013-07-20 00:16:08 <kuzetsa> ah
 75 2013-07-20 00:16:15 <Diablo-D3> they also have ones that speak a modified version of SATA using the same form factor
 76 2013-07-20 00:16:24 <gmaxwell> kuzetsa: comes with the fact that there are 20 mpixel 35mm cameras with CF... you can get 128gb cf cards now.
 77 2013-07-20 00:16:29 <Diablo-D3> takes a little bit more effort to plug those into SATA, and the cards wont speak original CF
 78 2013-07-20 00:16:36 <Diablo-D3> so you need a camera/card reader that has support for those
 79 2013-07-20 00:16:51 <Diablo-D3> gmaxwell: Ive seen 256gb ones for sale
 80 2013-07-20 00:17:05 <Diablo-D3> or at least announced, maybe not for sale yet
 81 2013-07-20 00:17:22 <Diablo-D3> problem is, you need a camera that uses a file system that can use that much
 82 2013-07-20 00:17:30 <kuzetsa> gmaxwell: oh... I see... I thought compactflash was dead / useles so I upgraded to an EOS 60D running SD card instead of trying to keep using my old digital rebel xt (which used compact flash)
 83 2013-07-20 00:17:46 <kuzetsa> like... I didn't think compact flash was gonna break the 2GB barrier at that time
 84 2013-07-20 00:18:08 <Diablo-D3> kuzetsa: see thats the weird part
 85 2013-07-20 00:18:14 <Diablo-D3> CF is still used by EOS high end models
 86 2013-07-20 00:18:16 <kuzetsa> and the 60D was nicer & used the same EOS-style lenses (those thinks are bloody expensive. like hundreds of dollars each)
 87 2013-07-20 00:18:22 <Diablo-D3> and my EOS is low end but still uses CF
 88 2013-07-20 00:18:32 <Diablo-D3> they arent THAT expensive
 89 2013-07-20 00:18:43 <Diablo-D3> I mean, L series ones are massively expensive
 90 2013-07-20 00:18:50 <Diablo-D3> but try buying sigma if you cant afford canon
 91 2013-07-20 00:19:42 <Diablo-D3> sigma EOS lenses are quite nice
 92 2013-07-20 00:19:50 <Diablo-D3> like 3/4th the visual quality for 2/3rds the price
 93 2013-07-20 00:20:13 <kuzetsa> guess we're done talking about SCSI now at least
 94 2013-07-20 00:20:20 <Diablo-D3> I guess =P
 95 2013-07-20 00:20:44 <kuzetsa> Diablo-D3: privmsg?
 96 2013-07-20 00:20:51 <Diablo-D3> go ahead
 97 2013-07-20 00:21:15 <Diablo-D3> btw, you MAY look into discontinued lenses on ebay
 98 2013-07-20 00:21:22 <Diablo-D3> EOS has been in use since the early 70s
 99 2013-07-20 00:21:46 <Diablo-D3> theres a few classics that are still pretty good quality
100 2013-07-20 00:35:16 <ahmed_mobile1> hey guys would any of you be able to help me out
101 2013-07-20 00:35:30 <ahmed_mobile1> im trying to create a fork of bitcoin
102 2013-07-20 00:35:35 <ahmed_mobile1> using the mergecoin git
103 2013-07-20 00:35:44 <ahmed_mobile1> and i get this error?
104 2013-07-20 00:36:12 <ahmed_mobile1> http://pastebin.com/7NXkB5RQ
105 2013-07-20 00:39:54 <gwillen> ahmed_mobile1: are you just building something exactly as you downloaded it? It seems like you have incompatible versions of something.
106 2013-07-20 00:40:04 <gwillen> (I am not familiar with mergecoin.)
107 2013-07-20 00:45:46 <ahmed_mobile1> sorry about that
108 2013-07-20 01:26:21 <jgarzik> kuzetsa, There are no jgarziks but me
109 2013-07-20 01:26:30 <jgarzik> :)
110 2013-07-20 01:38:14 <jaxkr> Has anyone looked at this yet? https://bitcointalk.org/index.php?topic=259188.0
111 2013-07-20 01:40:35 <Luke-Jr> jaxkr: I'm not sure how many active developers actually read the troll forums
112 2013-07-20 01:40:54 <jaxkr> Luke-Jr: The troll forums?
113 2013-07-20 01:41:06 <Luke-Jr> yes, the domain you linked
114 2013-07-20 01:42:03 <ahmed_mobile1> hey guys
115 2013-07-20 01:42:11 <jaxkr> Luke-Jr: The troll forum you're currently active on? https://bitcointalk.org/index.php?action=profile;u=3318
116 2013-07-20 01:42:24 <Luke-Jr> yep
117 2013-07-20 01:42:27 <ahmed_mobile1> could any of you tell me which was the last version of bitcoin to use berkerly db
118 2013-07-20 01:42:44 <turboroot> ahmed_mobile1: 0.8.3
119 2013-07-20 01:42:45 <Luke-Jr> ahmed_mobile1: all versions of wxBitcoin, bitcoind, and Bitcoin-Qt use berkley db
120 2013-07-20 01:43:03 <ahmed_mobile1> i thought it switched to leveldb Luke-Jr
121 2013-07-20 01:43:04 <Luke-Jr> ahmed_mobile1: 0.7.x was the last series to use it for blockchain indexes
122 2013-07-20 01:43:09 <Luke-Jr> ahmed_mobile1: it is still used for wallets
123 2013-07-20 01:43:12 <ahmed_mobile1> thnks turboroot
124 2013-07-20 01:43:27 <ahmed_mobile1> right okay i think ill use 0.7.x then
125 2013-07-20 01:43:32 <Luke-Jr> 0.9.x is planned to get rid of bdb entirely
126 2013-07-20 01:43:45 <Luke-Jr> ahmed_mobile1: bad idea long-term <.<
127 2013-07-20 01:43:49 <ahmed_mobile1> i know
128 2013-07-20 01:43:54 <ahmed_mobile1> ill eventually switch over
129 2013-07-20 01:43:59 <ahmed_mobile1> second question
130 2013-07-20 01:44:10 <ahmed_mobile1> where can i obtain bitcoin's merged mining patches
131 2013-07-20 01:44:14 <Luke-Jr> there are none
132 2013-07-20 01:44:18 <Luke-Jr> Bitcoin does not support merged mining
133 2013-07-20 01:44:21 <ahmed_mobile1> ?
134 2013-07-20 01:44:23 <jaxkr> ahmed_mobile1: Certain altcoins do.
135 2013-07-20 01:44:30 <ahmed_mobile1> along wih ixcoin i0coin etc
136 2013-07-20 01:44:30 <jaxkr> ahmed_mobile1: Depends what you want to merge mine.
137 2013-07-20 01:44:45 <Luke-Jr> ahmed_mobile1: that's a function of the "slave" altcoin
138 2013-07-20 01:44:55 <jaxkr> ahmed_mobile1: Then I don't think this is where you should look. I'd recommend looking around Alternative Cryptocurrencies.
139 2013-07-20 01:44:55 <Luke-Jr> bitcoin does not have any explicit support for it
140 2013-07-20 01:45:06 <ahmed_mobile1> jaxkr ive just asked there
141 2013-07-20 01:45:21 <Luke-Jr> ahmed_mobile1: there are 2 merged mining systems in use: namecoin and p2pool
142 2013-07-20 01:45:29 <jaxkr> ahmed_mobile1: Are both of those coins SHA-256?
143 2013-07-20 01:45:31 <Luke-Jr> but bitcoin itself is unrelated to both
144 2013-07-20 01:45:37 <ahmed_mobile1> yep
145 2013-07-20 01:45:55 <ahmed_mobile1> im personally making another one hopefully and im looking for it to be merge mined
146 2013-07-20 01:45:58 <ahmed_mobile1> but as the master
147 2013-07-20 01:46:11 <Luke-Jr> ahmed_mobile1: why?
148 2013-07-20 01:46:13 <jaxkr> Another altcoin?
149 2013-07-20 01:46:16 <ahmed_mobile1> yep
150 2013-07-20 01:46:19 <jaxkr> Why?
151 2013-07-20 01:46:28 <ahmed_mobile1> i may not release it
152 2013-07-20 01:46:34 <ahmed_mobile1> but id just like to test it myself
153 2013-07-20 01:46:40 <Luke-Jr> ahmed_mobile1: "master" doesn't mean anything
154 2013-07-20 01:46:44 <jaxkr> It's a good activity to learn how Bitcoin works.
155 2013-07-20 01:46:51 <Luke-Jr> slaves define what can be a "master", not the "master" itself
156 2013-07-20 01:47:05 <ahmed_mobile1> right okay
157 2013-07-20 01:47:06 <jaxkr> Luke-Jr: I think he means creator.
158 2013-07-20 01:47:13 <Luke-Jr> ahmed_mobile1: you might be interested in checking in with #Freicoin
159 2013-07-20 01:47:22 <Luke-Jr> they are working on a new merged mining system to address the problems with namecoin's
160 2013-07-20 01:47:28 <ahmed_mobile1> nice
161 2013-07-20 01:47:32 <Luke-Jr> similar to p2pool's, but not chain-specific
162 2013-07-20 01:47:55 <ahmed_mobile1> with p2pool's is there a certain way to get that implemented?
163 2013-07-20 01:48:46 <Luke-Jr> ahmed_mobile1: you could certainly implement it, but it doesn't really make sense as-is for anything but p2pool
164 2013-07-20 01:48:58 <Luke-Jr> and the only implementation currently is Twisted code
165 2013-07-20 01:49:12 <jaxkr> Twisted as in the language?
166 2013-07-20 01:49:18 <jaxkr> Or twisted as in terrible programming?
167 2013-07-20 01:49:47 <Luke-Jr> the language
168 2013-07-20 01:49:53 <Luke-Jr> Python 2 dialect
169 2013-07-20 01:50:09 <jaxkr> Luke-Jr: I know. Good language.
170 2013-07-20 01:50:17 <Luke-Jr> I beg to differ, but ok
171 2013-07-20 01:50:40 <jaxkr> Really? It's just a python that specializes in networking.
172 2013-07-20 01:51:05 <Luke-Jr> jaxkr: and makes the code even more unreadable
173 2013-07-20 01:51:18 <Luke-Jr> jaxkr: I wrote my own networking interfaces for Eloipool
174 2013-07-20 01:51:27 <jaxkr> Luke-Jr: "even more" Are you anti-python in general?
175 2013-07-20 01:51:32 <Luke-Jr> yes :p
176 2013-07-20 01:51:48 <jaxkr> Luke-Jr: Why? Python's one of my favorites.
177 2013-07-20 01:52:13 <Luke-Jr> jaxkr: I'm not even sure why, it just bothers me.
178 2013-07-20 01:52:40 <jaxkr> I have a task for you. Open your python interpreter. And import the antigravity module.
179 2013-07-20 01:52:46 <Luke-Jr> ???
180 2013-07-20 01:53:22 <jaxkr> Luke-Jr: Amazing, right?
181 2013-07-20 01:53:25 <Luke-Jr> no
182 2013-07-20 01:53:29 <jaxkr> :(
183 2013-07-20 01:53:58 <Luke-Jr> it's like a trojan! :p
184 2013-07-20 01:54:10 <jaxkr> What's like a trojan?
185 2013-07-20 01:54:26 <Luke-Jr> antigravity
186 2013-07-20 01:54:42 <jaxkr> Eh. It's really a joke. I have no idea how it made it into the standard library.
187 2013-07-20 01:55:05 <Luke-Jr> :P
188 2013-07-20 01:55:24 <jaxkr> But the code of that module is something like import webbrowser webbrowser.open("http://xkcd.com/353/")
189 2013-07-20 01:55:42 <Luke-Jr> I was joking too.
190 2013-07-20 01:55:50 <jaxkr> Oh.
191 2013-07-20 01:56:11 <jaxkr> So, scrypt  isn't even a hashing algorythm.
192 2013-07-20 01:57:42 <Luke-Jr> ;)
193 2013-07-20 01:58:27 <jaxkr> Something I've been meaning to ask you, why do you have such a negative opinion on Litecoin/
194 2013-07-20 01:58:29 <jaxkr> *?
195 2013-07-20 01:59:53 <Luke-Jr> jaxkr: off-topic here, feel free to read https://en.bitcoin.it/wiki/Litecoin for the basic problems and/or ask somewhere else (perhaps #eligius )
196 2013-07-20 02:00:53 <jaxkr> "(Slight) Premining
197 2013-07-20 02:00:54 <jaxkr> Litecoin had two blocks premined, one more than the minimum single genesis block needed to start a block chain."
198 2013-07-20 02:01:03 <jaxkr> Those fuckers. 2 blocks.
199 2013-07-20 02:01:31 <Luke-Jr> again, off-topic here. (and note that isn't considered a criticism :p)
200 2013-07-20 05:51:14 <gjs278> I joined the #bitcoin channel on efnet. I didn't recognize any of the names so I left before things got weird
201 2013-07-20 10:49:42 <imton> guys, I need to get the "vin" value for getrawtransaction
202 2013-07-20 10:49:52 <imton> is there any patch there?
203 2013-07-20 10:50:40 <lianj> that would require fetching the previous outputs
204 2013-07-20 10:51:32 <sipa> imton: you mean fetching the output being consumed by a particular output?
205 2013-07-20 10:51:37 <sipa> *input
206 2013-07-20 10:51:48 <imton> yes
207 2013-07-20 10:52:01 <sipa> you can just fetch it
208 2013-07-20 10:52:13 <imton> sipa: specially in your searchforaddress
209 2013-07-20 10:52:18 <sipa> each input in getrawtransaction will list the txid and vout being consumed
210 2013-07-20 10:52:42 <sipa> so you can do a getrawtransaction for that txid, and find its output with the vout number
211 2013-07-20 10:52:49 <sipa> that's the output being consumed
212 2013-07-20 10:53:02 <Scrat> sounds like he's trying to find the fee :p
213 2013-07-20 10:53:13 <imton> hop the fee is the difference
214 2013-07-20 10:53:16 <imton> *nop
215 2013-07-20 10:53:31 <imton> sipa: yes, but I was wondering if this could be done directly from bitcoind
216 2013-07-20 10:53:31 <sipa> yeah
217 2013-07-20 10:53:42 <sipa> imton: what do you need it for?
218 2013-07-20 10:53:51 <imton> sipa: balances
219 2013-07-20 10:54:16 <sipa> you don't need that for balances
220 2013-07-20 10:54:48 <imton> sipa: I need vins' values for address balances...
221 2013-07-20 10:54:52 <imton> ?
222 2013-07-20 10:54:58 <imton> don't i?
223 2013-07-20 10:55:07 <sipa> iterate through the transactions affecting a given address, remember all outputs that credit your address, and remove those that get spend afterwards
224 2013-07-20 10:55:14 <sipa> the result is the utxo set for your address
225 2013-07-20 10:55:17 <Scrat> imton: why not use gettransaction then?
226 2013-07-20 10:56:12 <sipa> searchrawtransactions will list both crediting and spending transactions
227 2013-07-20 10:57:26 <sipa> so that should work without problems
228 2013-07-20 10:57:37 <Scrat> uh, a balance system based solely on bitcoind?
229 2013-07-20 10:57:53 <sipa> watch-only wallets is likely a much better solution
230 2013-07-20 10:58:22 <imton> "iterate through the transactions ???" >> yeah, I did it like that previously???
231 2013-07-20 10:58:43 <sipa> will be much faster than trying to find all inputs
232 2013-07-20 10:58:52 <imton> but would be easier for me if I just get each vin value directly from bitcoind.
233 2013-07-20 10:58:55 <sipa> even if implemented directly in bitcond
234 2013-07-20 10:59:28 <sipa> no, it won't
235 2013-07-20 10:59:40 <sipa> you'd still need to know which inputs are relevant
236 2013-07-20 10:59:47 <sipa> and to do that, you need to track the outputs
237 2013-07-20 11:00:03 <sipa> so you'd just duplicate functionality that can could be used to calculate the balance directly
238 2013-07-20 11:01:28 <imton> ok. so you mean that with a single searchrawtransactions I can get all the balance for that given address?
239 2013-07-20 11:01:35 <Scrat> is it just me or I cant see a use case for this
240 2013-07-20 11:01:35 <sipa> ~yes
241 2013-07-20 11:01:47 <sipa> i consider it abuse of the RPC, but yes
242 2013-07-20 11:02:38 <sipa> well, anything that relies on "balance of an address" is broken imho - you should consider balance of a wallet, being a collection of addresses
243 2013-07-20 11:03:01 <imton> Scrat: it useful for web services that need to consult multiple users balances/addresses, watch-only is better I know, but I couldn't find a patch that worked and was updated.
244 2013-07-20 11:03:13 <Scrat> yep, balances are a high level construction that should only live in a database
245 2013-07-20 11:03:21 <sipa> though probably the easiest way to do that with implemented code in bitcoind is using searchrawtransaction for every address in the wallet
246 2013-07-20 11:04:31 <Scrat> preferrably an SQL database, so you cap wrap a transaction around the RPC call
247 2013-07-20 11:04:44 <Scrat> so you can rollback if it fails
248 2013-07-20 11:05:40 <Scrat> imton: I want to know of one web service that uses "address balances" directly
249 2013-07-20 11:06:00 <imton> http://testnet.btclook.com/addr/mpjYfZXekpjqnNdgTSDAEscAwYR7rJZSAe
250 2013-07-20 11:06:10 <imton> you can see a completely detailed address balance there
251 2013-07-20 11:06:37 <imton> i need to get all that information
252 2013-07-20 11:06:57 <Scrat> (other than blockchain explorers or blockchain.info)
253 2013-07-20 11:07:30 <sipa> imton: and it's exactly what searchrawtransactions gives you
254 2013-07-20 11:07:32 <imton> well I am building a service like an escrow that ask the seller of the btc to send the btcs to an address i give to him
255 2013-07-20 11:07:46 <imton> i need to know all the txs to and from that address
256 2013-07-20 11:08:21 <Scrat> imton: you can have that, but balances should not be done at such a low level
257 2013-07-20 11:08:37 <imton> Scrat: i can't see why
258 2013-07-20 11:08:53 <sipa> the right solution is a watch-only wallet
259 2013-07-20 11:09:09 <imton> sipa: where's the bitcoind with that feature implemented?
260 2013-07-20 11:09:21 <sipa> but as that isn't really up-to-date, ...
261 2013-07-20 11:09:32 <sipa> yeah, i get it
262 2013-07-20 11:09:39 <Scrat> imton: because then you'll have to build your own send transactions that use the correct outputs
263 2013-07-20 11:09:50 <Scrat> bitcoind won't do that for you
264 2013-07-20 11:10:22 <imton> sipa: I suck at c++, and can't afford learn it now. If not I'd have already tried to do it myself :(
265 2013-07-20 11:12:54 <imton> sipa: will searchrawtransaction be merged into the master?
266 2013-07-20 11:13:04 <sipa> imton: hopefully
267 2013-07-20 11:13:16 <imton> sipa: awesome
268 2013-07-20 11:13:24 <sipa> but i hate it :(
269 2013-07-20 11:14:01 <sipa> because it'll remove the incentive for you people like you to demand the right solution :)
270 2013-07-20 11:14:35 <Scrat> sipa hates O(n) with a passion
271 2013-07-20 11:15:17 <Scrat> imton: but do tell, how will you implement sending
272 2013-07-20 11:20:36 <imton> sipa: I know you hate it :p
273 2013-07-20 11:29:18 <imton> sipa: searchrawtransactions is not taking mempool in consideration right?
274 2013-07-20 11:44:19 <sipa> imton: indeed, it doesn't (yet)
275 2013-07-20 11:44:54 <imton> sipa: np
276 2013-07-20 11:52:26 <chmod755> any android devs here?
277 2013-07-20 14:09:44 <imton> sipa: i want to get the searchrawtransactions for mempool
278 2013-07-20 14:10:16 <imton> right now I am using getrawmempool and iterating it with a getrawtransaction
279 2013-07-20 14:10:39 <sipa> better use gettxout
280 2013-07-20 14:10:54 <imton> gettxout is for UXOS ?
281 2013-07-20 14:11:09 <sipa> that way, you can know whether an outout was already spent or not
282 2013-07-20 14:11:43 <sipa> anyway, extending searchrawtramsactions for the mempool sounds useful
283 2013-07-20 14:11:53 <sipa> but i have higher priorities, especia
284 2013-07-20 14:12:04 <sipa> lly since i think it's not the right solution
285 2013-07-20 14:12:54 <imton> sipa: ok, np
286 2013-07-20 14:13:06 <imton> sipa: but i can't see why gettxout is better...
287 2013-07-20 14:13:56 <imton> I tought gettxout only worked with bitcoind addresses/txs
288 2013-07-20 14:14:01 <imton> sorry, wallet
289 2013-07-20 14:14:08 <gmaxwell> no.
290 2013-07-20 14:14:22 <imton> ok.
291 2013-07-20 14:14:26 <gmaxwell> gettxout queries the coins database, which all nodes have, which is used to validate transactions and blocks.
292 2013-07-20 14:15:10 <sipa> imton: i may have spoken too soon
293 2013-07-20 14:15:24 <sipa> gettxout can't tell you how many outputs a transaction has
294 2013-07-20 14:15:52 <imton> oh, i was about to test it
295 2013-07-20 14:15:53 <sipa> and you can indeed use it together with getrawtransaction to know whether a mempool tx has already been spent
296 2013-07-20 14:16:26 <imton> ok, the problem is that I can only get if that address is in the vouts addresses
297 2013-07-20 14:16:31 <imton> but not the vin
298 2013-07-20 14:16:38 <sipa> but as you have to iterate all mempool transactions anyway, it's faster to reuse that information to find spent outputs
299 2013-07-20 14:16:43 <sipa> you do not need thsat
300 2013-07-20 14:16:53 <sipa> you know which txid:vout pays to your address
301 2013-07-20 14:17:08 <sipa> if any such txid:vout is listed in an input, it is spent
302 2013-07-20 14:17:19 <sipa> so just count the unspent ones
303 2013-07-20 14:17:28 <sipa> again, this is not the right way to do that
304 2013-07-20 14:17:32 <imton> ok, let me think slowly..
305 2013-07-20 14:17:34 <imton> yeah, it sucks
306 2013-07-20 14:17:34 <sipa> but it would work
307 2013-07-20 14:17:40 <gmaxwell> I guess I missed the context of what was being asked here.
308 2013-07-20 14:17:50 <imton> gmaxwell: np
309 2013-07-20 14:18:21 <sipa> imton: stop thinking that you need to see everything as a credit or debit of an address
310 2013-07-20 14:18:52 <sipa> it is really individual transactions (and their outputs, so,etimes named coins) you need to track
311 2013-07-20 14:19:15 <sipa> so you don't need to know which address an input spends "from"
312 2013-07-20 14:19:19 <gmaxwell> The system does not work like credits and debits of addresses, and if you keep imposing that mental model on it you're going to end up with software which doesn't scale, and potentially losing your or your customer's money.
313 2013-07-20 14:19:24 <sipa> it really just spends a previous coins
314 2013-07-20 14:19:36 <sipa> and you already know the coins that credited you
315 2013-07-20 14:21:50 <imton> great. I will try :)
316 2013-07-20 14:51:26 <davec> Hey guys.  While writing btcchain, I wrote some code to programatically identify checkpoints.
317 2013-07-20 14:51:32 <davec> The idea being a few of the most recent checkpoint candidates can be listed and a core developer still hand picks one to ensure everything is good, but candidates are pre-validated by code.
318 2013-07-20 14:51:40 <davec> The following comments in the code identify the criteria used -- https://github.com/conformal/btcchain/blob/master/checkpoints.go#L166-L177
319 2013-07-20 14:51:47 <davec> Is there any other criteria you guys use that you feel should go in?
320 2013-07-20 14:57:06 <gmaxwell> There must be no publicly known viable competing chain. The checkpoint must be far back from the current time, our preference is at least 2016 blocks.
321 2013-07-20 14:58:49 <gmaxwell> I'm actually really disappointed that you have substantial checkpoint code in your software.
322 2013-07-20 14:59:52 <davec> ah 2016 makes sense due to the retarget
323 2013-07-20 15:00:39 <gmaxwell> "non-standard scripts" is probably not a good criteria.
324 2013-07-20 15:01:11 <gmaxwell> The goal on that one is to avoid any question about a checkpoint forcing a hardfork by imposing a shorter chain which contains transactions that some implementations consider invalid.
325 2013-07-20 15:01:24 <davec> The vast majority of the checkpoint code is simply to have parity with bitcoind in the way checkpoints are handled.  That is to say, the difficulty must be at least the minimum possible, hashes and heights have to match at the checkpoint, etc
326 2013-07-20 15:01:51 <gmaxwell> davec: Then you've just blindly aped the flawed syncing design of the current reference software?
327 2013-07-20 15:01:57 <davec> but I thought it would be nice to have some programatic way of identifying cp candidates
328 2013-07-20 15:02:14 <gmaxwell> We only need the checkpoints there because absent them its very easy to DOS attack the reference software because it doesn't validate headers first.
329 2013-07-20 15:02:49 <gmaxwell> (and we have to keep updating them because the protection they provide falls away after two years)
330 2013-07-20 15:03:31 <davec> correct.  I understand why it's there
331 2013-07-20 15:04:38 <gmaxwell> davec: while you're here, I cannot understand how you could have gotten 60% loc coverage if you've run bluematt's the block tester. The test should be hitting every condition for block acceptance.
332 2013-07-20 15:04:47 <davec> and yes, we are being extremely paranoid about causing any chain forks, so we made sure to keep parity with every rule in bitcoind
333 2013-07-20 15:04:56 <davec> I did respond to your blog post as well
334 2013-07-20 15:05:06 <davec> that test coverage is automated test coverage
335 2013-07-20 15:05:08 <gmaxwell> I saw that, but I'm confused.
336 2013-07-20 15:05:13 <davec> we passed bluematt's block tester
337 2013-07-20 15:05:26 <gmaxwell> oh you haven't given a coverage report on running that. Ah.
338 2013-07-20 15:05:27 <davec> but it's not automated into the test harness
339 2013-07-20 15:05:34 <gmaxwell> Okay, makes more sense now.
340 2013-07-20 15:05:45 <gmaxwell> Did you find any bugs in your implementation when you ran it?
341 2013-07-20 15:07:47 <gmaxwell> davec: wrt " we are being extremely paranoid about causing any chain forks, so we made sure to keep parity with every rule in bitcoind"  ... syncing behavior isn't a block validation rule. The particular syncing behavior used by bitcoind is fairly vulnerable to dos attacks, though mostly thats patched over by additional behavior.
342 2013-07-20 15:09:00 <gmaxwell> Sounds like you've got it under control in any case.
343 2013-07-20 15:09:14 <davec> there were two issue iirc
344 2013-07-20 15:09:55 <davec> definitely appreciate your feedback, the last thing we want is to cause issues.  Our goal is to improve the ecosyste
345 2013-07-20 15:09:58 <davec> m
346 2013-07-20 15:09:58 <gmaxwell> Thats good to hear. (I mean, obviously bugs aren't good... but if you're finding some its a suggestion that the test may have adequate depth)
347 2013-07-20 15:11:28 <gmaxwell> If along your way you don't find any interesting bugs in bitcoind (that you need to emulate) I will be surprised.  Bluematt found several while adding validation to bitcoinj (which are now tested by his tester and perhaps better documented in the code)
348 2013-07-20 15:14:19 <gmaxwell> You should check coverage when running the blocktester... if it's not ~100% of the block validity rules, thats interesting.
349 2013-07-20 15:24:47 <davec> That is the goal, but the tricky part there is the way the tester runs versus how Go generates the coverage reports (it instruments based on code in _test files).
350 2013-07-20 15:29:00 <gmaxwell> hm. That seems pretty limiting for systems level tests!   Perhaps there is a non-sampling profiling tool you could run that could indicate coverage as a side effect?
351 2013-07-20 20:43:04 <ahmedbodi__> hey guys
352 2013-07-20 20:43:29 <ahmedbodi__> has anyone here worked with bitcoin's code with the merge mining patches?
353 2013-07-20 22:14:38 <ahmedbodi__> anyone here?
354 2013-07-20 22:25:58 <Luke-Jr> ahmedbodi__: you were told there is no such thing a few nights ago.
355 2013-07-20 22:26:11 <ahmedbodi__> huh?
356 2013-07-20 22:26:38 <ahmedbodi__> nvm
357 2013-07-20 22:26:52 <ahmedbodi__> im working with doublec's code here
358 2013-07-20 22:26:58 <ahmedbodi__> https://github.com/doublec/bitcoin/tree/m0.8.1_merged
359 2013-07-20 22:27:32 <weex> ahmedbodi__: it's better to ask your question here anyway
360 2013-07-20 22:27:48 <Luke-Jr> weex: he did. he got answers.
361 2013-07-20 22:28:08 <weex> well there you go then
362 2013-07-20 22:28:11 <Luke-Jr> ahmedbodi__: maybe you should ping doublec specifically
363 2013-07-20 22:28:39 <ahmedbodi__> yeah i did
364 2013-07-20 22:32:05 <ahmedbodi__> the answers i got confused me and by looking at the code i can see that the patches or whatever add rpc command etc to the bitcoin daemon for things like getauxblock which i dont believe is there as standard
365 2013-07-20 22:38:20 <turboroot> Welp, here is possibly what's going up on whatcanidoforbitcoin.org. https://i.minus.com/irSjj8p0frNDG.png
366 2013-07-20 22:41:41 <turboroot> Clicking on each project will bring up more information: https://i.minus.com/ib0VOaFk4aueRj.png