1 2011-12-09 00:00:30 <BlueMatt> nice
  2 2011-12-09 00:00:30 <gmaxwell> while OP_EVAL is compatible it has some chain splitting risk if someone maliciously tried to make trouble... so we only want to really deploy it when we know a good majority of the hash power is behind it.
  3 2011-12-09 00:01:05 <gmaxwell> E.g. you could use a modified node to mine a txn with OP_EVAL that is invalid to OP_EVAL nodes but valid to everyone else.
  4 2011-12-09 00:01:20 <BlueMatt> yea
  5 2011-12-09 00:02:30 <gmaxwell> (It's also a proof of concept for making other changes...)
  6 2011-12-09 00:02:42 <BlueMatt> yep
  7 2011-12-09 00:03:00 <BlueMatt> will op_eval txes be forwarded by current nodes?
  8 2011-12-09 00:03:04 <BlueMatt> (Im assuming not)
  9 2011-12-09 00:03:07 <BlueMatt> not IsStandard...
 10 2011-12-09 00:03:07 <luke-jr> no
 11 2011-12-09 00:04:01 <gmaxwell> Right, (and, hey, this is another reason to get keepnode merged sooner rather than later)
 12 2011-12-09 00:04:16 <BlueMatt> hey, I dont know why keepnode still isnt merged
 13 2011-12-09 00:04:32 <BlueMatt> (aside from the fact it has 0 comments on the pull-req...)
 14 2011-12-09 00:04:43 <BlueMatt> oh wait, no luke ack'd it
 15 2011-12-09 00:04:53 <BlueMatt> well atleast it has 1...
 16 2011-12-09 00:05:09 <gmaxwell> I only got to test it a little, thus no ack from me yet. :-/  It looked okay though.
 17 2011-12-09 00:05:24 <BlueMatt> oh wait there was one potential race I wanted to test...
 18 2011-12-09 00:05:49 <BlueMatt> well more like work around because I dont feel like actually testing it...
 19 2011-12-09 00:23:44 <BlueMatt> while Im digging through code, what should the maximum wait time of the exponential backoff for retrying connection to -keepnode's be?
 20 2011-12-09 00:23:50 <BlueMatt> (powers of 2 minutes)
 21 2011-12-09 00:27:23 <gmaxwell> BlueMatt: I don't think it should be higher than a few minutes otherwise network outages leave it disconnected a long time... also a 'couple minutes' is enough to keep it from DOSing things.
 22 2011-12-09 00:28:00 <BlueMatt> couple being 2, 4, 8, 16, or 32?
 23 2011-12-09 00:28:14 <BlueMatt> s/couple/few/
 24 2011-12-09 00:28:18 <gmaxwell> more like 2-4 than higher, I think.
 25 2011-12-09 00:35:23 <BlueMatt> someone have a dns name for their node I can use to test really quick?
 26 2011-12-09 00:42:55 <sipa> BlueMatt: bitcoin.sipa.be
 27 2011-12-09 00:43:13 <BlueMatt> thanks
 28 2011-12-09 00:47:58 <sipa> luke-jr: i think it's wrong to use a tx's prevout's address as identity for the payer, which is what you'd encourage by signing based on it
 29 2011-12-09 00:48:24 <luke-jr> sipa: no, that's why I said we need a NEW form of signmessage just for txns
 30 2011-12-09 00:48:31 <sipa> or is there another use case?
 31 2011-12-09 00:48:48 <luke-jr> ignore the prevout and vin entirely.
 32 2011-12-09 00:48:59 <luke-jr> instead of signing with an address, we sign with a txnid.
 33 2011-12-09 00:49:23 <luke-jr> the technical details might be, to sign it with one of the keys that signed the txn.
 34 2011-12-09 00:49:54 <sipa> right... same problem
 35 2011-12-09 00:49:56 <luke-jr> which will *usually* be the same as a vin, but unlike vin is guaranteed to always be standard
 36 2011-12-09 00:50:18 <luke-jr> vin is not-really-associated with the transaction, but the keys used to sign the transaction definitely are.
 37 2011-12-09 00:50:39 <luke-jr> and those keys are basically guaranteed to exist
 38 2011-12-09 00:50:42 <sipa> what do you need it for?
 39 2011-12-09 00:50:48 <luke-jr> sipa: proof of payment
 40 2011-12-09 00:51:26 <sipa> why do you need it to be done by the same identity as the author of the tx?
 41 2011-12-09 00:51:48 <BlueMatt> ok, new keepnode pushed, now with less redundant code and less potential to segfault in very rare cases
 42 2011-12-09 00:52:17 <sipa> BlueMatt: i'll look at it soon, poke me if i forget
 43 2011-12-09 00:52:54 <sipa> ok phone battery is done
 44 2011-12-09 00:52:56 <sipa> cya
 45 2011-12-09 00:53:02 <BlueMatt> bye
 46 2011-12-09 00:53:31 <luke-jr> sipa: that's how you prove you sent it, obviously.
 47 2011-12-09 00:57:42 <BlueMatt> gmaxwell: I did 8 minutes, if anyone has objections speak now or forever hold your peace
 48 2011-12-09 00:58:54 <luke-jr> I object.
 49 2011-12-09 00:59:05 <luke-jr> It should be a timton.
 50 2011-12-09 00:59:20 <luke-jr> (5 minutes 37.5 seconds)
 51 2011-12-09 01:00:58 <gmaxwell> I wonder what OSes use for the backfor for tcp syns?
 52 2011-12-09 01:02:06 <phantomcircuit> gmaxwell, wat
 53 2011-12-09 01:03:14 <gmaxwell> er autotype error, for the maximum backoff on initial syn.
 54 2011-12-09 01:05:32 <phantomcircuit> i repeat
 55 2011-12-09 01:05:33 <phantomcircuit> wat
 56 2011-12-09 01:05:41 <phantomcircuit> gmaxwell, there is a simple timeout for the initial syn
 57 2011-12-09 01:05:59 <gmaxwell> phantomcircuit: I thought it did exponential backoff for that too. 0_o
 58 2011-12-09 01:06:09 <gmaxwell> memory fail for me then.
 59 2011-12-09 01:06:50 <phantomcircuit> gmaxwell, i guess the interval increases between syn
 60 2011-12-09 01:07:06 <phantomcircuit> the default timeout on linux is huge
 61 2011-12-09 01:07:08 <phantomcircuit> like 2 minutes
 62 2011-12-09 01:07:17 <BlueMatt> o rly?
 63 2011-12-09 01:07:41 <phantomcircuit> yeah it's why the connect stuff had to be changed
 64 2011-12-09 01:08:06 <gmaxwell> BlueMatt: I think 8 minutes is too high... besides, if every single bitcoin node keepnoded a single host.. that was full/down to minutes would be 333 PPS or about 100kbit/sec... which isn't a big deal at all.
 65 2011-12-09 01:08:25 <gmaxwell> s/to/for two/
 66 2011-12-09 01:08:52 <BlueMatt> fair enough, though if default timeout is 2 min, minimum timeout should also be 2 minutes
 67 2011-12-09 01:09:03 <BlueMatt> which means we would have exponential backoff - from 2 minutes to 4 ;)
 68 2011-12-09 01:09:09 <BlueMatt> seems kinda...overkill
 69 2011-12-09 01:09:31 <gmaxwell> Yea, it's overkill as mentioned 2 minutes gets you a fairly low rate.
 70 2011-12-09 01:09:32 <phantomcircuit> what's this all about
 71 2011-12-09 01:09:39 <phantomcircuit> im too lazy to read scrollback
 72 2011-12-09 01:09:51 <BlueMatt> -keenode timeout between retries
 73 2011-12-09 01:10:05 <BlueMatt> fair enough, Ill just change it to Sleep(2000);
 74 2011-12-09 01:10:05 <phantomcircuit> keepnode?
 75 2011-12-09 01:10:09 <gmaxwell> BlueMatt: you still need some timeout in your code because the initial syn timeout doesn't apply to e.g. if you get hung up on right away, or if you get an ICMP unreach.
 76 2011-12-09 01:10:19 <BlueMatt> -addnode but retry forever until you get connected
 77 2011-12-09 01:10:34 <BlueMatt> yea, ofc
 78 2011-12-09 01:10:35 <phantomcircuit> ah
 79 2011-12-09 01:11:33 <gmaxwell> BlueMatt: oh, you should also take care not to block the network thread for long spans of time.
 80 2011-12-09 01:11:46 <gmaxwell> (e.g. I don't think inserting a sleep is ideal)
 81 2011-12-09 01:11:52 <BlueMatt> its a separate thread
 82 2011-12-09 01:12:02 <BlueMatt> -keepnode connect is a separate thread
 83 2011-12-09 01:12:19 <gmaxwell> shows how useful my memory is. ... but ... seperate thread for each keepnode?
 84 2011-12-09 01:12:39 <BlueMatt> no, one additional thread
 85 2011-12-09 01:12:53 <BlueMatt> which while(true) { add keepnodes; sleep (2min); }
 86 2011-12-09 01:14:01 <gmaxwell> I guess someone ought to test that with a bunch of unresponsive (no icmp error) nodes plus one good one just to make sure it doesn't get stuck on down ones.
 87 2011-12-09 01:15:06 <BlueMatt> if OpenNetworkConnection(CAddress addr) gets stuck on an unresponsive node, then we have a more serious problem than just -keepnode
 88 2011-12-09 01:15:47 <gmaxwell> I don't think it does anymore.
 89 2011-12-09 01:15:51 <gmaxwell> (it used to)
 90 2011-12-09 01:16:03 <BlueMatt> well then -keepnode is safe
 91 2011-12-09 01:16:31 <gmaxwell> The other thing we're currently lacking is a way to figure out if your kn's are actually up.
 92 2011-12-09 01:16:42 <BlueMatt> true
 93 2011-12-09 01:16:48 <gmaxwell> As you only see a raw connection count... it means your KN config can bitrot.
 94 2011-12-09 01:17:02 <gmaxwell> (and if you're depending on KN's for security or forwarding properties, thats bad)
 95 2011-12-09 01:17:13 <Diablo-D3> gmaxwell: hey you
 96 2011-12-09 01:17:14 <BlueMatt> true
 97 2011-12-09 01:17:17 <Diablo-D3> did you change the top 10?
 98 2011-12-09 01:17:22 <gmaxwell> No sir.
 99 2011-12-09 01:17:32 <BlueMatt> should I add a keepnode-connections field to getinfo?
100 2011-12-09 01:17:36 <Diablo-D3> I wonder who did
101 2011-12-09 01:17:56 <Diablo-D3> owner of EMC? is bitching at me because top 10 got changed and bumped him out
102 2011-12-09 01:17:57 <gmaxwell> I thought about it when someone was complaining that something wasn't listed but .. got distracted before I figured out if I should.
103 2011-12-09 01:17:58 <Diablo-D3> but it wasnt me
104 2011-12-09 01:18:36 <Diablo-D3> welp, I guess its top ten sorting time
105 2011-12-09 01:18:45 <gmaxwell> BlueMatt: or a listpeers RPC that tells you all the peers you're connected to, if they're keepnodes, etc.
106 2011-12-09 01:18:58 <BlueMatt> that sounds like more work...
107 2011-12-09 01:19:10 <gmaxwell> Yea.. seperate patch.
108 2011-12-09 01:19:13 <theymos> Diablo-D3: It was Maged.
109 2011-12-09 01:19:27 <BlueMatt> well if I remember Ill write it tomorrow or sometime...
110 2011-12-09 01:20:10 <Diablo-D3> theymos: who?
111 2011-12-09 01:20:31 <gmaxwell> BlueMatt: (it could also show their badness score, what block they've told you about, their network time offset, some other crap.. scope creep scope creep.
112 2011-12-09 01:20:34 <gmaxwell> )
113 2011-12-09 01:20:50 <theymos> Diablo-D3: He's a global moderator. I don't know why he unstickied it -- I just see it in the moderation log. You'll have to ask him about it.
114 2011-12-09 01:21:13 <Diablo-D3> we have global mods? since when?
115 2011-12-09 01:21:24 <gmaxwell> Diablo-D3: perhaps the criteria should be changed to "big enough to solve N blocks a week" based on current rate and difficulty (you pick the N because I have NFI)
116 2011-12-09 01:21:24 <theymos> Always.
117 2011-12-09 01:21:31 <BlueMatt> gmaxwell: yea, well well see how inspired I feel when writing it...(probably quite a bit since I will likely be procrastinating writing a final...)
118 2011-12-09 01:21:41 <Diablo-D3> gmaxwell: that'd make it easier. we'd have three pools.
119 2011-12-09 01:21:52 <gmaxwell> Diablo-D3: Even I knew who Maged is.. read the staff forum.
120 2011-12-09 01:21:59 <Diablo-D3> theres a staff forum?!
121 2011-12-09 01:22:53 <gmaxwell> Diablo-D3: when you were little did people often trick you?
122 2011-12-09 01:23:13 <Diablo-D3> no, but dude, I never venture out of the mining subforum
123 2011-12-09 01:23:18 <gmaxwell> :)
124 2011-12-09 01:23:19 <Diablo-D3> too many people I want dead
125 2011-12-09 01:23:51 <theymos> It's a top-level section listed near the bottom of the front page.
126 2011-12-09 01:23:57 <gmaxwell> 0_o
127 2011-12-09 01:23:58 <theymos> https://bitcointalk.org/index.php?board=3.0
128 2011-12-09 01:24:13 <BlueMatt> awww, Im not admin...
129 2011-12-09 01:24:42 <theymos> Diablo-D3: Recently I posted some mod action counts. You're fifth in mod actions. Pretty impressive!
130 2011-12-09 01:24:44 <Diablo-D3> theymos: yeah, but when was the last time I looked at the front page?
131 2011-12-09 01:24:55 <Diablo-D3> dude, I'd be first if you let me ban people
132 2011-12-09 01:25:19 <theymos> I'm sure you would be, but then there'd be no users. :)
133 2011-12-09 01:25:35 <Diablo-D3> you say that like theres a problem
134 2011-12-09 01:25:50 <k9quaint> he wouldn't ban me, I am far too sexy
135 2011-12-09 01:26:26 <Diablo-D3> hah
136 2011-12-09 01:26:29 <SomeoneWeird> lolol
137 2011-12-09 01:26:42 <Diablo-D3> unison mod wrath
138 2011-12-09 01:26:43 <Diablo-D3> fear
139 2011-12-09 01:26:59 <BlueMatt> heh, hes not coming back...
140 2011-12-09 01:27:08 <BlueMatt> ...oops
141 2011-12-09 01:27:30 <theymos> You kiilled him. You monster!
142 2011-12-09 01:27:59 <Diablo-D3> now Im going to read everything theymos says in that voice.
143 2011-12-09 01:28:48 <BlueMatt> heh
144 2011-12-09 01:29:54 <SomeoneWeird> lol
145 2011-12-09 01:29:57 <SomeoneWeird> -.-
146 2011-12-09 01:30:40 <k9quaint> nerve, kicking me when I wasnt looking :P
147 2011-12-09 01:30:54 <BlueMatt> damn, you look away quick
148 2011-12-09 01:32:04 <k9quaint> hazards of having a 6 year old :)
149 2011-12-09 01:32:12 <BlueMatt> heh
150 2011-12-09 01:33:14 <Diablo-D3> lol
151 2011-12-09 01:35:24 <k9quaint> I guess I should flip out and make an altcoin or something :)
152 2011-12-09 01:36:01 <Diablo-D3> yeah seems all the rage
153 2011-12-09 01:36:33 <k9quaint> Bannedfrombitcoincoin
154 2011-12-09 01:37:01 <Diablo-D3> bfbcbtc
155 2011-12-09 01:37:13 <k9quaint> why aren't the top 10 pools sorted by size?
156 2011-12-09 01:37:20 <k9quaint> (lazy mod)
157 2011-12-09 01:37:23 <Diablo-D3> no
158 2011-12-09 01:37:26 <Diablo-D3> the forum software doesnt support it
159 2011-12-09 01:37:32 <Diablo-D3> they're sorted by last post
160 2011-12-09 01:38:00 <k9quaint> isn't the forum software opensource?
161 2011-12-09 01:39:54 <Diablo-D3> yes, but its also php.
162 2011-12-09 01:40:21 <gmaxwell> sorting them by size is _not_ what we want.
163 2011-12-09 01:40:32 <k9quaint> let me know once you have modded it to support ordering sticky threads by hash size, I will test it :P
164 2011-12-09 01:40:37 <gmaxwell> it's bad for the network to encourage people to concentrate on the largest few pools.
165 2011-12-09 01:40:53 <Diablo-D3> yeah I was actually thinking about getting rid of stickies
166 2011-12-09 01:40:56 <k9quaint> gmaxwell: true, but you could have waiting until after he added it
167 2011-12-09 01:41:07 <gmaxwell> The only reason to have a size cutoff is just to help people avoid miniscampools.
168 2011-12-09 01:41:07 <k9quaint> *waited
169 2011-12-09 01:41:29 <Diablo-D3> and just give the biggest, say, 3 pools their own subforums
170 2011-12-09 01:41:41 <theymos> I wouldn't do stickies. Just list them in one sticky topic if necessary.
171 2011-12-09 01:41:59 <SomeoneWeird> Diablo-D3, that'll have the same effect?
172 2011-12-09 01:42:49 <k9quaint> big pooling is an interesting tragedy of commons problem
173 2011-12-09 01:44:20 <Diablo-D3> theymos: hrm.
174 2011-12-09 01:44:29 <Diablo-D3> theymos: still takes too much effort
175 2011-12-09 01:45:08 <theymos> I probably wouldn't deal with it at all. Let some other site maintain a top 10.
176 2011-12-09 01:47:33 <gmaxwell> k9quaint: I don't think it is... it's not like people gain enormously from using the biggest.
177 2011-12-09 01:47:46 <k9quaint> its the safety in numbers instinct
178 2011-12-09 01:48:04 <k9quaint> probably a pretty powerful urge in first time users
179 2011-12-09 01:48:17 <gmaxwell> They have no other basis to go on.
180 2011-12-09 01:48:22 <k9quaint> indeed
181 2011-12-09 01:49:43 <gmaxwell> k9quaint: well they do, actually, but apparently a couple percent fee difference doesn't matter to anyone.
182 2011-12-09 01:50:48 <k9quaint> I am sure Bank of America could elaborate further on the effects of fees on customers
183 2011-12-09 01:53:27 <k9quaint> ouch, more shooting at VTech :(
184 2011-12-09 01:54:20 <Diablo-D3> heh
185 2011-12-09 01:54:27 <Diablo-D3> subject of a thread in mod forum
186 2011-12-09 01:54:33 <Diablo-D3> "Apparently, I'm a dick"
187 2011-12-09 01:54:47 <Diablo-D3> a dick is just another name for a mod.
188 2011-12-09 01:58:38 <phantomcircuit> awesome
189 2011-12-09 01:58:42 <phantomcircuit> make -j
190 2011-12-09 01:58:47 <phantomcircuit> no swapping
191 2011-12-09 01:58:49 <phantomcircuit> ^_^
192 2011-12-09 02:02:06 <SomeoneWeird> lol
193 2011-12-09 02:02:35 <phantomcircuit> ;;bc,blocks
194 2011-12-09 02:02:36 <gribble> 156710
195 2011-12-09 02:57:20 <CIA-100> libbitcoin: genjix * r906c02584c34 / (19 files in 7 dirs): new style network interface [old style: network_ptr + channel_handle -> new style: network_ptr / channel_ptr] http://tinyurl.com/8xkjfc6
196 2011-12-09 03:07:03 <CIA-100> libbitcoin: genjix * ra626229c3f06 / (19 files in 7 dirs): new style network interface [old style: network_ptr + channel_handle -> new style: network_ptr / channel_ptr] http://tinyurl.com/cxzxpyo
197 2011-12-09 07:43:46 <SomeoneWeird> ffs. anyone have any experience with facebook api?
198 2011-12-09 08:44:03 <doublec> SomeoneWeird: I did a while back
199 2011-12-09 08:44:21 <doublec> SomeoneWeird: I'm a bit rusty now tho
200 2011-12-09 10:01:30 <c_k> http://blockchain.info/pools?timespan=24hrs
201 2011-12-09 10:01:36 <c_k> oops, wrong chan
202 2011-12-09 10:23:13 <sipa> luke-jr: that proves you (or someone else having access to your keys) created it, yes; but what do you need that information for?
203 2011-12-09 10:46:36 <cande> can you send bitcoins via NFC without internet access?
204 2011-12-09 10:47:52 <sipa> in theory... i suppose you could transmit a signed tx through nfc, without broadcasting it yourself
205 2011-12-09 10:48:24 <justmoon> cande, yes, TD (BitcoinJ) has done testing with NFC - as for sending offline, you won't know if there has been a conflicting transaction until you get online and check the blockchain (and of course you can't get your own transaction confirmed until you can send it to miners)
206 2011-12-09 10:48:25 <sipa> but i don't know about any defined interfaces or implementations
207 2011-12-09 10:48:53 <sipa> in the future, i believe that is the way to go even
208 2011-12-09 10:49:04 <justmoon> sipa: for sure
209 2011-12-09 10:49:14 <sipa> send your transaction directly to the one who cares about whether it goes through
210 2011-12-09 10:49:18 <justmoon> just worried carriers will lock us out, like apple did
211 2011-12-09 10:49:58 <sipa> on the other hand... devices with NFC but without internet connection may be rare
212 2011-12-09 10:50:16 <justmoon> sipa: traveling, bad reception
213 2011-12-09 10:50:22 <sipa> maybe
214 2011-12-09 10:50:35 <sipa> so it may prove easier to send the tx to your merchant via IP than via NFC... not sure what the future will bring
215 2011-12-09 10:51:09 <cande> hm
216 2011-12-09 10:51:24 <justmoon> it's certainly more likely that the merchant will have internet than it is for you to have it
217 2011-12-09 10:51:30 <sipa> true
218 2011-12-09 10:51:40 <justmoon> and since he's the recipient he's the only one who cares about confirming the tx anyway
219 2011-12-09 10:51:55 <justmoon> nfc definitely seems the way to go
220 2011-12-09 10:52:06 <justmoon> less dependency on outside factors
221 2011-12-09 10:52:37 <cande> an NFC signed tx can be broadcast by the reciever to get it verified
222 2011-12-09 10:52:45 <sipa> yes, that's the idea
223 2011-12-09 10:52:51 <justmoon> cande, it would be a normal transaction like any other
224 2011-12-09 10:53:03 <justmoon> it doesn't matter who submits it to the network
225 2011-12-09 10:53:09 <justmoon> it's p2p anyway
226 2011-12-09 10:53:14 <justmoon> relaying is the same as sending
227 2011-12-09 10:53:16 <justmoon> (almost)
228 2011-12-09 10:53:21 <justmoon> except for rebroadcasting
229 2011-12-09 10:53:26 <justmoon> (don't worry about that :P)
230 2011-12-09 10:53:43 <cande> but if you get the tx from the bitcoin network, then you atleast know its not conflicting
231 2011-12-09 10:54:14 <sipa> if you have a full node as merchant; you can verify whether the incoming tx isn't conflicting either
232 2011-12-09 10:54:38 <sipa> most likely you'll use a third party service for that, i imagine
233 2011-12-09 10:54:53 <justmoon> yeah, bitcoinjs has an api call that tells you
234 2011-12-09 10:55:14 <cande> how does that api work?
235 2011-12-09 10:55:26 <justmoon> when you submit a new transaction for broadcast, it'll tell you if it passed verification or not
236 2011-12-09 10:55:35 <sipa> nice
237 2011-12-09 10:56:04 <cande> ah
238 2011-12-09 10:56:33 <cande> 0confirms also?
239 2011-12-09 10:56:43 <sipa> it can't do more than that
240 2011-12-09 10:56:49 <sipa> or the API would block
241 2011-12-09 10:56:54 <justmoon> don't understand the question
242 2011-12-09 10:57:13 <justmoon> oh you mean does it tell you when the transaction is confirmed?
243 2011-12-09 10:57:46 <justmoon> if you're either the receiver or sender, then yes, it'll tell you about confirmations in real time
244 2011-12-09 10:58:01 <cande> hm good :)
245 2011-12-09 10:58:03 <justmoon> (basically, it'll tell you about events that concern any addresses in your wallet)
246 2011-12-09 10:59:01 <cande> but today no mobile nfc app sends a tx with nfc to the receiver
247 2011-12-09 10:59:20 <justmoon> you have to TD, I'm not sure what's implemented and what isn't
248 2011-12-09 10:59:30 <cande> what does TD stand for?
249 2011-12-09 10:59:38 <justmoon> it's a username
250 2011-12-09 10:59:58 <cande> is TD in this channel?
251 2011-12-09 11:00:15 <justmoon> TD[gone] <- that guy :)
252 2011-12-09 11:00:19 <justmoon> he's away it seems
253 2011-12-09 11:00:27 <justmoon> or offline probably
254 2011-12-09 11:00:29 <cande> ah :)
255 2011-12-09 11:01:10 <justmoon> I believe he announced doing the first ever bitcoin transaction over NFC a while back
256 2011-12-09 11:04:54 <cande> thx
257 2011-12-09 11:07:33 <justmoon> ah I just realized I missed a word there, I meant to say: you have to ask* TD :)
258 2011-12-09 11:18:58 <cande> right :)
259 2011-12-09 14:36:14 <Eliel> are there any C/C++ implementations of light bitcoin node?
260 2011-12-09 14:52:54 <helo> how light? (not that i know the answer, just curious what you're looking for)
261 2011-12-09 14:54:10 <helo> it would be kind of neat to have a "bitcoin scanner" tool that could be set to monitor certain addresses, either in confirmed blocks or in unconfirmed transactions
262 2011-12-09 14:55:57 <helo> perhaps if you really want to be lightweight (maybe a walletless mobile phone "bitcoin notifier")
263 2011-12-09 14:57:01 <helo> although running a full node in a centralized location and having a secure connection to it is probably still both more lightweight and useful
264 2011-12-09 15:04:11 <Eliel> I mean a bitcoin client that only downloads blockchain headers and the transactions it needs to spend the bitcoins it has.
265 2011-12-09 15:10:44 <k9quaint> I have a bitcoin client written in C that says 'Hello World' and little else, is that light enough?
266 2011-12-09 15:24:17 <luke-jr> sipa: again& proof of payment.
267 2011-12-09 17:50:53 <CIA-100> bitcoin: Luke Dashjr maintree * reb1af55df85d gentoo/net-p2p/ (bitcoind/Manifest wxbitcoin/Manifest): Merge branch 'master' into maintree http://tinyurl.com/7aog3yj
268 2011-12-09 17:50:54 <CIA-100> bitcoin: Luke Dashjr * r8fee050a023f gentoo/net-p2p/ (24 files in 5 dirs): net-p2p/{bitcoin-qt,bitcoind,libbitcoin,namecoin,wxbitcoin}: Depend on sys-libs/db with USE=cxx http://tinyurl.com/855thsk
269 2011-12-09 18:00:39 <CIA-100> bitcoin: Luke Dashjr maintree * r75adb992c34d gentoo/net-p2p/ (11 files in 3 dirs): Merge branch 'master' into maintree http://tinyurl.com/7wv5pby
270 2011-12-09 18:17:19 <CIA-100> libbitcoin: genjix * r061e0081ee47 / (3 files in 2 dirs): Updated kernel for new style network interface. http://tinyurl.com/clv7fz8
271 2011-12-09 18:19:50 <lianj> why is libbitcoin c++?!
272 2011-12-09 18:22:07 <luke-jr> lianj: why not?
273 2011-12-09 18:22:48 <lianj> not as easy to make binding in other languages for it
274 2011-12-09 18:22:54 <[eval]> luke-jr: are you the maintainer of bitcoin-pl on gitorious, and am i correct in reading the license that the code is public domain?
275 2011-12-09 18:23:30 <luke-jr> [eval]: I am not.
276 2011-12-09 18:23:48 <[eval]> luke-jr: ok, thanks
277 2011-12-09 18:23:55 <luke-jr> lianj: you mean why is the API C++?
278 2011-12-09 18:24:03 <lianj> yes
279 2011-12-09 18:24:08 <luke-jr> ask genjix
280 2011-12-09 18:24:11 <lianj> hehe
281 2011-12-09 18:35:54 <CIA-100> bitcoin: Luke Dashjr * rb3b52ee5cd45 gentoo/net-p2p/libbitcoin/ (Manifest libbitcoin-9999.ebuild): net-p2p/libbitcoin: formatting adjustments http://tinyurl.com/7agwp4z
282 2011-12-09 18:39:49 <helo> how's progress with OP_EVAL being included in blocks?
283 2011-12-09 18:40:47 <luke-jr> helo: it will work if you -addnode=relay.eligius.st
284 2011-12-09 18:41:34 <BlueMatt> well while you are custom-building with OP_EVAL might as well add keepnode
285 2011-12-09 18:41:42 <BlueMatt> then you can -keepnode=relay.eligius.st
286 2011-12-09 18:42:46 <[Tycho]> Hello.
287 2011-12-09 18:42:51 <BlueMatt> hi
288 2011-12-09 18:43:38 <[Tycho]> BlueMatt: what is your bitcoin project ?
289 2011-12-09 18:43:57 <BlueMatt> ?
290 2011-12-09 18:44:02 <[Tycho]> Do you have any ?
291 2011-12-09 18:44:10 <BlueMatt> do I have to have a bitcoin project?
292 2011-12-09 18:44:18 <BlueMatt> I work on the main client when I have spare time?
293 2011-12-09 18:44:26 <[Tycho]> Ok.
294 2011-12-09 18:44:33 <BlueMatt> run a dnsseed
295 2011-12-09 18:44:46 <BlueMatt> run jenkins for bitcoind/-qt automated building
296 2011-12-09 18:44:50 <[Tycho]> You are on #bitcoin-dev, so it was possible that you are developing something :)
297 2011-12-09 18:44:54 <BlueMatt> etc
298 2011-12-09 18:45:39 <BlueMatt> bitcoin wallet encryption?
299 2011-12-09 18:48:41 <helo> nice
300 2011-12-09 18:49:04 <[Tycho]> I just noticed that you are not in my list, that's why I asked.
301 2011-12-09 18:49:16 <BlueMatt> list of?
302 2011-12-09 18:49:33 <[Tycho]> List of bitcoin-related people.
303 2011-12-09 18:49:47 <BlueMatt> mmm
304 2011-12-09 18:51:26 <[Tycho]> So when I see someone on forum or IRC, I check my list to find who is it.
305 2011-12-09 18:52:05 <BlueMatt> mmm
306 2011-12-09 18:56:43 <luke-jr> [Tycho]: BlueMatt likes to consider himself important ;)
307 2011-12-09 18:58:36 <BlueMatt> heh, never had enough free time to actually contribute that much...
308 2011-12-09 19:00:01 <midnightmagic> Sweet! Am I on the list too?
309 2011-12-09 19:01:00 <iz> [Tycho]: do you check it twice?
310 2011-12-09 19:01:12 <[Tycho]> midnightmagic: not yet.
311 2011-12-09 19:01:23 <[Tycho]> iz: sure, new year is coming.
312 2011-12-09 19:02:17 <midnightmagic> Put "Dork responsible for -1 Satoshi in block http://blockexplorer.com/b/124724"
313 2011-12-09 19:02:23 <midnightmagic> next to my name. :)
314 2011-12-09 19:02:52 <[Tycho]> I still have to wait months until my "gifts" will be ready.
315 2011-12-09 19:03:11 <rjk2> o/
316 2011-12-09 19:03:26 <midnightmagic> =]
317 2011-12-09 19:03:29 <[Tycho]> midnightmagic: -2 Satoshi ?
318 2011-12-09 19:03:45 <rjk2> -1 and a fee right
319 2011-12-09 19:04:00 <BlueMatt> no, blockexplorer displays it wrong
320 2011-12-09 19:04:33 <midnightmagic> -1 in the generation, and I ignored the fees partly because the fees didn't occur to me, and partly because I think the 49.999999 was more obvious that way
321 2011-12-09 19:04:55 <BlueMatt> oh, no its 0.00000001 and 0.01
322 2011-12-09 19:05:08 <midnightmagic> (so in retrospect I would've done it that way on purpose anyway.)
323 2011-12-09 19:05:35 <midnightmagic> It started off as a joke from BlueMatt, who said he was going to race me to do it.
324 2011-12-09 19:05:54 <midnightmagic> And ended up as a tribute to Satoshi. We are minus one  Satoshi, and now the blockchain is too.
325 2011-12-09 19:06:03 <BlueMatt> heh
326 2011-12-09 19:38:38 <luke-jr> [Tycho]: you're giving us something? :P
327 2011-12-09 19:39:21 <rjk2> lol giving it away would be generous
328 2011-12-09 19:43:06 <luke-jr> BlueMatt: don't worry, you're on my (git remote) list ;)
329 2011-12-09 19:44:51 <BlueMatt> heh, I have so many random people on mine that did one-off pull reqs...
330 2011-12-09 19:45:01 <BlueMatt> my list is huge...
331 2011-12-09 19:45:12 <[Tycho]> No, selling it :)
332 2011-12-09 19:46:29 <lianj> oO
333 2011-12-09 20:00:31 <[Tycho]> He he he :)
334 2011-12-09 20:02:04 <luke-jr> BlueMatt: I don't add remotes for mere pull requests :P
335 2011-12-09 20:02:29 <BlueMatt> luke-jr: meh whatever
336 2011-12-09 20:02:41 <BlueMatt> Im honored ;)
337 2011-12-09 20:17:18 <cj> what debian squeeze packages do I need to grab to satisfy bitcoin build deps?
338 2011-12-09 20:17:52 <BlueMatt> look at doc/build-unix.txt
339 2011-12-09 20:18:00 <BlueMatt> there should be an apt-get line that will work 90%
340 2011-12-09 20:18:28 <BlueMatt> just make sure you use libdb4.8++-dev if you want wallet.dat compat with release versions
341 2011-12-09 20:19:17 <cj> oh, look.  there's a contrib/debian
342 2011-12-09 20:19:30 <BlueMatt> if you want a deb package, that will work
343 2011-12-09 20:27:47 <cj> BlueMatt: looks like you're targeting wheezy, eh?  got a debian/ for squeeze?
344 2011-12-09 20:28:17 <cjdelisle> I built on lenny/squeeze without too much trouble
345 2011-12-09 20:28:54 <cj> cjdelisle: did you patch debian/control to reference the versions of packages in those dists?
346 2011-12-09 20:29:00 <BlueMatt> cj: targeting ubuntu, not even debian
347 2011-12-09 20:29:33 <cjdelisle> I actually built with the new libdb so my wallet is not compatable with old versions
348 2011-12-09 20:29:53 <cjdelisle> doesn't bother me that much
349 2011-12-09 20:30:12 <cjdelisle> but the apt command worked pretty much verbadum IIRC
350 2011-12-09 20:30:29 <cj> cjdelisle: okay.  I'll patch control and push it up to my github
351 2011-12-09 20:30:36 <cj> BlueMatt: roger
352 2011-12-09 20:30:48 <cjdelisle> I also did make USE_UPNP=
353 2011-12-09 20:31:05 <cjdelisle> because my stuff doesn't even support upnp and it was just one more thing
354 2011-12-09 20:31:15 <cjdelisle> I opened the port manually
355 2011-12-09 20:38:47 <cj> cjdelisle: yeah, I saw that I'd need to do that, since there's no libminiupnp in squeeze apparently
356 2011-12-09 20:43:37 <CIA-100> bitcoin: Wladimir J. van der Laan master * r45198af / src/qt/bitcoingui.cpp : Prevent window from being shown momentarily when using -min ... https://github.com/bitcoin/bitcoin/commit/45198af2be4e4cf26bf6d751a4bacb564abddb7f
357 2011-12-09 22:23:23 <luke-jr> ;;bc,calcd 500 1
358 2011-12-09 22:23:24 <gribble> The average time to generate a block at 500 Khps, given the supplied difficulty of 1, is 2 hours, 23 minutes, and 9 seconds
359 2011-12-09 22:23:29 <gribble> The average time to generate a block at 2000 Khps, given the supplied difficulty of 1, is 35 minutes and 47 seconds
360 2011-12-09 22:23:29 <luke-jr> ;;bc,calcd 2000 1
361 2011-12-09 23:10:04 <Mad7Scientist> I was sending 8 BTC and it said I needed to pay 0.01 BTC fee because I was over the size limit
362 2011-12-09 23:10:15 <Mad7Scientist> but I waited until the next block and there was no fee
363 2011-12-09 23:10:19 <Mad7Scientist> what happened
364 2011-12-09 23:11:20 <luke-jr> Mad7Scientist: the coins matured more
365 2011-12-09 23:22:53 <gribble> The average time to generate a block at 2500 Khps, given the supplied difficulty of 1, is 28 minutes and 37 seconds
366 2011-12-09 23:22:53 <luke-jr> ;;bc,calcd 2500 1