1 2013-08-23 00:34:12 <Luke-Jr> in other news, looks like 0.7.x recovered after 0.7.2 hardforked off
2 2013-08-23 00:34:22 <gmaxwell> \\O/
3 2013-08-23 00:34:24 <Luke-Jr> so backport success
4 2013-08-23 00:34:40 <gmaxwell> however, vulnerablity analysis failure.
5 2013-08-23 00:34:53 <gmaxwell> the forking block was smaller than we believed could possibly trigger this.
6 2013-08-23 00:34:55 <warren> Luke-Jr: it seems some are against removal of the internal miner. I personally don't care if it is kept or not. There seems to be no opposition to -disable-wallet with working GBT, so can that be split into a separate path forward?
7 2013-08-23 00:35:12 <warren> Luke-Jr: (I think the reasons for keeping the internal miner are bad, but whatever.)
8 2013-08-23 00:35:17 <Luke-Jr> gmaxwell: yeah, I already suspected the exact nature may be other than we decided it was
9 2013-08-23 00:35:28 <Luke-Jr> due to difficulty fabricating the problem
10 2013-08-23 00:35:52 <gmaxwell> Luke-Jr: did the the recent fork causing event involve a reorg?
11 2013-08-23 00:35:59 <Luke-Jr> warren: it's possible, I'll wait and see how things turn out with the rest
12 2013-08-23 00:36:12 <Luke-Jr> gmaxwell: I don't believe so.
13 2013-08-23 00:36:27 <Luke-Jr> gmaxwell: I did save a copy of the .bitcoin dir before it recovered
14 2013-08-23 00:37:08 <Luke-Jr> ??? though it looks like not before debug.log got truncated :<
15 2013-08-23 00:37:32 <Luke-Jr> but blk*.dat should reveal order of events I suppose
16 2013-08-23 00:38:01 <Luke-Jr> 7.1 GB txz
17 2013-08-23 00:38:15 <gmaxwell> yea, in theory we should be able to reply the blk*.dat to a node to reproduce.
18 2013-08-23 00:56:51 <JyZyXEL> what was that blockchain parser that could be used to generate a list of balances for example?
19 2013-08-23 02:06:03 <weex> block parser?
20 2013-08-23 03:24:33 <Diablo-D3> GARGH
21 2013-08-23 03:24:36 <Diablo-D3> NEED MORE HPMOR
22 2013-08-23 03:34:48 <Vinnie_win> hey what's up fellas
23 2013-08-23 05:16:33 <cjd> Does anybody here know anything about ECC based accumulators? I keep seeing allusions to them but I can't find any papers.
24 2013-08-23 05:35:09 <jurov> https://bugs.gentoo.org/show_bug.cgi?id=480096
25 2013-08-23 05:35:20 <jurov> Luke-Jr: can you please elaborate about the regressions?
26 2013-08-23 05:35:53 <jurov> are they so serious that gentoo stable users gonna use vulerable 0.8.1 ?
27 2013-08-23 05:44:01 <JyZyXEL> what kind of mechanism is there to make sure the address always begins with 1?
28 2013-08-23 05:44:45 <kuzetsa> jurov: some will... but most of the gentoo users I know are comfortable unmasking individual packages via /etc/portage/package.keywords (and .accept_keywords .unmask .use etc. etc. etc.)
29 2013-08-23 05:45:02 <gmaxwell> JyZyXEL: the mechanism of just sticking a 0 byte at the front of the encoded data.
30 2013-08-23 05:47:06 <jurov> kuzetsa, of course i did unmask. but still would like to see it answered
31 2013-08-23 05:48:38 <gmaxwell> jurov: 0.8.4 is rc2 now and will be out in a day or two.
32 2013-08-23 05:48:48 <jurov> ah okay then
33 2013-08-23 05:49:26 <sipa> what version is currently in gentoo stable?
34 2013-08-23 05:49:41 <jurov> 0.8.1 as i said
35 2013-08-23 05:50:00 <sipa> hmm, i don't know of any regressions from 0.8.1 -> 0.8.3
36 2013-08-23 05:50:16 <sipa> though if you can wait, please go for 0.8.4
37 2013-08-23 05:50:39 <gmaxwell> if you don't go to 0.8.4 you're just going to have a mandatory update to it once its out in any case.
38 2013-08-23 05:51:46 <kuzetsa> 1) hmm? why is there a mandatory update coming up for 0.8.4?
39 2013-08-23 05:51:54 <kuzetsa> 2) I'm kinda stuck on the whole "what regressions"
40 2013-08-23 05:52:30 <gmaxwell> kuzetsa: Why are you stuck on something that was already answered?
41 2013-08-23 05:54:00 <kuzetsa> no it wasn't
42 2013-08-23 05:54:10 <kuzetsa> sipa not being aware doesn't mean luke is wrong
43 2013-08-23 05:54:28 <jurov> the question was what kind of regressions are blocking security fixes?
44 2013-08-23 05:54:38 <kuzetsa> aye, what jurov just said
45 2013-08-23 05:54:43 <gmaxwell> You're all confused.
46 2013-08-23 05:54:51 <gmaxwell> Luke mispoke or was mistaken.
47 2013-08-23 05:55:22 <gmaxwell> 0.8.4 is about to be released. 0.8.3 and prior versions have issues and you will want to update to 0.8.4 promptly.
48 2013-08-23 05:55:33 <kuzetsa> is it the memory exhaustion thing?
49 2013-08-23 05:55:48 <gmaxwell> 0.8.4 is in RC2 currently.
50 2013-08-23 05:55:56 <sipa> http://sourceforge.net/mailarchive/forum.php?thread_name=CABsx9T0dXH43TWdCuOURQkENYHxp4tKg58c8avqjxeWTWbRFJQ%40mail.gmail.com&forum_name=bitcoin-development
51 2013-08-23 05:59:16 <kuzetsa> ACTION nods
52 2013-08-23 05:59:43 <kuzetsa> yeah, CVE-2013-4627 is what I was asking about when I said "memory exhaustion thing" ... thanks :)
53 2013-08-23 06:01:38 <jurov> thanks
54 2013-08-23 07:58:42 <Luke-Jr> gmaxwell: I think I was referring to the lock issues some reported.
55 2013-08-23 08:00:26 <sipa> lock issues?
56 2013-08-23 08:57:57 <Luke-Jr> sipa: weren't some people reporting deadlocks?
57 2013-08-23 08:59:18 <warren> Luke-Jr: with what version/
58 2013-08-23 08:59:25 <Luke-Jr> 0.8.3
59 2013-08-23 09:00:00 <sipa> i only know of a deadlock report with the walletmanager pullreq
60 2013-08-23 09:00:45 <Luke-Jr> hmm
61 2013-08-23 09:01:09 <Luke-Jr> kanoi was just mentioning his bitcoind deadlocks a lot since 0.8.3 too
62 2013-08-23 09:02:47 <warren> does he build it himself?
63 2013-08-23 09:03:02 <warren> no problems here with fedora built or gitian built
64 2013-08-23 09:03:10 <Luke-Jr> probably
65 2013-08-23 09:03:24 <Luke-Jr> he also uses getwork apparently (though he doesn't seem upset over its pending removal)
66 2013-08-23 09:03:52 <Luke-Jr> and some undefined "php app"
67 2013-08-23 09:04:48 <warren> cgminer has a php api, is it that?
68 2013-08-23 09:06:11 <warren> only weird problems our users reported: 1) MacOS X 10.5.x works for a few minutes at a time then just stops. 2) ARM works but RPC takes forever to respond.
69 2013-08-23 09:07:44 <Luke-Jr> cgminer's bundled php api doesn't call bitcoind
70 2013-08-23 09:17:12 <sipa> Luke-Jr: oh, the RPC thing?
71 2013-08-23 09:17:15 <sipa> right
72 2013-08-23 09:17:36 <Luke-Jr> sipa: speaking of which, does 0.8.4 fix it? I didn't see a patch :/
73 2013-08-23 09:17:50 <sipa> i don't know of any patch for that
74 2013-08-23 09:17:57 <Luke-Jr> bleh :<
75 2013-08-23 09:18:26 <warren> what RPC thing?
76 2013-08-23 09:18:52 <Luke-Jr> I didn't maintain a 0.8.2.x branch either :<
77 2013-08-23 11:07:48 <doublec> Luke-Jr: I was getting deadlocks with 0.8.2 with getwork
78 2013-08-23 11:07:55 <doublec> Luke-Jr: but not with 0.8.1
79 2013-08-23 11:08:47 <sipa> when was the threads refactor?
80 2013-08-23 11:08:50 <doublec> I did notice that with 0.8.2 using an rpc client that does keep-alive would end up stopping other clients from using the rpc interface but I resolved that by not using keep alive
81 2013-08-23 11:09:31 <doublec> I assume I was hitting some max limit of connections allowed to the bitcoind
82 2013-08-23 11:35:29 <helo> Fourty-two shalt be the connections thou shalt make, and the number of the connections shall be fourty-two. Fourty-three connections shalt thou not create, neither connect thou fourty-one times, excepting that thou then proceed to fourty-two.
83 2013-08-23 11:36:58 <helo> :/
84 2013-08-23 11:40:21 <sipa> fourty-four is way out.
85 2013-08-23 11:57:00 <sipa> ;;genrate 85000
86 2013-08-23 11:57:01 <gribble> The expected generation output, at 85000.0 Mhps, given difficulty of 50810339.0483, is 0.841306212423 BTC per day and 0.0350544255176 BTC per hour.
87 2013-08-23 12:28:57 <moarrr_> oi
88 2013-08-23 12:29:05 <moarrr_> why #bitcoin-dev Cannot send to channel
89 2013-08-23 12:29:09 <moarrr_> and now it works
90 2013-08-23 12:29:49 <jgarzik> mornin'
91 2013-08-23 12:38:51 <Luke-Jr> moarrr_: need to be auth'd with nickserv
92 2013-08-23 12:39:21 <moarrr_> oh thought i was banned for a sec
93 2013-08-23 13:06:00 <jgarzik> hum
94 2013-08-23 13:06:02 <jgarzik> for C++
95 2013-08-23 13:06:09 <jgarzik> is genjix' libbitcoin the library to use?
96 2013-08-23 13:06:17 <jgarzik> disappointing that our ref client isn't lib-ified
97 2013-08-23 13:08:07 <petertodd> jgarzik: note the AGPL license
98 2013-08-23 13:08:16 <petertodd> jgarzik: agreed
99 2013-08-23 13:08:19 <jgarzik> petertodd, ugh :(
100 2013-08-23 13:08:22 <gribble> Error: "@#!#!#@" is not a valid command.
101 2013-08-23 13:08:22 <jgarzik> !@#!#!#@
102 2013-08-23 13:09:35 <petertodd> I have nothing against the AGPL, but it seems like a poor choice for a bitcoin library - it's not like there is any lack of alternatives.
103 2013-08-23 13:10:22 <jgarzik> well C++ alternatives are a more limited set
104 2013-08-23 13:10:55 <petertodd> jgarzik: for now, it wouldn't be a huge amount of effort to libify the ref client
105 2013-08-23 13:11:13 <jgarzik> pondering a pool server: (a) stratum only to miners, (b) GBT to bitcoind, ( c) internal work generation
106 2013-08-23 13:11:39 <sipa> if refactorings were considered high priority for reviewing, i'm sure librarifying wouldn't be much work
107 2013-08-23 13:11:43 <jgarzik> with a bitcoin lib connecting directly to P2P to notice blocks, it would be superior to my C version (pushpool), which was popular in the 'getwork' days
108 2013-08-23 13:12:09 <petertodd> sipa: after all, at worst a bitcoin lib doesn't need to be upstreamed - just take the existing code and make it a library
109 2013-08-23 13:12:26 <jgarzik> sipa, I was tempted to figure out a non-bitcoind project to check into bitcoin.git, as a motivator/proof that lib is possible within bitcoin.git
110 2013-08-23 13:12:29 <sipa> petertodd: you mean libcoin?
111 2013-08-23 13:12:31 <jgarzik> nod
112 2013-08-23 13:12:52 <petertodd> sipa: ah, so it does already exist! all the more reason not to use the AGPL...
113 2013-08-23 13:12:53 <jgarzik> ie.. check the pool server into bitcoin.git. it's really only adding stratum support; everything else is already there.
114 2013-08-23 13:13:13 <jgarzik> separate binary and program, same codebase and git
115 2013-08-23 13:13:20 <jgarzik> makes lib-ifying easier
116 2013-08-23 13:13:54 <sipa> heh? pool server in the bitcoin repo? :o
117 2013-08-23 13:26:54 <jgarzik> radical I know :) put if people want to put a full miner in there...
118 2013-08-23 13:26:58 <jgarzik> *but
119 2013-08-23 13:29:54 <sipa> heh, i want a full miner packaged in it perhaps
120 2013-08-23 13:29:58 <sipa> but not in the same repository
121 2013-08-23 13:30:12 <handle> what is being AGPL'd?
122 2013-08-23 13:30:24 <sipa> nothing
123 2013-08-23 13:30:39 <handle> is libbitcoin already AGPL?
124 2013-08-23 13:30:45 <jgarzik> gavinandresen, RE payment protocol, "at the end of the checkout process, a paymentrequest is generated and sent to the customer's bitcoin client"
125 2013-08-23 13:31:05 <jgarzik> gavinandresen, by what method? clicking on URI?
126 2013-08-23 13:31:15 <jgarzik> gavinandresen, trying to figure out how to deploy this...
127 2013-08-23 13:31:38 <jgarzik> gavinandresen, the "merchant payment service" example on the gist is the best to go by, I've found. BIPs are great for specification, but not flow.
128 2013-08-23 13:31:42 <sipa> jgarzik: you do a http post with the payment, and get a paymentACK back
129 2013-08-23 13:31:59 <jgarzik> sipa, one step before that
130 2013-08-23 13:32:35 <jgarzik> sipa, "customer goes through checkout process? at end of checkout, PaymentRequest is generated and send to the customer's bitcoin client" how is the PR sent to client?
131 2013-08-23 13:32:44 <jgarzik> sipa, http post will not work through firewall, obviously
132 2013-08-23 13:32:48 <sipa> heh
133 2013-08-23 13:32:55 <sipa> the client always starts the connects
134 2013-08-23 13:33:07 <jgarzik> nod
135 2013-08-23 13:33:34 <sipa> customer connects to payment server, gets a payment request, shows the user information, user clicks ok, transaction is created, payment is created, payment is sent to payment_uri, paymentACK comes back
136 2013-08-23 13:33:51 <sipa> ah, you mean how to find the payment server? a URI i suppose
137 2013-08-23 13:33:57 <sipa> isn't that a separate BIP?
138 2013-08-23 13:34:06 <jgarzik> sipa, 0072 I think
139 2013-08-23 13:35:09 <jgarzik> sipa, I'm trying to figure out how to get from "click checkout" to "customer received PaymentRequest"
140 2013-08-23 13:35:45 <jgarzik> Does the customer simply click a "pay now" URI, and we hope their browser is set up correctly to pay?
141 2013-08-23 13:36:01 <sipa> i think so
142 2013-08-23 13:36:08 <petertodd> jgarzik: I'd expect that generally it'll be a URI and either the browser does it right, or they have to copy-n-paste it into their wallet.
143 2013-08-23 13:36:09 <jgarzik> i.e. will BitPay simply put a "bitcoin:xxxx" URI at the final stage of checkout?
144 2013-08-23 13:36:23 <petertodd> jgarzik: In particular, it's important that a qrcode still works so I can pay with my phone.
145 2013-08-23 13:36:24 <jgarzik> That is the part we must figure out ;-)
146 2013-08-23 13:36:37 <jgarzik> We want to support this ASAP
147 2013-08-23 13:36:37 <sipa> poke gavin or mike, i guess :)
148 2013-08-23 13:36:46 <jgarzik> ACTION poked gavin above ;p
149 2013-08-23 13:36:58 <sipa> (and if you can't figure it out from the bip, i think the bip needs improvement :p)
150 2013-08-23 13:37:04 <jgarzik> heh
151 2013-08-23 13:37:18 <k9quaint> petertodd: this is america, nobody shall pay for anything with their phone, ever
152 2013-08-23 13:37:52 <jgarzik> BIP 70 describes the requests themselves. The flow and initiation is? to be divined from a picture
153 2013-08-23 13:37:53 <petertodd> k9quaint: But I'm in Canada, and we're civilized here.
154 2013-08-23 13:38:17 <k9quaint> petertodd: unless you lose an olympic hockey game
155 2013-08-23 13:39:04 <jgarzik> and then, the collective Canadian reaction is "take off, eh"
156 2013-08-23 13:39:26 <jgarzik> anyway
157 2013-08-23 13:39:36 <petertodd> k9quaint: but they apologized after so it's all good
158 2013-08-23 13:39:57 <jgarzik> it sounds like BitPay's main payment protocol implementation problem is "this requires a new, unknown URI format that nobody yet supports"
159 2013-08-23 13:40:04 <jgarzik> thus, clicking will pop up? nothing
160 2013-08-23 13:40:10 <jgarzik> (without user intervention)
161 2013-08-23 13:40:57 <petertodd> jgarzik: my understanding was the idea was the payment protocol would reuse the bitcoin: URI namespace
162 2013-08-23 13:41:05 <sipa> yes, it will
163 2013-08-23 13:41:29 <sipa> but imho, a payment request could just be a file you download with your browser, and have a mime-type that calls your bitcoin client
164 2013-08-23 13:41:40 <petertodd> jgarzik: essentially with an inner URL to tell the client where to get the actual request
165 2013-08-23 13:42:04 <jgarzik> yes, BIP 0072
166 2013-08-23 13:42:13 <jgarzik> but we must worry that the client does not support request=
167 2013-08-23 13:42:26 <jgarzik> i.e. the client knows older bitcoin:
168 2013-08-23 13:42:28 <sipa> well then they don't support the payment protocol
169 2013-08-23 13:42:36 <jgarzik> nod
170 2013-08-23 13:42:43 <jgarzik> but the merchant/checkout/etc. doesn't know that
171 2013-08-23 13:42:43 <sipa> you can try to be compatible, by using just a constant payout address
172 2013-08-23 13:42:55 <sipa> but that means you don't get any of the benefits of the payment protocol either
173 2013-08-23 13:43:03 <petertodd> jgarzik: right, but then either fall back to the address on the screen - best way is make the address clickable, and the URL being clicked is the bitcoin: namespace
174 2013-08-23 13:43:16 <jgarzik> the checkout process cannot know whether they support the payment protocol or not :/
175 2013-08-23 13:43:37 <petertodd> jgarzik: the payment protocol URI thing included a standard address as backup IIRC
176 2013-08-23 13:43:38 <sipa> yeah, that's why i argued that trying to be compatible doesn't make much sense
177 2013-08-23 13:43:45 <sipa> yeah, that's why i argued that trying to be compatible doesn't make much sense
178 2013-08-23 13:43:48 <jgarzik> ACTION kicks xchat
179 2013-08-23 13:43:57 <petertodd> jgarzik: the payment protocol URI thing included a standard address as backup IIRC
180 2013-08-23 13:44:10 <sipa> if you want to advantages of the payment protocol, you can't have a standard address there too
181 2013-08-23 13:44:12 <petertodd> jgarzik: like bitcoin:<address>?payment-procol-url-or-whatever
182 2013-08-23 13:44:19 <jgarzik> petertodd, correct
183 2013-08-23 13:44:33 <jgarzik> and further, I imagine we will include QR code etc. too as you say
184 2013-08-23 13:45:20 <jgarzik> It sounds like we must generate a PaymentRequest each checkout, then handle the case where it is not used at all
185 2013-08-23 13:45:28 <jgarzik> because one must support multiple avenue for payment each checkout :/
186 2013-08-23 13:45:39 <petertodd> sipa: right, the issue is to make it secure you need to ensure that the attacker on the merchant or MITM can't make it fall back to the address, but that's just something we'll have to live with in the interm
187 2013-08-23 13:46:02 <sipa> the purpose should absolutely be to move to payment-uri-only
188 2013-08-23 13:46:12 <petertodd> sipa: yes, but that's can't happen tomorrow
189 2013-08-23 13:46:17 <sipa> sure
190 2013-08-23 13:46:22 <jgarzik> or even in a year :)
191 2013-08-23 13:46:26 <sipa> maybe
192 2013-08-23 13:46:29 <sipa> let's hope
193 2013-08-23 13:46:33 <petertodd> jgarzik: yup... shit, people still don't support P2SH
194 2013-08-23 13:47:07 <jgarzik> ACTION is adding P2SH to libnode (nee bitcoinjs-server) right now, in fact
195 2013-08-23 13:47:20 <jgarzik> hopefully we will start contributing more to the P2SH traffic in the blockchain :)
196 2013-08-23 13:47:43 <jgarzik> flush out the slacker implementations that lack P2SH
197 2013-08-23 13:48:27 <petertodd> jgarzik: ha, better check if python-bitcoinlib does...
198 2013-08-23 13:48:37 <jgarzik> also, on the payment protocol, the proposal is a bit unrealistic for us -- it suggests a cert for each merchant
199 2013-08-23 13:48:52 <jgarzik> no way that happens out of the box, if ever, for our 10,000+ current merchants
200 2013-08-23 13:49:10 <petertodd> jgarzik: Don't those merchants have SSL?
201 2013-08-23 13:50:04 <jgarzik> petertodd, surely they do
202 2013-08-23 13:50:39 <petertodd> jgarzik: right, so use those certs - I mean the logical thing is for the payment protocol to be basically URL based
203 2013-08-23 13:50:59 <jgarzik> petertodd, but (a) obtaining signing authority will be time consuming, (b) also legally difficult in some cases, (c) it is highly unlikely the merchants have sub-certs or separate certs for payment protocol, as recommended
204 2013-08-23 13:51:06 <jgarzik> petertodd, yes
205 2013-08-23 13:51:50 <petertodd> jgarzik: right, in which case there is really nothing that can be done frankly other than an entity liek BitPay acting as a signing authority - have fun with that
206 2013-08-23 13:52:01 <jgarzik> yeppers
207 2013-08-23 13:52:44 <petertodd> jgarzik: yup, at that level the payment protocol might as well have just been "grab this file from this https URL" - far easier to implement for a lot of companies
208 2013-08-23 13:53:19 <petertodd> jgarzik: It'll be especially problematic fro the companies that have their SSL keys embedded in tamper-proof boxes that just don't let you sign things other that SSL traffic with them.
209 2013-08-23 13:59:08 <jgarzik> Real time tracker of 51% attack cost, versus country defense spending: https://www.resallex.com/bitcoin/brix
210 2013-08-23 13:59:59 <Luke-Jr> jgarzik: nice
211 2013-08-23 14:00:09 <Cusipzzz> Namibia can pwn us :/
212 2013-08-23 14:01:03 <Luke-Jr> jgarzik: I suspect it doesn't consider an attacker DDoSing good miners thoug
213 2013-08-23 14:02:13 <petertodd> ACTION wonders what 4GiB/s of bandwidth costs...
214 2013-08-23 14:02:28 <Luke-Jr> petertodd: JEDEC ftw
215 2013-08-23 14:03:15 <petertodd> Luke-Jr: JEDEC?
216 2013-08-23 14:03:35 <Luke-Jr> petertodd: the standard that puts GB at 1024 MB
217 2013-08-23 14:03:49 <petertodd> Luke-Jr: lol, yeah that...
218 2013-08-23 14:13:01 <petertodd> Luke-Jr: oh, BTW I managed to get python-bitcoinlib working in py3 with surprisingly few changes
219 2013-08-23 14:13:13 <petertodd> Luke-Jr: unittests work fine on py2 or py3
220 2013-08-23 14:13:25 <Luke-Jr> nice
221 2013-08-23 14:14:08 <Diablo-D3> http://www.microsoft.com/en-us/news/press/2013/aug13/08-23AnnouncementPR.aspx
222 2013-08-23 14:14:22 <petertodd> Luke-Jr: see https://github.com/jgarzik/python-bitcoinlib/pull/11 for my latest work on CScript, and I'm going to tackle CTransaction and other soon too
223 2013-08-23 15:25:09 <JyZyXEL> how are people able to modify the starting character of the public key addresses?
224 2013-08-23 15:25:27 <JyZyXEL> like how did namecoin make it N?
225 2013-08-23 15:25:47 <Luke-Jr> JyZyXEL: that's done by abusing the version byte
226 2013-08-23 15:26:00 <Luke-Jr> it's meant for Bitcoin versions, but altcoins have taken to using it as a network id
227 2013-08-23 15:26:18 <JyZyXEL> damn thing is very well hidden in the blockparser
228 2013-08-23 15:29:26 <JyZyXEL> im thinking its on the Line 258 https://github.com/znort987/blockparser/blob/master/util.h
229 2013-08-23 15:29:37 <JyZyXEL> but changing those did not have any effect
230 2013-08-23 15:34:09 <JyZyXEL> i wonder how would 48 result in L for the litecoin for example
231 2013-08-23 15:34:30 <JyZyXEL> const uint8_t b58Digits[] = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz";
232 2013-08-23 15:38:29 <JyZyXEL> oh crap, the value was in both the .cpp and .h file :p
233 2013-08-23 15:39:46 <JyZyXEL> setting it to 58 made the hash start with Q :D
234 2013-08-23 15:48:32 <jgarzik> libbitcoin is AGPL, and libcoin is LGPL
235 2013-08-23 15:48:34 <jgarzik> sigh
236 2013-08-23 15:48:55 <jgarzik> does look like libcoin supports mining and pool stuffs already
237 2013-08-23 15:49:47 <Luke-Jr> jgarzik: I seem to recall the libcoin guys saying they'd relicense if it meant merging back
238 2013-08-23 15:50:14 <jgarzik> if theuni would only contribute that autoconf stuff
239 2013-08-23 15:50:28 <jgarzik> I would go ahead and make core.cpp the first file in libbitcoind.a
240 2013-08-23 15:50:37 <jgarzik> and transition could proceed apace from there
241 2013-08-23 15:50:56 <jgarzik> I doubt any merging back will even happen, given such divergent codebases already
242 2013-08-23 15:51:14 <jgarzik> class and method names and tons of cosmetic details are changed
243 2013-08-23 16:14:31 <diatonic> I don't know a better place to send this feedback so I'll post it here... I wish the -qt console would not echo my wallet passphrase when I unlock it.
244 2013-08-23 16:15:29 <Luke-Jr> diatonic: how does it know it's your wallet passphrase?
245 2013-08-23 16:16:23 <diatonic> Luke-Jr, when I need to do something in the console that requires me to unlock it, like importprivkey
246 2013-08-23 16:16:48 <diatonic> I just wish it would hide my actual wallet passphrase when it exho's back
247 2013-08-23 16:16:52 <diatonic> *echo
248 2013-08-23 16:16:57 <Luke-Jr> it doesn't know what you're doing
249 2013-08-23 16:17:00 <Luke-Jr> it's just a dumb terminal
250 2013-08-23 16:17:09 <diatonic> it knows walletpassphrase command
251 2013-08-23 16:17:14 <diatonic> right?
252 2013-08-23 16:17:17 <Luke-Jr> no
253 2013-08-23 16:17:27 <diatonic> oh
254 2013-08-23 16:17:29 <Luke-Jr> whole different part of the code
255 2013-08-23 16:17:41 <gmaxwell> Instead we could add a gui timed unlock which would achieve that end.
256 2013-08-23 16:17:58 <gmaxwell> file->unlock wallet until
257 2013-08-23 16:18:09 <diatonic> well, just feedback I wanted to pass on
258 2013-08-23 16:18:19 <diatonic> When I'm bitcoining around prying eyes
259 2013-08-23 16:18:22 <Luke-Jr> gmaxwell: or maybe a button in the console
260 2013-08-23 16:20:17 <oleganza> does anybody know why nHashType is a an argument in VerifyScript, EvalScript, CheckSig etc.? In every place it's 0 and when it's zero it is read from the last byte of the signature.
261 2013-08-23 16:20:25 <oleganza> is it just a historical artifact?
262 2013-08-23 16:21:21 <oleganza> so essentially in tx verification process, hash type is always being read from the signature
263 2013-08-23 16:21:53 <gmaxwell> oleganza: it is not zero everywhere. It's the sighash type.
264 2013-08-23 16:22:22 <oleganza> where in the source code a non-zero value is passed?
265 2013-08-23 16:22:37 <oleganza> i've only seen zeros and reading it from the signature inside CheckSig
266 2013-08-23 16:22:43 <gmaxwell> The different types are here: https://en.bitcoin.it/wiki/OP_CHECKSIG
267 2013-08-23 16:22:47 <oleganza> i know that
268 2013-08-23 16:23:01 <gmaxwell> oleganza: it's read out of the transactions, and signrawtransaction lets you specify the type.
269 2013-08-23 16:23:55 <oleganza> i mean, it seems to me we don't need that argument in CheckSig: it always gets 0 and then does this: if (nHashType == 0) nHashType = vchSig.back();
270 2013-08-23 16:24:07 <oleganza> or am I missing something?
271 2013-08-23 16:24:45 <gmaxwell> oleganza: oh, the argument? No idea, the argument may indeed be unneeded. Check the unit tests.
272 2013-08-23 16:27:02 <oleganza> gmaxwell: ah, yes. It's used in unit tests with SIGHASH_NONE
273 2013-08-23 16:27:30 <oleganza> i wonder why it does that
274 2013-08-23 17:52:18 <TheLordOfTime> anyone able to tell me what the current difficulty is on testnet?
275 2013-08-23 17:53:45 <TheLordOfTime> i can't load bitcoin-qt or bitcoind on here to check, because of a segfault related to memory issues on this system
276 2013-08-23 17:54:34 <c0rw1n> whut about fixing the ram?
277 2013-08-23 17:55:27 <jgarzik> TheLordOfTime, 301
278 2013-08-23 17:55:53 <TheLordOfTime> c0rw1n, that'll happen when the system is replaced.
279 2013-08-23 17:56:00 <TheLordOfTime> jgarzik, thanks
280 2013-08-23 17:56:25 <c0rw1n> oh ok
281 2013-08-23 17:56:47 <TheLordOfTime> c0rw1n, the system is so broken i can't power down the system without it *not* being able to be booted again
282 2013-08-23 17:57:07 <c0rw1n> TheLordOfTime it's time to can it maybe?
283 2013-08-23 17:57:09 <TheLordOfTime> c0rw1n, so this system *must* remain on until I replace the system and move my wallet(s) to here.
284 2013-08-23 17:57:26 <TheLordOfTime> c0rw1n, yes, well, unless you can transfer $1100 to my bank account by, oh, Monday, i have to wait a while :/
285 2013-08-23 17:57:39 <c0rw1n> waitwhut, you don't have three copies of the private keys?
286 2013-08-23 17:57:47 <TheLordOfTime> c0rw1n, i do, i meant the testnet wallets
287 2013-08-23 17:58:08 <TheLordOfTime> main net keys, backed up. testnet keys/wallets, not so much
288 2013-08-23 17:58:10 <TheLordOfTime> because testnet :P
289 2013-08-23 18:00:14 <c0rw1n> well if you're using testnet you're supposed to know what you're doin', rite
290 2013-08-23 18:00:36 <c0rw1n> so keys backups are supposed to ha e been done correctly
291 2013-08-23 18:00:51 <TheLordOfTime> c0rw1n, true, except since my addresses no longer have any testnet coin in them...
292 2013-08-23 18:01:05 <TheLordOfTime> kind of pointless... been working with an active testnet node recently and *that* is still running.
293 2013-08-23 18:01:17 <TheLordOfTime> the system that keeps segfaulting, that one's broken beyond help
294 2013-08-23 18:02:04 <TheLordOfTime> ... bah now my web server died :/
295 2013-08-23 18:02:21 <c0rw1n> mh ok, so canning the b0red box would not lose you money or anything
296 2013-08-23 18:02:25 <TheLordOfTime> nope
297 2013-08-23 18:03:12 <c0rw1n> wtf typos, s/b0red/b0rKed
298 2013-08-23 18:03:36 <TheLordOfTime> c0rw1n, besides, even if I didn't back up my main net keys, i've got 160 other privkeys i could use for vanitygen'd addresses matching similar prefixes.
299 2013-08-23 18:03:45 <TheLordOfTime> c0rw1n, and, i have 0 coins on main net anyways :p
300 2013-08-23 18:04:03 <c0rw1n> (am too drunk for -dev. just managed to make three bottles fall down without touching them.)
301 2013-08-23 18:04:13 <TheLordOfTime> any bitcoins i have, including fractional amounts, are on physical coins anyways, and those are in a safe.
302 2013-08-23 18:04:26 <c0rw1n> am impressed
303 2013-08-23 18:04:48 <TheLordOfTime> ACTION yawn
304 2013-08-23 18:04:51 <TheLordOfTime> bleh i need more coffee
305 2013-08-23 18:05:01 <c0rw1n> you don't have 0 coin on mannet then though
306 2013-08-23 18:05:07 <c0rw1n> grr typos
307 2013-08-23 18:05:19 <c0rw1n> cause you have privkeys to coins
308 2013-08-23 18:05:26 <c0rw1n> thus you can spend them
309 2013-08-23 18:05:30 <TheLordOfTime> c0rw1n, true, however on the addresses in that wallet, there's 0
310 2013-08-23 18:05:41 <TheLordOfTime> and i haven't used the privkeys for the physical coins yet :P
311 2013-08-23 18:05:46 <c0rw1n> in the wallet, not in the physical coins
312 2013-08-23 18:05:51 <c0rw1n> yeah
313 2013-08-23 18:06:10 <TheLordOfTime> c0rw1n, true, but with no unspent outputs (i sold my bitcoins already) the net amount ends up with me having no bitcoins
314 2013-08-23 18:06:14 <TheLordOfTime> except physical coin amounts
315 2013-08-23 18:06:29 <c0rw1n> ooh, we could sell anonymous-er physical coins
316 2013-08-23 18:06:32 <TheLordOfTime> heh
317 2013-08-23 18:06:40 <c0rw1n> if you mine 25 btc
318 2013-08-23 18:06:41 <TheLordOfTime> oh boo stupid firewall
319 2013-08-23 18:07:00 <c0rw1n> you could sell them for like say 25.25btc
320 2013-08-23 18:07:11 <c0rw1n> in physical form
321 2013-08-23 18:07:15 <c0rw1n> if you're a miner
322 2013-08-23 18:07:20 <c0rw1n> or pool op
323 2013-08-23 18:07:37 <c0rw1n> (wrong channel mebbe)
324 2013-08-23 18:09:39 <TheLordOfTime> heh
325 2013-08-23 18:12:10 <c0rw1n> #bitcoin seems to ignore the idea
326 2013-08-23 18:12:19 <c0rw1n> doesn't matter, it's in the logs 'neway
327 2013-08-23 18:13:50 <TheLordOfTime> what's the default rpc port for bitcoind/bitcoin-qt running on testnet?
328 2013-08-23 18:13:57 <TheLordOfTime> i forgot what the port was...
329 2013-08-23 18:14:19 <jgarzik> 1XXXX, where XXXX is the non-testnet port
330 2013-08-23 18:14:28 <jgarzik> 18332, 18333
331 2013-08-23 18:14:50 <TheLordOfTime> jgarzik, i thought 18332, 18333, but apparently those resulted in a network failure on my end...
332 2013-08-23 18:14:54 <TheLordOfTime> no idea why, but it's working now :/
333 2013-08-23 18:45:10 <rubino123> how can I momentarily shutdown the ports that bitcoind is recieving blockchain data on?
334 2013-08-23 18:47:00 <diatonic> rubino123, pull the ethernet cable
335 2013-08-23 18:47:26 <rubino123> I tried but Bezos told me to get the hell off the farm
336 2013-08-23 18:47:48 <c0rw1n> so what are you still doing there?
337 2013-08-23 18:49:02 <rubino123> I still need ssh access; so on linux how can I close all ports at once except ssh and then set them back to the original position?
338 2013-08-23 18:49:18 <rubino123> perhaps #linux
339 2013-08-23 18:49:31 <rubino123> would be a better place to ask
340 2013-08-23 18:49:52 <rubino123> unless bitcoind can do this on its own
341 2013-08-23 18:49:58 <Tril> rubino123 there's a tool called tcpkill that can forge the reset packets.
342 2013-08-23 18:50:14 <Tril> if you want them not to re-open then use iptables too
343 2013-08-23 18:50:26 <rubino123> can bitcoind not just stop network comms on its own?
344 2013-08-23 18:50:58 <Tril> can't you just stop bitcoind
345 2013-08-23 18:51:29 <c0rw1n> killall -9 bitcoind
346 2013-08-23 18:51:35 <diatonic> bitcoind stop
347 2013-08-23 18:51:38 <c0rw1n> "there, i fixed it"
348 2013-08-23 18:51:39 <diatonic> probably more graceful
349 2013-08-23 18:51:39 <rubino123> Tril: I still need access to the blockchain to look at all confirmations to address at that point. Can I use the sx tool?
350 2013-08-23 18:51:59 <c0rw1n> better : killall -SIGKILL bitcoind
351 2013-08-23 18:52:14 <c0rw1n> or was it -KILL
352 2013-08-23 18:52:14 <rubino123> I would use abe but it takes weeks to bring up to speed
353 2013-08-23 18:52:17 <Luke-Jr> rubino123: there's a pullreq to add a network activity switch
354 2013-08-23 18:52:26 <rubino123> Amen.
355 2013-08-23 18:52:40 <diatonic> rubino123, blockchain.info?
356 2013-08-23 18:52:48 <rubino123> So its already writter in someones private branch?
357 2013-08-23 18:52:54 <Luke-Jr> yes
358 2013-08-23 18:53:06 <Luke-Jr> maybe was rejected too, I forget
359 2013-08-23 18:53:41 <rubino123> I am working on several time critical applications... it would be easier to just stop network activity without jumping all over iptables
360 2013-08-23 18:55:39 <rubino123> any fast blockchain parsers that do not require bitcoind on?
361 2013-08-23 18:55:50 <c0rw1n> SPV client, arguably
362 2013-08-23 18:56:21 <c0rw1n> or take apart the code and call the primitives however you want to (but do that in testnet)
363 2013-08-23 18:56:46 <Tril> rubino123: I'd just stop bitcoind then run it again with -connect=127.0.0.1. It will never get other peers and you can still look at your history
364 2013-08-23 18:57:05 <rubino123> Ah, That would do it
365 2013-08-23 18:57:10 <rubino123> thanks
366 2013-08-23 21:04:26 <warren> Luke-Jr: I'm hoping more people weigh in on the remove internal miner issue so a decision can be made soon. Litecoin already removed the internal miner entirely. If the decision here is to not remove it, then I'll help to implement/test the variant PR that keeps it but allows disable-wallet and removal of getwork.
367 2013-08-23 21:12:02 <AlexNagy> LiteCoin removed the internal miner? Well no point in keeping the wallet for me. I'm not going to hit up LTC faucets like I did with BTC faucets. Too much work for too little reward.
368 2013-08-23 21:13:04 <warren> AlexNagy: if you enjoy burning electricity with an almost zero chance of reward, fine by me.
369 2013-08-23 21:13:32 <gmaxwell> AlexNagy: do you have an LTC wallet at all?
370 2013-08-23 21:13:39 <k9quaint> the only use I could see would be as a reference implementation of the mining process
371 2013-08-23 21:14:09 <AlexNagy> warren: I'm not making an argument to keep the internal bitcoin-qt miner, mind you. Just surprised litecoin-qt did. gmaxwell I do, but with not coins in it. I was hoping to use litecoin-qt's internal miner to mine some.
372 2013-08-23 21:14:29 <AlexNagy> Unfortunately the port maintainer won't keep it updated.
373 2013-08-23 21:14:38 <Luke-Jr> there's no need for reference miners anymore
374 2013-08-23 21:14:55 <sipa> a reference client is useful, but a python script can do that just fine :)
375 2013-08-23 21:15:03 <sipa> s/client/miner/
376 2013-08-23 21:15:08 <Luke-Jr> sipa: useful for what?
377 2013-08-23 21:15:20 <k9quaint> Luke-Jr: as a reference :P
378 2013-08-23 21:15:23 <sipa> ^
379 2013-08-23 21:15:23 <warren> AlexNagy: the internal miner of both bitcoin and litecoin are terrible compared to other CPU miners anyway.
380 2013-08-23 21:15:31 <k9quaint> ACTION high fives sipa
381 2013-08-23 21:15:43 <Luke-Jr> SHA256d is too simple to need a reference.
382 2013-08-23 21:15:44 <sipa> just to explain the process, with no regard for efficiently
383 2013-08-23 21:15:55 <Luke-Jr> sipa: oh, then libblkmaker's example should do fine
384 2013-08-23 21:16:19 <AlexNagy> warren: then why is there a debate about keeping it? If they are terrible compared to others, out with it. (:
385 2013-08-23 21:16:59 <warren> AlexNagy: some expressed a desire to keep it for reasons that amount to convenience.
386 2013-08-23 21:17:25 <AlexNagy> warren: how is inefficiency convenient?
387 2013-08-23 21:17:50 <warren> AlexNagy: You should know well that there is not a lot of rationality here.
388 2013-08-23 21:18:20 <Luke-Jr> sipa: https://gitorious.org/bitcoin/libblkmaker/blobs/master/example.c
389 2013-08-23 21:18:23 <AlexNagy> ACTION thinks there should be, but understands as he is often irrational
390 2013-08-23 21:19:49 <k9quaint> if you are looking to explain the process to someone for the first time, an unoptimized naive solution is often a good starting point
391 2013-08-23 21:20:18 <Luke-Jr> k9quaint: like that example? :p
392 2013-08-23 21:20:49 <k9quaint> I was thinking of brute force traveling salesman solution
393 2013-08-23 21:21:16 <Luke-Jr> huh?
394 2013-08-23 21:21:39 <AlexNagy> I also find my 'rational thoughts' differ wildly from other people's idea of 'rational' a bit too often, too.
395 2013-08-23 22:47:11 <warren> https://github.com/bitcoin/bitcoin/pull/2917 Hi, could more of the core devs please add your opinion to this? It would be helpful to decide one way or the other.
396 2013-08-23 22:53:12 <Cusipzzz> <-- cpu mines sometimes