1 2012-10-01 00:08:24 <wizkid057> hmm... so, in the code it says that "this should never happen", yet I get a ton of " ERROR: mempool transaction missing input" in my debug log...
  2 2012-10-01 00:08:30 <wizkid057> this normal? lol
  3 2012-10-01 02:09:55 <jgarzik> amiller: ping
  4 2012-10-01 02:10:06 <amiller> yo jgarzik
  5 2012-10-01 02:10:06 <jgarzik> amiller: Do you agree that your pynode stuff is ready for pulling?
  6 2012-10-01 02:11:08 <amiller> yes i think it's ready
  7 2012-10-01 02:11:23 <amiller> i've had two of them up for a couple of days
  8 2012-10-01 02:11:43 <jgarzik> amiller: OK
  9 2012-10-01 02:12:12 <jgarzik> amiller: I'll pull locally, do one final test import, then push to pynode.git/master
 10 2012-10-01 02:12:34 <jgarzik> amiller: so it should show up in $IBD_time_amount hours :)
 11 2012-10-01 02:18:03 <amiller> hm, i think i just figured out how to make IBD go fast as hell
 12 2012-10-01 02:18:12 <amiller> specifically, it's IBD without any seeking
 13 2012-10-01 02:18:47 <jgarzik> amiller: if things are cached, it should be pretty fast
 14 2012-10-01 02:18:50 <jgarzik> amiller: but... do tell :)
 15 2012-10-01 02:18:54 <amiller> the trick is to do two passes
 16 2012-10-01 02:19:10 <amiller> where the first pass is used to create a large file with all the data in order
 17 2012-10-01 02:19:34 <amiller> this file will include the data for each transaction output twice, once when the block is created, and second when the transaction output is spent
 18 2012-10-01 02:20:22 <amiller> you will still need to store a UTXO set in memory, but it will not need any data, just keys
 19 2012-10-01 02:29:40 <jgarzik> amiller: flat block file + per-block undo log (for reorgs) seemed like it had promise
 20 2012-10-01 02:30:47 <amiller> hm, is the per-block undo log also a flat file that can be processed in order
 21 2012-10-01 02:32:13 <jgarzik> amiller: what is the purpose of gevent.sleep() at the top of got_message in node.py?
 22 2012-10-01 02:33:03 <jgarzik> c.f. my comment days ago, about models needing odd fixes in unexpected locations, because the model (simulated blocking, on top of non-blocking) emulated does not match the underlying OS syscall usage...
 23 2012-10-01 02:33:24 <amiller> right, i'll try to justify it here
 24 2012-10-01 02:33:57 <amiller> that's the gevent cooperative yield, by putting it at the top of each get message it allows 'messages' to be the granularity of execution
 25 2012-10-01 02:34:42 <jgarzik> amiller: so, necessary but unnatural ;p
 26 2012-10-01 02:34:49 <amiller> actually hm that probably isn't quite true
 27 2012-10-01 02:35:09 <amiller> let me push a concern on the conversation stack, which is that we need to look at what happens if two messages are processed interleaved, is there a race condition there
 28 2012-10-01 02:35:26 <amiller> but the only reason that sleep is needed is that the rpc call sometimes processses a sequence of messages at once
 29 2012-10-01 02:35:48 <amiller> and if there is no yield in between those messages then it will starve the other connections
 30 2012-10-01 02:39:22 <jgarzik> amiller: it is the nature of async single process networking that you service things one-at-a-time, ultimately
 31 2012-10-01 02:39:35 <jgarzik> amiller: no matter what illusions the model provides
 32 2012-10-01 02:40:03 <amiller> i should remove gevent's monkey.patch_all, that's an inappropriate hack here, so i've introduced a race condition that wasn't there in asyncore :p
 33 2012-10-01 02:40:36 <amiller> by patching all, i've allowed execution control to switch at any of the IO operations, including writing to the log file (but probably excluding leveldb)
 34 2012-10-01 02:40:53 <jgarzik> amiller: I liked the multi-process setup of:  1 network, 1 database, N workers.  Typically it is just network<->database, but network can offload difficult work like "handle new block message" to the worker processes
 35 2012-10-01 02:42:08 <jgarzik> amiller: (continuing review) shouldn't puttxidx call batch.Put() and not .db.Put()?
 36 2012-10-01 02:43:04 <jgarzik> amiller: i.e. we make many tx index updates when importing a block, and would want to gather all connect-block operations into a single large batch write, it would seem.
 37 2012-10-01 02:44:04 <amiller> ah yes it should, that's probably an important optimization
 38 2012-10-01 02:45:11 <jgarzik> amiller: optimization, yes, but I was thinking more about atomicity of connect-block operation
 39 2012-10-01 02:45:38 <jgarzik> amiller: die in the middle of the operation leaves you with a consistent database... but inconsistent data
 40 2012-10-01 02:47:01 <jgarzik> amiller: the raw block file needs a header, a la bitcoind
 41 2012-10-01 02:47:27 <jgarzik> amiller: a stream of CBlock's is perfectly fine... as long as our index remains 100% intact
 42 2012-10-01 02:47:52 <jgarzik> still, no worse off than with gdbm, admittedly
 43 2012-10-01 02:48:56 <amiller> it's true that a die in the middle of connect_block would result in an inconsistency
 44 2012-10-01 02:49:09 <amiller> there's a log message for that, "TxIndex failed" etc.
 45 2012-10-01 02:50:41 <amiller> there's no more validation to be done at that point, so only an exception  (as opposed to invalid network data) would cause it
 46 2012-10-01 02:51:18 <jgarzik> amiller: or disk error (out of space etc)
 47 2012-10-01 02:51:29 <jgarzik> guess that falls under exception
 48 2012-10-01 02:51:46 <amiller> is rolling that transaction back sufficient to solve the problem and leave you in a consistent state?
 49 2012-10-01 02:52:58 <jgarzik> amiller: if one part of connect-block operation fails, the entire operation fails, and should leave no trace in the database
 50 2012-10-01 02:53:02 <amiller> the only other state modification in that function is removing transactions from self.mempool, does that harm consistency?
 51 2012-10-01 02:53:18 <jgarzik> amiller: previous pynode was vulnerable to this as well, so it is not a merge-blocker
 52 2012-10-01 02:53:25 <jgarzik> amiller: gdbm is not transactional
 53 2012-10-01 02:53:58 <jgarzik> amiller: for the moment, no
 54 2012-10-01 02:54:09 <jgarzik> amiller: but if a wallet is attached, getting mempool right is much more important
 55 2012-10-01 02:58:46 <jgarzik> amiller: in any case, putting the entire connect-block in one big batch should make the import quite a bit faster
 56 2012-10-01 02:59:51 <amiller> jgarzik, i pushed a commit with two changes, one removes the race condition i introduced by over-geventing, the other is a writebatch for everything in connect block, simulating an IBD now
 57 2012-10-01 03:01:44 <amiller> i'm going to think about how we can unittest for concurrency issues
 58 2012-10-01 03:02:56 <jgarzik> amiller: pretty fast so far...  height zero to 162501 in 10 minutes
 59 2012-10-01 03:04:26 <jgarzik> amiller: any tests welcome
 60 2012-10-01 03:04:38 <amiller> okay so now i can answer your original question a little bit more reasonably
 61 2012-10-01 03:04:59 <amiller> the concurrency with gevent is modeled by having the tasks switch contexts only at special points
 62 2012-10-01 03:05:22 <amiller> these are the gevent.sleep() at the beginning of get_message, and in any of the calls to gevent.socket.Socket recv and send
 63 2012-10-01 03:09:34 <jgarzik> amiller: what is the leveldb default sync policy, I wonder?  We could drop .flush() for IBD, then re-enable for normal network
 64 2012-10-01 03:11:40 <amiller> i am using the default sync policy, which is not to sync
 65 2012-10-01 03:12:21 <amiller> so if the process is killed, some writes may not have been committed and the dat file may be inconsistent with the db
 66 2012-10-01 03:15:17 <amiller> it might not be that bad, since i flush the file before executing the transaction, so the worst case might be that there is some extra data in blocks.dat
 67 2012-10-01 03:16:17 <jgarzik> height 190001 after 22 minutes
 68 2012-10-01 03:19:27 <jgarzik> yep, just hit the "wall" at height 193000, where script verification kicks in
 69 2012-10-01 03:20:30 <amiller> jgarzik, it seems like to analyze concurrency we only need to focus on connect_block and disconnect_block, does that sound right to you?
 70 2012-10-01 03:20:50 <jgarzik> amiller: yes
 71 2012-10-01 03:21:37 <jgarzik> amiller: BTW, for post-IBD operation, we need a signature cache a la bitcoind
 72 2012-10-01 03:21:50 <jgarzik> amiller: as transactions trickle in, you verify their signatures and cache the result
 73 2012-10-01 03:22:00 <jgarzik> amiller: when a block arrives, the vast majority of transactions are already verified
 74 2012-10-01 03:26:31 <amiller> jgarzik, i hereby claim that pynode is safely concurrent, given the semantics of leveldb and file io
 75 2012-10-01 03:26:41 <amiller> disconnect_block and connect_block now use exactly one leveldb write
 76 2012-10-01 03:28:59 <amiller> blocks.dat is only written to and flushed in one place, which is prior to inserting the file position into the leveldb
 77 2012-10-01 03:29:33 <amiller> so even if the process is interrupted in between flushing the file and committing the new index information, the result would be redundant blocks in the file
 78 2012-10-01 03:30:41 <jgarzik> amiller: great!
 79 2012-10-01 03:30:53 <jgarzik> amiller: the next bottleneck is per-sig (or per-tx) concurrency
 80 2012-10-01 03:36:39 <jgarzik> amiller: another BTW: you will note that the entire IBD is an ugly hack.  part of that is the fault of the bitcoin protocol, with its special 'inv'-to-continue behavior (noted in node.py)
 81 2012-10-01 03:37:16 <jgarzik> amiller: but in particular, pynode requests the first 500 blocks... and then pauses until some message -- any message -- is received from the network, before downloading blocks 500-200000
 82 2012-10-01 03:37:33 <sipa> jgarzik: per-sig is very hard, per-txin is doable
 83 2012-10-01 03:37:55 <jgarzik> amiller: this send_getblocks logic is due to asyncore's shite, lack of a real timer/timeout facility
 84 2012-10-01 03:38:50 <jgarzik> sipa: per-txin probably the closest we can get to per-sig, agreed
 85 2012-10-01 03:38:58 <amiller> sipa, now that i've announced that i think pynode is concurrent, would you consider reviewing our leveldb/flatfile write patterns
 86 2012-10-01 03:39:50 <sipa> amiller: i haven't ever looked at pynode's code...
 87 2012-10-01 03:40:09 <jgarzik> amiller: heh, a bit premature still...
 88 2012-10-01 03:40:15 <sipa> also, i don't know python
 89 2012-10-01 03:40:30 <jgarzik> amiller: "pynode is concurrent" is a tough claim for a single-threaded process, too
 90 2012-10-01 03:40:49 <sipa> well, i did write some patches for poclbm
 91 2012-10-01 03:41:19 <jgarzik> amiller: just pulled your update, b1a1f3e
 92 2012-10-01 03:42:08 <amiller> sipa, hm, is there an easy way i could document for you just the sequence of leveldb and file interactions, as well as the task-switch points?
 93 2012-10-01 03:42:27 <amiller> i suppose the best answer is that i should model it in haskell if i were seriously concerned about getting it right
 94 2012-10-01 03:45:39 <jgarzik> height 160001 at 10 minutes
 95 2012-10-01 03:46:02 <jgarzik> a time shade slower than the last minute, which was pre-one-big-batch
 96 2012-10-01 03:46:07 <jgarzik> s/minute/time/
 97 2012-10-01 03:46:30 <jgarzik> not concerned -- atomicity is more important
 98 2012-10-01 03:46:59 <amiller> take my commit c1d6a20363
 99 2012-10-01 03:47:06 <amiller> i did the same thing for disconnect_block as i did for connect_block
100 2012-10-01 04:02:52 <knotwork> With deterministic addresses, it is possible to create a determinastic sequence of addresses for someone without knowing their private key?
101 2012-10-01 04:03:39 <sipa> knotwork: yes, search the forum for type-2 determinstic addresses, or look at BIP 32 which exploits them
102 2012-10-01 04:03:57 <knotwork> So for example you could compute different addresses for the same recipient which could be mapped to block numbers, such as if I mean block 240,001 I use your 240,001st address from the sequence?
103 2012-10-01 04:04:40 <knotwork> So to specify a future block against which I wish a specific deposit to apply I could know an address of yours that by a convention will mean I intend that block?
104 2012-10-01 04:05:04 <jgarzik> sipa: do you have code for the append-only wallet format anywhere public?
105 2012-10-01 04:05:19 <sipa> jgarzik: in my logdb branch, but it's not up to date
106 2012-10-01 04:05:41 <knotwork> so I could say please specify strike price as last digits after the decimal and amount wagered by the whole coins sent and the settlement block number by the address you send to?
107 2012-10-01 04:05:43 <sipa> knotwork: that's possible
108 2012-10-01 04:06:06 <jgarzik> tnx
109 2012-10-01 04:06:26 <sipa> 
ACTION -> first work day

110 2012-10-01 04:06:55 <jgarzik> sipa: does logdb keep the keys in RAM?
111 2012-10-01 04:07:00 <jgarzik> sipa: woo!  congrats :)
112 2012-10-01 04:07:30 <knotwork> is there yet any tool an end user could use that he can tell it an address and the how many'th address from that one in sequence he wants?
113 2012-10-01 04:08:03 <amiller> have fun sipa :o
114 2012-10-01 04:10:16 <jgarzik> real\t34m36.259s
115 2012-10-01 04:10:26 <jgarzik> amiller: full import, nosig=1
116 2012-10-01 04:10:28 <jgarzik> nice
117 2012-10-01 04:12:09 <jgarzik> amiller: pushed out
118 2012-10-01 04:12:16 <jgarzik> amiller: can you please rebase your last commit?
119 2012-10-01 04:12:34 <jgarzik> amiller: I had to fix all the broken whitespace
120 2012-10-01 04:17:46 <amiller> jgarzik, although you said you pulled my second-to-last update b1a1,  your latest merge (e689) already contains my latest commit c1d6
121 2012-10-01 04:17:50 <amiller> so we're currently in sync
122 2012-10-01 04:19:54 <jgarzik> amiller: so it does
123 2012-10-01 04:51:03 <jgarzik> amiller: updated pybond.git to match pynode's greenlet/rpc changes
124 2012-10-01 04:57:17 <amiller> jgarzik, you should also remove monkey.patch_all(), from line 12 on node.py
125 2012-10-01 05:04:52 <jgarzik> amiller: good catch
126 2012-10-01 05:51:05 <sipa> jgarzik: yes, it keeps everything in RAM
127 2012-10-01 05:51:35 <sipa> jgarzik: though you could just keep key->pos
128 2012-10-01 12:10:23 <isis1> Hey there, anyone on and can answer a quick question about the satoshi client sources?
129 2012-10-01 12:15:45 <isis1> I am extending the client by modifying the "Alert" system.  Basically I intend to (ab)use alerts to send messages between clients that are running my modified version of bitcoin.  So I don't pollute the network with a bunch of alerts that only my clients can understand I plan to relay exclusively between  my clients.  To do that I need to be able to identify them.  I'm looking at CNode:: strSubVer and was wondering if that corresponds to the
130 2012-10-01 12:17:58 <isis1> Maybe a better way to put the question would be to ask "From within main.cpp how can I tell what client a connected node is running, assuming the version & verack messages have already been exchanged?"
131 2012-10-01 12:22:18 <helo> some people are going persuade you to not do that here in a bit ;)
132 2012-10-01 12:22:34 <helo> well, attempt to
133 2012-10-01 12:23:57 <gavinandresen> no, that's a fine thing to do
134 2012-10-01 12:24:12 <isis1> Thanks Gavin
135 2012-10-01 12:24:14 <gavinandresen> CNode.strSubVer should tell you what client they're running
136 2012-10-01 12:24:26 <gavinandresen> I forget the exact format... I think there's a BIP...
137 2012-10-01 12:24:30 <gmaxwell> yea, sounds okay to me. (well, in practice there may be problems with whatever you're doing; but no reason for me to say 'no don't!')
138 2012-10-01 12:24:49 <epscy> some people don't like the alert system, since it implies centralization
139 2012-10-01 12:24:58 <isis1> Yeah considering I got the idea from you in the first place. ;)
140 2012-10-01 12:25:10 <gavinandresen> isis1: https://en.bitcoin.it/wiki/BIP_0014
141 2012-10-01 12:26:02 <ThomasV> gavinandresen: hi, what's up with bitcoin aliases? I saw that you posted something on the forum, do you have a specific idea?
142 2012-10-01 12:26:33 <gavinandresen> isis1: if you screw up and send too many alerts to reference implementation clients that don't understand them you'll get disconnected, by the way, so be sure to test thoroughly on testnet
143 2012-10-01 12:27:02 <isis1> Well alerts serve a dual purpose epscy.  It lets you know when something important is happening on the network, something that could cause disruption.  But it is also there for client software developers to notify of important topics relevant to their clients such as a critical patch or fix.
144 2012-10-01 12:28:12 <epscy> isis1: yes but who has the ability to send alerts?
145 2012-10-01 12:28:22 <epscy> can i send one now to everybody?
146 2012-10-01 12:28:49 <gavinandresen> ThomasV: Yes, I'm thinking of a combination of https://gist.github.com/2217885  with something like https://gist.github.com/1237788
147 2012-10-01 12:28:49 <isis1> In my case I'm going to abuse it a bit by modifying it to a "send me money" type of message.  Hence I plan to limit it to ONLY to clients identifying themselves as receptive to that type of alert.
148 2012-10-01 12:29:27 <gavinandresen> ThomasV: ... and doing an initial implementation that assume ssl for the identity system.
149 2012-10-01 12:29:44 <ThomasV> yes, ssl is fine for now
150 2012-10-01 12:29:47 <isis1> You can epscy, but there is a hardcoded key right now that means the client will ignore the message if it isn't signed with that key.
151 2012-10-01 12:30:16 <isis1> So if you do send a bunch of alerts you're going to end up being banned by the software.
152 2012-10-01 12:31:06 <gavinandresen> epscy: you are perfectly free to create your own client with its own alert key and convince a bunch of people to use your client.
153 2012-10-01 12:31:25 <isis1> That's why I'm customizing my fork to accept & send alerts of this type ONLY to each other.
154 2012-10-01 12:32:06 <epscy> i am, but the point is, because of inertia you have influence over the network that ordinary bitcoin users do not
155 2012-10-01 12:32:36 <epscy> i am not making a big deal of it, just that some people don't like that aspect of bitcoin
156 2012-10-01 12:32:36 <ThomasV> gavinandresen: it would be great to have an initial spec soon. it should not be complicated
157 2012-10-01 12:32:51 <ThomasV> and we really need to make it happen
158 2012-10-01 12:33:45 <gavinandresen> ThomasV: agreed. Want to head up creating a spec?  I think a small group (me, you, etotheipi, sipa, TD) could put together a really solid spec pretty quickly
159 2012-10-01 12:33:59 <epscy> gavinandresen: i realise it does serve a purpose and if alerts were abused they would quickly lose influence
160 2012-10-01 12:34:25 <epscy> which to me kinda begs the question, why have a messaging system built into the client at all
161 2012-10-01 12:34:29 <gavinandresen> epscy isis1 : denial-of-service attacks using the alert system is something you have to be very careful of if you let anybody create alerts
162 2012-10-01 12:35:13 <epscy> why not just have an rss feed on bitcoin.org and publically state all urgent issues will be posted to it
163 2012-10-01 12:35:16 <gavinandresen> "Oh, I can send one message and have every node in the network relay it for me?....."
164 2012-10-01 12:35:19 <gmaxwell> epscy: I'm struggling to figure out how your comments have _any_ relationship to the discussion that started them; am I missing it? or do you just have a nevervous tick triggered by the word 'alert'
165 2012-10-01 12:35:28 <gmaxwell> ? :P
166 2012-10-01 12:35:28 <isis1> In my case I'm using a portable key that can be input somewhere else such as a store.  This causes a client at the store to generate an alert and send it across to your home(or phone) client.  Since your home client is setup to recognize that key as having come from you it will then take whatever steps to process a transaction to the merchant.  There's a lot more involved than just that, but that is the jist of it.
167 2012-10-01 12:35:29 <gavinandresen> epscy: I thought you didn't like centralization
168 2012-10-01 12:36:14 <isis1> I think epscy might be recoiling because it used to be that an Alert would shut the client down.
169 2012-10-01 12:36:30 <epscy> gmaxwell: well it's relevant because isis1 suggested he wants to "abuse" the alerts system
170 2012-10-01 12:36:36 <gavinandresen> epscy: ... and an RSS feed on bitcoin.org is certainly more centralized and easier to take down than an alert key shared by multiple trusted people...
171 2012-10-01 12:36:45 <isis1> Abuse is probably the wrong word.
172 2012-10-01 12:36:53 <gmaxwell> epscy: to do something apparently unrelated to alerts.
173 2012-10-01 12:36:54 <isis1> Leverage, repurpose etc.
174 2012-10-01 12:37:24 <epscy> gavinandresen: ok fair enough, i remember people disliking the alert system way back, did the devs ever look at alternatives?
175 2012-10-01 12:37:33 <isis1> Just easier than creating a custom message type and trying to get support into the various libs I'm going to have to deal with.
176 2012-10-01 12:37:48 <ThomasV> gavinandresen: do you think that getting me involved would accelerate things? very often, involving less people means a quicker decision process, so I will be happy to follow whatever is proposed if that can make it happen faster :)
177 2012-10-01 12:37:57 <gmaxwell> epscy: In any case, feel free to disable it in your own nodes??? but it serves a valuable purpose: to be able to send a notice to all users of the software like "your software is insecure, and you need to do someting about it".
178 2012-10-01 12:38:10 <epscy> gmaxwell: yes, i am going off on a tangent and asking if/why the alert system needs to exist
179 2012-10-01 12:38:21 <gavinandresen> ThomasV: dunno, you good at writing specs?
180 2012-10-01 12:38:28 <ThomasV> probably not
181 2012-10-01 12:38:43 <ThomasV> I'm good at whining
182 2012-10-01 12:38:46 <isis1> No joke, for instance the default version of bitcoind on Ubuntu is like 3.x something.  The alert system kept me from losing a wallet.
183 2012-10-01 12:39:24 <epscy> gmaxwell: and it is the best system in your opinion for disseminating that information?
184 2012-10-01 12:39:34 <gavinandresen> ThomasV: my TODO list is:   finish up some work I'm doing to fix the DB_RUNRECOVERY problem lots of people are having, and (hopefully) get that into a 0.7.1 release.  Do some technical work for the Foundation. And then tackle payment protocol stuff.
185 2012-10-01 12:40:14 <ThomasV> I see. so that's pretty far fetched :)
186 2012-10-01 12:40:26 <isis1> epscy, it's an in-band signaling system that requires signing by the folks who WROTE the software.  If they figure something is wrong I can pretty much guarantee that it's time to get out of the pool.
187 2012-10-01 12:40:31 <gmaxwell> epscy: It, by definition, reaches all the systems running the software, it's targeted.  It doesn't disclose that users are running bitcoin or reveal any personal information about them.  "Best" ? I have no freeking idea. But it achieves its purposes.
188 2012-10-01 12:41:12 <gmaxwell> The 'obvious' things people do instead like polling update servers are absolutely horrible by comparison.
189 2012-10-01 12:41:14 <isis1> It alerts, it does not control (anymore), just an FYI epscy.
190 2012-10-01 12:41:35 <gmaxwell> isis1: I don't think epscy was ever exposed to the original behavior.
191 2012-10-01 12:41:45 <kjj_> hilariously, running a CA for managing alert keys would be a good job for The Foundation
192 2012-10-01 12:41:56 <gmaxwell> About the worst I can say about it is that it doesn't scale well??? e.g. in a network with many client types its not as useful.
193 2012-10-01 12:42:18 <isis1> Not so sure about that gmax
194 2012-10-01 12:42:27 <isis1> Why do you say it doesn't scale well?
195 2012-10-01 12:42:29 <gmaxwell> I'm pretty sure about that.
196 2012-10-01 12:42:35 <gmaxwell> Because there is one key to rule them all.
197 2012-10-01 12:42:38 <epscy> hmmm, ok fair enough
198 2012-10-01 12:43:18 <isis1> Yes but that key is in the hands of the folks developing the reference implementation and the whole alert system amounts to not much more than a stickynote on your screen or in your logs.
199 2012-10-01 12:43:57 <gmaxwell> So for example, if FooClient became popular, its right and proper that the maintaince team for FooClient could control its alerts. But the FooClient subgraph may not itself be connected; so even if they had their own alert keys it wouldn't reliably propagate unless they had their own p2p network; and a seperate topology is bad for network stability and for user privacy.
200 2012-10-01 12:44:01 <kjj_> ooh.  just figured out how to do it without a central CA
201 2012-10-01 12:44:15 <gmaxwell> kjj_: sure, subscriptions.
202 2012-10-01 12:44:29 <isis1> If they have their own client they should modify the client constant.
203 2012-10-01 12:44:38 <isis1> Then change the pubkey in the client.
204 2012-10-01 12:44:39 <gmaxwell> isis1: No, that doesn't work.
205 2012-10-01 12:44:55 <gmaxwell> isis1: if that happens and such a client is moderately popular alerts stop being reliable.
206 2012-10-01 12:45:13 <kjj_> gmaxwell: if you want it in-band, you have to allow something to pass from node to node, even with sub/pub
207 2012-10-01 12:45:36 <t7> if i know the first bit of plaintext, i still have to check n^(security - 1)  to find a collision in sha256, right?
208 2012-10-01 12:45:39 <kjj_> and if the client isn't moderately popular, the alerts don't get to them
209 2012-10-01 12:46:58 <t7> where security is 256 i guess :)
210 2012-10-01 12:47:27 <kjj_> t7: there is no promise that 2^256 attempts will collide with a specific key
211 2012-10-01 12:47:32 <gmaxwell> t7: on average. Unless the space of your preimage becomes less than that.
212 2012-10-01 12:47:33 <kjj_> er, specific hash
213 2012-10-01 12:47:42 <isis1> As long as the client is maintaining a list of nodes it's seen with a client ver = to whatever client they are, then the problem is reduced to one of filtration.
214 2012-10-01 12:47:53 <gmaxwell> isis1: no, it really isn't.
215 2012-10-01 12:48:12 <isis1> Elaborate please
216 2012-10-01 12:48:13 <gmaxwell> isis1: there is no guarentee that the subgraph of nodes of a particlar type will be fully connected.
217 2012-10-01 12:48:58 <isis1> Yes, but the message should continue to float around until it expires out.  Eventually it will connect or die.
218 2012-10-01 12:49:08 <gmaxwell> if you have [type A] - [type B] - [type A] <- [announce]  the left most type a won't get the alert.
219 2012-10-01 12:49:48 <kjj_> t7: as in, once you make (2^256)+1 hashes, you have a guarantee of getting at least one collision, but you don't a guarantee of getting a *specific* collision
220 2012-10-01 12:49:59 <sipa> gavinandresen: remind me to talk to you about payment protocols; i had a discussion with justmoon and michael gronager (the libcoin guy) at the conference
221 2012-10-01 12:50:35 <gavinandresen> sipa: great
222 2012-10-01 12:50:59 <gmaxwell> isis1: and if it takes weeks to manage to connect to span the partition then the alert isn't timely and can't serve its purpose.  And if you have many client types, then weeks may not even be realistic.
223 2012-10-01 12:51:06 <gavinandresen> sipa:  as I said, I think we should get together a small group of interested people to put together an initial proposal
224 2012-10-01 12:51:23 <kjj_> ok, so if alert keys for clients were signed by the keyholders of other clients, and clients would propogate messages bearing certificates signed by their own keys...
225 2012-10-01 12:51:43 <isis1> That's assuming a and b only connect to one another though.  If you place a preference for connections during discovery, to clients using your version then you span it pretty quickly.
226 2012-10-01 12:52:04 <gmaxwell> isis1: "a seperate topology is bad for network stability and for user privacy"
227 2012-10-01 12:52:43 <gmaxwell> and thats assuming you ever even meet one of your kind. Which isn't likely if there are many client kinds.
228 2012-10-01 12:53:27 <gmaxwell> And again??? for the purpose of alerts it's important that they be both timely and reliable; and while they do have value, making the network less private and more partitioning prone is not really acceptable to achieve that end.
229 2012-10-01 12:54:37 <isis1> That's nice but the network already has separate topologies.  We aren't talking general use here, we are talking a seperate signaling system that's trying not to pollute the network.  For general (bitcoiny) things the mark, filter & forward doesn't apply.
230 2012-10-01 12:56:31 <gmaxwell> isis1: I regret that you're not listening to me, but I really don't have time to debate this with you. If you go down the route of creating software that preferentally connects to its kind you'll be creating something which is insecure and I'll be forced to recommend to people that they not use it.
231 2012-10-01 12:57:24 <isis1> Tx and all other messages follow the normal path.  All I'm changing is the profile of the Alert relay system, so alerts created for my client only reach my client.
232 2012-10-01 12:58:06 <gmaxwell> Thats fine and great and all. But you can't count on that to actually work??? because the network of your nodes will almost certantly not be fully connected.
233 2012-10-01 12:58:13 <Eliel> isis1: I think if you keep separate pools for main bitcoin-network connections and the samekind connections, I think it's workable.
234 2012-10-01 12:58:50 <Eliel> it'll increase the number of total connections though but shouldn't cause any lack of connectivity compared to now.
235 2012-10-01 12:59:01 <kjj_> gmaxwell: I think he is talking about a client running two totally different p2p meshes.  One is the bitcoin mesh, the other is the alt_client mesh, just used to pass alerts.
236 2012-10-01 12:59:08 <gmaxwell> Eliel: I would still discourage that sort of thing. The partitioning risk is subtle and I wouldn't expect anyone (myself included) to get it right without doing simulations.
237 2012-10-01 13:00:01 <gmaxwell> kjj_: I refer back to my comment that spawned this subthread: Alerts don't scale.
238 2012-10-01 13:00:11 <Eliel> gmaxwell: even if the bitcoin-pool runs identical code to what bitcoin-client uses now?
239 2012-10-01 13:00:13 <kjj_> agreed
240 2012-10-01 13:00:19 <isis1> Look at main.cpp when you have a moment.  There is a block of code starting with,   else if (strCommand == "alert"), go a little further down and you will see that it relays the alert to EVERYONE it knows about.  I'm modifying it to relay a custom alert only to custom clients.  It doesn't even effect the normal alert system.
241 2012-10-01 13:00:40 <gmaxwell> isis1: Yes, I know how it works.
242 2012-10-01 13:00:52 <gmaxwell> And as I said, I regret that you're not listening to me.
243 2012-10-01 13:00:55 <isis1> Sorry gmax that was for Eliel
244 2012-10-01 13:01:00 <gmaxwell> TTYL
245 2012-10-01 13:01:45 <isis1> It's not that I'm not listening, I understand your concern but it's broader than the specific problem domain.
246 2012-10-01 13:03:17 <Eliel> isis1: you could also consider building an entirely separate daemon process for this. One that interacts with bitcoind through the RPC interface.
247 2012-10-01 13:03:31 <gmaxwell> isis1: Then why did you begin arguing with me when I commented on the domain of multiple clients and the purpose of alerts?
248 2012-10-01 13:04:07 <isis1> Not arguing, just trying to make sure I understand your point.  Your feedback has been invaluable thus far.
249 2012-10-01 13:04:43 <gmaxwell> I don't know what you're doing with alerts specifically, and for all I know it's harmless at worst. (well, it may stop being fine if you also change peer selection; but you say you're not doing that; great)
250 2012-10-01 13:05:34 <gmaxwell> I was only pointing out that alerts??? for their real purpose and current implementation??? don't scale to achieve that purpose in a bitcoin network with many client authors. Thats all.
251 2012-10-01 13:06:13 <isis1> True and there a probably a lot of clients that don't implement alerts at all.
252 2012-10-01 13:07:29 <epscy> it possibly doesn't make sense for them to
253 2012-10-01 13:07:29 <gmaxwell> Currently? no. Which is why they still work.  But I think this is mostly self solving. As alerts lose their usefulness the need for them is also decreasing.
254 2012-10-01 13:07:47 <epscy> don't mtgox and some pool ops run custom clients?
255 2012-10-01 13:07:49 <gmaxwell> If there are many client types then just one being exploitable is not so bad.
256 2012-10-01 13:08:52 <gmaxwell> epscy: facing the network? I don't believe so. But even still, you're talking about a couple nodes.  There need to be at least 8 listeners that don't forward alerts before someone has any chance of having all no-alert peers.
257 2012-10-01 13:15:32 <helo> so if alternative clients become popular enough, satoshi client alerts may not reach all nodes?
258 2012-10-01 13:16:09 <helo> oh, missed the discussion... nm :)
259 2012-10-01 13:26:02 <isis1> Hey I see a lot of things that Bitcoin no longer uses for client discovery.  What does it use now days?
260 2012-10-01 13:26:31 <gmaxwell> Hm. The only thing we don't use by default anymore is irc.
261 2012-10-01 13:26:48 <gmaxwell> The primary mechnism is hearing nodes from other nodes.
262 2012-10-01 13:27:09 <gmaxwell> Are you asking about discovery or bootstrapping? They're highly related but different problems.
263 2012-10-01 13:27:30 <isis1> Sorry bootstrapping
264 2012-10-01 13:27:53 <gmaxwell> dnsseed and the hardcoded seeds like (or manual configuration via addr.txt or addnode/connect)
265 2012-10-01 13:28:00 <gmaxwell> s/like/list/
266 2012-10-01 13:28:59 <isis1> Interesting.  Why did we stop IRC discovery?
267 2012-10-01 13:29:10 <kinlo> it doesn't scale
268 2012-10-01 13:29:23 <gmaxwell> It also hardly worked.
269 2012-10-01 13:29:28 <kinlo> and it's a lot of overhead, dns is much easyer
270 2012-10-01 13:30:02 <kjj_> also, some ISPs/datacenters hate it
271 2012-10-01 13:30:18 <gmaxwell> And also had all sorts of security weirdness. (singally controlled IRC network, who's operators??? with good intentions??? were already filtering the results given to clients)
272 2012-10-01 13:30:38 <gmaxwell> Yea, it was blocked world wide on many major networks several times too.
273 2012-10-01 13:31:09 <isis1> Dam
274 2012-10-01 13:31:28 <isis1> Ok final question and I'll quit asking for awhile.
275 2012-10-01 13:32:16 <gmaxwell> Also bad for user privacy; since even if you didn't listen you ended up making your IP public as a bitcoin user to anyone who cared to monitor it... but mostly because it didn't work well.
276 2012-10-01 13:32:44 <isis1> Assuming I have the publickey bytes is there a ready made function somewhere to validate that the key bytes make a key?
277 2012-10-01 13:33:03 <kjj_> hmm.  too bad TOR hidden services can't do anycast
278 2012-10-01 13:33:19 <isis1> Something along the lines of isThisStringAKey(stringtocheck)
279 2012-10-01 13:33:35 <kinlo> you can convert a private key to the matching public key if that's your question
280 2012-10-01 13:33:47 <isis1> No but it is close.
281 2012-10-01 13:33:53 <kinlo> also, converting a public key to a bitcoin address is also a one way function
282 2012-10-01 13:34:10 <kjj_> isis1: not really.  just about any string of bits can be a public key.
283 2012-10-01 13:34:27 <isis1> Assume I have a bitcoin address of 1QZxyzpdq...
284 2012-10-01 13:34:30 <kinlo> afaik only a bitcoin key can be verified
285 2012-10-01 13:34:36 <kinlo> there is a checksum inside the key
286 2012-10-01 13:34:46 <Luke-Jr> isis1: addresses aren't keys
287 2012-10-01 13:34:49 <kinlo> but I don't think you can validate the public key
288 2012-10-01 13:34:57 <kinlo> euh
289 2012-10-01 13:35:02 <kinlo> a bitcoin address can be verfied
290 2012-10-01 13:35:09 <isis1> I just want to validate that the string is a valid bitcoin address.  Sorry got publickey and address mixed up there.
291 2012-10-01 13:35:23 <isis1> Yes ok, how to validate a bitcoin address is the question I'm asking.
292 2012-10-01 13:35:23 <kjj_> valid address, yes.
293 2012-10-01 13:35:32 <kinlo> isis1: the best way to do it - like I do it - call the validate function on your bitcoind
294 2012-10-01 13:35:49 <kinlo> the day newer address types are created, your code will continue to work
295 2012-10-01 13:36:12 <isis1> Right, but my code is inside bitcoind, rpc is probably not the answer.
296 2012-10-01 13:36:15 <kinlo> there is validateaddress <bitcoinaddress> on the rpc
297 2012-10-01 13:36:22 <kinlo> I do it with the rpc
298 2012-10-01 13:36:40 <kinlo> if you want to re-write that code, that's possible
299 2012-10-01 13:36:44 <isis1> Guess I could use that to find my entrance point those since that's looking at a potentially arbitrary string.
300 2012-10-01 13:36:46 <kinlo> there are plenty of samples on the internet
301 2012-10-01 13:37:01 <isis1> @Kinlo I just want to leverage the existing functionality.
302 2012-10-01 13:37:11 <kinlo> I just do a regular expression, checking it's all numbers and letters, and then use bitcoind's verify
303 2012-10-01 13:37:15 <isis1> In otherwords what is that rpc call actually calling.
304 2012-10-01 13:37:26 <kjj_> isis1: look in rpcwallet.cpp, function validateaddress()
305 2012-10-01 13:37:29 <kinlo> isis1: it just checks the validity
306 2012-10-01 13:37:36 <kinlo> isis1: it verifies all the fields.
307 2012-10-01 13:37:52 <kinlo> isis1: the last few characters are actually a sha256 of the previous chars
308 2012-10-01 13:38:00 <kinlo> and some other checks, like network version number and so on
309 2012-10-01 13:38:09 <kinlo> but note that almost all sites got it wrong
310 2012-10-01 13:38:11 <isis1> Thanks
311 2012-10-01 13:38:12 <isis1> p, li { white-space: pre-wrap; }  CBitcoinAddress address(params[0].get_str());     bool isValid = address.IsValid();
312 2012-10-01 13:38:20 <isis1> grr stupid copy paste/
313 2012-10-01 13:38:26 <kinlo> with 0.6.x there is a new bitcoin address
314 2012-10-01 13:38:41 <kinlo> and you can't use the new type on most sites coz they all did not use the rpc
315 2012-10-01 13:38:47 <kinlo> and they all re-invented the weel
316 2012-10-01 13:39:32 <kinlo> new bitcoin address type is what I mean, not just a new address :p
317 2012-10-01 13:40:10 <arij> how do i start bitcoiind?
318 2012-10-01 13:40:16 <arij> bitcoind -daemon ....
319 2012-10-01 13:40:28 <isis1> Right the code I'm using now just instantiates a new bitcoin address given the (potentially) arbitrary and then returns address.isValid();
320 2012-10-01 13:40:51 <kinlo> ?
321 2012-10-01 13:40:55 <isis1> Thanks for the tip about RPCWallet, I'm going to be bookmarking that file.
322 2012-10-01 14:19:37 <isis1> In the context of the CWallet class when it refers to addressbook, is that addresses we have sent money to, or is it address that correspond to keys in our wallet?
323 2012-10-01 14:19:58 <isis1> I just want to quickly look to see if an address is in a given wallet.
324 2012-10-01 14:20:53 <sipa> the addressbook just gives names to addresses
325 2012-10-01 14:20:58 <sipa> they may or may not be your own
326 2012-10-01 14:23:15 <isis1> Dang.  Is there a way to say "Does this address belong to us?"
327 2012-10-01 14:24:18 <kjj_> CWallet::IsMine() in wallet.cpp
328 2012-10-01 14:25:03 <edcba> is there a way to know if client is mining ?
329 2012-10-01 14:25:42 <kjj_> like from the command line?
330 2012-10-01 14:26:54 <BlueMatt> TD: I decided against removing length caching entirely - its too big a rebase for me to tackle right now, so I just fixed up some of the issues with the length caching that I found, this look a bit better?
331 2012-10-01 14:26:55 <BlueMatt> https://code.google.com/r/bluemattme-bitcoinj/source/detail?r=c082d809d6bc975d3bd5c5b98eb04b1aeda626a8&name=newscripts
332 2012-10-01 14:34:27 <edcba_> luissuarez: it's not a channel for btc trading
333 2012-10-01 14:34:33 <edcba_> stop pv spamming
334 2012-10-01 14:44:56 <isis1> @kjj_ didn't see that one for some reason.
335 2012-10-01 14:46:32 <isis1> Actually just looked, that one only tells us if a tx is mine.  I've got a bitcoin address and I want to see if it's one of mine or not.
336 2012-10-01 14:53:54 <gavinandresen> isis1: wallet is derived from keystore, and there is a CKeyStore::HaveKey() method
337 2012-10-01 14:57:13 <isis1> So I've got an arbitrary string I've converted into a CAddress object (to validate it actually is an address).  pwalletMain->HaveKey(addr); is going to let me know that I have that address?
338 2012-10-01 14:58:41 <gavinandresen> addr.GetKeyId() I think
339 2012-10-01 14:58:41 <isis1> Well  pwalletMain->HaveKey(addr.GetKeyID());  anyways
340 2012-10-01 14:59:05 <isis1> Cool that saves me a lot of looping.
341 2012-10-01 14:59:17 <isis1> Thanks Gavin
342 2012-10-01 14:59:27 <gavinandresen> If it is a pay-to-script-hash address then the right call is ->HaveCScript()
343 2012-10-01 14:59:58 <isis1> No this is a bit different.
344 2012-10-01 15:00:29 <gavinandresen> ok, carry on then.
345 2012-10-01 15:00:30 <isis1> Remember I'm repurposing the alerts to create a method for requesting bitcoins.
346 2012-10-01 15:00:49 <isis1> I'm using the comment field to store a bitcoin address.
347 2012-10-01 15:01:00 <gavinandresen> oh, that's probably the wrong way to do it.
348 2012-10-01 15:01:15 <isis1> If that address is one of mine when I recieve it then we know to display it to the user.
349 2012-10-01 15:01:22 <luissuarez> anyone buying at 12usd pm me
350 2012-10-01 15:01:47 <isis1> Ok gavin, I'm all ears.
351 2012-10-01 15:01:57 <gavinandresen> bitcoin addresses are really a GUI thing... if you're creating  a payment protocol it should be "Please pay to this CScript"
352 2012-10-01 15:02:16 <isis1> Yes and that will be in the message body
353 2012-10-01 15:02:43 <gavinandresen> I see, you're using bitcoin addresses as identifiers?  hmmm.....
354 2012-10-01 15:02:43 <isis1> This is using the bitcoin address a bit like a phone number.
355 2012-10-01 15:02:52 <gavinandresen> that doesn't feel right, either.
356 2012-10-01 15:02:52 <isis1> Yes
357 2012-10-01 15:03:17 <isis1> I know, but the alternative was to try and implement a new message type.
358 2012-10-01 15:03:29 <isis1> Could just as easily use a publickey I guess.
359 2012-10-01 15:03:54 <isis1> Here let me start at the beginning so you have a feeling for how this would work.
360 2012-10-01 15:04:51 <isis1> I would enroll a secret that lets me identify myself to my bitcoin client.  This secret could be anything but for our purposes let's say it's a payment card of some type....
361 2012-10-01 15:05:34 <isis1> Once I'm enrolled, that secret is converted to a private/public keypair and stored in my client (I'm using the wallet for convience but it could be anywhere).
362 2012-10-01 15:05:47 <TD> gavinandresen: actually, it should be more than that
363 2012-10-01 15:05:53 <TD> gavinandresen: it should be "please pay to this list of scripts"
364 2012-10-01 15:06:17 <gavinandresen> TD: ... where list of scripts is (script,amount) ?
365 2012-10-01 15:06:18 <luissuarez> ANYONE WONNA BUY BTC AT 12USD VIA PP PM ME
366 2012-10-01 15:06:18 <TD> in future for privacy most single payments will probably end up as set of independent transactions to a set of independent addresess, divided up such that it makes blockchain analysis hard
367 2012-10-01 15:06:22 <TD> yeah sorry
368 2012-10-01 15:06:25 <TD> "pay to this list of outputs
369 2012-10-01 15:06:38 <jgarzik> a new bitcoin client appears...
370 2012-10-01 15:06:41 <jgarzik> http://ufasoft.com/files/ufasoft_coin-0.33.tar.xz
371 2012-10-01 15:06:51 <TD> ufasoft coin was around for a while, iirc, but it's proprietary?
372 2012-10-01 15:06:53 <TD> or it was
373 2012-10-01 15:07:28 <isis1> Now I go to a merchant.  I hand over my secret (payment card) to the merchants POS gateway.  The gateway generates an alert, and I know the alert is intended for my client because it uses the bitcoin address generated from the secret, in it's comment field.
374 2012-10-01 15:07:55 <isis1> After I have the alert, then I post it to a new screen on the client and allow the user to approve or decline the request.
375 2012-10-01 15:08:38 <jgarzik> TD: that's the ufasoft-coin source code
376 2012-10-01 15:08:43 <TD> ah ok
377 2012-10-01 15:08:59 <isis1> If the user approves then a new tx is created as per whatever the requesting merchant asked for.
378 2012-10-01 15:09:13 <TD> jgarzik: xz?
379 2012-10-01 15:09:16 <TD> what is xz?
380 2012-10-01 15:09:29 <jgarzik> TD: the "new gzip"
381 2012-10-01 15:09:34 <jgarzik> TD: lzma, standardized
382 2012-10-01 15:09:38 <TD> ah
383 2012-10-01 15:09:49 <TD> well, crap. i love LZMA but i suspect my tar doesn't know how to uncompress it
384 2012-10-01 15:09:59 <jgarzik> TD: Fedora and other distros are defaulting to xz compression in rpms.  kernel.org is using .xz, etc.
385 2012-10-01 15:10:02 <TD> lzmadec ufasoft_coin-0.33.tar.xz
386 2012-10-01 15:10:07 <TD> 
ACTION sighs

387 2012-10-01 15:10:10 <jgarzik> TD: "J" argument to tar
388 2012-10-01 15:10:23 <jgarzik> tar xvfJ $FILE
389 2012-10-01 15:10:27 <Eliel> isis1: what's the benefit of this system over just remote controlling the node at home directly from your mobile device?
390 2012-10-01 15:10:27 <TD> maybe if i upgrade macos it'll learn how to deal with these :)
391 2012-10-01 15:10:30 <TD> or i can do it on my server
392 2012-10-01 15:11:26 <gavinandresen> isis1: uhh... too busy right now to figure out if your payment protocol is secure.  But "generates a bitcoin address from the secret" seems like the wrong thing to do, I think you want to broadcast a signature not an address.
393 2012-10-01 15:12:09 <TD> wow
394 2012-10-01 15:12:10 <isis1> @Gavin, we still have a signature, just haven't discussed it because it's in the alert body and not the alert comment.
395 2012-10-01 15:12:15 <TD> seems like ufasoft coin is a pretty huge project
396 2012-10-01 15:12:35 <isis1> ufasoft is a good wallet, it's multicurrency though.
397 2012-10-01 15:12:39 <gavinandresen> isis1: and I also think you'll probably save yourself time "doing it right" with a new message type rather than using alert comments....
398 2012-10-01 15:12:39 <Luke-Jr> Ufasoft made a client?
399 2012-10-01 15:12:44 <TD> it's a full node?
400 2012-10-01 15:13:06 <isis1> ufasoft will slow your computer down dramatically though.
401 2012-10-01 15:13:23 <TD> this isn't the miner
402 2012-10-01 15:13:52 <TD> seems like some of the code was copy/pasted from satoshis
403 2012-10-01 15:13:54 <isis1> @gavin, in the long run you're probably right.  However I wasn't sure of the entrance point for a new message type and Alert has all the fields I require.
404 2012-10-01 15:13:58 <TD> yikes.
405 2012-10-01 15:14:06 <TD> i hope people don't start mining on this ....
406 2012-10-01 15:14:37 <Eliel> isis1: could you please explain what benefits the system you're planning provides over what we have now?
407 2012-10-01 15:14:38 <TD> isis1: i'd suggest studying the code more then. it's not that complicated - just check out PushMessage and the main loop in main.cpp (search for "alert" if you want to find how alert messages are processed
408 2012-10-01 15:14:47 <isis1> Since I'm only passing these particular type of alerts between clients identifying themselves as OpenPay enabled, I think it will be alright.
409 2012-10-01 15:15:30 <isis1> I know how alert messages are processed,I'm in the section of code you're talking about right now.
410 2012-10-01 15:16:11 <L8> does any one have some pdf that I can learn from zero about how bitcoin works?
411 2012-10-01 15:16:36 <helo> L8: [PDF]
412 2012-10-01 15:16:37 <helo> bitcoin.org/bitcoin.pdf
413 2012-10-01 15:16:37 <isis1> @Eliel, its using a paradigm that would be more comfortable for end users and merchants.  When I'm done there will be a home version, plus an android wallet version, both will be capable of doing it this way.
414 2012-10-01 15:16:45 <helo> oops, sorry for the sloppy paste
415 2012-10-01 15:16:57 <L8> thanks :)
416 2012-10-01 15:17:00 <jgarzik> gah, PM spam starting again
417 2012-10-01 15:17:06 <jgarzik> what is the IRC magic to block it?
418 2012-10-01 15:17:11 <jgarzik> /mode +R something something?
419 2012-10-01 15:17:12 <isis1> I use /ignore
420 2012-10-01 15:17:27 <helo> maybe /umode +R
421 2012-10-01 15:17:28 <jgarzik> isis1: doesn't work if they keep switching hosts, which they do
422 2012-10-01 15:17:46 <Eliel> isis1: you want to mimic the user interface of paying with a credit card?
423 2012-10-01 15:17:53 <isis1> True, well at least he's not selling viagra
424 2012-10-01 15:18:04 <isis1> @Eliel, yes
425 2012-10-01 15:19:17 <isis1> Software capable of doing it is one piece of the puzzle.  There are some other steps involved as well.  But eventually my goal is to create a payment card network using bitcoins for the funds transfer component.
426 2012-10-01 15:19:33 <gavinandresen> isis1: So how are merchants and users identified?
427 2012-10-01 15:19:37 <Eliel> isis1: doing it this way sounds overcomplicated to me.
428 2012-10-01 15:20:53 <isis1> Merchant is running a bitcoind with a custom RPC command to generate the payment request with information gathered from their CC gateway software.
429 2012-10-01 15:21:23 <gavinandresen> isis1: right, but my question is "If I get a payment request, how do I know it is from Merchant X and not man-in-the-middle-Y ?"
430 2012-10-01 15:21:25 <Eliel> isis1: why use bitcoin network at all for this? why not just have the merchant system connect directly with HTTP or such?
431 2012-10-01 15:21:55 <isis1> I'll explain in a minute Eliel, let me finish with Gavin first...
432 2012-10-01 15:22:22 <isis1> @Gavin, the request itself is signed.
433 2012-10-01 15:23:03 <gavinandresen> isis1: ok, so how are merchants identified?  Certificate authority built into your client or something?
434 2012-10-01 15:23:33 <isis1> That's a possibility in the future but not relevant to how I'm doing it at this time...
435 2012-10-01 15:23:56 <isis1> A signature can only be generated with the private key right?
436 2012-10-01 15:24:07 <isis1> Well a valid signature anyways.
437 2012-10-01 15:24:42 <gavinandresen> what private key?  is there one master private key that all the merchants get and use to sign payment requests?
438 2012-10-01 15:24:59 <Eliel> you show your own private key at the shop that you have configured as acceptable? and the shop uses that to make the signature?
439 2012-10-01 15:25:07 <isis1> Yep!
440 2012-10-01 15:25:13 <isis1> Thanks for saving me some typing.
441 2012-10-01 15:25:19 <gavinandresen> oh. What stops the shop from stealing that private key?
442 2012-10-01 15:25:29 <Eliel> (I got tired of waiting you say that :P)
443 2012-10-01 15:25:34 <isis1> Nothing, which is why it's revokable
444 2012-10-01 15:26:01 <isis1> Also it's not automatic.  The request comes through but you still have to click "approve"
445 2012-10-01 15:26:10 <runeks> I'm trying to create a private key in base58 format. I have successfully encoded the private key itself as base58, but the checksum bytes are wrong. aren't the checksum bytes simply SHA256(SHA256(0x80+<32_byte_address>))?
446 2012-10-01 15:26:17 <L8> if I forgot my passpharse
447 2012-10-01 15:26:22 <L8> and I have nothing in my wallet
448 2012-10-01 15:26:26 <L8> can I get a new user?
449 2012-10-01 15:26:58 <Eliel> runeks: that "address" word gives me a feeling you're doing something unnecessary there.
450 2012-10-01 15:27:33 <Eliel> runeks: please describe in more detail what this "32_byte_address" means.
451 2012-10-01 15:27:39 <runeks> oh. i mean 32_byte_key
452 2012-10-01 15:28:32 <runeks> the 32 byte key must be right, because the first part of the private key corresponds to what brainwallet.org says it should be. so I figure it must be the checksumming step I've gotten wrong (since it's only the last characters in the resulting base58-encoded private key that are wrong)
453 2012-10-01 15:29:06 <runeks> *first part of private key _in base58 encoding_
454 2012-10-01 15:29:08 <Eliel> runeks: how many characters are wrong?
455 2012-10-01 15:29:18 <runeks> it's 5KJvsngHeMpm884wtkJNzQGaCErckhHJBGFsvd3VyK5qMTWmw7V
456 2012-10-01 15:29:38 <runeks> should be 5KJvsngHeMpm884wtkJNzQGaCErckhHJBGFsvd3VyK5qMZXj3hS
457 2012-10-01 15:29:50 <isis1> Almost forgot to mention...  The secret to generate the key isn't just the payment card.  It's the payment card+pin.  This allows you to set spending limits for times you are AFK, don't have your smartphone handy or whatever.\\
458 2012-10-01 15:30:13 <runeks> Eliel: so 6 characters
459 2012-10-01 15:30:24 <Joric> runeks, looks like sha256('correct horse battery staple')
460 2012-10-01 15:30:45 <isis1> Ideally you would configure all of that with a service provider.
461 2012-10-01 15:30:55 <runeks> isis1: yep. that's the private key.
462 2012-10-01 15:31:08 <runeks> don't tell anyone!
463 2012-10-01 15:32:00 <isis1> In the future I plan to move the signing function to an EMV compatible card and keep the private key truly private.
464 2012-10-01 15:32:05 <Joric> runeks, try double sha256-ng bytes not hex strings
465 2012-10-01 15:32:33 <Joric> oh you got 00000000 as checksum i just checked
466 2012-10-01 15:32:42 <Joric> something went wrong on your side
467 2012-10-01 15:32:52 <isis1> I just need to figure out how to quickly get a list of unspent txouts for a given address.  That's the ONLY reason I'm going with the alert system now.
468 2012-10-01 15:33:07 <runeks> i'm writing it in C so it is bytes. I'm using the exact same function to add the "version byte" in front of the data and the checksum to the data as I'm using for the (public key) address, and the address comes out fine.
469 2012-10-01 15:33:11 <kjj_> isis1: wait, what?
470 2012-10-01 15:33:20 <Joric> runeks, 5KJvsngHeMpm884wtkJNzQGaCErckhHJBGFsvd3VyK5qMTWmw7V -> 80c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a00000000
471 2012-10-01 15:33:44 <runeks> Joric: hmm.
472 2012-10-01 15:34:00 <Eliel> isis1: ... then add an RPC call to do that. There might be a patch for one already.
473 2012-10-01 15:34:06 <gavinandresen> isis1: OK.  Well, if you trust that the merchant isn't hacked or dishonest and that the merchant->gateway communication is secure, then having the gateway generate a signature from the private key and broadcasting that signature is the right thing to do.  Then your clients just look for messages signed with their keys.
474 2012-10-01 15:34:12 <Eliel> the shop's bitcoind can do that perfectly well.
475 2012-10-01 15:34:56 <gavinandresen> isis1: you still have the problem of how to combat denial-of-service attacks by somebody flooding your network with bogus signatures, but you could have a master key/signature, too.
476 2012-10-01 15:34:56 <isis1> Ok let me elaborate on that last one a bit.  Right now as far as I can tell, there is no way to get a list of unspent txout's for an address that is not currently sitting in my wallet.  Thus signing has to be done by an external wallet application.
477 2012-10-01 15:35:57 <Eliel> isis1: then fix that by adding that feature, no need to require the user to run a bitcoind with public access to it.
478 2012-10-01 15:36:42 <jgarzik> bleh
479 2012-10-01 15:36:44 <isis1> The ideal would be to have an application that says for any given addresses(s) what are then unspent's that total n amount?
480 2012-10-01 15:36:49 <jgarzik> pondered doing a bitcoin router in C
481 2012-10-01 15:36:54 <jgarzik> to make block shovelling really fast
482 2012-10-01 15:37:01 <jgarzik> looks like CBitcoin is quite useless
483 2012-10-01 15:37:18 <jgarzik> so time for Yet Another Bitcoin Implementation
484 2012-10-01 15:37:51 <isis1> This way the merchant or his service provider could ask the card for a list of public bitcoin addresses that the card can sign then craft the transaction and hand it to the card.
485 2012-10-01 15:37:59 <isis1> At which point the card would sign it.
486 2012-10-01 15:38:02 <Eliel> isis1: it should be reasonably easy to extend bitcoind so it keeps a database of unspent txouts for every address in existence that has any.
487 2012-10-01 15:38:24 <kjj_> heh.  everything is reasonably easy when you don't have to do it yourself
488 2012-10-01 15:38:33 <gavinandresen> jgarzik: does language matter?  Seems like pynode running on a box with lots of memory so all blocks are in ram would be plenty fast enough
489 2012-10-01 15:38:37 <Eliel> kjj_: certainly easier than this alert hack.
490 2012-10-01 15:38:41 <isis1> @Eliel, unfortunately at the moment that is beyond my ability to do in C.
491 2012-10-01 15:39:20 <Eliel> didn't someone alraedy write a patch to do this some time ago?
492 2012-10-01 15:39:31 <gavinandresen> jgarzik: ... or maybe 11 pynodes, with the blocks stored in memcached ....
493 2012-10-01 15:39:51 <isis1> As far as I know it only returns unspenttx for addresses currently in your wallet.
494 2012-10-01 15:40:08 <isis1> I'd love to figure out how blockchain explorer does it.
495 2012-10-01 15:40:16 <runeks> Joric: now it works for me. was messing up wrt. to buffer sizes. thanks! :)
496 2012-10-01 15:40:19 <Eliel> isis1: checkout bitcoin-abe
497 2012-10-01 15:40:21 <gavinandresen> isis1: yes, there is no index of arbitrary address to outpoints in the reference implementation.
498 2012-10-01 15:41:27 <runeks> jgarzik: what do you mean with "block shovelling".
499 2012-10-01 15:42:39 <isis1> @Eliel that's great, but my requirement is for C or Java.  That's a business requirement from the folks paying the bills on this one.
500 2012-10-01 15:42:57 <isis1> bitcoin-abe is python
501 2012-10-01 15:43:42 <isis1> @Gavin, what would be involved in creating an index like that?
502 2012-10-01 15:43:58 <Eliel> isis1: should be reasonably easy to write a C or Java version of the critical functions.
503 2012-10-01 15:44:31 <Eliel> isis1: bitcoin-abe is an example of how to do it.
504 2012-10-01 15:45:05 <Eliel> not a great example, mind you, but it works.
505 2012-10-01 15:45:24 <isis1> If gavin thinks it's easy and can point me in the direction to get started I'll go that route instead.  But at the moment, everyone I've talked to so far says it's going to require more computing power than we have at our disposal.
506 2012-10-01 15:45:49 <jgarzik> gavinandresen: pynode script verification is just too slow
507 2012-10-01 15:46:00 <isis1> Easy =< 40 hours to get a prototype going for a moderately competent programmer.
508 2012-10-01 15:46:15 <jgarzik> gavinandresen: SignatureHash() requires copying CTransaction to modify
509 2012-10-01 15:46:51 <jgarzik> for fast block relaying, I would want balls-out fastest implementation  :)
510 2012-10-01 15:46:57 <jgarzik> C makes the "sendfile block" trick a lot easier
511 2012-10-01 15:47:08 <kjj_> isis1: get a database package, write a schema, and start reading the block files
512 2012-10-01 15:47:58 <jgarzik> even if the ref client were willing to change the block file format to match that of the "block" message, it is still a mess to plug sendfile'd data into the current scheme
513 2012-10-01 15:48:34 <jgarzik> alternatively, you could leave the block file format the same, but send out the header with MSG_MORE.  still very messy for the current ref client.
514 2012-10-01 15:48:37 <isis1> @kjj_ seems like most of what I need is here, otherwise transactions couldn't validate.  Just wish I could find an entrance point.
515 2012-10-01 15:49:07 <isis1> How long does it take to scan the blockchain currently for an unspenttx, for instance during the privkeyimport?
516 2012-10-01 15:49:45 <gavinandresen> jgarzik: oh, 'shovelling blocks' includes signature verification?
517 2012-10-01 15:49:48 <kjj_> isis1: you can borrow the bitcoin code, but the index you want isn't there, and adding it to the node is probably more work than writing something totally different
518 2012-10-01 15:50:08 <kjj_> isis1: usually, several minutes to scan the blocks for a new key
519 2012-10-01 15:50:21 <jgarzik> gavinandresen: if you want to turn around a block, verified
520 2012-10-01 15:50:28 <isis1> Ideally I'
521 2012-10-01 15:50:40 <jgarzik> gavinandresen: it is even faster to relay the block without script verification, I grant
522 2012-10-01 15:51:01 <kjj_> lol.  if you believe the foundation trolls on the forums, there are like 90 people on the board
523 2012-10-01 15:51:09 <Eliel> isis1: one solution that is hacky and gets slower with big wallets is to temporarily add the addresses in question to the wallet and rescan.
524 2012-10-01 15:51:25 <jgarzik> another option is a hybrid:  script verify memory pool TX's, and cache the result (signature cache)
525 2012-10-01 15:51:28 <Eliel> isis1: but I suspect that won't really fly long term.
526 2012-10-01 15:51:37 <jgarzik> and then DON'T verify any TX scripts not cached
527 2012-10-01 15:51:48 <jgarzik> that would verify -most- TX's, while resulting in small turnaround time
528 2012-10-01 15:54:51 <isis1> @kjj_ I'm not sure what the schema would look like on something like that.  Guess I could talk to a data modeler.  We have multiple tx_in's mapping to multiple tx_out's with arbitrary script telling us whether or not is has been spent.
529 2012-10-01 15:55:59 <isis1> However I guess it wouldn't have been included in a block if it was invalid.  But only looking at blocks and not just tx's leaves us open to a potential double spend since the spend may have occured but not been included in a block yet.
530 2012-10-01 15:58:00 <isis1> @Eliel, thats a good idea but problematic because it could mix funds if several people were doing it at once.  You would have to create a seperate & temporary wallet, import the keys, scan the block chain, return the unspent tx's and then delete the wallet.
531 2012-10-01 15:58:43 <Eliel> isis1: look at the schema bitcoin-abe uses. It stores the data into a database.
532 2012-10-01 15:59:04 <isis1> Remember the ideal for payment processing when you're standing in line is 30 seconds or less.  2 minutes tops, but by then the cashier has probably had you swipe the card 5 times ;)
533 2012-10-01 16:01:25 <Eliel> isis1: sipa's ultraprune implementation could be a good starting point actually. It only stores unspent txout data. you'd only need to add an index that maps bitcoin-address -> list of txouts
534 2012-10-01 16:03:06 <isis1> Hmm thats something i never thought of before.
535 2012-10-01 16:03:13 <isis1> I'll look into it.  Have a link?
536 2012-10-01 16:03:22 <Eliel> isis1: ultraprune is an optimization that's most likely going into bitcoind 0.8. Improves both disk usage as well as synchronization speed.
537 2012-10-01 16:03:43 <Eliel> I expect it's in sipa's github repo. I lack a link though
538 2012-10-01 16:03:52 <jgarzik> and scalability
539 2012-10-01 16:04:03 <isis1> I'll take a look.
540 2012-10-01 16:05:23 <isis1> Searched and saw no reference to ultraprune @ github.com/sipa
541 2012-10-01 16:06:02 <jgarzik> isis1: https://github.com/bitcoin/bitcoin/pull/1677
542 2012-10-01 16:06:28 <molecular> https://github.com/sipa/bitcoin/tree/ultraprune
543 2012-10-01 16:08:25 <isis1> TYVM
544 2012-10-01 16:14:40 <isis1> Dang I wish there was a source map.  I'm trying to follow   uiInterface.NotifyAlertChanged(GetHash(), CT_NEW) so i can do something else with the alert, but it disappears into a black hole at that point.
545 2012-10-01 16:14:49 <kjj_> grep
546 2012-10-01 16:15:29 <Eliel> isis1: if you cloned the git repo, use git grep
547 2012-10-01 16:15:37 <Eliel> isis1: it'll automatically grip all files.
548 2012-10-01 16:15:41 <Eliel> umm grep
549 2012-10-01 16:19:32 <TD> jgarzik: you mean like a load balancing proxy type thing? shads was implementing one of those in bitcoinj before he disappeared
550 2012-10-01 16:19:36 <TD> he did a bunch of optimizations for it
551 2012-10-01 16:20:22 <jgarzik> TD: a C program that is the bitcoin analogue of a "core / border router"
552 2012-10-01 16:20:59 <jgarzik> TD: reference client serves this purpose reasonably well, but I think it can be done better with a wallet-free implementation focused purely on tx/block serving
553 2012-10-01 16:21:01 <TD> what i'd like to see is a program that basically handles relaying of blocks and transactions but doesn't do any processing itself. it'd use a bitcoin node on the backend to ensure it only relays valid stuff
554 2012-10-01 16:21:04 <TD> yes
555 2012-10-01 16:21:06 <TD> indeed
556 2012-10-01 16:21:14 <TD> i wanted to write one. never got around to it
557 2012-10-01 16:21:37 <jgarzik> TD: well, I would want my beast to verify
558 2012-10-01 16:21:44 <jgarzik> TD: a signature cache gets you 75% there
559 2012-10-01 16:21:51 <TD> then how is it different to a regular full node
560 2012-10-01 16:22:07 <jgarzik> TD: no wallet, several optimizations to increase relay speed
561 2012-10-01 16:22:15 <TD> why does no wallet make a difference?
562 2012-10-01 16:22:35 <jgarzik> TD: there are wallet checks in the ref client
563 2012-10-01 16:22:43 <jgarzik> TD: core router doesn't need those
564 2012-10-01 16:22:50 <TD> yeah, but i doubt they impact performance much if the wallet is empty
565 2012-10-01 16:23:54 <jgarzik> of course, I could always strip down the C++ client to bare bones, and change the block file format
566 2012-10-01 16:24:02 <jgarzik> but it's more fun to write from scratch ;p
567 2012-10-01 16:52:26 <kjj_> jgarzik: I think you are wrong on the forums.  Clearly, becase one bounty worked, all bountys everywhere for every thing must also work.  QED.
568 2012-10-01 16:52:59 <jgarzik> ;-)
569 2012-10-01 16:52:59 <ThomasV> kjj_: someone is wrong on the internet?
570 2012-10-01 16:53:19 <Diablo-D3> kjj_: best logic ever
571 2012-10-01 16:54:06 <kjj_> also, I'm surprised that it took several days for them to get around to the "if we aren't right, why is everyone calling us trolls?" argument
572 2012-10-01 16:56:23 <isis1> OMG what is implementing uiInterface.NotifyAlertChanged ?  This is seriously starting to turn into a rabbit hole for me.
573 2012-10-01 16:56:24 <gmaxwell> hah
574 2012-10-01 16:56:38 <gmaxwell> kjj_: more of the foundation thread?
575 2012-10-01 16:56:45 <kjj_> isis1: qt/clientmodel.cpp
576 2012-10-01 16:57:28 <kjj_> gmaxwell: totally.  I'm thinking of posting a link to:  http://www.youtube.com/watch?v=dOOTKA0aGI0
577 2012-10-01 16:57:54 <isis1> Thanks was losing my mind there for a min.  I somehow thought that was only for the GUI client.
578 2012-10-01 16:58:05 <kjj_> heh.  it is only for the GUI client
579 2012-10-01 17:09:14 <jgarzik> ultimately the BF furor boils down to "how dare you declare yourselves the spokesman of Anonymous?  Anonymous has no spokesperson, that's the whole point!"
580 2012-10-01 17:09:29 <kjj_> jgarzik: heh, exactly
581 2012-10-01 17:09:30 <jgarzik> it's not the bogeyman, but only time and action will prove or disprove that
582 2012-10-01 17:17:56 <sipa> kjj_, isis1: yes and no, it's also implemented in noui.cpp
583 2012-10-01 17:20:07 <kjj_> sipa: I don't see it in noui.cpp.  Don't see much of anything in there, really
584 2012-10-01 17:20:33 <TD> gavinandresen: i'm wondering if you have any estimates on when the pull request backlog might get cleared, if you're going to be able to focus on development full time post-foundation-launch
585 2012-10-01 17:22:26 <gavinandresen> TD: haven't had time to estimate.  And yes, I should be able to focus on development after a couple of post-foundation-launch technical items get done
586 2012-10-01 17:23:26 <gavinandresen> TD: there seems to be consensus that a 0.7.1 release should happen soon, to get the URI bug fix released
587 2012-10-01 17:23:37 <Luke-Jr> gavinandresen: are you doing that or am I?
588 2012-10-01 17:23:55 <gavinandresen> "We" will do that in mainline
589 2012-10-01 17:24:07 <Luke-Jr> thanks
590 2012-10-01 17:25:31 <TD> ok, great
591 2012-10-01 17:26:22 <kinlo> are there any cpu statum miners?
592 2012-10-01 17:31:44 <stamit> 
ACTION says hello to the high-quality people.

593 2012-10-01 17:40:29 <helo> 
ACTION frowns at his low quality abdomen

594 2012-10-01 17:47:02 <stamit> first class, second class, third class...
595 2012-10-01 17:47:23 <stamit> why is it always like that?
596 2012-10-01 17:47:29 <sipa> how about i'th class?
597 2012-10-01 17:47:38 <sipa> like the square root of -1
598 2012-10-01 17:50:32 <stamit> you look like a person of high class, sipa
599 2012-10-01 17:51:19 <sipa> no no, imaginary class
600 2012-10-01 17:51:34 <maaku> jgarzik amiller: I pushed a refactoring of the 'bitcoin' sub package of pynode to https://github.com/monetizeio/python-bitcoin
601 2012-10-01 17:52:28 <maaku> the idea is to separate p2p node and filesystem/database stuff from the basic bitcoin types and protocol logic
602 2012-10-01 17:53:06 <stamit> sipa: i like those charts, btw. i've looked at them probably hundreds of times
603 2012-10-01 17:53:07 <maaku> and to refactor it to be a bit more pythonic, rather than a direct port of Satoshi API
604 2012-10-01 17:54:01 <sipa> stamit: i think they are very useful for the few hours they cost to set up :)
605 2012-10-01 17:59:08 <TD> hmm
606 2012-10-01 17:59:15 <TD> speed has been rising steadily since july
607 2012-10-01 17:59:20 <gmaxwell> sipa: I still want to see ones for testnet3. :P
608 2012-10-01 17:59:20 <TD> FPGA upgrades kicking into gear, perhaps
609 2012-10-01 18:00:07 <gmaxwell> TD: even gpu mining is pretty profitable now??? would even be profitable at half, so who knows what people have been adding. Used GPUs still sell well on ebay.
610 2012-10-01 18:00:18 <TD> hmpmh
611 2012-10-01 18:00:28 <TD> mining isn't supposed to be very profitable :)
612 2012-10-01 18:00:46 <TD> but yeah i guess it still has to climb to match the doubling of the exchange rate
613 2012-10-01 18:01:00 <gmaxwell> TD: well thus the increasing hashrate??? it's trying for equlibrium...
614 2012-10-01 18:01:55 <gmaxwell> right, it was unprofitable to gpu mine for just about anyone paying for power at $3 a few months back.. but at $12 it's a little different.
615 2012-10-01 18:02:37 <gmaxwell> I expect uncertanty about the introduction of ASIC is slowing convergance to unprofitablity.
616 2012-10-01 18:03:33 <denisx> the rise of the asics are the reason why alot of people do not buy fpgas right now
617 2012-10-01 18:03:53 <denisx> is the reason
618 2012-10-01 18:03:55 <sipa> TD, gmaxwell: mining tends to an equilibrium where electricity + hardware costs equal income
619 2012-10-01 18:04:10 <sipa> but those hardware costs are hard to observe
620 2012-10-01 18:04:42 <sipa> gmaxwell: right, testnet hashrate
621 2012-10-01 18:05:41 <sipa> not sure my current algorithm is stable enough for that
622 2012-10-01 18:07:28 <gmaxwell> sipa: :P thats a little bit why I was suggesting doing it.
623 2012-10-01 18:07:32 <BlueMatt> TD: so I pushed new copies of the first few commits to a newscripts branch, I havent gotten into the FullPrunedBlockStore stuff yet
624 2012-10-01 18:08:40 <TD> thanks
625 2012-10-01 18:09:15 <TD> will take a look in the next few days
626 2012-10-01 18:09:27 <BlueMatt> sure
627 2012-10-01 18:10:01 <sipa> gmaxwell: i once did may a version that had a simulated perfectly constant & known hashrate
628 2012-10-01 18:10:56 <sipa> gmaxwell: bitcoin.sipa.be/simulation
629 2012-10-01 18:11:00 <sipa> it's outdated though
630 2012-10-01 18:12:33 <jgarzik> maaku: sigh
631 2012-10-01 18:12:59 <jgarzik> maaku: it would have been nicer if you would have coordinated a bit more
632 2012-10-01 18:13:37 <jgarzik> maaku: the clear intention was always to build python-bitcoin -- but you don't build a library with 1000+ gadgets, none of which have an immediate user outside of tests
633 2012-10-01 18:14:11 <jgarzik> maaku: I would have been more than happy to split out python-bitcoin and take pull requests
634 2012-10-01 18:17:33 <maaku> jgarzik: this is what i need for my own projects and no ambition beyond that
635 2012-10-01 18:45:20 <amiller> maaku, do you have a pynode branch that uses your python-bitcoin tools?
636 2012-10-01 18:45:45 <maaku> yes, but it's got proprietary stuff mixed in with it, so it's not public
637 2012-10-01 18:50:12 <maaku> i hope to factor that out on its own in the future so i can share it of course, but I've got a lot on my plate already : \\
638 2012-10-01 19:16:10 <yellowhat> could someone be so kind to mine a few (6) blocks testnet3 for me?
639 2012-10-01 19:18:03 <lianj> yellowhat: maybe better use testnet in a box
640 2012-10-01 19:18:36 <yellowhat> its just a matter of laizness to be honest. i need my fauchet coins confirmed.
641 2012-10-01 19:18:48 <lianj> ah ok :D
642 2012-10-01 19:18:50 <kjj_> ha!
643 2012-10-01 19:18:59 <yellowhat> also the app i am testing cannot simply be pointed to a custom testnet that would be real work
644 2012-10-01 19:19:38 <lianj> testnet in a box isnt custom
645 2012-10-01 19:20:44 <gmaxwell> yellowhat: testnet3 is actively mined.
646 2012-10-01 19:21:25 <yellowhat> it is? well, going to sleep then did not get enough in the last days. maybe someone will mine while i sleep if its actively mined
647 2012-10-01 19:24:23 <gmaxwell> yellowhat: er, how many blocks do you see?
648 2012-10-01 19:24:37 <gmaxwell> 31715
649 2012-10-01 19:27:05 <yellowhat> im on height 31715 no blocks last 15 minutes at least
650 2012-10-01 19:32:49 <jgarzik> getheaders 42001 to 00000000000000000000
651 2012-10-01 19:32:50 <yellowhat> great a block :)
652 2012-10-01 19:32:56 <jgarzik> cool... somebody is actually using getheaders on mainnet
653 2012-10-01 19:34:57 <lianj> which useragent?
654 2012-10-01 19:35:50 <sipa> jgarzik: BitcoinJ does
655 2012-10-01 19:35:59 <sipa> for blocks before wallet creation