1 2013-02-04 00:10:40 <Aranjedeath> badass, it's workin :D
  2 2013-02-04 00:10:49 <Aranjedeath> issss there any way to find out what the address is?
  3 2013-02-04 00:11:09 <Aranjedeath> listaccounts didn't provide anything useful
  4 2013-02-04 00:11:34 <Aranjedeath> maybe I have to generate an address?
  5 2013-02-04 00:19:35 <rdponticelli> Aranjedeath: getnewaddress to get a new
  6 2013-02-04 00:20:38 <Aranjedeath> rdponticelli:) thanks :)
  7 2013-02-04 00:20:39 <rdponticelli> getaddressesbyaccount to get the asigned to some account
  8 2013-02-04 00:21:02 <Aranjedeath> listaccounts only gives me "" : 0.00000000
  9 2013-02-04 00:21:30 <jgarzik> Luke-Jr: for which project is that commit?
 10 2013-02-04 00:21:31 <rdponticelli> Yeah, that's the default account
 11 2013-02-04 00:21:40 <Aranjedeath> okay, how do I get the address?
 12 2013-02-04 00:21:41 <Luke-Jr> jgarzik: cpuminer
 13 2013-02-04 00:21:50 <Aranjedeath> getaddressbyaccount returns method not found
 14 2013-02-04 00:22:09 <rdponticelli> getaddressesbyaccount
 15 2013-02-04 00:22:18 <Aranjedeath> oh!
 16 2013-02-04 00:22:22 <Aranjedeath> missed a letter or two :)
 17 2013-02-04 00:22:24 <jgarzik> Luke-Jr: a two-line comment patch that is Via-CPU-specific?
 18 2013-02-04 00:22:28 <Luke-Jr> yes
 19 2013-02-04 00:22:30 <Aranjedeath> thank you very much
 20 2013-02-04 00:22:31 <jgarzik> Luke-Jr: what about it?
 21 2013-02-04 00:22:47 <rdponticelli> Just use getnewaddress
 22 2013-02-04 00:22:51 <Luke-Jr> jgarzik: it confuses me, because bitcoind provided (getwork) the data in little endian, and it makes sense that it'd be converted to big endian for a dedicated processor like that
 23 2013-02-04 00:22:58 <Luke-Jr> jgarzik: but the comment says the opposite
 24 2013-02-04 00:23:16 <Luke-Jr> jgarzik: and this commit also states the VIA converts it *back* to big endian (really little endian?)
 25 2013-02-04 00:23:42 <HM2> go with middle endian
 26 2013-02-04 00:23:46 <HM2> then everyone is miserable
 27 2013-02-04 00:23:49 <jgarzik> Luke-Jr: VIA CPU docs for this are public
 28 2013-02-04 00:23:52 <Luke-Jr> since it was added later, I'm wondering if there is some docs on the VIA which state how it handles the hashing internally?
 29 2013-02-04 00:24:01 <Luke-Jr> oh, do you know where I can find it?
 30 2013-02-04 00:24:11 <Luke-Jr> Google found some info, but nothing like proper docs :/
 31 2013-02-04 00:24:20 <jgarzik> Luke-Jr: Don't recall the specific details, but it seemed like that was added in response to a comment or bug or somesuch
 32 2013-02-04 00:24:45 <Luke-Jr> hmm, I'll check out the cpuminer github issues list - any other place that might have had it?
 33 2013-02-04 00:25:37 <jgarzik> Luke-Jr: http://www.via.com.tw/en/initiatives/padlock/developercenter.jsp
 34 2013-02-04 00:26:06 <Luke-Jr> ty
 35 2013-02-04 00:51:27 <Luke-Jr> jgarzik: did you ever confirm the VIA code worked?
 36 2013-02-04 00:52:33 <jgarzik> Luke-Jr: I think I got a bug report that got it going, but there were always lingering questions
 37 2013-02-04 00:52:40 <jgarzik> would appreciate confirmation one way or the other
 38 2013-02-04 00:54:05 <Luke-Jr> hmm, wonder if there's any cheap hardware with one of them
 39 2013-02-04 00:54:21 <phantomcircuit> it's all cheap
 40 2013-02-04 00:54:32 <Luke-Jr> phantomcircuit: ?
 41 2013-02-04 00:55:34 <phantomcircuit> all the via hardware is cheap
 42 2013-02-04 00:56:06 <Luke-Jr> I don't know of any ;)
 43 2013-02-04 00:56:21 <phantomcircuit> http://www.newegg.com/Product/Product.aspx?Item=N82E16813135322
 44 2013-02-04 00:56:24 <phantomcircuit> case in point
 45 2013-02-04 00:56:49 <Luke-Jr> oh, these are desktop processors? X
 46 2013-02-04 00:56:51 <Luke-Jr> XD*
 47 2013-02-04 00:57:31 <phantomcircuit> they made very good home servers
 48 2013-02-04 00:57:54 <phantomcircuit> pad lock makes doing network crypt possible with such a slow cpu
 49 2013-02-04 01:05:56 <Luke-Jr> phantomcircuit: hmm, price might be less of a problem than finding somewhere to put it I guess >_<
 50 2013-02-04 01:12:17 <Luke-Jr> oh well, wasting too much time on stupid CPU mining >_<
 51 2013-02-04 01:13:52 <Rlc23> any idea why i keep getting wallet.xxxxxxxxx.bak created when running bitcoind?
 52 2013-02-04 01:15:03 <Rlc23> even loading an old (good) version of that wallet
 53 2013-02-04 01:30:44 <Rlc23> anyone? bueller?
 54 2013-02-04 01:50:28 <Rlc23> keep getting 'Renamed wallet.dat to wallet.xxxxxxxx.bak in the startup of a bitcoind
 55 2013-02-04 01:52:19 <weex> Rlc23: is this in windows?
 56 2013-02-04 01:52:28 <Rlc23> debian
 57 2013-02-04 01:52:39 <weex> could it be a permissions issue?
 58 2013-02-04 01:52:52 <Rlc23> hm, let me check
 59 2013-02-04 01:57:20 <Rlc23> doesnt look like permissions
 60 2013-02-04 02:00:50 <Rlc23> any other ideas?
 61 2013-02-04 02:26:09 <weex> what if you make a backup of your wallet.dat and rename it? a new one should be created so at least you'll know if it was a problem with the wallet.dat file
 62 2013-02-04 02:26:34 <Rlc23> thanks weex, definitely a wallet problem
 63 2013-02-04 02:26:54 <Rlc23> i ran bitcointools wallet repair, got a much cmaller file, but it runs and appears to have all the keys
 64 2013-02-04 02:27:23 <Rlc23> maybe a bad transaction right when bitcoind crashed?
 65 2013-02-04 02:27:43 <Rlc23> never seen this before
 66 2013-02-04 07:31:59 <ne0futur> bitnumus: try on #bitcoin-otc
 67 2013-02-04 14:21:08 <Luke-Jr> hmm, my client is stuck
 68 2013-02-04 14:21:47 <helo> mine became stuck because of incorrect system time, but that apparently is to be expected
 69 2013-02-04 14:22:56 <Luke-Jr> http://codepad.org/IZyQ7UK6
 70 2013-02-04 14:32:42 <kjj> hey Luke, did you notice that the bfg API commands are a jumble of <verb><noun> and <noun><verb> ?
 71 2013-02-04 14:33:12 <Luke-Jr> kjj: I didn't. I try to avoid touching the RPC stuff >_<
 72 2013-02-04 14:33:30 <kjj> hmm
 73 2013-02-04 14:34:06 <kjj> most of the device commands are gpu/cpu/pga + verb, while most of the pool commands are verb + pool
 74 2013-02-04 14:34:10 <Luke-Jr> that be troll territory lol
 75 2013-02-04 14:34:34 <Luke-Jr> kjj: when/if I end up redoing parts of the RPC, I'll likely remove the GPU/CPU/PGA distinction altogether
 76 2013-02-04 14:34:39 <Luke-Jr> it's useless and makes for headaches
 77 2013-02-04 14:38:10 <kjj> did you buy an avalon?
 78 2013-02-04 14:39:21 <Luke-Jr> kjj: no
 79 2013-02-04 14:39:40 <Luke-Jr> kjj: Avalon is the only ASIC vendor who was unwilling to provide me with a device
 80 2013-02-04 14:39:57 <Luke-Jr> although they did donate one to the Foundation, which in theory I'd expect I should be able to use for development
 81 2013-02-04 14:40:34 <kjj> I'm hoping they can be converted to USB
 82 2013-02-04 14:41:22 <Luke-Jr> I believe so
 83 2013-02-04 14:41:35 <Luke-Jr> Jeff said it looks like serial, but his dmesg showed a serial-to-USB convertor
 84 2013-02-04 14:42:36 <kjj> I didn't count the wires on the ribbon cables, but it looked too wide for serial to me
 85 2013-02-04 14:43:51 <abracadabra> what cgminer version comes with avalon?
 86 2013-02-04 14:44:03 <abracadabra> oh meh.. n/m found it
 87 2013-02-04 14:47:11 <Luke-Jr> abracadabra: 2.10.4, but apparently modified a lot
 88 2013-02-04 14:47:26 <Luke-Jr> abracadabra: the GBT seems to be more broken than normally
 89 2013-02-04 14:47:29 <Guest55983> so asics are reality now, are they?
 90 2013-02-04 14:49:34 <helo> have been for ~33 years now :)
 91 2013-02-04 14:51:20 <moore_> Luke-Jr, you wort the common patched to block SD right?
 92 2013-02-04 14:52:19 <Guest55983> dedicated bitcoin asic miners
 93 2013-02-04 14:52:32 <moore_> I have realized that my attack against SD can be leveraged in to a attack on bitpay
 94 2013-02-04 14:53:34 <moore_> It can be used thou when ever there are differences in which TX are considered valid by miners
 95 2013-02-04 14:54:33 <moore_> and Eliel pointed out that there are other asymmetries like accepting large blocks with small fees
 96 2013-02-04 14:55:31 <Luke-Jr> moore_: I think you are wrong.
 97 2013-02-04 14:55:35 <moore_> it is interesting because where it may not be considered a attack against bit coin it is a attack against common use ( if you considere bitpay common )
 98 2013-02-04 14:55:38 <moore_> really?
 99 2013-02-04 14:55:39 <moore_> why
100 2013-02-04 14:56:00 <Luke-Jr> moore_: I don't think you can hurt BitPay.
101 2013-02-04 14:56:21 <moore_> bitpay uses uncomited tx
102 2013-02-04 14:56:28 <Eliel> Luke-Jr: you can hurt some bitpay customers... but only those who have chosen to accept unconfirmed txs.
103 2013-02-04 14:56:46 <Luke-Jr> moore_: no, they don't.
104 2013-02-04 14:56:53 <Eliel> as far as I understand it, Bitpay will pass those losses to customers.
105 2013-02-04 14:56:56 <Luke-Jr> Eliel: sure, known unsafe practices are unsafe
106 2013-02-04 14:56:58 <Luke-Jr> that's obvious
107 2013-02-04 14:57:08 <moore_> Their demo videos show the use of uncomited tx
108 2013-02-04 14:57:13 <teenidle> hello
109 2013-02-04 14:57:49 <moore_> well bitpay's promo videos push it as safe
110 2013-02-04 14:58:18 <Luke-Jr> then email Tony
111 2013-02-04 14:58:25 <moore_> https://bitpay.com/bitcoin-mobile-checkout
112 2013-02-04 14:58:27 <moore_> k
113 2013-02-04 14:58:57 <Luke-Jr> moore_: note the video looks like it's for retail like a restaurant
114 2013-02-04 14:59:05 <moore_> ya
115 2013-02-04 14:59:26 <Luke-Jr> moore_: so double spending in that case is like someone giving you a bad check
116 2013-02-04 14:59:30 <moore_> do you have a email for him
117 2013-02-04 14:59:38 <Luke-Jr> I'm sure it's on the site..
118 2013-02-04 14:59:45 <moore_> I just see info
119 2013-02-04 14:59:50 <Luke-Jr> that should work
120 2013-02-04 15:01:23 <moore_> Luke-Jr, if miners published there rules for tx accptance it would be much easer to avoid this attack
121 2013-02-04 15:05:57 <Luke-Jr> moore_: easier to arrange a deal with merchant(s) to accept transactions to them
122 2013-02-04 15:06:49 <moore_> you mean that bitpay or who ever should have some deal with miners to make sure there tx get in?
123 2013-02-04 15:08:06 <amiller> i've read contradictory things about bitpay's policy, whether or not they wait 6 blocks before considering themselves contractually bound to pay out
124 2013-02-04 15:08:58 <moore_> what about in the chained case, where a customer spends a output of a unconfirmed tx that is not going to be accepted? I suppose most clinets don't let you spend unconfermed tx so you could just reject them
125 2013-02-04 15:09:03 <moore_> as valid
126 2013-02-04 15:10:04 <Luke-Jr> moore_: yes
127 2013-02-04 15:10:14 <jgarzik> amiller: Cannot speak for BitPay, but in general... it's product based
128 2013-02-04 15:10:20 <Luke-Jr> amiller: I'd expect they show the merchants how confirmed it is
129 2013-02-04 15:10:28 <amiller> "HIGH speed confirmations typically take 5-10 seconds, and can be used for digital goods or low-risk items.  LOW speed confirmations take about 1 hour, and should be used for high-value items." is supposedly a quote from bitpay's options
130 2013-02-04 15:10:34 <jgarzik> amiller: You can accept zero-conf, if the merchant can cancel a purchase before shipping a physical product
131 2013-02-04 15:10:53 <amiller> which suggests that bitpay would not actually pay out in case of a double spend
132 2013-02-04 15:11:04 <Luke-Jr> amiller: of course they wouldn't
133 2013-02-04 15:11:14 <jgarzik> ie. "payment accepted!"  then the merchant checks before shipment, which happens hours or days later.
134 2013-02-04 15:11:53 <jgarzik> no idea if that's how BitPay does it, but it would make sense.
135 2013-02-04 15:11:57 <jgarzik> best user experience
136 2013-02-04 15:12:01 <Luke-Jr> ^
137 2013-02-04 15:13:13 <Luke-Jr> wtf
138 2013-02-04 15:13:21 <Luke-Jr> it seems a large chunk of my blk0001.dat has just nulled out
139 2013-02-04 15:16:35 <kjj> better that than your wallet.dat
140 2013-02-04 15:17:25 <Luke-Jr> sure, but still disturbing
141 2013-02-04 15:29:48 <Luke-Jr> can anyone seed blk0001?
142 2013-02-04 15:35:49 <kinlo> you probably want a clean version?
143 2013-02-04 15:36:07 <Luke-Jr> kinlo: it won't seed unless it is, yes :P
144 2013-02-04 15:36:20 <kinlo> why not?
145 2013-02-04 15:36:20 <Luke-Jr> https://bitcointalk.org/index.php?topic=94881.0 <-- link to torrent file
146 2013-02-04 15:36:25 <Luke-Jr> because torrents are fixed data
147 2013-02-04 15:37:12 <kinlo> with clean I mean the version one would download now, excluding the orphans stuff
148 2013-02-04 15:37:51 <kinlo> oh
149 2013-02-04 15:38:00 <kinlo> so you mean if we want to seed YOUR version :)
150 2013-02-04 15:38:10 <Luke-Jr> kinlo: clean is clean ;)
151 2013-02-04 15:40:07 <jgarzik> BTC Guild switched to pre-0.8, for at least a few of its machines
152 2013-02-04 15:40:16 <jgarzik> I wonder when we will lock in v2 blocks?
153 2013-02-04 15:40:31 <kinlo> jgarzik: it's still a long time before that happens
154 2013-02-04 15:40:50 <kinlo> we're barely at 50%
155 2013-02-04 15:41:12 <kinlo> blockorigin tracks the blocks, so you can easily see that several major pools still need to switch
156 2013-02-04 15:41:14 <Luke-Jr> jgarzik: despite the warnings that 0.8 shouldn't be used for mining yet? :P
157 2013-02-04 15:41:35 <jgarzik> Luke-Jr: What specific bugs/problems remain outstanding?
158 2013-02-04 15:41:50 <Luke-Jr> jgarzik: as recently as 2 weeks ago, both slush's Stratum server and my Eloipool both made invalid v2 blocks in some cases :P
159 2013-02-04 15:41:58 <Luke-Jr> jgarzik: lack of testing only, I think
160 2013-02-04 15:42:12 <jgarzik> Luke-Jr: invalid in what way?
161 2013-02-04 15:42:45 <Luke-Jr> jgarzik: in slush's case, he wasn't encoding the height as a signed number; in my case, I was creating longpoll merkleroots with the height of the *current* block
162 2013-02-04 15:43:19 <Luke-Jr> jgarzik: do you have a clean blk0001 by any chance?
163 2013-02-04 15:45:56 <kinlo> does 0.7 enforce the rules for v2 blocks?   ie will it reject v2 blocks without valid blocknum in the generation hash?
164 2013-02-04 15:46:17 <Luke-Jr> kinlo: after something like 98% adoption
165 2013-02-04 15:46:32 <Luke-Jr> IIRC 950 of past 1000 blocks
166 2013-02-04 15:46:39 <kinlo> it's 95% afaik
167 2013-02-04 15:46:44 <kinlo> so basicly, not yet
168 2013-02-04 15:47:02 <kinlo> it could have enforced the v2 rules already, and accept any v1 block
169 2013-02-04 15:47:11 <kjj> I thought that it enforced v2 rules on blocks claiming to be v2, but still accepted v1 blocks until the 95% mark hits
170 2013-02-04 15:47:14 <Luke-Jr> kinlo: not without risk of orphaning
171 2013-02-04 15:47:15 <kinlo> but then again, one might exploit that
172 2013-02-04 15:47:22 <Luke-Jr> kjj: yes and no
173 2013-02-04 15:47:23 <kinlo> indeed
174 2013-02-04 15:47:30 <kinlo> makes sense not to enforce the rules.
175 2013-02-04 15:47:54 <Luke-Jr> 750/1000 starts rejecting wrong-v2 blocks
176 2013-02-04 15:47:59 <kjj> ahh
177 2013-02-04 15:48:00 <Luke-Jr> 950/1000 starts rejecting v1 blocks
178 2013-02-04 15:48:11 <kinlo> 2 pools of the top 5 are not even began testing with v2 blocks
179 2013-02-04 15:48:26 <kinlo> and the top 7 all have more then 5%
180 2013-02-04 15:48:51 <kinlo> so it will still take some time
181 2013-02-04 15:49:41 <Luke-Jr> @ whoever seeded, thanks
182 2013-02-04 15:50:47 <kinlo> it would make sense to create a new torrent for file 1 and 2
183 2013-02-04 15:51:38 <Luke-Jr> kinlo: it would
184 2013-02-04 15:52:07 <kinlo> on the other hand, isn't 0.8 doing everything with much smaller files?
185 2013-02-04 15:54:25 <TD> good day
186 2013-02-04 15:58:20 <jgarzik> Luke-Jr: RE blk0001... torrent it
187 2013-02-04 15:58:28 <jgarzik> Luke-Jr: https://bitcointalk.org/index.php?topic=117982.0
188 2013-02-04 15:59:06 <Luke-Jr> jgarzik: that's not blk0001 :P
189 2013-02-04 15:59:21 <Luke-Jr> jgarzik: and yes, I was using a torrent:  https://bitcointalk.org/index.php?topic=94881.0
190 2013-02-04 15:59:38 <jgarzik> no, but you can recreate it quickly
191 2013-02-04 15:59:44 <muhoo> TD: thanks for the bloom filtering, 0.7-SNAPSHOT is a lot faster now
192 2013-02-04 16:00:21 <muhoo> TD: any idea what the status of fees are in bitcoinj?
193 2013-02-04 16:00:36 <TD> you're welcome. who are you, might i ask?
194 2013-02-04 16:01:12 <muhoo> TD: nobody in particular :-) i'm doing a bitcoin store in my spare time, using bitcoinj, to run the server on a cheap 500MB RAM VPS
195 2013-02-04 16:01:20 <TD> fees can be set explicitly, but solving them according to the protocol rules is unimplemented. i keep wanting to do it and then andreas convinces me it's not the biggest UX problem with the android wallet right now
196 2013-02-04 16:01:28 <TD> ah ok. i thought you might be somebody i talked to before
197 2013-02-04 16:02:12 <TD> muhoo: i'd strongly recommend to run a full node if you're actually selling stuff
198 2013-02-04 16:02:33 <TD> muhoo: but if you really can't afford that,  make sure you at least are waiting for confirmations
199 2013-02-04 16:02:44 <muhoo> can't. not enough RAM. also, i need to be able to watch raw transactions. we're just selling music, no confirmations required
200 2013-02-04 16:03:14 <muhoo> nobody's going to want to wait a half hour to get their download.
201 2013-02-04 16:03:21 <TD> mmm. RAM is cheap though. i guess if you're on a strict budget the cost of running a node can be an issue.
202 2013-02-04 16:03:31 <TD> but i suppose if you get ripped off for some music it's no big deal
203 2013-02-04 16:03:38 <TD> ok, well, good to hear you find it useful at least
204 2013-02-04 16:03:39 <muhoo> that was the thinking.
205 2013-02-04 16:03:49 <TD> let me know if there's some features you want (beyond fees. i already know about them)
206 2013-02-04 16:04:17 <muhoo> the algorithm for fees in bitcoind looks pretty simple. probably wouldn't be that hard to just transliterate it to java
207 2013-02-04 16:04:23 <TD> btw do you use watching wallets at all? bitcoinj supports them but it's not really documented.
208 2013-02-04 16:04:37 <TD> sure. but it's also about making sure it's properly tested and things like that.
209 2013-02-04 16:04:44 <muhoo> PeerGroup.addWallet() ?
210 2013-02-04 16:04:45 <TD> it's not hard. it's just not floated to the top of the todo list yet, as i'm still quite mobile focused.
211 2013-02-04 16:05:02 <TD> muhoo: no, i mean, does your store have only public keys on it? you can keep the wallet with private keys on your own laptop or whatever
212 2013-02-04 16:05:10 <TD> it's more secure that way, a web server compromise can't steal the money collected
213 2013-02-04 16:05:41 <muhoo> the  plan is to have one wallet per musician on the server, and as soon as payments come in, get them the hell off the server and send them to an address on file for the musician
214 2013-02-04 16:06:01 <muhoo> so that there are no coins sitting in live wallets on the server for very long
215 2013-02-04 16:06:07 <CodeShark> don't even have them come to the server in the first place
216 2013-02-04 16:06:23 <CodeShark> just watch for transactions - but don't hold any private keys on the server
217 2013-02-04 16:06:32 <muhoo> well, we want to take a cut. i guess could do that with raw transactions.
218 2013-02-04 16:06:42 <CodeShark> there's absolutely no good reason for keeping private keys on the web server
219 2013-02-04 16:07:45 <CodeShark> have musicians pregenerate a bunch of addresses and give you a list
220 2013-02-04 16:07:52 <muhoo> interesting. watch-only wallet makes sense.
221 2013-02-04 16:08:00 <muhoo> these guys aren't bitcoin savvy.
222 2013-02-04 16:08:11 <muhoo> i need to make it totallly stoned-ass-musician-proof
223 2013-02-04 16:08:48 <muhoo> these guys will take whatever they make and go spend it on silk road, no doubt :-)
224 2013-02-04 16:10:05 <eckey> ping Mike Hearn
225 2013-02-04 16:10:12 <TD> muhoo: hah. well, it's up to you. if you want to be automatically forwarding money direct from the web server then yeah it's an issue. if you have a second system that can be made more locked down than your web server (very likely) you can write a program that does the forwarding/cut taking for you
226 2013-02-04 16:10:38 <muhoo> TD: that is pretty much what i've got, yes.
227 2013-02-04 16:10:44 <HM2> if your web app can control your wallet then your wallet is only as secure as your web app
228 2013-02-04 16:11:32 <TD> eckey: pong
229 2013-02-04 16:12:07 <muhoo> HM2: true, but there are many wallets. "my" wallet is not on a web server. "a" wallet is, and it just forwards coins, essentially.
230 2013-02-04 16:12:40 <muhoo> but i'll look into other ways to do it, thanks for the suggestions all.
231 2013-02-04 16:13:09 <muhoo> heirarchal wallets BIP would make this a lot easier
232 2013-02-04 16:13:28 <CodeShark> indeed it would
233 2013-02-04 16:13:34 <CodeShark> I think I'm gonna just start implementing that3
234 2013-02-04 16:13:45 <CodeShark> no more waiting around for the cryptographers :p
235 2013-02-04 16:13:59 <HM2> heirarchical wallets?
236 2013-02-04 16:14:06 <CodeShark> BIP32
237 2013-02-04 16:14:19 <HM2> hi-er-arch-ic-al
238 2013-02-04 16:14:23 <HM2> i hate that word
239 2013-02-04 16:14:25 <muhoo> 
ACTION can't spell, sorry

240 2013-02-04 16:14:33 <HM2> no i can't either :P
241 2013-02-04 16:15:00 <Luke-Jr> CodeShark: I'm pretty sure sipa is going to do that..
242 2013-02-04 16:15:29 <CodeShark> sipa is waiting on hal
243 2013-02-04 16:15:57 <CodeShark> and he's on vacation now
244 2013-02-04 16:16:00 <CodeShark> sipa, that is
245 2013-02-04 16:16:13 <MC1984> i like how there are more new people talking about dev stuff
246 2013-02-04 16:16:20 <CodeShark> and I NEED a deterministc wallet
247 2013-02-04 16:16:20 <CodeShark> ASAP
248 2013-02-04 16:16:21 <CodeShark> like, yesterday
249 2013-02-04 16:16:23 <TD> muhoo: bear in mind that the current code doesn't handle multiple wallets very well. you can attach new wallets, but if you disconnect and reconnect them later, they won't automatically re-scan the right parts of the chain
250 2013-02-04 16:16:33 <TD> muhoo: so i'm not sure 1-wallet-per-artist is a good idea as they all need to be in RAM at once.
251 2013-02-04 16:16:49 <HM2> that BIP looks awesome
252 2013-02-04 16:16:59 <kjj> CodeShark: it is easy enough to make your own deterministic wallet
253 2013-02-04 16:17:01 <muhoo> TD: i noticed that, and was worried about it.
254 2013-02-04 16:17:02 <HM2> CodeShark: is the crypto side of it similar to key splitting used in vanitygen?
255 2013-02-04 16:17:02 <TD> muhoo: a design where you create a new key for each transaction in a single wallet and then record which artist it was for, seems to make more sense to me
256 2013-02-04 16:17:10 <CodeShark> kjj: that's exactly the idea
257 2013-02-04 16:17:11 <TD> muhoo: there's no real reason for every artist to have a wallet, imho.
258 2013-02-04 16:17:40 <kjj> but be sure to read up on how to do it right.  if you do it poorly, you'll leak all of your private info
259 2013-02-04 16:18:11 <CodeShark> I don't set out to do things to do them poorly :)
260 2013-02-04 16:18:11 <muhoo> TD: good point. i can keep the mapping of addresses-to-artist in a database, which i was going to have to do anyway, to keep track of which songs were sold (so artists can see their sales history)
261 2013-02-04 16:18:11 <TD> yeah. the documentation for how to use bitcoinj in the merchant case isn't very good today. there was a guy (gary rowe) who wanted to do MultiBit Merchant and provide a merchant server to handle all this, but i never heard anything back
262 2013-02-04 16:18:32 <TD> muhoo: yeah. eventually you may run out of RAM anyway because the wallet keeps all spent transactions too, but there's no real reason for that. it can be fixed.
263 2013-02-04 16:18:52 <CodeShark> HM2, I haven't really used vanitygen much...but the same idea could be applied
264 2013-02-04 16:18:54 <TD> muhoo: just be aware that bitcoinj is designed for mobile phones/individual users and hasn't really been battle-tested for the merchant server case. you'll find things that need fixing.
265 2013-02-04 16:19:03 <muhoo> i noticed that too :-) a Wallet.toString() can get very long
266 2013-02-04 16:19:24 <TD> it can, yes. i'll probably fix that soon. there isn't a strong justification to keep spent transactions around except for historical interest.
267 2013-02-04 16:19:30 <CodeShark> we need a wallet that is merchant-facing...too much emphasis on mobile and end-user wallets...not enough on good, solid merchant solutions :)
268 2013-02-04 16:19:33 <muhoo> fair enough. i don't mind being on the bleeding edge here.
269 2013-02-04 16:19:36 <TD> cool
270 2013-02-04 16:19:40 <TD> might you contribute patches?
271 2013-02-04 16:19:45 <Luke-Jr> CodeShark: BitPay
272 2013-02-04 16:19:51 <CodeShark> bah
273 2013-02-04 16:19:53 <HM2> hmmm
274 2013-02-04 16:19:56 <muhoo> TD: i'd be happy to, if the opportunity arises
275 2013-02-04 16:20:00 <TD> superb
276 2013-02-04 16:20:25 <muhoo> IIRC there's a CA involved, i shoudl get up on that
277 2013-02-04 16:21:12 <TD> CA involved?
278 2013-02-04 16:22:07 <HM2> CodeShark: i'm looking at BIP32....it seems to me that child keys are just derived by salting and hashing parent keys?
279 2013-02-04 16:22:13 <muhoo> contributor agreement?
280 2013-02-04 16:22:21 <CodeShark> HM2: yes
281 2013-02-04 16:22:44 <HM2> How is that helpful?
282 2013-02-04 16:23:08 <muhoo> TD: if you require a signed agreement to accept patches, i should get that squared away at some point
283 2013-02-04 16:23:30 <TD> ah, yes, CLA. you can just sign it electronically.
284 2013-02-04 16:23:37 <TD> it's easy
285 2013-02-04 16:24:12 <CodeShark> you also multiply by some k, HM2
286 2013-02-04 16:24:52 <HM2> oh i see
287 2013-02-04 16:24:57 <eckey> TD: using bitcoinj, is there a way to specify a block or timestamp and have PeerGroup go back and catch up from that point?  Would be useful when reconstructing a wallet.
288 2013-02-04 16:25:25 <eckey> rerun the transactions
289 2013-02-04 16:25:33 <HM2> K[n] i= I[L] * K[par]
290 2013-02-04 16:25:59 <HM2> so it is similar to the vanitygen keysplitting you told me about before, i believe
291 2013-02-04 16:26:13 <HM2> just using a hash to produce a deterministic value
292 2013-02-04 16:26:39 <TD> eckey: wallet.clearTransactions(0); and then delete the block chain file.
293 2013-02-04 16:26:46 <TD> you can't currently do partial chain re-fetches
294 2013-02-04 16:26:56 <TD> it's not hard to implement. just didn't get to the top of the todo list yet.
295 2013-02-04 16:29:15 <HM2> hmm
296 2013-02-04 16:29:40 <eckey> TD: and rerun from genesis?
297 2013-02-04 16:29:40 <muhoo> at least for testing purposes, it'd make life easier.
298 2013-02-04 16:29:47 <TD> yes
299 2013-02-04 16:29:57 <TD> it'll use getheaders to catch up to the wallet birthday pretty fast though
300 2013-02-04 16:30:31 <HM2> CodeShark: I'm guessing I[L] in that math cannot be 1 or Kn = Kpar
301 2013-02-04 16:30:35 <muhoo> the new bloom filter code seems to speed it up dramatically
302 2013-02-04 16:30:50 <TD> are you guys on the bitcoinj mailing list?
303 2013-02-04 16:31:01 <eckey> pointer?
304 2013-02-04 16:31:07 <eckey> nevermind
305 2013-02-04 16:32:32 <TD> doing partial chain refetches for the single wallet case is pretty easy.
306 2013-02-04 16:33:00 <muhoo> this is a "hello world" running bitcoinj: http://spazcoin.bamfic.com
307 2013-02-04 16:33:17 <TD> doing it online when you have multiple wallets attached is a bit less easy, the current code more or less assumes it's at one "place" in the sync process. so some refactoring is required to be syncing/rewinding different wallets simultaneously. i suspect most apps don't need multiple wallets at once, so it's not high up my list.
308 2013-02-04 16:33:37 <TD> muhoo: oh, cool, that's a raw feed of every tx being broadcast?
309 2013-02-04 16:33:42 <muhoo> yep
310 2013-02-04 16:34:00 <TD> muhoo: bonus points for adding the transactions to an html list and updating the number of seen peers in place
311 2013-02-04 16:34:02 <TD> that'd be cool
312 2013-02-04 16:34:36 <muhoo> i'll need to do that in memory. once it's seen by 4 peers, i'll ship the download to the customer
313 2013-02-04 16:34:46 <muhoo> this was a test of that functionality
314 2013-02-04 16:34:58 <TD> sure
315 2013-02-04 16:35:12 <muhoo> plus all the ajax plumbing.
316 2013-02-04 16:35:47 <Luke-Jr> 
ACTION kicks his stuck node

317 2013-02-04 16:36:08 <CodeShark> 
ACTION hands Luke-Jr a sledgehammer

318 2013-02-04 16:36:23 <muhoo> ok, well now i'm inspired to get off my slacker ass and move this thing forward a bit
319 2013-02-04 16:37:41 <HM2> CodeShark: i think i get that hierarchical stuff.
320 2013-02-04 16:38:26 <TD> coo
321 2013-02-04 16:38:26 <TD> cool
322 2013-02-04 16:38:42 <TD> muhoo: could you do me a favor and take notes on what you find easy/hard/annoying/unintuitive/etc? API user case studies are hard to come by.
323 2013-02-04 16:38:52 <TD> then we can turn your notes into issues on the tracker and work through them
324 2013-02-04 16:39:58 <muhoo> ok, will do. you've already mentioned the main things i've already run up against: ram-bloat with wallet storing everything its seen, ability to replay the blockchain, etc
325 2013-02-04 16:40:34 <TD> yeah
326 2013-02-04 16:40:58 <TD> we can just add some methods to control the size of the spent pool. you probably don't need it.
327 2013-02-04 16:41:38 <muhoo> one of the things that's interestign to me as a store, is there's going to be some duplication of data between what's in the wallet and what i need to store in the db anyway (sales history)
328 2013-02-04 16:42:19 <TD> yeah. over time i want to find a good refactoring of the wallet so it can be saved to different kinds of database, rather than a file.
329 2013-02-04 16:42:33 <muhoo> right now i'm serializing it and saving it as a blob.
330 2013-02-04 16:42:40 <TD> i always wanted to let you attach data to arbitrary objects and have it be persisted during serialization.
331 2013-02-04 16:42:45 <TD> muhoo: protobuf serialization i hope!
332 2013-02-04 16:42:51 <muhoo> so one other thign would be nice is to have the auto-save code more general and not be tied to a File
333 2013-02-04 16:42:54 <TD> yeah
334 2013-02-04 16:42:55 <TD> i know
335 2013-02-04 16:43:09 <muhoo> yes, protobuf.
336 2013-02-04 16:43:18 <TD> for now though, i'm unfortunately still going to be focusing on mobile/desktop wallets, so these sorts of features won't happen unless somebody contributes them.
337 2013-02-04 16:43:37 <TD> on the grounds that if i try to satisfy every use case simultaneously it'll end up satisfying none of them well
338 2013-02-04 16:43:52 <muhoo> understandable.
339 2013-02-04 16:43:58 <CodeShark> merchant wallets should be an entirely different app than mobile wallets
340 2013-02-04 16:44:14 <CodeShark> they have two very different sets of requirements
341 2013-02-04 16:44:17 <muhoo> hmm.
342 2013-02-04 16:44:25 <TD> well, obviously they are different apps. it's about the features they demand of the underlying API.
343 2013-02-04 16:44:33 <gmaxwell> Luke-Jr: wrt the conversation in #bitcoin or wherever altcoins was coming up: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas
344 2013-02-04 16:45:19 <muhoo> if needed, i suppose there could be separate wallet classes with a common interface, etc.
345 2013-02-04 16:45:34 <muhoo> one for android wallets, one for merchant, etc,
346 2013-02-04 16:45:56 <TD> yeah, Wallet is a huge class though. the issue is really one of "save a consistent snapshot" vs "submit each change to a database layer in an easy SQLable form"
347 2013-02-04 16:46:20 <TD> the current code is only capable of the first. you can find out the wallet changed but there's no packaging up of the changes in a form that's good to put into an UPDATE statement.
348 2013-02-04 16:46:29 <muhoo> i wasn't going to try to break up the wallet into sql table fields or anythign crazy like that.
349 2013-02-04 16:46:57 <TD> well, i'm thinking about scalability. SatoshiDice had to make pretty big changes to allow the wallet to be in a database
350 2013-02-04 16:47:13 <TD> so now they're forked quite badly and fireduck seems uninterested in rebasing, so he isn't getting bugfixes and new features :(
351 2013-02-04 16:47:18 <muhoo> oh, do they? i didn't know their implementation.
352 2013-02-04 16:47:22 <TD> yeah
353 2013-02-04 16:47:29 <gmaxwell> Luke-Jr: you might find the 'chain folding' one there interesting, as I don't think I'd talked about that much in IRC. (Amiller may have had the same idea, but I wasn't completely clear on it until coming up with it myself. ... after doing so I realized he might have been saying the same thing)
354 2013-02-04 16:47:34 <TD> it's open source actually. but not mergable.
355 2013-02-04 16:47:42 <muhoo> :-(
356 2013-02-04 16:48:36 <Luke-Jr> gmaxwell: it would be neat to start a (general, not user-specific) wiki page listing different ideas and classifying them as no-fork, soft-fork, hard-fork, altcoin, etc
357 2013-02-04 16:49:42 <amiller> a half-formed ideas list maybe...
358 2013-02-04 16:49:59 <gmaxwell> Luke-Jr: yea, well I'm just throwing it on a userpage so I don't forget them (again). Feel free to mine it.  What would be neat to do is to create a summary page for each idea, a short summary, a long argument with links to discussions about it and similar ideas.. then have a table that lists all of them and transcludes the summary pages for their summaries (<includonly>)
359 2013-02-04 16:50:30 <Luke-Jr> gmaxwell: sounds good ;)
360 2013-02-04 16:51:01 <muhoo> TD: in my case, i'm ok with doing my transaction tracking and sales tracking outside of the wallet
361 2013-02-04 16:51:32 <TD> ok
362 2013-02-04 16:51:43 <Luke-Jr> yay, Bitcoin-Qt recovered!
363 2013-02-04 16:52:02 <muhoo> but i see how it could evolve into essentially a wallet of its own
364 2013-02-04 16:54:23 <muhoo> i guess i'll jump off that bridge when i come to it. thanks, got to run for a while. very much appreciate the discussion.
365 2013-02-04 16:57:47 <TD> later
366 2013-02-04 16:58:47 <Pucilowski> I have some transactions (with fee that meet bitcoin fee guidelines) that have a network propagation of 50% (according to blockchain.info) whereas usually blockchain.info reports numbers as high as 300%, somehow
367 2013-02-04 16:59:16 <Pucilowski> anyway, I believe this is why they are taking unusually long to confirm, any ideas how I could re-broadcast it and have nodes relay it again?
368 2013-02-04 17:00:10 <MC1984> how can that site measure propagation?
369 2013-02-04 17:03:36 <gmaxwell> amiller: dunno if you saw before but I did (vaguely) come up with a way to turn POW into clock ticking for timelock encryption.
370 2013-02-04 17:03:44 <gmaxwell> (I just added it to the page now)
371 2013-02-04 17:04:22 <Pucilowski> MC1984: its connected to a lot of nodes, every time its relayed a transaction it logs the ip and it works with that
372 2013-02-04 17:04:33 <Pucilowski> an estimate at best
373 2013-02-04 17:04:54 <MC1984> oh
374 2013-02-04 17:09:55 <Pucilowski> deepbit is the only larger pool that relayed it, hopefully they get a block soon
375 2013-02-04 17:14:48 <eckey> TD: speaking of Wallet, if one were to extend it for the purpose of adding additional data, would that break serialization?
376 2013-02-04 17:15:24 <eckey> Wallet class
377 2013-02-04 18:03:07 <curious> is there a log of #bitcoin-dev?  thx
378 2013-02-04 18:04:07 <MC1984> topic#
379 2013-02-04 18:13:43 <kjj> so, one time, I made a database table too small, and ended up with a bunch of addresses that were missing the last 2 letters
380 2013-02-04 18:14:54 <kjj> I just now got around to writing a script to brute force the missing letters
381 2013-02-04 18:15:20 <HM2> it's amazing how recent some of these EC protocols have been revised/proposed
382 2013-02-04 18:15:40 <kjj> I'm just curious if there is a clever way to reconstruct damaged addresses
383 2013-02-04 18:30:37 <HM2> djj : the last 4 bytes of the 25 byte public key is just a checksum
384 2013-02-04 18:31:06 <HM2> that corresponds to more than 5 characters
385 2013-02-04 18:31:32 <HM2> sorry kjj
386 2013-02-04 18:33:47 <HM2> kjj: https://en.bitcoin.it/w/images/en/9/9b/PubKeyToAddr.png
387 2013-02-04 18:33:50 <kjj> I'm aware of the structure, I use it to validate that I've found the correct missing letters
388 2013-02-04 18:34:31 <HM2> oh right, you've done it already then
389 2013-02-04 18:35:17 <kjj> I know I could have just pulled my pubkeys and recreate the addresses that way.  I just wanted to see if I could fix addresses with a few missing letters on the end
390 2013-02-04 18:37:40 <kjj> brute force is plenty easy, and quick if you are only missing 1 or 2 letters.  after that, it starts getting bad
391 2013-02-04 18:38:23 <HM2> potentially though there could be a collision
392 2013-02-04 18:38:25 <kjj> hmm.  I wonder how much of my time is spent in bcmul()
393 2013-02-04 18:39:18 <HM2> not that it would make a difference
394 2013-02-04 18:39:36 <HM2> you don't need to bruteforce though
395 2013-02-04 18:39:45 <kjj> very slim chance.  the 32 bit checksum gives a 1 in 4 billion chance per try.  that is less than 1% when replacing 4 letters, 15% at 5 letters (take too long to brute force anyway)
396 2013-02-04 18:40:17 <kjj> and at 6 letters, you'd get 8 false positives per correct address
397 2013-02-04 18:40:40 <kjj> (on average)
398 2013-02-04 18:42:29 <kjj> my brute forcer is just a set of loops, each run through it tacks on a different combination of letters, then runs the new string through the decoder (which iterates bcmul) to reconstruct the pubkey and check
399 2013-02-04 18:43:25 <kjj> I bet I could save a lot of time by just adding the original decode to the last decode.
400 2013-02-04 18:46:43 <HM2> isn't base58 fun
401 2013-02-04 18:47:50 <HM2> actually you probably do need to bruteforce it
402 2013-02-04 18:48:27 <kjj> yeah, I can't see any way to avoid that part yet.  but I can make my brute force more efficient
403 2013-02-04 18:50:42 <HM2> kjj, i think you can decode the address you have as a bigint and then multiply by 3364
404 2013-02-04 18:50:50 <HM2> then you only have to do an addition for each combination
405 2013-02-04 18:51:22 <kjj> base58 is placeless
406 2013-02-04 18:51:37 <gmaxwell> placeless?!@#!
407 2013-02-04 18:51:53 <kjj> as in AB means "A * B", not "A*58+B"
408 2013-02-04 18:52:15 <HM2> eh
409 2013-02-04 18:52:18 <HM2> how
410 2013-02-04 18:52:20 <moarrr> kjj? really?
411 2013-02-04 18:52:23 <gmaxwell> 0_o
412 2013-02-04 18:52:46 <kjj> no, shit.  I might still be drunk
413 2013-02-04 18:53:00 <gmaxwell> Sounds like a likely hypothesis.
414 2013-02-04 18:53:10 <HM2> what i mean is if you pad with "00" then you only need to do one multiplication (x 3364) then you can just count up 3364
415 2013-02-04 18:53:21 <moarrr> yeh, what hes saying doesnt make sense if base58 is a binary representation of a number
416 2013-02-04 18:53:23 <HM2> I think?
417 2013-02-04 18:54:10 <jgarzik> on cbitcoin...   https://bitcointalk.org/index.php?topic=123488.msg1503373#msg1503373
418 2013-02-04 18:54:17 <jgarzik> > Do you really intend to convert the newly allocated pointer to an integer and then return it as a boolean?
419 2013-02-04 18:54:24 <jgarzik> Yes, believe it or not. I was in two minds as to whether or not this is a good idea or not, but for the dependencies I've used uint64_t instead of void * so that it is friendly with integer identifiers
420 2013-02-04 18:54:28 <jgarzik> *facepalm*
421 2013-02-04 18:56:42 <HM2> jgarzik: he looks about 15
422 2013-02-04 18:56:50 <HM2> don't be too harsh :P
423 2013-02-04 18:57:01 <kjj> hmm.  ok, I know what I was thinking.
424 2013-02-04 18:58:30 <pjorrit> maybe you should work on cbitcoin ;D
425 2013-02-04 18:58:44 <HM2> who?
426 2013-02-04 18:59:47 <kjj> I just need a new base58 decoder.  mine returns a base256 binary, so I don't bother reconstructing the leading zeros and thus can't tell how many places I'm missing
427 2013-02-04 18:59:52 <pjorrit> kjj, those ints could be multiplied by A * B before casting to bool
428 2013-02-04 19:00:33 <pjorrit> is it faster bruteforcing it or are you doing it for fun?
429 2013-02-04 19:00:38 <kjj> heh.  the logs will show that this wasn't my worst moment of dumb in here.
430 2013-02-04 19:02:38 <kjj> pjorrit: pywallet could have done this in like a second because I have the pubkeys.  but I was curious about how to do it.  it isn't useful, because the right thing to do is ask the recipient to send it again, or to send a new key.  but it is kinda fun
431 2013-02-04 19:13:35 <kjj> ugh.  still plenty of crazies on the forums that think that Avalon might have faked the whole thing
432 2013-02-04 19:30:25 <HM2> kjj: I hear there's a company supercooling their mining equipment on the dark side of the moon
433 2013-02-04 19:33:25 <pjorrit> it's the same trolls who invented jgarzik ;D
434 2013-02-04 19:34:44 <kjj> apparently, some people think that maybe Jeff's miner is proxying requests to a pool for hire, paid for by the preorder cash
435 2013-02-04 19:35:24 <pjorrit> lol that's pretty clever
436 2013-02-04 19:35:38 <pjorrit> would be a pretty crazy con
437 2013-02-04 19:36:43 <gmaxwell> "that explains why it didn't work on p2pool!"
438 2013-02-04 19:37:04 <Goonie> when will rc1 be tagged?
439 2013-02-04 19:37:39 <pjorrit> well of they set it up correctly the proxy would just be retargeted :D
440 2013-02-04 19:41:32 <Luke-Jr> Goonie: I presume after some issues are fixed
441 2013-02-04 19:43:14 <MC1984> "jgarzic" is simply an account which avalon staff share on a rota
442 2013-02-04 20:23:21 <benkay> good morning!
443 2013-02-04 20:48:25 <muhoo> TD: hmm, looking at it, maybe i should just subclass com.google.bitcoinj.core.Wallet ?
444 2013-02-04 20:48:34 <muhoo> or would that be .... evil?
445 2013-02-04 20:48:53 <HM2> It's java. It's already evil
446 2013-02-04 20:49:05 <muhoo> HM2: please, don't tell me that, i already know that.
447 2013-02-04 20:54:43 <muhoo> hmm, in this diagram, it says Base256-to-Base58. is that number in base256? or is it base16 (hex)? https://en.bitcoin.it/w/images/en/9/9b/PubKeyToAddr.png
448 2013-02-04 20:56:29 <HM2> it's the raw 160 bit / 20 byte output from ripemd160()
449 2013-02-04 20:56:56 <HM2> there's no hex encoding
450 2013-02-04 20:57:14 <Luke-Jr> muhoo: neither, it's binary
451 2013-02-04 21:01:55 <HM2> muhoo: you might find the C++ code helpful https://github.com/bitcoin/bitcoin/blob/master/src/base58.h
452 2013-02-04 21:12:50 <HM2> hmm both bitcoind and libbitcoin allocate 138% more space for the base58 encoded value
453 2013-02-04 21:14:04 <HM2> ln 256 / ln 58 = <1.37
454 2013-02-04 21:14:37 <muhoo> that drawing, why does it say base256?
455 2013-02-04 21:14:45 <muhoo> makes. no. sense.
456 2013-02-04 21:15:09 <HM2> base256 is binary, basically
457 2013-02-04 21:15:25 <HM2> not all binary is base256 though :P
458 2013-02-04 21:15:27 <muhoo> base2 was binary last i checked
459 2013-02-04 21:16:07 <muhoo> 
ACTION goes to re-study his number theory

460 2013-02-04 21:16:16 <HM2> right, but a 4 bit string isn't base256 unless you pad it to 8 bits, definite a bit order and label it as such
461 2013-02-04 21:16:38 <gmaxwell> any 2^n base is trivally converted among each other.
462 2013-02-04 21:17:06 <HM2> muhoo : it basically means it's a string of whole bytes
463 2013-02-04 21:19:57 <muhoo> right, 25 raw bytes. i was just tripped up by the term base256 i guess. thanks
464 2013-02-04 21:43:18 <awkorama> Hi everyone. How can I monitor transactions on many addresses in server side situation (e.g. not without any 3rd party) ?
465 2013-02-04 21:48:14 <lianj> what is a wallet token?
466 2013-02-04 22:23:35 <benkay> does anyone have a minute to help me figure out atomic transactions?