1 2011-07-26 00:00:02 <BlueMatt> vs dns were you cant really
2 2011-07-26 00:00:11 <jrmithdobbs> whereas it can with dns it can well enough with no extra work
3 2011-07-26 00:00:14 <BlueMatt> or...it doesnt work as well for certain cases
4 2011-07-26 00:00:25 <wasabi1> Are ya'll talking about seeding of IPs for bc? I assume you are.
5 2011-07-26 00:00:34 <BlueMatt> no name->address mapping
6 2011-07-26 00:00:39 <jrmithdobbs> so you throw out 80% of the solution because it doesn't fit a .1% use case?
7 2011-07-26 00:00:41 <wasabi1> In general?
8 2011-07-26 00:00:46 <jrmithdobbs> wasabi1: yes fucking lol
9 2011-07-26 00:01:14 <BlueMatt> no, Im saying throw out one solution in favor of another that has an advantage for probably 25% of people
10 2011-07-26 00:01:23 <wasabi1> Use an existing P2P DNS system. Booyah!
11 2011-07-26 00:01:28 <BlueMatt> remember the bitcoin community is full of people who think they are being anonymous and want to be
12 2011-07-26 00:01:28 <wasabi1> Probably not.
13 2011-07-26 00:02:57 <SerajewelKS> upb / jgarzik: http://pastie.org/2271650
14 2011-07-26 00:03:07 <SerajewelKS> this is THE* solution
15 2011-07-26 00:03:10 <SerajewelKS> * my
16 2011-07-26 00:05:21 <upb> cool :D
17 2011-07-26 00:06:09 <wasabi1> SerajewelKS: You should make my miner Mono compatible.
18 2011-07-26 00:06:18 <wasabi1> Heh.
19 2011-07-26 00:06:20 <SerajewelKS> wasabi1: it's not? O_o
20 2011-07-26 00:06:25 <SerajewelKS> tsk
21 2011-07-26 00:06:25 <wasabi1> Got me. Haven't tried.
22 2011-07-26 00:06:38 <wasabi1> I'm pretttttty sure the mixed mode assembly ain't gonna works.
23 2011-07-26 00:06:47 <wasabi1> I did an SSE version.
24 2011-07-26 00:06:56 <SerajewelKS> it won't work
25 2011-07-26 00:06:58 <upb> damn youre a mono dev?
26 2011-07-26 00:07:07 <upb> thought i'd seen your nick somewhere
27 2011-07-26 00:07:23 <wasabi1> Yeah I know. I was being facetious.
28 2011-07-26 00:07:28 <SerajewelKS> upb: me? i'm not an official developer OF mono. i've worked with it a lot and contributed patches.
29 2011-07-26 00:07:32 <wasabi1> I have Cloo working though.
30 2011-07-26 00:07:37 <upb> ic:)
31 2011-07-26 00:07:41 <wasabi1> That should probably work. I need to test it.
32 2011-07-26 00:07:45 <wasabi1> I'm using a LOT of 4.0 stuff.
33 2011-07-26 00:08:11 <wasabi1> Actually... am I? Maybe I toned that down a bit in the last rearch.
34 2011-07-26 00:08:16 <wasabi1> It's been two weeks since I looked at it.
35 2011-07-26 00:08:27 <upb> SerajewelKS: any chance you worked on the tls or soap implementations there ?
36 2011-07-26 00:08:38 <upb> or the cryptography part
37 2011-07-26 00:08:48 <SerajewelKS> upb: no, i don't know enough about ssl/crypto type stuff and soap makes me vomit
38 2011-07-26 00:08:58 <jrmithdobbs> as it should
39 2011-07-26 00:09:00 <wasabi1> YOu're not supposed to swallow it.
40 2011-07-26 00:09:08 <SerajewelKS> wasabi1: that's what he said?
41 2011-07-26 00:09:15 <wasabi1> Why would he say that?
42 2011-07-26 00:09:21 <jrmithdobbs> lol
43 2011-07-26 00:09:29 <wasabi1> He's an idiot.
44 2011-07-26 00:09:30 <SerajewelKS> dunno, it just sounds like something he might say
45 2011-07-26 00:10:05 <upb> ok
46 2011-07-26 00:10:11 <wasabi1> I've been lacking on the Linux desktop department for a bit. Doing way too much real work in VS... so haven't tested it.
47 2011-07-26 00:10:14 <SerajewelKS> upb: now i get to parse nnnnnnnn.nnnnnnnn as int64. woot.
48 2011-07-26 00:10:15 <wasabi1> I used Diablo's kernel.
49 2011-07-26 00:10:21 <wasabi1> And it runs. ANd produces valid hashes.
50 2011-07-26 00:10:37 <SerajewelKS> wasabi1: virtualbox.org. go get it.
51 2011-07-26 00:10:43 <wasabi1> True, true.
52 2011-07-26 00:11:56 <SerajewelKS> upb: i have to be really careful how i parse this :S
53 2011-07-26 00:48:32 <SerajewelKS> upb: i win
54 2011-07-26 00:49:23 <SerajewelKS> upb: http://pastie.org/2271842
55 2011-07-26 00:50:23 <eian> whatever that is, it doesn't look good
56 2011-07-26 00:50:32 <eian> you broke something :(
57 2011-07-26 00:50:42 <SerajewelKS> what did i break?
58 2011-07-26 00:50:54 <jrmithdobbs> that looks awesome
59 2011-07-26 00:51:08 <eian> sorry, I was trying to make a funny
60 2011-07-26 00:51:12 <SerajewelKS> oh :)
61 2011-07-26 00:51:12 <upb> :D
62 2011-07-26 00:51:14 <eian> I'm tired
63 2011-07-26 00:51:18 <upb> good night/morning/midday
64 2011-07-26 00:51:19 <jrmithdobbs> SerajewelKS: so / will always use v0?
65 2011-07-26 00:51:24 <SerajewelKS> jrmithdobbs: yes
66 2011-07-26 00:51:31 <SerajewelKS> jrmithdobbs: as the patch author, i am declaring v0 and v1 equal
67 2011-07-26 00:52:45 <jrmithdobbs> fair
68 2011-07-26 01:02:51 <SerajewelKS> i'm staging a branch against 0.3.24
69 2011-07-26 01:05:24 <jgarzik> SerajewelKS: putting a new API at a new URL seems a fair and standard way to do things
70 2011-07-26 01:19:08 <eian> Anyone here know how to exponentiate using crypto++? (I can obviously multiple in a loop, but that defeats the purpose). I'm using CryptoPP::Integer
71 2011-07-26 01:19:17 <eian> multiply*
72 2011-07-26 01:23:22 <SerajewelKS> upb: https://github.com/bitcoin/bitcoin/pull/431
73 2011-07-26 01:23:39 <SerajewelKS> hopefully this pull request will receive some attention, unlike my listsinceblock pull request, which has sat there bit-rotting
74 2011-07-26 01:25:30 <luke-jr> SerajewelKS: that one *should* bitrot
75 2011-07-26 01:25:43 <SerajewelKS> mmhmm
76 2011-07-26 01:26:11 <luke-jr> SerajewelKS: it looks like a rewrite of my RPCv1 branch, but without fixing the actual problem
77 2011-07-26 01:26:39 <SerajewelKS> the problem being that it doesn't use TBC?
78 2011-07-26 01:26:56 <luke-jr> SerajewelKS: the problem being that it is trying to use human units for a low-level API
79 2011-07-26 01:27:17 <SerajewelKS> JSON is low-level?
80 2011-07-26 01:27:20 <luke-jr> yes
81 2011-07-26 01:27:23 <SerajewelKS> go away, troll
82 2011-07-26 01:27:30 <eian> haha
83 2011-07-26 01:27:33 <luke-jr> also, your claimed Python issues don't exist
84 2011-07-26 01:27:35 <lfm> luke-jr you mean it should just use satoshis?
85 2011-07-26 01:27:40 <luke-jr> lfm: yes
86 2011-07-26 01:28:18 <luke-jr> lfm: like everything else ;)
87 2011-07-26 01:28:54 <lfm> well almost everything
88 2011-07-26 01:29:10 <luke-jr> at least everything in bitcoind
89 2011-07-26 01:30:14 <lfm> luke-jr ya , i guess it is the old debate, is the json a purely computer interface or is it a human interface too.
90 2011-07-26 01:30:34 <luke-jr> pretty sure that was never argued: it's obviously a computer interface
91 2011-07-26 01:30:52 <luke-jr> the only argument was that fixing it didn't justify breaking compatibility, nor adding a versioning layer
92 2011-07-26 01:31:07 <lfm> the raw json out put is exposed to human eyes tho thru the bitcoind command line commands
93 2011-07-26 01:31:28 <luke-jr> sure, but that's a test/debug interface, not meant for actual use
94 2011-07-26 01:31:57 <SerajewelKS> it's meant for use by CLI people
95 2011-07-26 01:32:10 <luke-jr> SerajewelKS: no it isn't.
96 2011-07-26 01:32:18 <forrestv> SerajewelKS, you can tell the python json parser to convert json numbers to Decimals ...
97 2011-07-26 01:32:21 <lfm> a human test debug interface, and it is prefectly feasible for humans to use it for bitcoin operations, I know I do, but maybe I am too weird to be considered human
98 2011-07-26 01:32:33 <SerajewelKS> forrestv: using which mechanism?
99 2011-07-26 01:32:37 <luke-jr> forrestv: that wouldn't work like people assume though
100 2011-07-26 01:32:40 <forrestv> SerajewelKS, one of the examples on http://docs.python.org/library/json.html
101 2011-07-26 01:32:48 <luke-jr> SerajewelKS: it's default for bitcoinrpc module
102 2011-07-26 01:32:49 <lfm> the bitcoind comand line comands
103 2011-07-26 01:33:04 <SerajewelKS> forrestv: neat
104 2011-07-26 01:33:12 <luke-jr> lfm: I do too, but someone using programic interfaces should know how to read them too
105 2011-07-26 01:33:21 <forrestv> luke-jr, what do you mean?
106 2011-07-26 01:33:26 <luke-jr> forrestv: even if you parse it as Decimal, you still need to round it
107 2011-07-26 01:33:41 <luke-jr> forrestv: bitcoind can send 0.03999999999999999 when it means 0.04
108 2011-07-26 01:34:00 <luke-jr> at least in theory
109 2011-07-26 01:34:11 <lfm> luke-jr well I spoze it could use satoshis but it would be kinda a pain
110 2011-07-26 01:34:26 <luke-jr> lfm: not at all. and the code's already been done for months
111 2011-07-26 01:34:59 <luke-jr> or you mean a pain to read?
112 2011-07-26 01:35:06 <lfm> without breaking aps that use the api?
113 2011-07-26 01:35:26 <luke-jr> lfm: my RPCv1 branch used a version for it
114 2011-07-26 01:35:46 <lfm> ya a pain to read. I spoze bitcoind could add some extra ui stuff to display amounts more reasonably anyway.
115 2011-07-26 01:35:47 <luke-jr> so ver 0 (default) was the old way, and ver 1 was satoshis
116 2011-07-26 01:36:04 <luke-jr> bitcoin-cli should display it nicer anyway :p
117 2011-07-26 01:36:15 <lfm> I think 0 and 1 are the same. 2 is satoshis
118 2011-07-26 01:36:35 <luke-jr> lfm: not in my original code, at least
119 2011-07-26 01:36:47 <SerajewelKS> lfm: if you're referring to my patch, 0/1 are the same and 2 uses string representation (but still uses a decimal point)
120 2011-07-26 01:36:50 <lfm> oh what SerajewelKS did
121 2011-07-26 01:36:55 <luke-jr> Spesmilo still has support for RPCv1, though I don't even bother anymore
122 2011-07-26 01:37:16 <luke-jr> SerajewelKS: there's no reason/use for the stringification as satoshis ;)
123 2011-07-26 01:37:57 <luke-jr> unless you're aiming to workaround the bugs in jansson, which is IMO a terrible reason
124 2011-07-26 01:38:45 <SerajewelKS> luke-jr: except that 1000000000000001 can't be represented in 32-bit floating-point, which is a perfectly legal json implementation. the problem is that json numbers don't convey any sort of precision or bit-length information, which is a serious deficiency for financial information.
125 2011-07-26 01:39:01 <lfm> as a string, just take out the . to get satoshis
126 2011-07-26 01:39:13 <luke-jr> SerajewelKS: it's reasonable to assume JSON Numbers must be able to represent ECMAScript Numbers
127 2011-07-26 01:39:16 <SerajewelKS> the json spec is intentionally vague about it, and that's no good for monetary units
128 2011-07-26 01:39:23 <luke-jr> lfm: doesn't work like that
129 2011-07-26 01:39:31 <SerajewelKS> luke-jr: reasonable != specified behavior
130 2011-07-26 01:39:50 <SerajewelKS> (specifically, the spec specifies no behavior at all)
131 2011-07-26 01:41:14 <SerajewelKS> when dealing with vague number types, using strings is preferred to "some kind of number thingy"
132 2011-07-26 01:42:19 <luke-jr> better to just drop JSON altogether than worry about that IMO
133 2011-07-26 01:42:35 <luke-jr> or define the requirement as "JSON with at least 51 bits of number resolution"
134 2011-07-26 01:42:43 <luke-jr> (which is every implementation except jansson afaik)
135 2011-07-26 01:42:52 <luke-jr> actually, if you throw a "." on the end, jansson included
136 2011-07-26 01:43:05 <SerajewelKS> perhaps
137 2011-07-26 01:44:18 <luke-jr> IF strings are to be used, however, it is IMO logical to say "anything other than digits should be ignored"
138 2011-07-26 01:44:33 <luke-jr> then you can send a . for BTC, and even commas for thousand separators
139 2011-07-26 01:44:54 <luke-jr> while also guaranteeing full satoshi resolution to parsers that just ignore thos
140 2011-07-26 01:45:08 <luke-jr> (ie, it'd have to be 0-padded on the right)
141 2011-07-26 01:45:40 <SerajewelKS> well my implementation always uses eight digits right of the decimal point, so for output you can just strip the .
142 2011-07-26 01:45:51 <SerajewelKS> input does consider the . though, so it would need to be tweaked
143 2011-07-26 01:46:19 <SerajewelKS> there could always be a suffix for satoshis; then you have satoshis with full compat with older clients
144 2011-07-26 01:46:41 <luke-jr> stringifying is not compatible no matter what you do
145 2011-07-26 01:47:01 <SerajewelKS> hence the versioning
146 2011-07-26 01:47:44 <luke-jr> RPCv1 had versioning and satoshis :
147 2011-07-26 01:49:03 <luke-jr> if you wanted to go crazy, you could do /?amount=strBTC /?amount=str /?amount= (with the default being /?amount=BTC) ;)
148 2011-07-26 01:49:22 <SerajewelKS> luke-jr: that idea did cross my mind :P
149 2011-07-26 01:50:04 <luke-jr> all of this seems to suggest one thing though: binary protocols are simplest :p
150 2011-07-26 01:50:49 <lfm> iiieee binary endianess protocols?
151 2011-07-26 01:50:53 <SerajewelKS> JSON is plain simple if you represent everything as strings, bools, null, or objects
152 2011-07-26 01:51:23 <SerajewelKS> the number type is useless since the spec leaves the implementing type open-ended
153 2011-07-26 01:51:39 <lfm> ok for 0 to 64000
154 2011-07-26 01:51:48 <jgarzik> heh
155 2011-07-26 01:52:01 <lfm> or 0 to 32000 I mean
156 2011-07-26 01:52:06 <SerajewelKS> 32767
157 2011-07-26 01:52:25 <lfm> you shouldnt assume it is binary based
158 2011-07-26 01:52:39 <luke-jr> lfm: there is a standard network endian, kthx
159 2011-07-26 01:52:43 <lfm> it might be running on a IBM 1401!
160 2011-07-26 01:52:44 <SerajewelKS> if it's not binary based then the 32000 division is meaningless
161 2011-07-26 01:53:00 <SerajewelKS> luke-jr: which is conveniently the opposite of most computers that exist today :(
162 2011-07-26 01:53:12 <lfm> ya, so?
163 2011-07-26 01:53:13 <luke-jr> SerajewelKS: I agree, quite convenient.
164 2011-07-26 01:53:21 <luke-jr> SerajewelKS: it forces people to write sane code. in theory.
165 2011-07-26 01:53:51 <JFK911> most computers? isnt x86 the only one?
166 2011-07-26 01:53:56 <luke-jr> JFK911: fail
167 2011-07-26 01:54:01 <lfm> or the MIX 1009 in its decimal version(s)
168 2011-07-26 01:54:09 <SerajewelKS> luke-jr: i think he's derping on purpose
169 2011-07-26 01:54:18 <luke-jr> maybe