1 2013-12-29 00:00:04 <warren> until a restart
2 2013-12-29 00:00:10 <CodeShark> perhaps if nothing is heard from the connection in x seconds, we ping automatically
3 2013-12-29 00:00:24 <sipa> warren: hmm, that sounds like a different issue
4 2013-12-29 00:00:27 <CodeShark> where x isn't a huge number
5 2013-12-29 00:00:37 <sipa> CodeShark: i should make https://github.com/bitcoin/bitcoin/pull/2784 up to date
6 2013-12-29 00:01:01 <CodeShark> yeah
7 2013-12-29 00:02:54 <CodeShark> while we're at it, we should be compiling statistics on peer latency and providing it in addr messages :)
8 2013-12-29 00:03:50 <foamz> what does Dual EC DRBG being compromised mean for Bitcoin? Is Bitcoin safe because it uses ECDSA?
9 2013-12-29 00:04:06 <CodeShark> we should also compute a peer reliability metric (how accurate/relevant the information a peer sends us is)
10 2013-12-29 00:04:40 <sipa> foamz: ECDSA has nothing to do with EC DRBG
11 2013-12-29 00:04:53 <sipa> well, it's both based on EC curves
12 2013-12-29 00:05:41 <foamz> so EC itself isnt broken right?
13 2013-12-29 00:05:49 <foamz> just dual EC DRBG?
14 2013-12-29 00:05:55 <sipa> yes
15 2013-12-29 00:05:57 <CodeShark> not that I'm aware of
16 2013-12-29 00:06:11 <foamz> yeah i thought so
17 2013-12-29 00:06:23 <foamz> someone was ranting to me about how bitcoins are worthless now
18 2013-12-29 00:06:30 <foamz> and it didnt make sense to me
19 2013-12-29 00:06:31 <sipa> people always rant; let them
20 2013-12-29 00:06:50 <foamz> but i dont know enough about crypto to shut him up :q
21 2013-12-29 00:07:23 <gmaxwell> foamz: tell him you'll buy all has for $1/ea then.
22 2013-12-29 00:09:01 <sipa> foamz: the wikipedia article explains it quite well
23 2013-12-29 00:09:32 <sipa> the algorithm requires a particular chosen point, which is presumably generated randomly, but wasn't proven to be
24 2013-12-29 00:09:44 <foamz> hah
25 2013-12-29 00:10:14 <foamz> i understand a bit, i just dont understand how the random isn't random though
26 2013-12-29 00:10:28 <foamz> like how do you introduce pseudo random code like that
27 2013-12-29 00:10:38 <foamz> and not have tons of people notice
28 2013-12-29 00:10:53 <sipa> very simply: in EC you have numbers and points
29 2013-12-29 00:11:25 <sipa> every number (~secret keys) corresponds to a single point (~public keys), and the other way around
30 2013-12-29 00:11:38 <foamz> with you so far
31 2013-12-29 00:12:11 <sipa> however, going from number to point is easy (a modern CPU can do such conversion in the order of 100000 times per second), going the other way is presumed to be extremely hard
32 2013-12-29 00:12:35 <deanclkclk> if I'm banned from #bitcoin how long it take for getting unbanned?
33 2013-12-29 00:12:49 <foamz> i dont think this is the right place to ask
34 2013-12-29 00:12:59 <sipa> complaining about it here certainly won't help :)
35 2013-12-29 00:13:07 <foamz> i suggest you pm midnight and apologize and wait it out :P
36 2013-12-29 00:13:13 <deanclkclk> wasn't complaining..was asking a question
37 2013-12-29 00:13:28 <deanclkclk> who's the pm?
38 2013-12-29 00:13:46 <deanclkclk> ohh sorry
39 2013-12-29 00:13:50 <Emcy> i think cycling your IP and trying again just makes them more angry
40 2013-12-29 00:14:04 <foamz> anyway
41 2013-12-29 00:14:12 <foamz> i understand at least that much sipa
42 2013-12-29 00:14:21 <sipa> foamz: anyhow, that algorithm (DBRG) required a point for which nobody knows the corresponding number
43 2013-12-29 00:14:39 <sipa> that's possible by generating the point directly, instead of from a number
44 2013-12-29 00:15:12 <sipa> however, in this case, and this was a known weakness in the system, it wasn't actually known how the point in the standard was generated
45 2013-12-29 00:15:33 <foamz> ah i see, so the entropy or bits used to generate the point
46 2013-12-29 00:15:39 <foamz> is whats compromised
47 2013-12-29 00:15:40 <Emcy> sipa yes it was, NSa did it lolol
48 2013-12-29 00:15:50 <sipa> Emcy: well, now it is known
49 2013-12-29 00:16:02 <sipa> when the standard was published, that wasn't the case
50 2013-12-29 00:16:10 <Emcy> yes
51 2013-12-29 00:16:16 <foamz> ok i got it now
52 2013-12-29 00:16:21 <foamz> thanks for the explanation
53 2013-12-29 00:16:28 <sipa> though apparently even then it was questioned, as there was no proof about how the point was generayed
54 2013-12-29 00:16:43 <sipa> it could easily have been done in a way that guaranteed that nobody knew the corresponding number
55 2013-12-29 00:16:49 <Emcy> how is it that any scheme can get standardised by NIST without using those nothing up my sleeve primatives
56 2013-12-29 00:17:00 <sipa> Emcy: $$$
57 2013-12-29 00:17:03 <sipa> :p
58 2013-12-29 00:17:16 <foamz> so do we know the specific logic being used the generate the point?
59 2013-12-29 00:17:24 <foamz> or do we just know that is has been compromised
60 2013-12-29 00:17:36 <Emcy> i dont think they were paid off, i think NSA had people on the inside
61 2013-12-29 00:17:36 <sipa> well, yes, they generated a random number, and converted it to a point
62 2013-12-29 00:17:43 <Emcy> RSA however was indeed paid off
63 2013-12-29 00:17:43 <sipa> and did not forget the number
64 2013-12-29 00:18:08 <sipa> instead, they should have used a deterministic random generation algorithm that constructed a point directly
65 2013-12-29 00:19:09 <foamz> i see
66 2013-12-29 00:22:28 <warren> sipa: the only change we made with 0.8.6 was upgrading to boost-1.54 to match bitcoin master. I'm going to try downgrading to see if that makes any difference.
67 2013-12-29 00:22:50 <warren> I suppose it's good if we shake out bugs ...
68 2013-12-29 00:22:56 <warren> Litecoin needs a purpose.
69 2013-12-29 00:23:36 <foamz> so do we know what the "secret numbers" yet?
70 2013-12-29 00:23:42 <foamz> are yet*
71 2013-12-29 00:23:59 <foamz> or does just the NSA know that
72 2013-12-29 00:24:22 <sipa> foamz: they haven't even confirmed this, why would they reveal it?
73 2013-12-29 00:25:29 <Emcy> foamz what does it matter, who the hell is going to use that crypto now?
74 2013-12-29 00:25:40 <foamz> wouldnt it be possible to reverse engineer it though?
75 2013-12-29 00:25:43 <Emcy> i think NIST even rescinded the standard
76 2013-12-29 00:25:54 <sipa> foamz: _that_ would require breaking EC entirely
77 2013-12-29 00:25:58 <foamz> yeah but im sure a lot of live systems out there still use it
78 2013-12-29 00:26:03 <foamz> i see
79 2013-12-29 00:26:14 <Emcy> like rsa bsafe
80 2013-12-29 00:26:32 <Emcy> what i want to know is where is the hugeass class action lawsuit
81 2013-12-29 00:27:00 <Emcy> or are corporate customers too scared of annoying the feds even by proxy
82 2013-12-29 00:27:41 <foamz> corporate customers will keep their trap shut unless they suddenly lose a lot of sensitive data
83 2013-12-29 00:28:36 <warren> cfields: you still plan on upgrading the other win32 gitian deps?
84 2013-12-29 00:29:27 <Emcy> foamz oh well kind of OT now i suppose
85 2013-12-29 00:29:33 <cfields> warren: qt was the main one i was targetting, and the new descriptor is included in the qt5 pr
86 2013-12-29 00:30:08 <warren> cfields: any feelings about upgrading boost again?
87 2013-12-29 00:30:26 <cfields> for what reason?
88 2013-12-29 00:30:38 <warren> higher number
89 2013-12-29 00:30:47 <cfields> heh, that's not a reason
90 2013-12-29 00:31:24 <cfields> if it was, they'd be on boost v35.0 by now :)
91 2013-12-29 00:32:03 <sipa> i prefer 42
92 2013-12-29 00:32:04 <warren> it's possible 1.54 broke something
93 2013-12-29 00:32:07 <cfields> warren: my only real input for boost would be sticking to what macports uses
94 2013-12-29 00:32:16 <cfields> since that's the roughest environment to build
95 2013-12-29 00:32:16 <sipa> warren: p2p networking doesn't use boost
96 2013-12-29 00:32:24 <sipa> warren: it would very much surprise me
97 2013-12-29 00:32:34 <warren> sipa: ok, then I have no idea what changed, we didn't touch anything else.
98 2013-12-29 00:32:49 <HM2> there's a guy at 30C3 with a Bitcoin atm. Looks like a nice bit implementation
99 2013-12-29 00:33:03 <warren> it's only a tiny minority of our users complaining about this too
100 2013-12-29 00:33:05 <sipa> warren: has this problem been reproduced more than once?
101 2013-12-29 00:33:12 <warren> sipa: about a dozen reports
102 2013-12-29 00:33:13 <CodeShark> p2p networking should use boost. asio is a nice library :)
103 2013-12-29 00:33:35 <sipa> meh
104 2013-12-29 00:33:50 <warren> some of them claim they had no problem with 0.8.5
105 2013-12-29 00:34:03 <cfields> imo, using boost libs that aren't header-only should be avoided unless 100% necessary
106 2013-12-29 00:34:16 <cfields> they're such a hassle
107 2013-12-29 00:35:22 <cfields> (not a gripe against what's currently in-use, i only meant if considering adding more)
108 2013-12-29 00:35:28 <justanotheruser> If I used OP_TRUE, and someone tried to spend it, a miner could just steal it right?
109 2013-12-29 00:35:51 <lianj> justanotheruser: yes
110 2013-12-29 00:35:54 <lianj> and does
111 2013-12-29 00:36:05 <cfields> especially now that c++11 is reasonably deployed
112 2013-12-29 00:36:38 <HM2> cfields, asio is header only
113 2013-12-29 00:36:47 <HM2> or at least it can be
114 2013-12-29 00:36:57 <justanotheruser> Is there any way to make a transaction spendable by someone I don't know the address of and only give the transaction to?
115 2013-12-29 00:37:30 <sipa> justanotheruser: if you can give them a transaction, why can't you ask for a public key?
116 2013-12-29 00:38:05 <justanotheruser> sipa: because I don't know who I'm going to give the transaction to. It will just be a piece of data someone will have access to eventually.
117 2013-12-29 00:38:07 <CodeShark> cfields: I just ran into some problems with boost_log Lo
118 2013-12-29 00:38:21 <CodeShark> it is annoying it is not header only
119 2013-12-29 00:38:32 <cfields> CodeShark: ah, i forgot to respond to your mail
120 2013-12-29 00:38:48 <cfields> CodeShark: sorry, been caught up in holiday stuff the last 2 weeks
121 2013-12-29 00:38:53 <CodeShark> cfields: no worries :)
122 2013-12-29 00:38:59 <CodeShark> I figured
123 2013-12-29 00:39:24 <CodeShark> anyhow, asio can be header only and is actually quite nice to use :)
124 2013-12-29 00:39:39 <CodeShark> I've migrated all my p2p networking code to it
125 2013-12-29 00:39:49 <justanotheruser> sipa: specifically, I want to have a hash h(x), and the first person to find x I want to pay.
126 2013-12-29 00:40:31 <sipa> justanotheruser: impossible without risking miners stealing it
127 2013-12-29 00:40:35 <gmaxwell> justanotheruser: no, not currently. You can achieve what you want with an interactive protocol though.
128 2013-12-29 00:40:48 <gmaxwell> Its _currently_ impossible, its not fundimentally impossible.
129 2013-12-29 00:41:12 <justanotheruser> gmaxwell: Is it fundamentally impossible to do it without an interactive protocol?
130 2013-12-29 00:41:16 <gmaxwell> No.
131 2013-12-29 00:41:41 <gmaxwell> justanotheruser: the interactive protocol looks like the outer (bitcoin transaction) part of this, https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment
132 2013-12-29 00:41:58 <justanotheruser> I'm guessing there aren't any disallowed opcodes that would make it possible gmaxwell?
133 2013-12-29 00:42:02 <gmaxwell> justanotheruser: No.
134 2013-12-29 00:44:37 <justanotheruser> gmaxwell: Would P2SH allow it?
135 2013-12-29 00:45:38 <gmaxwell> justanotheruser: No.
136 2013-12-29 00:45:41 <gmaxwell> justanotheruser: No. To achieve what you want, you need validation for a non-internative zero-knoweldge signature-of-knoweldge for a statement like "Z is an encryption under Q, of X such that H(X)==R" in script, and you provide the Q,R.
137 2013-12-29 00:46:50 <gribble> Internative | Facebook: <https://www.facebook.com/pages/Internative/108756475813938>; Eristoff Internative Festival I « onionlab.com: <http://www.onionlab.com/eristoff-internative-festival-i/>; Eristoff Internative Festival II « onionlab.com: <http://www.onionlab.com/eristoff-internative-festival-ii-3/>
138 2013-12-29 00:46:50 <justanotheruser> ;;google internative
139 2013-12-29 00:47:01 <gmaxwell> hah
140 2013-12-29 00:47:02 <gmaxwell> interactive.
141 2013-12-29 00:47:22 <justanotheruser> I see
142 2013-12-29 00:48:26 <gmaxwell> (and even that has a bit of a clawback race, an interactive protocol is a lot more secure)
143 2013-12-29 00:49:44 <gmaxwell> e.g. someone redeems your coin and you see the txn, so you now know X (because you can decrypt Z) and so you can try to doublespend race it. That could be fixed by making the redemption two phase, but that requires even more complicated transaction changes.
144 2013-12-29 00:50:25 <gmaxwell> justanotheruser: there is another way to somewhat safely redeem an anonymous hashlocked transaction.
145 2013-12-29 00:51:27 <justanotheruser> gmaxwell: oh? What is it?
146 2013-12-29 00:52:36 <gmaxwell> And thats to ask a miner to blindly mine it for you... e.g. you don't tell them anything but the txid to include. Of course, you can make them mine an invalid block this way, by giving them garbage or not rapidly handing over the transaction data when they find a block... but thats easily solved by just buying out their full hashpower so they don't care if you're throwing the work away or not.
147 2013-12-29 00:53:47 <sipa> if it's worth enough to buy a full block's worth of hashpower for, it may also be worth enough for others to reorganize the block away...
148 2013-12-29 00:54:07 <gmaxwell> sipa: perhaps, though "worth enough"â it's not like you're throwing away the coin. :P
149 2013-12-29 00:54:24 <sipa> right
150 2013-12-29 00:54:39 <gmaxwell> that was my 'somewhat' though. :P
151 2013-12-29 00:54:54 <sipa> but if it's a transaction that credits you let's say 10 blocks worth of subsidy/fees, then this approach won't be safe
152 2013-12-29 00:55:04 <gmaxwell> Indeed.
153 2013-12-29 00:55:38 <justanotheruser> gmaxwell: The reason I want to do this is so people can have timed secrets. I AES encrypt a document containing my secret. The password to the document is a hash of the concatenation of the data for the hashes values for a number of transactions. Miners could do "secret mining", where they try to find the value for hashlocked transaction for a reward. The central limit theorem says my secret will probably take a certain amount
154 2013-12-29 00:55:56 <gmaxwell> you're trying to achieve timelock encryption.
155 2013-12-29 00:56:16 <justanotheruser> gmaxwell: yes, but with bitcoin you can add an incentive
156 2013-12-29 00:56:51 <gmaxwell> well, as you can see, you can't easily.
157 2013-12-29 00:56:55 <justanotheruser> indeed
158 2013-12-29 00:57:19 <gmaxwell> justanotheruser: you may note I have timelock encryption on my altideas page.
159 2013-12-29 00:57:43 <justanotheruser> link?
160 2013-12-29 00:57:52 <nsh> timelock encryption is definitely possible
161 2013-12-29 00:58:01 <gmaxwell> justanotheruser: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas
162 2013-12-29 01:02:15 <gmaxwell> justanotheruser: you should /join #bitcoin-wizards
163 2013-12-29 01:02:30 <gmaxwell> as thats where most of the not really production development related crypto ideas go to die.
164 2013-12-29 01:05:20 <justanotheruser> joined
165 2013-12-29 01:08:24 <Ryan52> Can their be multiple valid merkle roots for a given block? Or is the merkle tree supposed to be balanced?
166 2013-12-29 01:08:36 <midnightmagic> ideas never die! they just need rediscovering every once in a while
167 2013-12-29 01:10:01 <h2odysee> if I use "bitcoind sendmany ..." and get "Transaction too large", is that limit set by the protocol? Am I forced to split the transaction up into multiple, or is there a workaround to get it as one transaction?
168 2013-12-29 01:10:18 <Ryan52> I saw a reference implementation that did create balanced merkle trees on the bitcoin wiki, but I'm seeing another implementation (that I don't know if it works properly) that adds a new level for each leaf. I'm wondering if both are acceptable or only the first one.
169 2013-12-29 01:11:09 <sipa> Ryan52: merkle trees for what?
170 2013-12-29 01:11:21 <sipa> if it's for the transactions in a block, there is only one allowed shape
171 2013-12-29 01:12:17 <CodeShark> yes, the merkle root is unique
172 2013-12-29 01:12:24 <Ryan52> sipa: Yeah, for the merkle root in the header, thanks for the answer.
173 2013-12-29 01:12:47 <Ryan52> I'm confused because the stratum mining proxy (https://github.com/slush0/stratum-mining-proxy/blob/master/mining_libs/jobs.py#L70) builds the merkle root like this:
174 2013-12-29 01:12:50 <Ryan52> for h in self.merkle_branch:
175 2013-12-29 01:12:53 <Ryan52> merkle_root = utils.doublesha(merkle_root + h)
176 2013-12-29 01:12:57 <Ryan52> Which would be an incorrect shape, right?
177 2013-12-29 01:13:19 <sipa> no
178 2013-12-29 01:13:33 <sipa> it's recomputing a single branch of the merkle tree
179 2013-12-29 01:15:37 <Ryan52> Oh, so the stratum protocol just gives the details to recompute a branch rather than providing all of the transactions?
180 2013-12-29 01:15:56 <Ryan52> ACTION misunderstood that detail, if so.
181 2013-12-29 01:20:58 <Ryan52> Oh, and it's explained right there in the specification. That does make sense, since the coinbase is the only one that would change, so only that branch would need to be recomputed -- just not quite as intuitive as getblocktemplate, but it definitely makes sense in its own way.
182 2013-12-29 01:21:09 <Ryan52> sipa, CodeShark: Thanks for helping me work through my misunderstanding!
183 2013-12-29 01:21:31 <CodeShark> :)
184 2013-12-29 01:27:06 <oneman> hello
185 2013-12-29 01:27:54 <oneman> I had a random idea i wrote down, mit might be dum but I reckoned I'd rather say a dum thing on the internet than not speak of a smart thing
186 2013-12-29 01:28:08 <oneman> https://gist.github.com/oneman/8166420/raw/cf03b760489523a41c9fe97a1cf607d1444e1919/gistfile1.txt
187 2013-12-29 01:29:36 <oneman> feel free to take my idea
188 2013-12-29 01:34:10 <edcba> i don't understand the motive
189 2013-12-29 01:35:29 <oneman> which one
190 2013-12-29 01:35:36 <oneman> uhm well
191 2013-12-29 01:36:57 <oneman> global marketplace is not optimal at price discovery
192 2013-12-29 01:37:40 <oneman> the cost of checking the background of vendor out is high
193 2013-12-29 01:38:00 <oneman> someone might have a lower cost but you cant tell if they are legit or not
194 2013-12-29 01:38:41 <oneman> new vendor might have much lower price in order to attract new buyers and proove capability
195 2013-12-29 01:39:09 <maaku> oneman: you can't trust blockchain data to reveal that info
196 2013-12-29 01:40:02 <oneman> you can get a much better idea about it using automatic tools analizing teh entire transaction history and giving you predictions
197 2013-12-29 01:40:15 <Ryan52> oneman: because addresses are so cheap and anonymous to some degree, a vendor could fairly easily pretend to be a buyer of their services and make themselves seem credible even if they are not, right?
198 2013-12-29 01:41:28 <Ryan52> oneman: I think it's a good idea if you can make it work reliably, I am just trying to poke holes and see how you might plan to address them.
199 2013-12-29 01:41:32 <oneman> yes, however there is two forces against it, one is that bitcoin tx cost fee's, the other is that real vendor is going to have interaction with buyer that use other vendors and so on so this can all be analized
200 2013-12-29 01:42:23 <oneman> yeah trying to poke holes is best thing you can do here
201 2013-12-29 01:43:24 <oneman> one not mentioned idea is that, in an ad-hoc organic way the offer data could be made friendly as possible for analysis using json microformats
202 2013-12-29 01:44:13 <Ryan52> well, that kind of depends on how they organize their supply chain.. if they've bought the commodities they need from other vendors using a different currency, or bought in bulk ahead of time, the analysis would not easily find that information.
203 2013-12-29 01:44:16 <oneman> the 'chain' if there is one would be only the sigs of the offer stuff, the data itself would be offered by the vendors themselves
204 2013-12-29 01:44:38 <oneman> ala bitcoin magnet links and so on
205 2013-12-29 01:44:48 <Ryan52> Oh, scratch that, I totally misunderstood and read that wrong. I see what you mean now.
206 2013-12-29 01:45:07 <oneman> this depends on only looking at transactions that can be prooven
207 2013-12-29 01:45:11 <Ryan52> So buyers would also need to be credible, and you would have a way of checking a buyer's reputation as well.
208 2013-12-29 01:46:28 <oneman> credible in that they are not double agents for other vendors buying product simply to trash it etc?
209 2013-12-29 01:47:18 <oneman> i think the bitcoin tx fee's do altleast, cut the amount of possible bullshit transactions down quite abit
210 2013-12-29 01:47:19 <Ryan52> I guess. Credible as I meant it was, by not being the actual vendor pretending to be a customer.
211 2013-12-29 01:48:11 <oneman> there is probably some ways that can be rooted out pretty effectivly
212 2013-12-29 01:50:42 <oneman> i think most of this comes down to 'big data' network analysis and other motivations
213 2013-12-29 01:51:24 <oneman> for example positive review that includeds addition evidence of product/service provided can be incentised by vendor for even lower future offers
214 2013-12-29 01:52:04 <oneman> because such evidence is rated higher by tools predicting vendor outcome
215 2013-12-29 01:52:16 <oneman> or transaction outcome rather
216 2013-12-29 01:53:54 <oneman> if there was a 'side chain' its like, the currency itself would be being able to create a message signed by a key in X bitcoin transaction
217 2013-12-29 01:54:49 <oneman> and maybe a limit of 1 or 2 messages per each side of the transaction, perhaps limited by the time elapsed since the transaction
218 2013-12-29 01:55:22 <oneman> so the data in the chain would be comparable to the size of bitcoin chain
219 2013-12-29 01:55:56 <oneman> but then the actual info itself, it could be zillions of petabytes
220 2013-12-29 01:56:13 <oneman> maybe the different sectors would maintain that
221 2013-12-29 01:57:46 <oneman> if you think about it right now, the marketplace is all heresy, an advertisement is litterally the oposite of cryptographicly prooved past performance
222 2013-12-29 01:58:12 <oneman> its just strait brainwashing
223 2013-12-29 02:00:08 <oneman> the 'idea' here is this system lets you tie or link to additional information about actual transactions
224 2013-12-29 02:00:48 <oneman> this would not be on the chain but you can link it and say, ok this vendor is cheap, but they killed all teh whales, dont forget the whale cost lol
225 2013-12-29 02:01:52 <Ryan52> So reviews in some blockchain, linked to the original transaction like when reviews on Amazon say "verified purchase" next to them.
226 2013-12-29 02:02:11 <oneman> if lots of the marketplace tho, was done in this way, it would be the way that customers could get the best price quicker, the price adjustments would be faster because all current offers can be analized
227 2013-12-29 02:02:40 <oneman> and new vendors can come online quicker because they can see exactly where prices are to high
228 2013-12-29 02:03:00 <oneman> the reviews are not in the blockchain
229 2013-12-29 02:03:34 <oneman> its the signature of the offer signed by the key of the receiver
230 2013-12-29 02:03:41 <oneman> err oops i said that wrong
231 2013-12-29 02:06:27 <oneman> its the signature of the details of the transaction signed by the seller that includes data from the buyer and the most recent block hash signed by the vendors key
232 2013-12-29 02:06:36 <oneman> blah
233 2013-12-29 02:06:44 <oneman> haha
234 2013-12-29 02:06:49 <oneman> I give up lol
235 2013-12-29 02:17:27 <Zapsoda> I feel stupid asking this, Is there a simple way to make a callback when you generate a address with the bitcoind (Using php and the JSON-RPC api) I normally use the blockchain API which has a great callback function but i'm trying to make a site without any 3rd parties (Blockchain), Ive been looking at the -walletnotify option for bitcoind but it seems i can only pass the transaction hash and I'm not sure how to access it when
236 2013-12-29 02:17:28 <Zapsoda> using the phpcli (I have it run a .sh file and wget the php callback file but that seems odd), I also thought about constant polling but that seems horribly inefficient), Any tips? I feel like i'm missing something obvious since most developers would want a way to know when a gened address receives payment
237 2013-12-29 02:54:02 <fanquake> Something funny going on over @ openssl.org
238 2013-12-29 04:12:07 <gmaxwell> sipa: I think your grapher node is broken.
239 2013-12-29 04:31:49 <mack25> trying to get bitcoind to run on centos. when i try to run make -f makefile.unix i get "alert.cpp:8:29: warning: boost/foreach.hpp: No such file or directory" - i do already have the boost libraries installed. any ideas?
240 2013-12-29 04:35:31 <warren> mack25: boost might be too old, and you'll get stuck separately because openssl of centos does not support ecdsa
241 2013-12-29 04:35:33 <warren> mack25: or the particular type of ecdsa that bitcoin needs
242 2013-12-29 04:36:04 <mack25> warren i just did yum install boost and yum install boost-devel
243 2013-12-29 04:36:10 <mack25> so it got the latest
244 2013-12-29 04:36:16 <warren> mack25: there are ways of building it on centos but it's painful
245 2013-12-29 04:36:16 <warren> mack25: you're recommended to use the official binaries if you don't need to modify anything
246 2013-12-29 04:37:45 <warren> mack25: boost in centos6 is pretty old
247 2013-12-29 04:37:45 <warren> mack25: centos6 is pretty old
248 2013-12-29 04:38:36 <andytoshi> i don't recall how makefile.unix is structured, but there is a very obvious place right before the boost stuff where you can add -mt
249 2013-12-29 04:38:36 <andytoshi> mack25: maybe you are missing -mt in the makefile?
250 2013-12-29 04:39:01 <mack25> i tried make -f makefile.unix BOOST_LIB_SUFFIX=-mt
251 2013-12-29 04:39:03 <mack25> but that didn't help
252 2013-12-29 04:39:10 <mack25> if that's what you are referring to
253 2013-12-29 04:40:51 <mack25> actually yum only installed Package boost-1.33.1-16.el5_9.i386 already installed and latest version
254 2013-12-29 04:40:56 <mack25> but boost is up to 1.55
255 2013-12-29 04:41:03 <mack25> think i should upgrade?
256 2013-12-29 04:41:55 <andytoshi> well, that's what the downloaded binary expects anyway
257 2013-12-29 04:41:55 <andytoshi> yeah, pretty sure you need 1.50 at least
258 2013-12-29 04:43:19 <mack25> ok
259 2013-12-29 04:43:24 <mack25> building boost from source
260 2013-12-29 04:44:44 <andytoshi> be aware you'll need to add some /usr/local paths to the makefile as well..
261 2013-12-29 04:44:44 <andytoshi> good luck
262 2013-12-29 04:44:44 <andytoshi> ok
263 2013-12-29 05:04:00 <oneman> gmaxwell: poke holes in my above scheme
264 2013-12-29 06:02:05 <nsh> hegenesisblock.com/bitcoin-0-8-4-update-provides-security-improvements/
265 2013-12-29 06:02:05 <nsh> "The second attack exploits the difference in 0.8.3 and bitcoinj clients. An attacker could spread malicious transactions through the network that would go unnoticed by older clients. When 0.8.3 clients truncate these invalid transactions it will force all bitcoinj clients to disconnect from 0.8.3, harming all 0.8.3 and bitcoinj nodes that now lost connections to their peers." --http://t
266 2013-12-29 06:02:15 <nsh> i wonder if there'll be a trend of problems like this...
267 2013-12-29 06:20:42 <BlueMatt> nsh: this is why the bloom filter bug should be exploited
268 2013-12-29 06:20:49 <BlueMatt> make it impossible for people to run nodes like this
269 2013-12-29 06:21:20 <nsh> ACTION nods
270 2013-12-29 06:22:51 <BlueMatt> we should leave lots of crash bugs in bitcoind so we can force people to upgrade when necessary :)
271 2013-12-29 06:38:28 <warren> BlueMatt: wasn't that the Windows business model ...
272 2013-12-29 06:38:55 <upb> ???
273 2013-12-29 06:39:35 <BlueMatt> warren: lol, yes, I think it was
274 2013-12-29 06:40:07 <upb> with claims like this i'm amazed you didnt refer ot it as M$ WINDOZE
275 2013-12-29 06:40:15 <upb> these usually go hand in hand
276 2013-12-29 06:41:05 <BlueMatt> it was a joke...
277 2013-12-29 06:44:08 <warren> the current Windows business model is along the lines of "We're finally killing this 14 year old product. PLEASE buy our new one."
278 2013-12-29 06:57:26 <Krellan> Question about newest bitcoin-qt client re unconfirmed transactions
279 2013-12-29 06:57:50 <Krellan> I sent a payment to myself. It's unconfirmed, 0 of 6 tx. However, the amount doesn't show up in the Unconfirmed total, only the Confirmed total. Seems misleading to me.
280 2013-12-29 06:58:51 <Krellan> also, what's the best way to clean up a wallet with much dust? I want to pay it all out to a new address, subtracting out only the TX fee, but it takes a lot of trial and error
281 2013-12-29 06:59:09 <Krellan> to get the correct amount, because if I increase the amount I pay for TX fee, it brings more dust into the transaction, which calls for higher TX fee, repeat....
282 2013-12-29 06:59:25 <Krellan> Anyone know an answer to these 2 unrelated dilemmas?
283 2013-12-29 06:59:34 <swulf--> not sure if it'll help but peter todd wrote a dust-b-gone tool for wallets
284 2013-12-29 06:59:47 <warren> Krellan: coin control?
285 2013-12-29 06:59:49 <Krellan> Hmm will have to look for it.
286 2013-12-29 06:59:53 <kuzetsa> I'm interested in such a tool
287 2013-12-29 07:00:02 <kuzetsa> dust-b-gone sounds like a great name for it :)
288 2013-12-29 07:00:10 <swulf--> https://github.com/petertodd/dust-b-gone
289 2013-12-29 07:00:11 <warren> Krellan: dust-b-gone donates it to the ether. coin control attempts to combine it
290 2013-12-29 07:00:17 <kuzetsa> nice
291 2013-12-29 07:00:25 <kuzetsa> oh
292 2013-12-29 07:00:35 <Krellan> I'd like to zero my entire wallet and pay myself a new clean wallet with no dust
293 2013-12-29 07:00:38 <kuzetsa> what is "the ether" ?
294 2013-12-29 07:00:58 <warren> Krellan: https://bitcointalk.org/index.php?topic=320695.0 0.8-based Coin Control client, or use bitcoin master
295 2013-12-29 07:01:17 <swulf--> right. dust-b-gone sends it to the miners
296 2013-12-29 07:01:48 <Krellan> thanks
297 2013-12-29 07:01:59 <Krellan> coin control is an awesome feature - wish it was standard in there
298 2013-12-29 07:02:54 <warren> Krellan: it's well tested in OMG
299 2013-12-29 07:03:01 <kuzetsa> oh, the dust-b-gone thing just tosses out all the bitcoin sending it as fees?
300 2013-12-29 07:17:57 <gittie> I have a question about gitian builds, what are the requirements for a build server ?
301 2013-12-29 07:22:22 <fanquake> gittie https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/README.md
302 2013-12-29 07:23:50 <gittie> fanquake: so is it possible to build on a VPS or would it have to be a dedicated platform ?
303 2013-12-29 08:09:47 <Krellan> Hmm, the TX that I made to myself, same wallet to same wallet (probably bad idea) hasn't been confirmed in some time
304 2013-12-29 08:10:20 <Krellan> it has an output that received exactly 0 BTC
305 2013-12-29 08:11:01 <Krellan> i will PM the TXID if interest (don't want to post it here)
306 2013-12-29 08:11:41 <wumpus> Krellan: there is no problem in sending transactions to yourself, those are not different from any other transactions
307 2013-12-29 08:11:44 <Krellan> what's the best way to stop the client from trying to retransmit unconfirmed TX?
308 2013-12-29 08:12:07 <Krellan> wumpus: thanks, I wonder why it sent a transaction that seems to be unhappy though
309 2013-12-29 08:12:35 <wumpus> I don't think any of the outputs is really zero either, it may think that because it regards the whole transaction as change?
310 2013-12-29 08:13:40 <gmaxwell> Krellan ... how did you manage to make a transaction with a zero value output? Bitcoin-qt won't do that, even with sendraw, IIRC.
311 2013-12-29 08:14:40 <gmaxwell> open up the console, getrawtransaction <txid> 1 and pastbin the result.
312 2013-12-29 08:18:22 <Krellan> Thanks, got it pasted, PM'ed the result (did not want it logged)
313 2013-12-29 08:19:00 <wumpus> that
314 2013-12-29 08:19:05 <wumpus> that's one transaction?!
315 2013-12-29 08:19:24 <Krellan> It's not zero after all, it was a rounding error on blockchain.info that led me to think it was zero
316 2013-12-29 08:19:32 <wumpus> how many vouts doet is have? 170+?
317 2013-12-29 08:19:34 <Krellan> yes, it's a big TX, it's my attempt to clean up dust
318 2013-12-29 08:19:52 <Krellan> i thought it would go out with a bigger TX fee to pay for it all, but evidently it didn't, sigh
319 2013-12-29 08:20:39 <gmaxwell> Krellan: only so none are zero.. part of the problem there is that it has a dust output.
320 2013-12-29 08:20:45 <Krellan> it was fun to watch the messages fly by on the console as the client struggled to piece together this big dusty mess
321 2013-12-29 08:21:38 <gmaxwell> it has a reasonably high fee at least.
322 2013-12-29 08:21:48 <Krellan> yes, I wonder why it would pay a dust output, I was expecting only 1 address (mine) as the output and no change, but I guess it wasn't completely exact so it crossed a boundary and had to split a coin to make change.
323 2013-12-29 08:22:08 <gmaxwell> well it used two different addresses.
324 2013-12-29 08:22:17 <gmaxwell> oh more than two.
325 2013-12-29 08:22:42 <gmaxwell> interesting, bitcoin-qt is supposted to automatically give away dust change to fees though
326 2013-12-29 08:22:46 <gmaxwell> I don't understand why it didn't.
327 2013-12-29 08:23:03 <Krellan> Me neither, which is why I posted it here.
328 2013-12-29 08:23:16 <wumpus> it always does for me
329 2013-12-29 08:23:19 <gmaxwell> in any case this will go right through if you reauthor it to remove that dust output.
330 2013-12-29 08:23:46 <Krellan> hmm, how to do that? I haven't tried manually reauthoring a TX.
331 2013-12-29 08:23:47 <gmaxwell> Krellan: how did you create this? just punched in your own address and typed in an amount? nothing speical? have you changed any defaults in your bitcoin.conf?
332 2013-12-29 08:24:50 <Krellan> I did increase blockmaxsize to 1000000 and lowered mintxfee and minrelaytxfee both to 0.000001
333 2013-12-29 08:25:21 <gmaxwell> ah. well that would do it.
334 2013-12-29 08:25:21 <Krellan> other than that, I just punched it into the bitcoin-qt client, doing nothing else out of the ordinary
335 2013-12-29 08:25:42 <gmaxwell> ::sigh::
336 2013-12-29 08:25:51 <gmaxwell> ACTION grumbled about people changing intentionally undocumented options.
337 2013-12-29 08:26:27 <gmaxwell> Krellan: one sec. I'll help you fix it.
338 2013-12-29 08:26:30 <Krellan> Thanks
339 2013-12-29 08:27:06 <Krellan> What should those options be? My goal was to be rather generous regarding TX that would get accepted into blocks I might mine, not to send out dust.
340 2013-12-29 08:28:32 <Krellan> Probably should set it to 0.00001 (about $0.01) instead, a penny for your thoughts (about a transaction)
341 2013-12-29 08:29:09 <gmaxwell> if you set that lower than your peers and the miners then you'll be at risk of authoring transactions that other nodes won't relay/mine.
342 2013-12-29 08:30:32 <Krellan> Ah makes sense. I was hoping it would only affect incoming TX that I might be so lucky as to mine into a block, and not affect my own TX that I author.
343 2013-12-29 08:32:44 <Krellan> Nice, Eligius mined it!!
344 2013-12-29 08:33:47 <gmaxwell> yea. k.
345 2013-12-29 08:34:15 <Krellan> Did you force it through on your mighty miner?
346 2013-12-29 08:34:26 <gmaxwell> No, though I did submit it directly to eligius.
347 2013-12-29 08:34:38 <gmaxwell> via http://eligius.st/~wizkid057/newstats/pushtxn.php
348 2013-12-29 08:34:43 <Krellan> Cool thanks!
349 2013-12-29 08:34:45 <gmaxwell> but I didn't know if it would take it.
350 2013-12-29 08:34:56 <gmaxwell> so I was in the middle of writing a replacement.
351 2013-12-29 08:35:29 <Krellan> is that a public service Eligius offers or is it something special that you did?
352 2013-12-29 08:36:23 <Krellan> would be a rather useful feature for a large pool to sell: ability to push a preferred TX through, possibly with additional payment
353 2013-12-29 08:36:36 <Krellan> thus giving people the ability to do what they often wish they had done: paid more TX fee originally when sending.
354 2013-12-29 08:36:46 <gmaxwell> Krellan: they have a php script to submit directly to their nodes, its not something special beyond the fact that it will help skip the relay network which might not be forwarding the txn.
355 2013-12-29 08:37:12 <gmaxwell> And yes, eligius actually has had prioritizion services, but has never had a public interface to it.
356 2013-12-29 08:37:24 <Krellan> I better bookmark that. What format is the input, it is direct from that pastebin?
357 2013-12-29 08:37:37 <gmaxwell> Krellan: it's the transaction hex, which was in your pastebin output.
358 2013-12-29 08:37:52 <gmaxwell> same thing you also get if you'd run the getrawtransaction without the "1" flag.
359 2013-12-29 08:38:02 <gmaxwell> or that you get out of a signrawtransaction.
360 2013-12-29 08:39:44 <Krellan> ah OK thanks.
361 2013-12-29 08:41:30 <gmaxwell> Krellan: you might want to dust-b-gone that really tiny output. :P
362 2013-12-29 08:41:58 <Krellan> Cool much thanks, I'll remember that. I increased my mintxfee and minrelaytxfee to 0.00001 also.
363 2013-12-29 08:43:01 <gmaxwell> https://github.com/petertodd/dust-b-gone < what it does it basically gives away your very low value coins to some service to be coinjoined away.
364 2013-12-29 08:47:33 <Krellan> And they're dust-b-goned!
365 2013-12-29 08:47:56 <Krellan> after making sure to read that Python script closely, considering it asks for my wallet password....
366 2013-12-29 08:49:08 <gmaxwell> Krellan: indeed. it's easy to read of course. I'd audited it previously. But it's certantly good to do so.
367 2013-12-29 08:49:56 <Krellan> aye, very nicely written. Of course if anybody wanted to be sneaky they would bury it in the python-bitcoinlib directory which has a lot of code in it.
368 2013-12-29 08:50:02 <gmaxwell> peter only issues the transactions every once in a while, but the next time he does, if you haven't managed to spend that coin first, he'll sweep it away.
369 2013-12-29 08:50:59 <gmaxwell> ultimately the functionality should be some advanced wallet feature... but deploying it without a collection server is probably more work than its worth... so its not quite clear how to do it.
370 2013-12-29 08:51:40 <gmaxwell> e.g. just a setting "[ ] give away any coin I recieve under [0.00001] in value"
371 2013-12-29 08:57:20 <Krellan> Or perhaps a "Cleanup/Move Wallet" option that would consume your entire wallet balance in a TX that would send to a single address of your choice
372 2013-12-29 08:57:47 <wumpus> why would you do that?
373 2013-12-29 08:58:00 <Krellan> It would be convenient to have a way to scrape clean wallets on installations of Bitcoin that I no longer wish to keep around.
374 2013-12-29 08:58:49 <wumpus> right, you want a 'send all and have fee inclusive' .. that makes sense
375 2013-12-29 08:58:52 <Krellan> alternative is to keep the wallet.dat file around forever, carrying some small dust
376 2013-12-29 08:59:27 <Krellan> yep, because right now it's a guessing game: you have to pick the right amount to send, so that amount + fee equals your entire balance, and it's difficult (impossible?) to get it exact
377 2013-12-29 09:00:30 <wumpus> never had any difficulties with that, I think changing the fee settings created most of the problem
378 2013-12-29 09:00:43 <wumpus> normally it just assigns extra dust to fees
379 2013-12-29 09:00:55 <wumpus> if you have a version with coin control you can even see that happen
380 2013-12-29 09:01:25 <wumpus> enter an amount *almost* the size of the entire input, and it increases the fee instead of generating change
381 2013-12-29 09:02:36 <wumpus> that said, a 'sender pays fee' checkbox makes sense, there are a few issues on github about that already
382 2013-12-29 09:05:49 <gmaxwell> wumpus: well you're not doing anything that results in you getting a half dozen 0.03 btc payments per day.
383 2013-12-29 09:06:31 <wumpus> gmaxwell: that's true
384 2013-12-29 09:07:03 <gmaxwell> Krellan: what I do think coin selection should generally do is once its picked inputs and has change, add in all the extra inputs send to the same addresses, subject to some maximum size limit.. its not like you're likely to pay substantially lower fees in the the future. but it's something that could use some simulation.
385 2013-12-29 09:07:38 <gmaxwell> Krellan: I use the kludgy shell script stuff here to just groom up p2pool addresses when I've switched to another one: http://0bin.net/paste/YsfhrW0fdY5hppnc#eQjliqYqjtlMNGg65oyU/2r2Rv1G5jwyKGtCvjTg5iE=
386 2013-12-29 09:08:19 <gmaxwell> and just make single transactions to consolidate an address and move the coins to a new one.
387 2013-12-29 09:10:12 <warren> sipa: the windows 0.8.6 connection failures are not related to IP address changing and computers are not sleeping
388 2013-12-29 09:10:26 <warren> The only other thing I changed was upgrading to boost-1.54
389 2013-12-29 09:10:38 <warren> but that isn't supposed to be related to p2p
390 2013-12-29 09:10:46 <Krellan> with my feeble hashrate? I can *wish* i was getting a half dozen 0.03 BTC payments each day, more like 3 payments of 0.003 each or so
391 2013-12-29 09:11:41 <warren> On the topic of p2pool dust, forrestv mentioned he thinks the trustless accumulator is feasible, he'll be updating the proposal soon.
392 2013-12-29 09:12:00 <warren> We're also sending him more money.
393 2013-12-29 09:12:21 <gmaxwell> "dust"
394 2013-12-29 09:12:43 <gmaxwell> I mean, 0.03 BTC is $20.
395 2013-12-29 09:13:07 <warren> gmaxwell: well, p2pool would do well to have fewer coinbase TXO...
396 2013-12-29 09:13:33 <Krellan> I like how p2pool is genuine mining, paid in coinbase
397 2013-12-29 09:13:51 <Krellan> it's about as close as I will come to being able to mine a full block myself
398 2013-12-29 09:14:17 <warren> I'm going to post in the thread right now, if others donate to forrestv before December 31st, we'll match an additional $1,000.
399 2013-12-29 09:14:32 <gmaxwell> Krellan: yea, there are ways to reduce the payout frequencies without eliminating direct coinbase outputs.
400 2013-12-29 09:14:39 <warren> People need to take p2pool more seriously.
401 2013-12-29 09:15:12 <Krellan> p2pool is my favorite pool because it's very technically elegant, being decentralized but still working as a good pool
402 2013-12-29 09:15:28 <Krellan> if it weren't for that, my next favorite would be Eligius
403 2013-12-29 09:15:30 <gmaxwell> I mean, it does mine about $56,000 BTC worth of bitcoin per day.
404 2013-12-29 09:15:49 <gmaxwell> warren: I dunno if you noticed me mention it, but the antminer firmware is now fixed wrt p2pool. and it works awesomely on it.
405 2013-12-29 09:16:13 <warren> gmaxwell: excellent
406 2013-12-29 09:16:25 <gmaxwell> DOA rate of 1.9%.
407 2013-12-29 09:16:26 <warren> gmaxwell: how's the work return latency now?
408 2013-12-29 09:17:25 <gmaxwell> (as compared to the avalons with tuning and patches, which are 5.5% which was already good enough to average >100% efficiency for me)
409 2013-12-29 09:30:59 <warren> https://bitcointalk.org/index.php?topic=329860.msg4199208#msg4199208 If the community donates in excess of $1,000 to Forrest's donation addresses before noon UTC December 31st, the Litecoin Dev Team will contribute an additional $1,000 in support of his research and development.
410 2013-12-29 11:07:00 <gmaxwell> sipa: 4c6d41b8b653ef90639b1a32f6aab0bb1cef90c5 broke getnetworkhashps
411 2013-12-29 11:09:08 <gmaxwell> GetNetworkHashPS is called with -1 to indicate pindexBest (this is the default when you call the rpc too). trivial fix.
412 2013-12-29 11:36:28 <berndj> re utxo bloat: would it make sense to take advantage of temporal locality, and let all those spammy dust outputs drop into a subset that's still available, but doesn't take the process's RSS unless those outputs move? (or is this done already)
413 2013-12-29 11:39:57 <gmaxwell> berndj: utxo isn't required to be in memory.
414 2013-12-29 11:40:30 <gmaxwell> but access patterns are pretty random, and things are normally written to once and read from basically once (ignoring some complications about multiple txout in a transaction)
415 2013-12-29 11:40:35 <berndj> it isn't, but if it's just a giant hash table (is it? isn't it?) the random accesses will try to access it all uniformly, no?
416 2013-12-29 11:41:39 <gmaxwell> it's a leveldb, which is actually ordered. but regardless. caching is actually effective because recently created txouts tend to be consumed pretty fast.
417 2013-12-29 11:43:39 <berndj> so what exactly is the "utxo bloat" issue - the fact that a node *must* carry along those 300MB? or that bitcoind will spread its accesses to it ~ uniformly, causing it to gram 300MB of RAM?
418 2013-12-29 11:44:30 <gmaxwell> you're repeating 300MB like its relevant.
419 2013-12-29 11:44:37 <gmaxwell> the size now isn't an issue at all
420 2013-12-29 11:44:45 <gmaxwell> it's what the size can be later.
421 2013-12-29 11:45:11 <gmaxwell> esp when it stopped looking polylogarithmic in the number of historic transactions after SD was created.
422 2013-12-29 11:45:19 <berndj> i'm just throwing it out as an example. (it already causes me pain btw, i think - my computer isn't loaded with GB upon GB)
423 2013-12-29 11:45:38 <gmaxwell> huh? it doesn't cause you pain.
424 2013-12-29 11:45:48 <Joric> hey greg! no hard feelings, right?
425 2013-12-29 11:45:52 <gmaxwell> how long do you take to verify a new block?
426 2013-12-29 11:46:01 <gmaxwell> Joric: hm?
427 2013-12-29 11:46:34 <berndj> gmaxwell, the pain isn't in bitcoind; it's that bitcoind touches all this memory that causes the kernel to swap a bunch of other stuff i'm doing out
428 2013-12-29 11:47:14 <Joric> did anyone really measue how much time takes a full blown ECDSA multiplication (gpu accelerated if possible?) comparing to a single sha256? i frankly did not
429 2013-12-29 11:47:17 <gmaxwell> berndj: in any case, it's both that any verifying node must have the data readily available, and as it spills out of ram block validation speed drops off enormously.
430 2013-12-29 11:47:20 <Joric> *measure
431 2013-12-29 11:48:41 <Joric> i just always stumble upon ppl why mention 'rainbow tables' in brainwallet context, i know the term but i doubt it's really applicable
432 2013-12-29 11:48:47 <Joric> *who
433 2013-12-29 11:48:48 <gmaxwell> Joric: you mean a multiplication with the generator? Due to precomputation a multiplication with a random point and a multiplication with the generator aren't the same.
434 2013-12-29 11:48:49 <berndj> gmaxwell, what i was getting at is that it isn't necessary for 1bitcoineater... and the like to be in core; it's okay if those just sit on disk, so i was wondering (if this isn't already done) if it'd make sense to have a 2-tier utxo db?
435 2013-12-29 11:49:10 <Joric> gmaxwell, how is it different from a random point
436 2013-12-29 11:49:29 <Joric> it's not vanitygen that's for sure
437 2013-12-29 11:49:44 <gmaxwell> Joric: its substantially faster if implementated correctly.
438 2013-12-29 11:50:43 <berndj> maybe i'm just misunderstanding the problem; is it that the utxo db is bloating with outputs that will *never* be spent, or that there just are that many unspent outputs that are likely to be spent "soon"?
439 2013-12-29 11:52:17 <gmaxwell> berndj: they already do sit on disk, but there are a large number of outputs which are not discernable. only very recently created ones have a obviously higher hitrate.
440 2013-12-29 11:52:25 <Joric> gmaxwell, what do you mean really? eg. build up a huge 'rainbow table' of hashes, sort it up and use interpolation or something like that?
441 2013-12-29 11:52:55 <gmaxwell> Joric: ... no.
442 2013-12-29 11:54:05 <Joric> i've stumbled upon batched ecdsa but i doubt it's 'substantially faster'
443 2013-12-29 12:08:36 <gmaxwell> Joric: fast code to multiply by G on my laptop can generate 171,159 random pubkeys per second.
444 2013-12-29 12:08:42 <Polyatomic> is the difficulty really high on test net for bitcoin ?
445 2013-12-29 12:09:27 <Joric> gmaxwell, yeah that's about it, thousands, not millions
446 2013-12-29 12:09:46 <gmaxwell> Joric: sure, its _much_ faster on an fpga however.
447 2013-12-29 12:11:19 <gmaxwell> Joric: well hundreds of thousands.
448 2013-12-29 12:12:17 <gmaxwell> on a gpu, I have no idea.
449 2013-12-29 12:12:27 <Joric> not billions either
450 2013-12-29 12:12:40 <gmaxwell> Joric: potentially, on an fpga farm.
451 2013-12-29 12:13:29 <gmaxwell> it's not fundimentally an expensive operation, it just doesn't map neatly to x86 cpus due to everything being large field operations.
452 2013-12-29 12:13:54 <gmaxwell> wrt rainbow tables, you sound like you misunderstand what a rainbow table is. One need not be exhaustive.
453 2013-12-29 12:14:35 <Joric> idk really never tried to layout a custom fpga
454 2013-12-29 12:16:37 <Joric> as i understand it rainbow tables is basically a set of Ñontrol points for interpolation, assuming interpolation is possible
455 2013-12-29 12:17:38 <gmaxwell> no.
456 2013-12-29 12:18:02 <gmaxwell> well, I suppose you could see it that way.
457 2013-12-29 12:18:08 <gmaxwell> it _makes_ interpolation possible.
458 2013-12-29 12:19:03 <gmaxwell> basically a that kind of time memory tradeoff invents an order for (input, output) pairs. The order doesn't matter, only that it is determinstic.
459 2013-12-29 12:19:15 <gmaxwell> Once an order has been invented, then you record control points.
460 2013-12-29 12:19:47 <gmaxwell> When you later want to look up the input for a given output, you start incrementing that ordering function starting from the output until you find a control point.
461 2013-12-29 12:20:05 <gmaxwell> then you look up what the _prior_ control point was in the order and increment from there.
462 2013-12-29 12:20:21 <gmaxwell> the penutimate step before you get back to where you started was the input.
463 2013-12-29 12:23:08 <gmaxwell> Joric: the typical way this is done is that you need two functionsâ your forward function, and a (pseudo-)inverse function. the inverse function takes an output and converts it to a determinstic 'random' input of the space of likely inputs. With those functions in hand you've defined an order.
464 2013-12-29 12:23:48 <Joric> sorry always wanted to ask do you blame yourself in what has happened with Aaron Swartz, did he bother about that jstor thing that has been released on tpb
465 2013-12-29 12:24:47 <gmaxwell> the fuck?
466 2013-12-29 12:25:04 <gmaxwell> No, a got a thank you letter from him. but seriously.
467 2013-12-29 12:27:26 <nsh> ACTION blinks
468 2013-12-29 12:27:50 <tg0> Hi folks, first time here.. Can someone explain compressed public keys to me? I'm writing the BIP38 specification in PHP, stuck trying to convert to a compressed public key (this much is mostly ok), however recovering the y-coordinate is my biggest issue here - I haven't a clue
469 2013-12-29 12:29:51 <tg0> particularly if anyone has used Mathias Danters phpecc library to do it.
470 2013-12-29 12:30:17 <Joric> sorry it was really random as i said i just write search for those guys
471 2013-12-29 12:32:39 <Joric> tg0 - uncompressed = byte type +x +y, compressed = byte type + x OR y
472 2013-12-29 12:33:03 <Joric> you may reconstruct the second coordinate
473 2013-12-29 12:34:14 <tg0> Joric - uncompressed byte type is 04, correct? my understanding is the compressed byte type comes from y. it's either even or odd, which gives 02, or 03.. But it's reconstructing the second coordinate that I'm not sure about
474 2013-12-29 12:35:31 <tg0> I get that there could be (x,y1) and (x, y2) at a particular point on an EC, so the compressed byte type basically just tells you which to use.. but, there is where I'm lacking - a way to get y
475 2013-12-29 12:35:59 <tg0> sorry at a particular x on an EC*
476 2013-12-29 12:37:31 <keyboard> Calculate it with the formula of the curve
477 2013-12-29 12:39:32 <Joric> oh i'm sorry not "byte type + x OR y", it's byte "odd OR even" + x, ALWAYS X (not Y)
478 2013-12-29 12:40:52 <tg0> keyboard- I had avoided that approach because I wasn't sure if gmp will return an array when solving y=sqrt(whatever) , but thanks I'll give it a shot
479 2013-12-29 12:42:11 <tg0> and Joric, is the odd/even test simply: (y % 2 == 0) ? even : odd
480 2013-12-29 12:42:14 <Joric> not odd/even either, just +/-
481 2013-12-29 12:42:45 <tg0> hmm k, that's where I was unsure. I've yet to see a negative y coordinate
482 2013-12-29 12:43:45 <tg0> I'll play around and see if I can spot it. cheers guys
483 2013-12-29 12:43:57 <Joric> yep, the byte itself is if (y.isEven()) { enc.unshift(0x02); } else { enc.unshift(0x03); } see bitcoinjs
484 2013-12-29 12:45:41 <tg0> yeah, was looking at that alright.
485 2013-12-29 12:45:43 <Joric> i wrote otc-verification for compressed keys but i don't really remember the code reconstructing y from x
486 2013-12-29 12:46:30 <Joric> see pull #33 https://github.com/nanotube/supybot-bitcoin-marketmonitor/pull/33
487 2013-12-29 12:56:18 <Joric> got 6 btc for it... sweet 2012
488 2013-12-29 12:58:43 <Joric> fuck me for that theme with aaron swartz i shouldn't mention it i just really don't know shit about that jstor torrent and how it worked
489 2013-12-29 13:01:01 <tg0> Joric, mind if I pm?
490 2013-12-29 13:01:12 <Joric> tg0, go ahead
491 2013-12-29 13:38:02 <greyox> .
492 2013-12-29 13:40:08 <greyox> hi
493 2013-12-29 13:53:52 <airbreather> So if someone were to be working on developing another Bitcoin client, is this the place to talk about the nitty-gritty details of such a thing? Such as all the wonderful different little tx script opcodes?
494 2013-12-29 13:55:45 <gmaxwell> Yes. Although I will now repeat my standard mantra: I would strongly discourage someone from writing yet another client right now, there are a lot of other interesting things which need to be build other than more clients, and a lot of existing clients that could use love and care.
495 2013-12-29 13:56:43 <gmaxwell> Writing a bitcoin client is unusually difficult and not in fun ways, because of the need to be pedantically exact about so muchâ including perfectly immitating some bugsâ because its a cryptographic consensus system.
496 2013-12-29 13:57:06 <greyox> Please did someone managed to compile bitcoinqtmsvc2012? (bitcoin source port to VS2012)
497 2013-12-29 13:57:38 <greyox> I mean this project: http://bitcoinqtmsvc2012.codeplex.com/
498 2013-12-29 13:59:13 <greyox> Or is there a better way to learn bitcoin source code, if you have windows?
499 2013-12-29 13:59:47 <gmaxwell> greyox: normally bitcoin is compiled with mingw. There are instructions available on compiling it with mingw online. Compiling with VS2012 is not recommended.
500 2013-12-29 14:01:00 <greyox> But then I can't debug the code in Visual Studio, can I? I am actually already close to finish it, everything compiles except of bitcoinQT
501 2013-12-29 14:02:09 <greyox> I think something is just slightly wrong with my QT configuration...
502 2013-12-29 14:06:13 <airbreather> gmaxwell: Thank you. I'm aware that the reference implementation has/had some quirks that more-or-less force any given implementation to act the same way or risk forking the chain.
503 2013-12-29 14:06:56 <airbreather> Though... is there a list of projects that could use some love and/or attention from a C#/.NET developer before I move on with my little project?
504 2013-12-29 14:07:47 <gmaxwell> well, I've seen https://code.google.com/p/bitcoinsharp/ mentioned.
505 2013-12-29 14:08:56 <airbreather> I've been there, and that's actually part of the reason I wanted to make my own -- I don't like the design of BitcoinJ and BitcoinSharp, and I haven't been able to dispel the illusion that I can do better without trying it myself...
506 2013-12-29 14:10:12 <gmaxwell> But beyond that there are just tons and tons of tools on top of bitcoin which almost no one is working on. see things like https://en.bitcoin.it/wiki/Contracts or tools for private cross chain trading or tools for blockchain escrow (though at least https://www.bitrated.com/ finally exists) ... etc. a lot of these things present complex UI changesâ no one really knows how to present a friendly interface on a complex cryptographic ...
507 2013-12-29 14:10:18 <gmaxwell> ... protocol.
508 2013-12-29 14:13:57 <gmaxwell> airbreather: wrt design, you may find that you have less freedom than you think, since the design of bitcoin itself imposes some abstraction limitations. ... but also, indeed, perhaps you could get a design you like better, but at the end of the day will people be able to do anything new and interesting with bitcoin if you do a somewhat better reimplementation in another language? Will you have the resources to keep updating it as the ...
509 2013-12-29 14:14:03 <gmaxwell> ... protocol changes? etc. okay, I've problably belabored it too much now, you've heard my sales pitch.
510 2013-12-29 14:16:29 <greyox> gmaxwell, and you the big guys, what development environment do you use?
511 2013-12-29 14:16:38 <greyox> for bitcoin development
512 2013-12-29 14:17:59 <Luke-Jr> greyox: almost everyone uses Linux
513 2013-12-29 14:18:18 <Luke-Jr> I don't think there's a consensus of editor software, nor is there a need for one
514 2013-12-29 14:18:28 <greyox> Linux?! ok...
515 2013-12-29 14:19:00 <Luke-Jr> no idea why anyone would use Windows anymore
516 2013-12-29 14:19:22 <greyox> Visual Studio is best env I've seen so far...but let's not do flamewar here :)
517 2013-12-29 14:21:06 <greyox> And if you do some change to the bitcoin source code locally, like some fix let's say, do you need to cross-compile it to different platforms to see if it works? Or do I need to run some smoke-tests or whatever to check I didn't screwedup something?
518 2013-12-29 14:21:34 <greyox> like is there some automated testing framework?
519 2013-12-29 14:21:54 <Luke-Jr> building will result in bitcoin_test
520 2013-12-29 14:22:00 <Luke-Jr> that runs unit tests
521 2013-12-29 14:22:27 <gmaxwell> there is also a more complete system testing harness, but that takes some external parts and is more work to setup.
522 2013-12-29 14:22:42 <greyox> So,if I want to build on Windows, I should use only mingw? Not Visual studio?
523 2013-12-29 14:23:00 <gmaxwell> From linux cross compiling is trivial, but fortunately the code is portable to our supported platforms and we've almost never had a platform specific bug in our own code.
524 2013-12-29 14:23:03 <Luke-Jr> greyox: that's recommended.
525 2013-12-29 14:23:09 <Luke-Jr> greyox: Microsoft's compiler sucks bad
526 2013-12-29 14:23:20 <greyox> No, it doesn't...
527 2013-12-29 14:23:20 <Luke-Jr> greyox: the only active Windows developer uses Qt Creator
528 2013-12-29 14:23:32 <Luke-Jr> yes it does, or else it would build the standard C++ code without changes..
529 2013-12-29 14:23:41 <gmaxwell> If you're comfortable using visual studio and you can get it working, and want to develop from itâ please do. Perhaps you'll do some distinctive work because its easier from that toolset.
530 2013-12-29 14:24:18 <gmaxwell> just be aware you'll somewhat alone there, â which can be good.
531 2013-12-29 14:25:06 <greyox> Ok I am close to having it compiled, I'll find someone who can help with the QT setup, other than that it compiles, and the bitcoind ran correctly compiled with VS2012.
532 2013-12-29 14:25:06 <Luke-Jr> on the other hand, it looks like this codebase has some real bug fixes: http://bitcoinqtmsvc2012.codeplex.com/SourceControl/changeset/31033
533 2013-12-29 14:25:27 <greyox> yest that's what I am using
534 2013-12-29 14:25:29 <Luke-Jr> I think it's legitimate to assume assert can be safely #define'd to a noop.. so this is a real bug
535 2013-12-29 14:25:34 <gmaxwell> Luke-Jr: yea, diversity is generally helpful... causes you to find real bugs.
536 2013-12-29 14:25:54 <gmaxwell> Luke-Jr: uuuhhh.
537 2013-12-29 14:26:23 <Luke-Jr> gmaxwell: at least, even glibc has an option to noop assert()
538 2013-12-29 14:26:25 <gmaxwell> Luke-Jr: https://github.com/bitcoin/bitcoin/pull/3344
539 2013-12-29 14:26:40 <Luke-Jr> ah
540 2013-12-29 14:26:56 <Luke-Jr> good, already fixed in master then :D
541 2013-12-29 14:27:39 <Luke-Jr> one downside to that fix is, however, that the assert errors are much less useful; but oh well
542 2013-12-29 14:29:52 <gmaxwell> meh, line numbers good enough.
543 2013-12-29 14:29:56 <gmaxwell> 10:58 < gmaxwell> sipa: most awesome backdoor sequence ever: put all rand calls directly in the assert macro... then later get in a patch to NDEBUG the codebase. :P
544 2013-12-29 14:43:26 <airbreather> gmaxwell: Thank you for your input. I really do appreciate it, and you've made me seriously reconsider whether my little project is really worth redirecting effort that can make other, smaller projects more awesome. I do think that if I really knock this out of the park and design a sufficiently abstract system (which is admittedly unlikely, just by virtue of how big of a task it is), I can le
545 2013-12-29 14:43:26 <airbreather> verage MEF (Managed Extensibility Framework) to enable other developers to extend or replace certain parts of the system without having to recompile or change any of the core code. One of my stretch goals is to make it so that an external interface can be used to store private keys. Someone could create some piece of hardware... all it would expose over the USB interface is "get my public key"
546 2013-12-29 14:43:27 <airbreather> and "sign this transaction". Then, with only a driver to hook it up to the system and dropping their completely separate plugin into my system (again, no changing core code), that address just shows up in their wallet and can be used as easily as using a "normal" address.
547 2013-12-29 14:43:33 <airbreather> wow
548 2013-12-29 14:43:35 <airbreather> sorry
549 2013-12-29 14:43:37 <airbreather> for the wall of text
550 2013-12-29 14:43:59 <gmaxwell> :)
551 2013-12-29 14:51:33 <airbreather> Another stretch goal is to expose an extension point so that someone can create additional GUI views that get limited capabilities within the system. So, someone could develop a plug-in view that would allow creating the kinds of transactions we see used for contracts or what not, again as an external plugin that can be developed independently and dropped into a folder to wire it up into the sy
552 2013-12-29 14:51:34 <airbreather> stem.
553 2013-12-29 14:53:28 <airbreather> Also, pending research into the feasibility, I'm thinking of exposing a "reduced-functionality" mode that would allow an external data store to only keep a pruned copy of the blockchain, pruned however they would like as long as it can supply the capabilities required by the reduced-functionality mode.
554 2013-12-29 14:53:44 <abishek> is there a way to find out how many confirmations are received on a testnet transaction using the blockexporer?
555 2013-12-29 14:55:48 <airbreather> I do not know of any projects that would make all of these possible, and I am just crazy enough to actually go about trying it. So a sincere thank you, gmaxwell, for making me rethink whether or not this is worth it. I think it is.
556 2013-12-29 14:56:07 <abishek> i am trying to get the transaction details of the testnet transaction @ http://blockexplorer.com/testnet . I am not able to figure out how many confirmations are received for a transaction, could someone please advice how to do it?
557 2013-12-29 14:56:33 <CodeShark> check the block height for the block containing it
558 2013-12-29 14:56:33 <gmaxwell> abishek: why do you want to know?
559 2013-12-29 14:56:41 <CodeShark> subtract it from the best current hight
560 2013-12-29 14:56:44 <CodeShark> and add 1
561 2013-12-29 14:56:56 <airbreather> walls-of-text aside, is https://en.bitcoin.it/wiki/Script up-to-date with all the transaction opcodes that are currently supported in the mainline bitcoin client?
562 2013-12-29 14:57:03 <airbreather> so, everything not in red is enabled
563 2013-12-29 14:57:50 <gmaxwell> yes, but the wiki page isn't normative or complete in every detail. If you implement from that you'll likely implement some things incorrectly.
564 2013-12-29 14:58:02 <gmaxwell> (though, when you discover that, please do update the wiki page)
565 2013-12-29 14:58:09 <abishek> gmaxwell, I have setup walletnotify event and it doesn't seem to notify of any confirmations but when I use getTransactionMethod I see that the number of confirmations for the transaction is about 700 of them
566 2013-12-29 14:58:36 <abishek> gmaxwell, i only get notified when a transaction comes in and not for confirmations
567 2013-12-29 14:58:40 <airbreather> gmaxwell: thanks
568 2013-12-29 14:59:23 <airbreather> I'll try to update the wiki if I find these issues... at the minimum, they'll end up as documentation in my code if this ever comes to light.
569 2013-12-29 14:59:57 <gmaxwell> abishek: ah, well the confirms is just the block height now minus the height where it was confirmed.
570 2013-12-29 15:00:00 <gmaxwell> as CodeShark said
571 2013-12-29 15:07:17 <abishek> gmaxwell, so there is no actual use of the walletnotify?
572 2013-12-29 15:20:20 <CodeShark> I have a filter command and a command for getting it to notify you at specific confirmation counts
573 2013-12-29 15:20:48 <CodeShark> so no, I would never use walletnotify :p
574 2013-12-29 15:24:09 <abishek> CodeShark, if I have 1000's of transactions on a wallet, how do you intend this need to work?
575 2013-12-29 15:24:39 <CodeShark> you create a filter over your wallet's signing scripts
576 2013-12-29 15:24:42 <abishek> CodeShark, my wallet is bitcoind based
577 2013-12-29 15:25:06 <CodeShark> doesn't matter - you can export the keys and construct a filter from that list
578 2013-12-29 15:26:16 <abishek> so, am not sure if I understand by the meaning of a filter. Does it mean to loop through the list of transactions recieved, kind of like a timer job and get the transaction data periodicaly?
579 2013-12-29 15:26:27 <CodeShark> no, absolutely not
580 2013-12-29 15:26:50 <abishek> CodeShark, can you advice on what you mean by a filter
581 2013-12-29 15:27:08 <CodeShark> what defines transactions being in your wallet is that they contain either input scripts or output scripts implicating one or more of the keys in your wallet
582 2013-12-29 15:27:24 <CodeShark> so say you have a wallet with 1000 keys in it
583 2013-12-29 15:27:56 <CodeShark> for each key, there is an output script and an input script format corresponding to it
584 2013-12-29 15:28:18 <abishek> ok
585 2013-12-29 15:28:28 <CodeShark> so all one needs to do is connect to a peer and filter the transaction stream
586 2013-12-29 15:29:33 <CodeShark> unfortunately, bitcoind does not provide a very high level interface allowing this - to do this you must use the p2p protocol
587 2013-12-29 15:29:53 <CodeShark> hence the websocket server, which serves as the link
588 2013-12-29 15:30:17 <abishek> CodeShark, where can i find more details about the output and input scripts?
589 2013-12-29 15:30:41 <CodeShark> https://en.bitcoin.it/wiki/Script
590 2013-12-29 15:31:42 <CodeShark> you can also use the getrawtransaction and decoderawtransaction commands with bitcoind to see the scripts
591 2013-12-29 15:31:56 <sipa> note that
592 2013-12-29 15:32:12 <sipa> getrawtransaction only really works when txindex is enabled
593 2013-12-29 15:32:30 <sipa> and can do an inline decoding if you pass 1 as extra argument
594 2013-12-29 15:32:38 <abishek> ok, i will have to figure out the scripts to see how to implement them into my app
595 2013-12-29 15:32:45 <abishek> sipa, thnx I will make a note of it
596 2013-12-29 15:32:57 <sipa> what do you need custom scripts for?
597 2013-12-29 15:33:10 <CodeShark> sipa: he's looking to filter a transaction stream
598 2013-12-29 15:33:27 <CodeShark> wants to see whether they belong to a particular wallet
599 2013-12-29 15:33:53 <sipa> watch-only wallet?
600 2013-12-29 15:34:00 <sipa> no need to understand the detaiks of scripts
601 2013-12-29 15:34:12 <CodeShark> you do if you want to do it right :)
602 2013-12-29 15:34:13 <abishek> I basically have a web app that needs to show a list of transactions per address that receives money and I only want to show the list of transactions that have confirmation more that 5
603 2013-12-29 15:35:25 <sipa> CodeShark: what constitutes a wallet is application defined
604 2013-12-29 15:35:55 <sipa> if you have a watch-only version of wallet compatible with that application's wallet, there should not be any problem
605 2013-12-29 15:36:16 <abishek> the way I implemented was using the walletNotify which notifies the transaction id for every transaction received which works correctly but I am trying to figure out a way to query bitcoind to get the list of confirmations, so that i flag the transaction to a successful one when the confirmations reach 5. I was under the impression that wallet notify also notifies when confirmations on a transaction is received
606 2013-12-29 15:36:49 <CodeShark> I really hope the term "watch-only wallet" soon gives way to the term "transaction stream filter" :)
607 2013-12-29 15:36:59 <sipa> walletnotify notifies when a transaction is first seen, and when it confirms the first time (which may coimcide)
608 2013-12-29 15:37:17 <sipa> CodeShark: i consider the latter a generic implementation for the first
609 2013-12-29 15:37:32 <CodeShark> it is entirely possible to write a generic transaction stream filter that supports ANY conceivable wallet app
610 2013-12-29 15:37:42 <sipa> agree
611 2013-12-29 15:37:48 <abishek> sipa, yes that is what is happening, the first time it gets notified when a payment is received and the second time when it reaches the block with the block details
612 2013-12-29 15:38:01 <CodeShark> sipa: moreover, that is the correct architecture to pursue :)
613 2013-12-29 15:38:29 <sipa> CodeShark: perhaps, but it's certainly not necessary to expose that to the user
614 2013-12-29 15:38:45 <abishek> CodeShark, is there any specific example that is published on the internet to know how to implement it using different languages? something similar to https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)
615 2013-12-29 15:39:12 <CodeShark> sipa: the main reason I stopped working on watch-only wallets for bitcoind was because I believe a service-oriented architecture that incorporates a process which allows filtered stream subscriptions is the way to go
616 2013-12-29 15:39:35 <sipa> CodeShark: perhaps
617 2013-12-29 15:39:58 <sipa> for large-scale installations, something like that sounds like the way to go for sure
618 2013-12-29 15:40:09 <CodeShark> sipa: even for small websites :)
619 2013-12-29 15:40:40 <CodeShark> I started out in bitcoin trying to write some web apps that did exactly what abishek is talking aboutâ¦this was nearly three years ago
620 2013-12-29 15:41:05 <CodeShark> I soon realized there was no good way to do it with existing software, so that's why I ended up writing my own :p
621 2013-12-29 15:42:02 <CodeShark> abishek: I intend to publish a comprehensive solution to this problem very soon
622 2013-12-29 15:42:24 <CodeShark> one that exposes a very high-level API
623 2013-12-29 15:43:05 <abishek> ok, am more on ruby and php developer so am not sure how to proceed.
624 2013-12-29 15:43:21 <CodeShark> as long as you can use websockets you can subscribe to streams
625 2013-12-29 15:43:37 <CodeShark> I can also have HTTP callbacks, but this is a rather inefficient mechanism
626 2013-12-29 15:44:23 <CodeShark> the programming language is irrelevant - as long as it has good libraries for websockets