1 2012-09-10 00:00:04 <phantomcircuit> http://metaexch.com:8000/login
  2 2012-09-10 00:00:14 <phantomcircuit> that now does everything but clear trades
  3 2012-09-10 00:00:21 <phantomcircuit> uber fast
  4 2012-09-10 00:00:22 <phantomcircuit> lawl
  5 2012-09-10 00:00:50 <MC-Eeepc> >deepbit
  6 2012-09-10 00:01:57 <copumpkin> phantomcircuit: kinda slow to log in and register
  7 2012-09-10 00:02:12 <copumpkin> SWEET
  8 2012-09-10 00:02:14 <copumpkin> I HAVE $1000
  9 2012-09-10 00:02:25 <copumpkin> whoa, I can keep doing this
 10 2012-09-10 00:02:27 <phantomcircuit> copumpkin, it's the single threaded debug server
 11 2012-09-10 00:02:36 <copumpkin> man, I'm gonna be riiiich
 12 2012-09-10 00:02:38 <phantomcircuit> the slowest part is logging it
 13 2012-09-10 00:02:40 <phantomcircuit> in*
 14 2012-09-10 00:03:25 <MC-Eeepc> shit i have 1000btc
 15 2012-09-10 00:03:30 <MC-Eeepc> withdraw withdraw
 16 2012-09-10 00:04:33 <Luke-Jr> ???
 17 2012-09-10 00:04:42 <phantomcircuit> and no withdrawals
 18 2012-09-10 00:05:03 <copumpkin> :(
 19 2012-09-10 00:05:46 <MC-Eeepc> i dont even know what im doing
 20 2012-09-10 00:06:33 <copumpkin> look at them fancy order types
 21 2012-09-10 00:06:44 <copumpkin> and massive UUID account IDs
 22 2012-09-10 00:08:24 <phantomcircuit> copumpkin, accounts can be labelled
 23 2012-09-10 00:08:32 <copumpkin> phantomcircuit: I b0rked it
 24 2012-09-10 00:08:33 <phantomcircuit> it's the only polish i have put on this
 25 2012-09-10 00:09:13 <copumpkin> now I can see part of your database schema, though
 26 2012-09-10 00:09:15 <copumpkin> whee
 27 2012-09-10 00:09:26 <copumpkin> wow, this is a very detailed stack trace
 28 2012-09-10 00:09:56 <phantomcircuit> it's probably got like
 29 2012-09-10 00:09:59 <phantomcircuit> all the codez
 30 2012-09-10 00:10:05 <copumpkin> omgz
 31 2012-09-10 00:10:06 <copumpkin> hax
 32 2012-09-10 00:10:18 <doublec> good idea then when people get a stack trace they can fix it
 33 2012-09-10 00:10:19 <copumpkin> 
ACTION l33thax

 34 2012-09-10 00:10:19 <phantomcircuit> here let me change that
 35 2012-09-10 00:10:25 <phantomcircuit> doublec, hehe
 36 2012-09-10 00:10:34 <copumpkin> phantomcircuit: imma fix it 4 u
 37 2012-09-10 00:10:37 <copumpkin> 
ACTION logs in

 38 2012-09-10 00:11:16 <jrmithdobbs> phantomcircuit: help me figure out dis unit test wonkiness
 39 2012-09-10 00:11:42 <phantomcircuit> jrmithdobbs, mayybee
 40 2012-09-10 00:11:55 <jrmithdobbs> phantomcircuit: see pastebin link at bottom of https://github.com/bitcoin/bitcoin/pull/1815
 41 2012-09-10 00:12:56 <phantomcircuit> copumpkin, i'll give you a clue
 42 2012-09-10 00:13:12 <phantomcircuit> the root password starts with zg9FU
 43 2012-09-10 00:13:29 <copumpkin> you mean it _did_
 44 2012-09-10 00:13:31 <copumpkin> it doesn't anymore
 45 2012-09-10 00:13:35 <phantomcircuit> oh knowz
 46 2012-09-10 00:13:39 <copumpkin> 
ACTION runs off with the seeekrirz

 47 2012-09-10 00:14:16 <sipa> 
ACTION wonders where to find the libbitcoin source

 48 2012-09-10 00:14:28 <phantomcircuit> sipa, gitorious iirc
 49 2012-09-10 00:14:53 <jrmithdobbs> sipa: genjix's or that guy that forked and wont maintain and switched everything to gpl3 like an asshole?
 50 2012-09-10 00:15:32 <jrmithdobbs> (genjix's is agplv3 but it's mostly his code so not an asshole for it)
 51 2012-09-10 00:15:35 <Luke-Jr> jrmithdobbs: libcoin != libbitcoin
 52 2012-09-10 00:15:46 <sipa> jrmithdobbs: genjix's; the other is libcoin, and he offered to switch the license to MIT
 53 2012-09-10 00:15:49 <jrmithdobbs> yes i'm trying to remember which is which, hence, question
 54 2012-09-10 00:16:21 <jrmithdobbs> sipa: it's on gitorious
 55 2012-09-10 00:16:43 <sipa> yeah, found it
 56 2012-09-10 00:16:50 <sipa> libbitcoin.org seems down, though
 57 2012-09-10 00:35:32 <MC-Eeepc> We had a kernel panic within the MD layer of the linux kernel. Service will be restored within the next 7 days.
 58 2012-09-10 00:35:33 <MC-Eeepc> In the meantime, you could assume the price to be either $0.01 or $100 so we can see some interesting rallies and have fun until you can look at boring numbers again :)
 59 2012-09-10 00:35:36 <MC-Eeepc> oh shit what
 60 2012-09-10 00:36:18 <xisalty> what
 61 2012-09-10 00:36:33 <MC-Eeepc> bitcoin charts
 62 2012-09-10 00:57:30 <gribble> Best bid: 11.07, Best ask: 11.10878, Bid-ask spread: 0.03878, Last trade: 11.10878, 24 hour volume: 13397, 24 hour low: 10.92452, 24 hour high: 11.14288
 63 2012-09-10 00:57:30 <JFK911> !ticker
 64 2012-09-10 01:56:51 <phantomcircuit> copumpkin, http://metaexch.com/
 65 2012-09-10 01:57:25 <copumpkin> phantomcircuit: http://snapplr.com/4yec
 66 2012-09-10 01:57:30 <copumpkin> when I try to create an order
 67 2012-09-10 01:57:37 <copumpkin> not even trying to break it!
 68 2012-09-10 01:58:25 <phantomcircuit> huh
 69 2012-09-10 01:58:26 <phantomcircuit> weird
 70 2012-09-10 02:00:28 <phantomcircuit> not logging the error either
 71 2012-09-10 02:01:11 <phantomcircuit> oh lol i know
 72 2012-09-10 02:02:12 <phantomcircuit> copumpkin, nginx is lying to django tell it that it's using https
 73 2012-09-10 02:03:48 <phantomcircuit> thar
 74 2012-09-10 02:06:13 <copumpkin> nope
 75 2012-09-10 02:06:53 <phantomcircuit> works for me
 76 2012-09-10 02:06:55 <phantomcircuit> clear cookies
 77 2012-09-10 02:08:58 <copumpkin> nope
 78 2012-09-10 02:09:02 <copumpkin> cleared and it still don't work
 79 2012-09-10 02:09:17 <copumpkin> http://snapplr.com/587s
 80 2012-09-10 02:10:34 <phantomcircuit> copumpkin, trying to create an order?
 81 2012-09-10 02:10:40 <copumpkin> yup
 82 2012-09-10 02:11:11 <copumpkin> I take my $1000 USD account, try to sell 1000 usd at a rate of 10 btc each (that's how I interpret it, anyway)
 83 2012-09-10 02:11:14 <copumpkin> and then I get that
 84 2012-09-10 02:12:19 <phantomcircuit> huh weird
 85 2012-09-10 02:12:46 <phantomcircuit> copumpkin, well first off quantity is always btc
 86 2012-09-10 02:12:48 <phantomcircuit> never used
 87 2012-09-10 02:12:50 <phantomcircuit> usd
 88 2012-09-10 02:12:56 <copumpkin> oh
 89 2012-09-10 02:13:05 <copumpkin> well originally it was telling me that I didn't have enough in my account
 90 2012-09-10 02:13:13 <copumpkin> and then I adjusted it and it stopped bitching
 91 2012-09-10 02:13:17 <copumpkin> and then gave me this error instead
 92 2012-09-10 02:13:22 <phantomcircuit> also debugging isn't logging things right
 93 2012-09-10 02:13:23 <phantomcircuit> :|
 94 2012-09-10 02:15:30 <phantomcircuit> copumpkin, and now?
 95 2012-09-10 02:15:52 <copumpkin> http://snapplr.com/fqt6
 96 2012-09-10 02:15:54 <copumpkin> same inut
 97 2012-09-10 02:15:55 <copumpkin> input
 98 2012-09-10 02:16:52 <phantomcircuit> copumpkin, http://metaexch.com:8080/
 99 2012-09-10 02:17:21 <copumpkin> http://snapplr.com/y599
100 2012-09-10 02:17:24 <phantomcircuit> AttributeError: 'module' object has no attribute 'handler500'
101 2012-09-10 02:17:25 <phantomcircuit> wat
102 2012-09-10 02:17:53 <copumpkin> probably you throw an error and it's looking for a 500 page?
103 2012-09-10 02:17:58 <copumpkin> or some designated handler for it
104 2012-09-10 02:18:14 <copumpkin> one of those "exception while trying to throw an exception" things, maybe
105 2012-09-10 02:18:19 <copumpkin> 
ACTION shrugs, doesn't do python :)

106 2012-09-10 02:20:33 <phantomcircuit> it's something weird about django
107 2012-09-10 02:20:58 <phantomcircuit> although weirder im not triggering it
108 2012-09-10 02:21:26 <phantomcircuit> copumpkin, try again
109 2012-09-10 02:21:50 <copumpkin> nope, same error
110 2012-09-10 02:22:07 <copumpkin> http://snapplr.com/5y07 is my input, btw
111 2012-09-10 02:23:25 <phantomcircuit> bleh
112 2012-09-10 02:23:33 <phantomcircuit> the meta exception is fixed now
113 2012-09-10 02:23:42 <phantomcircuit> should at least give an intelligible error
114 2012-09-10 02:24:29 <copumpkin> w00t, http://snapplr.com/5bej
115 2012-09-10 02:24:31 <copumpkin> :P
116 2012-09-10 02:25:11 <phantomcircuit> weird
117 2012-09-10 02:25:21 <phantomcircuit> some how you avoided the form validation for the expires field
118 2012-09-10 02:25:35 <phantomcircuit> which i doubt you were even trying to do
119 2012-09-10 02:26:32 <copumpkin> has that been around for a while?
120 2012-09-10 02:26:38 <tcatm> FYI bitcoincharts is online again.
121 2012-09-10 02:26:39 <copumpkin> because I was submitting the form in a new tab
122 2012-09-10 02:26:54 <copumpkin> so if you added additional validation to the form, then I didn't reload it
123 2012-09-10 02:27:29 <phantomcircuit> thar
124 2012-09-10 02:27:34 <phantomcircuit> thar
125 2012-09-10 02:27:47 <phantomcircuit> now if you dont specify an expires time it will give you an error
126 2012-09-10 02:27:55 <copumpkin> w00t, http://snapplr.com/0tjw
127 2012-09-10 02:27:58 <copumpkin> nice ;)
128 2012-09-10 02:28:12 <phantomcircuit> i actually had required=False
129 2012-09-10 02:28:28 <phantomcircuit> i was going to specify a default expire time of 90 days but i didn't actually do that
130 2012-09-10 02:28:29 <copumpkin> what's the format for the expires field, especially when I have a good till cancelled?
131 2012-09-10 02:28:35 <copumpkin> if I want no expiry?
132 2012-09-10 02:28:45 <phantomcircuit> you need an expire time
133 2012-09-10 02:28:50 <phantomcircuit> but it coudl be the year 3000
134 2012-09-10 02:28:57 <copumpkin> is it a timestamp?
135 2012-09-10 02:29:02 <copumpkin> or some formatted date?
136 2012-09-10 02:29:06 <phantomcircuit> https://docs.djangoproject.com/en/dev/ref/forms/fields/#datetimefield
137 2012-09-10 02:29:11 <phantomcircuit> all the formats will work
138 2012-09-10 02:29:51 <copumpkin> the problem with formats is that they vary by country, so you should tell people you expect the US order :P
139 2012-09-10 02:30:00 <copumpkin> (for the slashy ones)
140 2012-09-10 02:30:11 <phantomcircuit> well this is obviously not polished
141 2012-09-10 02:30:21 <copumpkin> w00t, my order is on the book!
142 2012-09-10 02:30:23 <phantomcircuit> will add some loverly js calendar thingie
143 2012-09-10 02:30:24 <copumpkin> quick quick
144 2012-09-10 02:30:27 <copumpkin> buy buy buy
145 2012-09-10 02:30:43 <phantomcircuit> copumpkin, lol there isn't a display of the orderbook
146 2012-09-10 02:30:51 <phantomcircuit> what rate did you specify
147 2012-09-10 02:32:09 <phantomcircuit> copumpkin, executed
148 2012-09-10 02:36:38 <copumpkin> w00t
149 2012-09-10 02:37:44 <phantomcircuit> lol
150 2012-09-10 02:37:48 <phantomcircuit> look at the account history
151 2012-09-10 02:38:02 <phantomcircuit> the ledger entry balances are all wrong
152 2012-09-10 02:38:06 <phantomcircuit> woops
153 2012-09-10 02:39:27 <phantomcircuit> OH
154 2012-09-10 02:39:30 <phantomcircuit> they're not ordered right
155 2012-09-10 02:39:31 <phantomcircuit> derp
156 2012-09-10 02:43:28 <phantomcircuit> default '2012-08-29 17:48:05.180842-04'::timestamp with time zone
157 2012-09-10 02:43:31 <phantomcircuit> lol
158 2012-09-10 02:43:35 <phantomcircuit> that explains that
159 2012-09-10 03:47:00 <jgarzik> https://github.com/jgarzik/pybond
160 2012-09-10 03:47:12 <Luke-Jr> wow, that was fast :D
161 2012-09-10 03:47:17 <jgarzik> just a skeleton right now with zero bond-market-related stuff (but a working skeleton!)
162 2012-09-10 03:52:00 <midnightmagic> jgarzik: That's pretty awesome.
163 2012-09-10 03:55:46 <amiller> i see, it's a skeleton in that it doesn't have anything bond specific yet, but it's a client with protobuf rpc and some boilerplate, similar to how pynode works
164 2012-09-10 03:59:10 <jgarzik> protobuf P2P.  HTTP+JSON RPC will be a trivial bolt-on from pynode.
165 2012-09-10 03:59:46 <jgarzik> since the bond stuff is protobuf, wanted to make sure those bits were working
166 2012-09-10 04:00:16 <amiller> it's a pretty cool technique for building p2p clients in python
167 2012-09-10 04:01:15 <jgarzik> yep.  once pynode's http server (a recipe copied from some py cookbook) is bolted on, it is a nice generic p2p+rpc node for experimentation.
168 2012-09-10 04:01:35 <jgarzik> then bond market stuff should be all "business logic", with little crapola code left to write
169 2012-09-10 04:06:40 <Luke-Jr> 
ACTION wonders why jgarzik must use old-Python :<

170 2012-09-10 04:07:03 <amiller> er, pybond is a bit different than pynode in that pybond seems to listen for open p2p connections whereas pynode doesn't do that - pynode's interface to the p2p network is through bitcoin
171 2012-09-10 04:08:51 <jgarzik> amiller: pybond connects out and listens.  pynode connects out, does not listen.
172 2012-09-10 04:09:50 <jgarzik> amiller: so "is through bitcoin" is mainly a matter of semantics ;p
173 2012-09-10 04:10:05 <jgarzik> pynode talks with any bitcoin p2p node
174 2012-09-10 04:11:40 <jgarzik> 
ACTION needs to switch to twisted (dependency++), or decide to fix decade-old asyncore.

175 2012-09-10 04:12:04 <jgarzik> pynode becoming a connect-out, listen-in full P2P node is blocked on python stupidity, sadly
176 2012-09-10 04:12:14 <jgarzik> pybond has the same problem
177 2012-09-10 04:12:44 <amiller> i recommend twisted and asking tahoe-lafs for help somehow
178 2012-09-10 04:12:47 <Luke-Jr> or upgrade to Python3
179 2012-09-10 04:12:54 <Luke-Jr> Twisted = garbage
180 2012-09-10 04:13:05 <amiller> i don't know wtf about asyncore though
181 2012-09-10 04:13:20 <Luke-Jr> asyncore does suck too :/
182 2012-09-10 04:13:31 <amiller> twisted's better than any alternative, i'm not sure what you'd use in python3
183 2012-09-10 04:13:51 <Luke-Jr> amiller: for what? for writing unreadable code?
184 2012-09-10 04:14:49 <jgarzik> asyncore is acceptable for servers, but it has a bug that throws uncaught exceptions, when connections-out fail
185 2012-09-10 04:15:50 <Luke-Jr> amiller: with Python3, you could use Eloipool's NetworkServer, HTTPServer, or JSONRPCServer ;)
186 2012-09-10 04:16:04 <jgarzik> asyncore also uses select/poll, which is not as efficient for large numbers of fd's, or for long running connections.  twisted is a bit more opaque, but does not have these bugs, and does support epoll.
187 2012-09-10 04:16:20 <wumpus> asyncore is more like a proof of concept
188 2012-09-10 04:16:27 <jgarzik> ...written in 1996
189 2012-09-10 04:16:43 <amiller> 
ACTION is about to enjoy reading Luke-Jr's highly readable code

190 2012-09-10 04:16:53 <wumpus> yep... it's not a good library to base something serious on
191 2012-09-10 04:20:17 <amiller> eloipool uses asynchat uses asyncore
192 2012-09-10 04:20:52 <amiller> but i don't think that matters too much, it could be swapped out with anything better
193 2012-09-10 04:21:04 <wumpus> well if you say it's different in python 3.0... I only know the 2.x one
194 2012-09-10 04:21:30 <amiller> Luke-Jr, what i'm looking to see is whether or not your code is "simpler than twisted" because every command is handled synchronously
195 2012-09-10 04:24:13 <Luke-Jr> amiller: Eloipool uses a few functions from asynchat/asyncore, but I had to reimplement a lot of it :p
196 2012-09-10 04:24:51 <Luke-Jr> amiller: individual commands are synchronous
197 2012-09-10 04:25:04 <Luke-Jr> except for longpolls
198 2012-09-10 04:25:37 <amiller> genjix wrote a whole elaborate tutorial on asynchronous programming in c++ for libbitcoin using a crazy boost library, in python the closest match to that library is twisted
199 2012-09-10 04:26:02 <amiller> otherwise you have to hack in your own longpolls at some point
200 2012-09-10 04:27:24 <jgarzik> a multi-threaded, asynchronous HTTP JSON-RPC server in C++:  https://github.com/jgarzik/rpcsrv
201 2012-09-10 04:27:45 <jgarzik> uses boost.asio.  genjix has been spotted on the boost.asio list in the past, so I'm guessing that is the "crazy boost library" ;p
202 2012-09-10 04:27:59 <amiller> yup
203 2012-09-10 04:28:09 <wumpus> yes boost::asio is pretty neat
204 2012-09-10 04:28:11 <amiller> hrm hrm
205 2012-09-10 04:28:28 <amiller> jgarzik, since you've worked with both now, how do they stack up to each other
206 2012-09-10 04:28:37 <amiller> using boost.asio vs python asyncore, vs twisted if you've looked into it?
207 2012-09-10 04:29:06 <jrmithdobbs> boost::* works worse than all of the above
208 2012-09-10 04:29:13 <jgarzik> boost.asio is barely industrial strength.  asyncore is a toy.  twisted is opaque but solid in production.
209 2012-09-10 04:29:15 <jrmithdobbs> you can tell because it has boost in the name
210 2012-09-10 04:29:20 <jgarzik> serious C/C++ wants libevent
211 2012-09-10 04:29:33 <wumpus> well twisted provides this whole framework with pre-implemented protocols and handlers and such, it's not really comparable unless you only use the base features
212 2012-09-10 04:30:13 <amiller> python gevent is pretty swell for getting libevent
213 2012-09-10 04:30:53 <jrmithdobbs> libevent really is better than all of the above
214 2012-09-10 04:31:08 <jrmithdobbs> thats not just linux bigotry
215 2012-09-10 04:31:12 <wumpus> pff depends on what you need
216 2012-09-10 04:31:18 <jrmithdobbs> it really doesn't
217 2012-09-10 04:39:12 <phantomcircuit> twisted is a ridiculous mess
218 2012-09-10 04:40:13 <amiller> so is boost
219 2012-09-10 04:40:26 <phantomcircuit> true
220 2012-09-10 04:40:34 <wumpus> async code always looks like a spaghetti mess
221 2012-09-10 04:42:00 <jgarzik> all these OOP I/O layers were written circa 1992
222 2012-09-10 04:42:12 <ThomasV> tcatm: virwox was removed from bitcoincharts?
223 2012-09-10 04:42:14 <jgarzik> asyncore is a toy...  but it sure does get me up and running fast, so there's its value
224 2012-09-10 04:42:24 <jgarzik> easy enough to switch out
225 2012-09-10 04:42:25 <wumpus> unless you use some coroutine stuff like gevent, but the monkey patching has its own issues
226 2012-09-10 04:43:06 <wumpus> yes, I suppose that's the reason for leaving it in the python library, it's easy for quick hacks
227 2012-09-10 04:43:08 <phantomcircuit> ThomasV, im guessing his data set is screwed up
228 2012-09-10 04:43:34 <wumpus> if you only have 10 clients you really don't care about 10000 socket scalability
229 2012-09-10 04:44:28 <amiller> wumpus, yeah coroutine style is the only one that actually is easier to read
230 2012-09-10 04:44:57 <amiller> the problem isn't scalability in number of clients, but scalability in more features added
231 2012-09-10 04:46:06 <wumpus> lightweight threads is really what you're trying to achieve anyway, but it usually comes at the cost of having to write explicit state machines and control flow all over the place
232 2012-09-10 04:46:41 <wumpus> right, otherwise you end up implementing the more complex libraries anyway, usually in a bad way :)
233 2012-09-10 04:47:15 <wumpus> speaking of that, I think it'd be nice to replace the hand-rolled select loop and winsock wrapper in the bitcoin P2P code with something like boost::asio or gevent
234 2012-09-10 04:47:46 <wumpus> eh libevent
235 2012-09-10 04:48:41 <ThomasV> phantomcircuit: probably
236 2012-09-10 04:49:04 <jrmithdobbs> haha winsock
237 2012-09-10 04:49:36 <jgarzik> new_connection_.reset(new connection(io_service_, request_handler_));
238 2012-09-10 04:49:49 <jgarzik> otherwise known as "start async accept"
239 2012-09-10 04:49:59 <jgarzik> boost is full of such long crud
240 2012-09-10 04:50:03 <jrmithdobbs> that is ugly as fuck
241 2012-09-10 04:50:10 <wumpus> that's... C++
242 2012-09-10 04:50:20 <phantomcircuit> jgarzik, lol i had a very simple irc client i wrote around boost::asio
243 2012-09-10 04:50:21 <wumpus> it's ugly as fuck, but so is life
244 2012-09-10 04:50:22 <jrmithdobbs> no that's boost
245 2012-09-10 04:50:25 <phantomcircuit> it was really fast
246 2012-09-10 04:50:32 <phantomcircuit> but a ridiculous amount of code
247 2012-09-10 04:50:38 <jgarzik> exactly
248 2012-09-10 04:51:06 <Luke-Jr> jgarzik: you wrote pushpool with libevent, and that turned out to be the biggest problem with it???
249 2012-09-10 04:51:10 <wumpus> yes that's the thing with template based code, it gets optimized very well, but it's terrifying to write
250 2012-09-10 04:51:52 <jgarzik> terrifying to debug, terrify to attempt decoding compiler messages, ...
251 2012-09-10 04:52:03 <wumpus> and templates are boost's conception of 'modern c++', whether you agree or not...
252 2012-09-10 04:52:20 <Luke-Jr> I hear clang has nice template error messages
253 2012-09-10 04:52:22 <wumpus> with clang the compiler messages are pretty nice even for templated code
254 2012-09-10 04:52:24 <wumpus> yep Luke-Jr
255 2012-09-10 04:52:31 <wumpus> readable and colorful
256 2012-09-10 04:53:32 <wumpus> and super-fast compilation, though gcc also is very fast these days
257 2012-09-10 04:55:36 <wumpus> clangs static analysis framework is also promising, though it's currently mainly aimed at objective C not C++
258 2012-09-10 04:59:34 <amiller> jgarzik, can you give me an example of how to use this skeleton
259 2012-09-10 04:59:41 <amiller> i think what i should do is create two config files that each know to  connect to each other
260 2012-09-10 04:59:44 <amiller> and run two instances
261 2012-09-10 05:00:18 <amiller> actually nvm one should be a test script
262 2012-09-10 05:00:28 <jgarzik> amiller: http://pastebin.com/CwxJB3nJ
263 2012-09-10 05:00:42 <jgarzik> amiller: that's a two node config, one listens, one connects
264 2012-09-10 05:01:00 <amiller> okay thanks
265 2012-09-10 05:03:13 <jgarzik> amiller: pushed that as example*.cfg in pybond.git
266 2012-09-10 05:04:45 <amiller> okay and what i really want is to be watching the debug log for the respective things, not the stderr
267 2012-09-10 05:05:28 <jgarzik> amiller: yes.  tail -f $logfile
268 2012-09-10 05:06:03 <jgarzik> amiller: from "log=/your/log/file.log" line in your configuration file
269 2012-09-10 05:06:05 <amiller> jgarzik, your config files with /spare/tmp/bonddb1 need to be changed, what if you just do ./examples/bonddb1 or something and include those
270 2012-09-10 05:06:53 <jgarzik> amiller: pathnames are expected to be changed before deployment, I tend to think
271 2012-09-10 05:09:59 <amiller> k, with pynode i wasn't sure how what i should modify and what i should create before deploying
272 2012-09-10 05:11:11 <Luke-Jr> jgarzik: is there a reason submitblock is disabled in safe mode? :/
273 2012-09-10 05:15:26 <amiller> jgarzik, i'm going to try to make a gevent version that's protocol compliant with what you have now
274 2012-09-10 05:15:42 <amiller> jgarzik, would you take whatever you'd call your 'skeleton' and tag it as a commit somewhere so i can continue to compare against it
275 2012-09-10 05:15:52 <amiller> (before it gets more complicated than this)
276 2012-09-10 05:17:54 <LightRider> What is code -22?
277 2012-09-10 05:18:29 <LightRider> I'm trying to send a raw transaction and I get this error.
278 2012-09-10 05:21:50 <jgarzik> amiller: that sounds more appropriate to a local tag on your side...
279 2012-09-10 05:22:27 <jgarzik> amiller: I would have to call the branch "amiller-preferred-branchpoint" otherwise ;p
280 2012-09-10 05:23:01 <amiller> heh yeah i guess you're right there
281 2012-09-10 05:23:20 <jgarzik> 
ACTION finds a libevent C++ wrapper, http://www.llucax.com.ar/proj/eventxx/

282 2012-09-10 05:27:45 <LightRider> TX rejected (code -22)
283 2012-09-10 05:35:59 <jgarzik> amiller: if -gevent turns out well, certainly would be an improvement over asyncore
284 2012-09-10 05:36:45 <amiller> i want to avoid wasting my time on a strawman, but i want to make as little of a change as possible vs what you have to make easy comparison
285 2012-09-10 05:36:49 <jgarzik> amiller: I am planning to keep pybond in 'skeleton' state for another 24 hours at least.  Have to add the DHT, don't ya know.
286 2012-09-10 05:37:08 <amiller> that's enough of a time window for me :p
287 2012-09-10 05:37:45 <amiller> difficulty = work / time, eh
288 2012-09-10 05:45:38 <wumpus> error code -22, is, well, error code -22... we don't define any constants for RPC the error codes
289 2012-09-10 05:46:14 <wumpus> I suppose the debug log tells more
290 2012-09-10 05:49:10 <wumpus> jgarzik: I'm a bit skeptical about C++ wrappers around C code usually, as it's mostly a matter of style, though here it's nice that it adds member functions-as-callback
291 2012-09-10 05:49:33 <jgarzik> wumpus: I have no idea if it's useful for not
292 2012-09-10 05:49:51 <jgarzik> I know that my libevent programming has led me to create C++-like objects in C ;p
293 2012-09-10 05:50:51 <wumpus> even boost cannot do that for boost::signal... you end up either writing a static wrapper function that calls the c++ method, or manual remapping of the *this argument with boost::bind
294 2012-09-10 06:02:06 <jgarzik> the benefits of code reuse... it took me all of 20 minutes to add RPC server to pybond
295 2012-09-10 06:04:39 <wumpus> heh
296 2012-09-10 06:28:22 <Luke-Jr> gmaxwell: fwiw, the errors I got earlier were printing prevblock very wrong; looks like Deepbit was sending the next block via normal getwork early, then the old one via normal getwork again, then the longpoll finally solved it altogether
297 2012-09-10 06:28:39 <Luke-Jr> definitely smells like a load balancing issue
298 2012-09-10 06:54:25 <amiller> hey jgarzik, check this out https://github.com/amiller/pybond/blob/gevent/gnode.py
299 2012-09-10 06:54:40 <amiller> i made a gnode.py that is 4-way compatible with your node.py
300 2012-09-10 06:55:04 <amiller> (meaning you can run any combination as client or server, thanks to how awesome protobuf is)
301 2012-09-10 06:55:32 <amiller> i removed your ad hoc state machine
302 2012-09-10 06:56:34 <amiller> it's arguably easier to read and understand this way
303 2012-09-10 06:56:56 <amiller> basically we have substituted the magic of the asyncore dispatcher for the magic of gevent's monkeypatched cooperative sockets
304 2012-09-10 07:04:59 <amiller> https://github.com/amiller/pybond/commit/66d399f4d6c6e6de2462c1a11d85e476be2c4b93
305 2012-09-10 07:09:21 <amiller> the result of this experiment is that it's even simpler to use gevent than asyncore (e.g., measured in number of state machines!), let alone the fact that gevent is more stable than asyncore
306 2012-09-10 07:15:08 <_dr> where in the source can i find the function that generated sig for transaction inputs?
307 2012-09-10 08:47:34 <Joric> sipa, can you make something like that but for bitcoins? http://internet-map.net
308 2012-09-10 08:52:39 <Joric> 350k+ sites, 2m links, rebalancing takes several weeks, uploading 30m tiles (256x256) takes two days
309 2012-09-10 08:59:42 <Diablo-D3> sipa, gmaxwell: those changes that made syncing faster... when do I get those?
310 2012-09-10 09:01:59 <Joric> maybe that http://bitcoin.sipa.be/builds/ultraprune/
311 2012-09-10 09:03:12 <Diablo-D3> its not merged into mainline though
312 2012-09-10 09:11:01 <wumpus> if you help testing it, it may make it into mainline faster
313 2012-09-10 09:19:46 <ThomasV> http://bitcoincharts.com/charts/mtgoxUSD#rg10ztgSzm1g10zm2g25zv  <-- it looks like the 10 days chart is not updating anymore...
314 2012-09-10 10:22:01 <tcatm> Why does a database break, when the RAID1 below it is consistent?!
315 2012-09-10 10:22:25 <edcba> why mentioning RAID1 at all ?
316 2012-09-10 10:25:07 <sipa> tcatm: raid1 guarantees per-block consistency between the two devices
317 2012-09-10 10:25:20 <sipa> (well, in the optimal case_
318 2012-09-10 10:25:46 <sipa> even then, it's no guarantee a crashed application can't cause corruption w.rt. its own consistency rules
319 2012-09-10 10:25:58 <sipa> Diablo-D3: 0.8 hopefully
320 2012-09-10 10:26:33 <sipa> Joric: feel free to make something like that? :)
321 2012-09-10 10:30:19 <Joric> naa he pays $3k for hosting )
322 2012-09-10 10:35:02 <Evilmax> why when I start the bitcoin client (wallet) for a moment I get a balance of 123 btc?
323 2012-09-10 10:43:04 <sipa> Evilmax: GUI problem; fixed in 0.7.0
324 2012-09-10 10:56:18 <Evilmax> ok
325 2012-09-10 11:38:02 <Diablo-D3> sipa: 0.8? thats like 2016
326 2012-09-10 11:38:05 <Diablo-D3> :<
327 2012-09-10 11:41:05 <epscy> 123 free btc?
328 2012-09-10 12:00:32 <gavinandresen> anybody awake?
329 2012-09-10 12:03:57 <epscy> zzz
330 2012-09-10 12:06:07 <kinlo> I am :)
331 2012-09-10 12:06:18 <kinlo> which reminds me, I need to still reply your mail
332 2012-09-10 12:07:41 <copumpkin> anyone know what the deal is with the public notes?
333 2012-09-10 12:07:52 <copumpkin> http://snapplr.com/dty7
334 2012-09-10 12:08:16 <copumpkin> http://snapplr.com/rg5w
335 2012-09-10 12:12:10 <gavinandresen> copumpkin: sure, it was a neat idea, badly implemented. I think we've convinced Ben to hold off until it can be implemented better.
336 2012-09-10 12:12:21 <copumpkin> oh
337 2012-09-10 12:12:25 <copumpkin> so that's actually in the blockchain?
338 2012-09-10 12:12:50 <Diablo-D3> what?
339 2012-09-10 12:13:17 <sipa> depends; he originally had notes just in a txid->message database, but then decided to store them in a phony txout in the actual transactions
340 2012-09-10 12:13:32 <sipa> he switched back to a txid->message database after complaints
341 2012-09-10 12:13:43 <Diablo-D3> what are we talking about?
342 2012-09-10 12:13:51 <sipa> blockchain.info transaction messages
343 2012-09-10 12:14:20 <Diablo-D3> oh, whatever happened to that?
344 2012-09-10 12:14:34 <sipa> read back two lines
345 2012-09-10 12:14:56 <gavinandresen> sipa: do you understand what's going on with the IPv6-doesn't-work reports in the rc2 thread ?
346 2012-09-10 12:15:27 <sipa> gavinandresen: that's the crazy ipv6 rpc stuff; i don't know anything about that
347 2012-09-10 12:15:44 <sipa> (it's independent from my p2p ipv6 code)
348 2012-09-10 12:15:47 <gavinandresen> sipa: who does?  jgarzik ?
349 2012-09-10 12:15:55 <sipa> "muggenhor" wrote it
350 2012-09-10 12:16:06 <gavinandresen> mmmm.....
351 2012-09-10 12:16:09 <sipa> (i did merge it, though, i think...)
352 2012-09-10 12:17:34 <gavinandresen> I just can't tell if it is a 0.7.0 final showstopper
353 2012-09-10 12:18:23 <sipa> github seems down?
354 2012-09-10 12:18:50 <gavinandresen> https://status.github.com/
355 2012-09-10 12:19:02 <gavinandresen> they failed over
356 2012-09-10 12:19:18 <DiabloD3> damnit
357 2012-09-10 12:19:22 <DiabloD3> no one heard me I guess
358 2012-09-10 12:19:36 <DiabloD3> [10:16:16] <Diablo-D3> PANIC
359 2012-09-10 12:20:13 <sipa> that was before you even joined this channel...
360 2012-09-10 12:21:26 <DiabloD3> sipa: I pinged out
361 2012-09-10 12:21:41 <Luke-Jr> wumpus: fyi, that database/ dir could be as important as wallet.dat to keep sometimes
362 2012-09-10 12:22:06 <sipa> gavinandresen: i haven't looked at it in too much detail, but seems that it fails trying to bind to the ipv6 any address if no ipv6 stack is present
363 2012-09-10 12:22:20 <sipa> gavinandresen: so i guess it's just a matter of catching an exception and ignoring it
364 2012-09-10 12:30:19 <sipa> gavinandresen: if that's the case, i'd say it's a dealbreaker for 0.7.0, but easily fixed
365 2012-09-10 12:31:58 <gavinandresen> ok... can you easily fix it?
366 2012-09-10 12:36:28 <jgarzik> amiller: very cool.  will check it out.
367 2012-09-10 12:37:00 <jgarzik> gavinandresen sipa: it sounds like there is sufficient build support for IPv6 in some cases, but it fails at runtime.  Just need an additional check for failure, then re-bind with AF_INET
368 2012-09-10 12:45:39 <jgarzik> amiller: you removed the send buffer.... hmmm
369 2012-09-10 12:46:26 <jgarzik> amiller: without pausing the message processing or other measures, that means the OS will drop (and/or truncate) messages once the send buffer fills up
370 2012-09-10 12:46:49 <jgarzik> amiller: which was largely the reason for the send buffer in the first place ;p
371 2012-09-10 12:48:10 <jgarzik> rofl
372 2012-09-10 12:48:18 <jgarzik> spam in my inbox: "Meetups this week with: IBD Enthusiasts, Zumbalicious, Tennis Players, and others"
373 2012-09-10 12:48:39 <jgarzik> 
ACTION never knew that IBD enthusiasts existed.  Guess some people _like_ long, slow downloads!

374 2012-09-10 12:48:56 <gmaxwell> Irritable bowel disease enthusiasts?
375 2012-09-10 13:44:29 <ne0futur> 
ACTION looking for partners and coders to build a free and open source, long lasting public service around bitcoin, for now for the price and feed tools on https://bitcointalk.org/index.php?topic=68205 and later with also graphing tools and mor

376 2012-09-10 13:46:18 <kreal> what is endorse?
377 2012-09-10 13:46:32 <kreal> endorsecount
378 2012-09-10 13:48:55 <ne0futur> ah forget it
379 2012-09-10 13:49:09 <kreal> ok
380 2012-09-10 13:49:20 <ne0futur> its from http://coderwall.com/
381 2012-09-10 13:49:26 <kreal> just though it was maybe similar to https://bitcoinspeech.com/trust
382 2012-09-10 13:50:14 <ne0futur> my codereall team : http://coderwall.com/team/neoskills
383 2012-09-10 13:50:51 <ne0futur> just some kind of coder social network based on your github achievements
384 2012-09-10 13:51:21 <ne0futur> http://coderwall.com/neofutur
385 2012-09-10 13:51:31 <kreal> ohrighty.
386 2012-09-10 13:52:09 <kreal> well if you pay my food, I'll be more then happy to help me.
387 2012-09-10 13:52:13 <kreal> you probably know what I can do.
388 2012-09-10 13:52:24 <kreal> s/me/you
389 2012-09-10 13:52:28 <ne0futur> eh I paid 20 btc for https://github.com/Trasp/GoxCLI
390 2012-09-10 13:53:02 <ne0futur> and a few btcs to zapsoda for his work on https://github.com/neofutur/MyBestBB
391 2012-09-10 13:53:32 <kreal> well then.
392 2012-09-10 13:53:38 <ne0futur> concerning the public service on p.b.gw.gd you ll just get partners links
393 2012-09-10 13:53:56 <kreal> I'l return in 10 days.
394 2012-09-10 13:53:59 <ne0futur> SEO and traffic, and possibly donations
395 2012-09-10 13:54:13 <kreal> currently building a mobile site for a hotel chains.
396 2012-09-10 13:54:15 <kreal> meh work.
397 2012-09-10 13:54:58 <kreal> just finished their new site.
398 2012-09-10 13:55:03 <kreal> http://www.arp-hansen.dk/  <-- pretty neat no ?
399 2012-09-10 13:59:19 <ne0futur> http://validator.w3.org/check?uri=http%3A%2F%2Fwww.arp-hansen.dk%2F&charset=%28detect+automatically%29&doctype=Inline&group=0
400 2012-09-10 13:59:35 <ne0futur> kreal: not so bad, I seens much worst validation
401 2012-09-10 14:16:31 <amiller> hey jgarzik
402 2012-09-10 14:16:45 <amiller> there are three behaviors you might want for this, i'll show you all three of them if you like
403 2012-09-10 14:16:47 <jgarzik> amiller: Whoops, sorry for the drop-out.  2.5 yo caused a cascading home networking failure ;p  I may have missed messages.
404 2012-09-10 14:17:04 <amiller> nah i buffered indefinitely and waited for your return :p
405 2012-09-10 14:17:19 <jgarzik> amiller: ok shoot
406 2012-09-10 14:17:31 <amiller> so i meant to replace my 'send' with 'sendall' and that's the one i think with the best semantics
407 2012-09-10 14:17:39 <amiller> what happens is that the thread will block if the os buffer is full
408 2012-09-10 14:18:00 <amiller> but it won't interfere with any other threads
409 2012-09-10 14:18:25 <amiller> the alternative (the way you did it before) is to buffer unboundedly in ram
410 2012-09-10 14:19:08 <amiller> we can also make a potentially large ram buffer and then throw an exception if the buffer fills up (but you may as well just use the os buffer for that)
411 2012-09-10 14:20:19 <amiller> so it's 1) if send doesn't complete because buffer is full, then through an exception 2) block the thread if the os buffer is full or 3) build an arbitrarily large external buffer
412 2012-09-10 14:20:22 <amiller> i like 2)
413 2012-09-10 14:20:32 <kreal> ne0futur, didn't make the html, just the booking form :)
414 2012-09-10 14:21:08 <BlueMatt> does matthew mitchell come on here/is he here?
415 2012-09-10 14:25:35 <kreal> _ma
416 2012-09-10 14:39:10 <jrmithdobbs> BlueMatt: your auto test thing is p cool, first time i've submitted a pull since you set that up
417 2012-09-10 14:45:00 <BlueMatt> jrmithdobbs: thanks, still need to do the github integration stuff... https://github.com/blog/1227-commit-status-api
418 2012-09-10 14:48:16 <jgarzik> amiller: Well the simple solution is RAM buffer + simply disconnect if the peer is misbehaving, and somehow (by bug, network misfortune or design) causing the buffer to grow too large
419 2012-09-10 14:48:33 <jgarzik> amiller: or stall read, another popular solution
420 2012-09-10 14:48:40 <jgarzik> standard flow control
421 2012-09-10 14:49:04 <jgarzik> amiller: but blocking is just fine, too.  I merely did not see handling in the code.
422 2012-09-10 14:49:34 <jgarzik> amiller: looked like the code was directly calling the OS syscall, in a non-blocking mode
423 2012-09-10 14:49:44 <amiller> yeah, that was my mistake - it is there now (send vs sendall)
424 2012-09-10 14:50:46 <jgarzik> amiller: ok
425 2012-09-10 14:51:00 <jgarzik> amiller: I would like to make your greenlets version the official pybond
426 2012-09-10 14:51:14 <jgarzik> amiller: need to figure out how to do http serving for JSON-RPC though
427 2012-09-10 14:52:12 <amiller> jgarzik, sure, it should be mostly orthogonal
428 2012-09-10 14:52:45 <amiller> i'll help you make the greenlet version of whichever http thing you're willing to use
429 2012-09-10 14:54:32 <jgarzik> amiller: check out git HEAD of pybond
430 2012-09-10 14:55:06 <jgarzik> amiller: that imported pynode's httpsrv recipe, which is asyncore-based.  pynode's RPC code is tested to be compliant with bitcoin's JSON-RPC, so it would be useful to reuse, if possible.
431 2012-09-10 15:01:45 <amiller> jgarzik, okay interesting, async_chat uses most of the python SimpleHTTPRequestHandler framework
432 2012-09-10 15:01:54 <amiller> as far as i know gevent can do that, for example in this test http://gevent.googlecode.com/hg/greentest/test_ssl.py
433 2012-09-10 15:02:51 <amiller> how should i test httpsrv?
434 2012-09-10 15:03:30 <jgarzik> amiller: curl --user user --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }' http://127.0.0.1:10301/
435 2012-09-10 15:03:53 <jgarzik> amiller: --user, password and port parameters come from settings{}
436 2012-09-10 15:09:42 <amiller> jgarzik: i get the following from line 263:   AttributeError: 'cStringIO.StringO' object has no attribute 'len'
437 2012-09-10 15:14:05 <jgarzik> amiller: hmmm, I don't see where it looks at len directly
438 2012-09-10 15:14:09 <jgarzik> amiller: are you using python3?
439 2012-09-10 15:14:28 <amiller> oh - no, python2.7
440 2012-09-10 15:14:31 <amiller> i don't think you are either though
441 2012-09-10 15:15:05 <amiller> https://github.com/jgarzik/pybond/blob/master/httpsrv.py#L263
442 2012-09-10 15:16:59 <jgarzik> amiller: appears to be return SimpleHTTPServer.SimpleHTTPRequestHandler.send_head(self) ?
443 2012-09-10 15:17:30 <amiller> line 263: size = f.len
444 2012-09-10 15:17:59 <jgarzik> amiller: yes... but what is f ?
445 2012-09-10 15:18:25 <amiller> i'm on commit aeb095d5, is that most recent?
446 2012-09-10 15:18:55 <amiller> (apparently, f is a cstringio.stringio)
447 2012-09-10 15:21:32 <jgarzik> amiller: aeb095d50d88ce564181de97756077ad331d6fb3 is most recent, yes
448 2012-09-10 15:21:39 <jgarzik> amiller: maybe I am blind and not reading the code
449 2012-09-10 15:22:11 <jgarzik> amiller: f = self.send_head()
450 2012-09-10 15:22:34 <jgarzik> amiller: and self.send_head() returns the value returned by SimpleHTTPServer.SimpleHTTPRequestHandler.send_head(self), yes?
451 2012-09-10 15:23:33 <amiller> jgarzik, i agree with all that yes
452 2012-09-10 15:24:08 <jgarzik> amiller: and SimpleHTTPServer creates f with "f = open(path, 'rb')"
453 2012-09-10 15:24:15 <jgarzik> amiller: thus, I do not see how it can be a cStringIO
454 2012-09-10 15:27:15 <jgarzik> amiller: and, hmmm, besides...  I am overriding that particular method
455 2012-09-10 15:27:36 <jgarzik> amiller: so perhaps your problem is only seen when testing httpsrv.py directly, rather than via rpc.py?
456 2012-09-10 15:27:51 <amiller> jgarzik, that could be, i am definitely just running httpsrv directly
457 2012-09-10 15:28:57 <jgarzik> amiller: I think that might be it.  There are some rpc-specific hacks in httpsrv's do_POST, and rpc overrides handle_data very intentionally, because the default httpsrv does not work
458 2012-09-10 15:29:07 <jgarzik> amiller: default httpsrv assumes file serving, which we do not do
459 2012-09-10 15:29:49 <jgarzik> amiller: our httpsrv assumes we can gobble up all POST data into a memory buffer
460 2012-09-10 15:30:27 <jgarzik> amiller: which is fine... HTTP requests should never be > 16MB or something large like that.  HTTP(JSON-RPC) responses might be large.
461 2012-09-10 15:31:27 <amiller> jgarzik, i think i would prefer to use bottle.py rather for this part rather than trying to port httpsrv
462 2012-09-10 15:31:58 <jgarzik> amiller: feel free to replace httpsrv in its entirety.
463 2012-09-10 15:31:59 <amiller> bottle.py is the lightest weight of the lightweight frameworks, it is literally one file https://github.com/defnull/bottle/blob/master/bottle.py
464 2012-09-10 15:32:00 <amiller> okay
465 2012-09-10 15:32:27 <amiller> jgarzik, well my reservations are that i'm probably going to mess up the buffer semantics the first few times and i'm not totally sure how to test this stuff thoroughly
466 2012-09-10 15:32:29 <jgarzik> amiller: the main requirement is http 1.1 keepalive/pipelining
467 2012-09-10 15:33:46 <jgarzik> amiller: as long as you preserve JSON-RPC 2.0 batch support and standard JSON-RPC, HTTP/1.1 keepalive, the remaining underlying details are unimportant to me.
468 2012-09-10 15:35:55 <amiller> jgarzik, hrm, pipelining seems not to work with gevent, or with libevent generally
469 2012-09-10 15:36:19 <jgarzik> amiller: bosh, sure it does
470 2012-09-10 15:37:22 <jgarzik> amiller: it will queue up in the OS buffers, if nothing else
471 2012-09-10 15:38:02 <jgarzik> amiller: pipelining is simply sending requests 1, 2, 3, and then looking for responses 1, 2, 3.
472 2012-09-10 15:38:32 <jgarzik> amiller: and keepalive is merely some state machine logic, to reset HTTP parsing rather than closing the connection after data transmit
473 2012-09-10 15:43:58 <jgarzik> amiller: proxies, web frameworks and WSGI tend to continually reset the connection between the client and JSON-RPC server (pynode/pybond).  Certainly that can be coded-around, but it becomes a huge pain, making it simpler to simply embed an http server.
474 2012-09-10 15:48:41 <amiller> ah, gevent.pywsgi supports HTTP 1/1 keepalive because it doesn't use as much of libevent's server
475 2012-09-10 15:52:11 <jgarzik> amiller: oh, libevent's server.  yeah, that sucks ;p
476 2012-09-10 15:52:40 <jgarzik> amiller: wholly inadequate
477 2012-09-10 15:52:47 <jgarzik> libevent's event framework is just fine
478 2012-09-10 15:53:00 <jgarzik> the http server is basically a cheap demo, not industrial strength, however
479 2012-09-10 15:53:14 <amiller> gevent.pywsgi is the way to go then
480 2012-09-10 15:53:31 <jgarzik> amiller: does that require a separate wsgi server?
481 2012-09-10 15:53:47 <jgarzik> amiller: I rather prefer a single-process design
482 2012-09-10 15:54:11 <jgarzik> well, single "binary".  it can fork or thread all it wants.
483 2012-09-10 15:54:41 <amiller> nah single process
484 2012-09-10 15:55:33 <jgarzik> ok, good
485 2012-09-10 16:26:01 <gavinandresen> sipa wumpus jgarzik gmaxwell : I organized some thoughts on OP_DROP at  https://bitcointalk.org/index.php?topic=108423
486 2012-09-10 16:26:49 <gavinandresen> TD might be interested, too....
487 2012-09-10 16:40:55 <jgarzik> gavinandresen: colored coins are an interesting concept
488 2012-09-10 16:41:21 <jgarzik> gavinandresen: but as you say in the post, I don't see anything as reliable or secure as simply signing with the transaction
489 2012-09-10 16:44:43 <gmaxwell> meh. For a basic bond all you need is coloring.  There are cases you can construct where you need bound data. I'm still generally not in the fan of speculative enablement. God knows if you'll actually get the required stuff correct, and there is a risk from unintended applications.
490 2012-09-10 16:46:06 <gavinandresen> gmaxwell: speculative design is good, though, right?  First step:  talk about.  Then implement it.  Then test it.  Then roll it out to production ....
491 2012-09-10 16:46:23 <gmaxwell> gavinandresen: sure but you should be talking about the applications, not the blockchain behavior.
492 2012-09-10 16:46:32 <gmaxwell> Then the applications will tell you what the behavior needs to be.
493 2012-09-10 16:46:40 <gavinandresen> Ok:  I want refund addresses with my transactions.  There's the application.
494 2012-09-10 16:47:09 <gavinandresen> (note that is already being done via hacks, aka SatoshiDice's extra txout with a specific value trick)
495 2012-09-10 16:47:17 <kakobrekla> hmm, i dont see "File", "Settings" and "Help" option on ubuntu like on windows?
496 2012-09-10 16:47:21 <gmaxwell> gavinandresen: you just posted the correct way to handle that in that recent thread. Adding that as auxilory data is inferior becuase it gums of the privacy model.
497 2012-09-10 16:47:52 <gmaxwell> If you're having a transaction then you _must_ already have a communications channel, so you can provide a refund address.
498 2012-09-10 16:49:04 <kakobrekla> seriously, how do i encrypt my wallet via gui on ubuntu
499 2012-09-10 16:49:40 <gmaxwell> kakobrekla: did ubuntu's crazy gui move everything to the ubuntu button or something? (like mac?)
500 2012-09-10 16:49:41 <gavinandresen> gmaxwell: mmm... yes, if there's a secure communication channel between me and the entity I'm paying then that works. I think.
501 2012-09-10 16:50:39 <kakobrekla> http://shrani.si/f/3L/AU/3pn4rV5i/wtf.png
502 2012-09-10 16:50:59 <kakobrekla> i dont know how to open settings :(
503 2012-09-10 16:51:25 <gmaxwell> gavinandresen: if there wasn't you couldn't have gotten their address to pay to securely. And, even if you go down the 'but its one way' route, you could sign a message with all the input addresses in your txn and send a 'refund here for txn1234' via p2p network (if we allowed that), and still avoid adding any data in the blockchain.
504 2012-09-10 16:51:54 <gmaxwell> (and I do think it's an excellent tradeoff to carry more p2p cruft, esp if nodes could opt out, in order to avoid the same cruft in the chain where it must be stored forever)
505 2012-09-10 16:52:40 <gmaxwell> In the refund case you don't care if there could be multiple messages (non-uniqueness), since you can just pick any if they create more thain one.
506 2012-09-10 16:52:47 <gavinandresen> gmaxwell: I'm still worried about the "I sign transaction" .... time passes ... "I sign metadata"  gap.  Gaps like that are where protocols are broken.
507 2012-09-10 16:53:15 <gavinandresen> (and reversing the order of operations doesn't help)
508 2012-09-10 16:53:16 <gmaxwell> gavinandresen: then make a new on the wire transaction format that sends both as a unit but doesn't put the metadata in the blockchain.
509 2012-09-10 16:54:18 <gmaxwell> Doing TXN metadata via p2p but not in the chain sounds like an excellent compromise to keep things out of the chain that don't really need to be in it. .. though meh on the privacy implications of doing this via p2p.. since you can't encrypt for the recipent only.
510 2012-09-10 16:54:36 <gmaxwell> (unless we define a new address type that packs in a public key for messaging)
511 2012-09-10 16:55:54 <gmaxwell> (in that case it's easy, you do ECDH with the two public keys (one from a scriptsig and the one in the address) and use that to encrypt the extended-address, and privacy is preserved because you don't even mention what remote public key you're using)
512 2012-09-10 16:56:19 <gmaxwell> (the extended address' pubkey wouldn't even be the same as the addresses' it would just be asscoiated)
513 2012-09-10 16:56:28 <gavinandresen> gmaxwell: I don't see how an on-the-wire transaction format helps.  If the transaction can be extracted separately from the metadata, then the transaction can be spent without the metadata being recorded anywhere... which is an attack I want to avoid.
514 2012-09-10 16:56:35 <jgarzik> Ultimately there are use cases where the most natural, simple, reliable and secure method is to bundle the data and metadata together in a signed package.  All these other solutions are more work and more complexity to achieve the same thing.  So look at the long term programmer incentives, too...
515 2012-09-10 16:56:37 <gmaxwell> sipa, if he were active right now, would point out that a simple direct payment protocol covers all this even more simply.
516 2012-09-10 16:56:54 <justmoon> gavinandresen: I posted an idea here: https://bitcointalk.org/index.php?topic=108423.0
517 2012-09-10 16:56:57 <gavinandresen> I agree 100% that we should implement a direct payment protocol.
518 2012-09-10 16:57:19 <kakobrekla> gmaxwell, fuck yeah its on the top of the screen thanks
519 2012-09-10 16:57:38 <gmaxwell> gavinandresen: a metadata hash in the txn doesn't provide that 'you don't have the metadata' property either???
520 2012-09-10 16:57:49 <gmaxwell> er 'you must have the metadata'
521 2012-09-10 16:58:43 <gmaxwell> jgarzik: the simplest thing is whatever is implemented already;  otherwise there would be no talk of this blockchain gibberish. Working with the blockchain is by far one of the most complicated ways of doing messaging ever devised. It's 'easy' because the software is already there.
522 2012-09-10 16:59:09 <gavinandresen> justmoon: ACK, reading...
523 2012-09-10 16:59:51 <amiller> gmaxwell, this payment protocol that has a communications channel - it has to be an authenticated communications channel unless you have a hash in the blockchain
524 2012-09-10 17:00:13 <gmaxwell> jgarzik: yea I thought of mentioning that above, and bytecoin (IIRC) has written a bunch about basically that. (ECDH pairing for pubkeys) but it prevents multisig, forces pubkey disclosure, etc.
525 2012-09-10 17:00:48 <gmaxwell> amiller: no, it doesn't.
526 2012-09-10 17:01:21 <gmaxwell> amiller: first (1) you already have one or your wouldn't have an address to pay to.. ignoring that (2) you sign the metadata with the same key that signed the transaction, so you know the author of the metadata is the same as the transaction.
527 2012-09-10 17:01:50 <gmaxwell> amiller: which does leave the possiblity that you don't happen to recieve the metadata. Though thats also possible if the only thing in the chain is a metadata hash.
528 2012-09-10 17:02:14 <gmaxwell> If you put the metadata directly in the chain, then we go down the slippery slope of large amounts of non-txn data...
529 2012-09-10 17:02:46 <amiller> let me pick apart one of those
530 2012-09-10 17:03:07 <gavinandresen> justmoon: nice, that works.
531 2012-09-10 17:04:02 <MC1984> you cant make slippery slope arguments, thats my job
532 2012-09-10 17:04:04 <amiller> gmaxwell, gavin pointed out that the property you want for that metadata is that it's 'immutable', written once. You're saying you can replace that with 'identity' based cryptography and signatures
533 2012-09-10 17:04:10 <amiller> but it's not the same goal at all
534 2012-09-10 17:04:21 <gmaxwell> amiller: Gavin gave an application. A refund address.
535 2012-09-10 17:05:06 <gavinandresen> refund address may be a bad example.  a multisig contract, with multiple parties committing to some contract language that can be independently verified is probably better.
536 2012-09-10 17:06:04 <gmaxwell> gavinandresen: you can use key agreement for that, like justmoon suggested. Effectively you make the hash of the contract part of (one of) the payment keys.
537 2012-09-10 17:06:27 <gmaxwell> That doesn't work for multisig generally because you want the keys to all be secret from each other.. but the contract wouldn't be secret.
538 2012-09-10 17:06:30 <gavinandresen> gmaxwell: cool, so lets make that happen.
539 2012-09-10 17:08:08 <gmaxwell> eroding my position somewhat, I should perhaps point out that using compressed public keys in scriptsig basically saves enough space to fit in a hash and still be the same size as a regular transaction.
540 2012-09-10 17:09:26 <gmaxwell> (I'm generally much less negative about adding aux data in scriptsigs than scriptpubkeys; but still strongly of the view that we should be careful that we don't indirectly encourage bloating the chain out of ignorance or lazyness when superior non-bloating alternatives are possible; the choices we make here will have an impact for as long as bitcoin exists)
541 2012-09-10 17:10:44 <gmaxwell> e.g. most cases for "I want to attach data to a txn" don't require that the data be unique, only that it be provably from the same author of the txn, and most would strongly benefit from making that data private.
542 2012-09-10 17:10:46 <amiller> gmaxwell, "forward integrity" is the reason why you shouldn't use a signature when what you really want is a hash
543 2012-09-10 17:11:16 <gmaxwell> amiller: For the return address forward integrity is not required or even especially desirable.
544 2012-09-10 17:11:55 <gmaxwell> and key agreement for contract terms gives you forward integrity. (the terms are effectively baked into the address the funds were sent to)
545 2012-09-10 17:12:11 <gavinandresen> Well, if the merchant sends to the user-provided refund address they probably DO care about forward integrity, they don't want users to be able to claim "that's not MY refund address"
546 2012-09-10 17:12:32 <gmaxwell> gavinandresen: they have a copy of the data they used, so they can _prove_ to anyone that it was a valid return address.
547 2012-09-10 17:13:15 <gmaxwell> "if you don't want the sender picking and choosing where they return, don't write multiple binding messages for a single transaction" ... besides, the problem exists even when its bound so long as the transactions happen before confirmation.
548 2012-09-10 17:13:49 <gmaxwell> E.g. you write two payments (a double spend), the recipents returns based on the first.. but the second is what actually ends up in the chain.  (e.g. presuming they returned instantly because you sent the wrong amount)
549 2012-09-10 17:13:54 <gavinandresen> ok, so lets say we go the key agreement route.  What code do we need to write?
550 2012-09-10 17:16:47 <gmaxwell> An interface mostly.  The key agreement itself is just multiplying two ECDSA points, which is just a call to the existing functions.  The idea is that you have a message, which gets combined with an existing key.. which creates a new key/address.  Anyone can perform the same operations, and to redeem you need the message.
551 2012-09-10 17:17:09 <gmaxwell> I guess figuring out the interface would require fleshing out the application some.
552 2012-09-10 17:17:19 <gavinandresen> right.  So you're sending me bitcoins with some metadata.  What does bitcoind on our two machines do?
553 2012-09-10 17:17:48 <gavinandresen> (lets start getting specific about where the metadata is stored, how communication happens, etc)
554 2012-09-10 17:18:45 <gavinandresen> I'm pushing because if we don't get a good solution, people will say "fuck it, here's an OP_DROP transaction with 800 bytes of metadata, I'll pay the frickin fee to Eligius and be done."
555 2012-09-10 17:18:52 <Luke-Jr> gavinandresen: re reject reasons: how about reject(strReason, nDoS, strDebugLogDetails, ???) ?
556 2012-09-10 17:19:10 <amiller> gmaxwell, suppose i make a purchase using my hot-wallet address A, but I want my refund to go to cold-wallet address B, and my key for B is offline
557 2012-09-10 17:19:21 <amiller> this is an example where forward integrity is crucial
558 2012-09-10 17:19:27 <gmaxwell> amiller: ... no it isn't.
559 2012-09-10 17:19:48 <amiller> what i want is that if my hot-wallet privkey A gets stolen, my refund is still safe at B
560 2012-09-10 17:19:49 <gmaxwell> amiller: you sign with the key that makes the transaction, which is by definition online, thats how you know its bound.
561 2012-09-10 17:20:08 <gmaxwell> Ah, interesting point.
562 2012-09-10 17:21:00 <gmaxwell> gavinandresen: I tell you about it, via some out of band channel (there are lots of choices), you addmetadataaddr address/pubkey "metadata" (or metadata hash). Keep in mind I said the keyagreemnt was useful for the contract case. I don't think it's the right thing for return addresses.
563 2012-09-10 17:22:08 <gmaxwell> gavinandresen: "fuck it, here's an OP_DROP transaction with 800 bytes of metadata,"  eligius won't mine that (or at least it won't if it happens more than once). And of course,  avoiding the 'fuck it, I'll op_drop' is why I'm encouraging being very conservative in making op_drop standard... so people don't widely deploy features that depend on it in stupid ways.
564 2012-09-10 17:22:35 <gmaxwell> A single party making an effort to peer with or agree with a miner isn't a big deal.  Blockchain.info just putting it into their webclient is.
565 2012-09-10 17:25:21 <gavinandresen> gmaxwell: ok. A concrete straw-man proposal is what I'm looking for.
566 2012-09-10 17:27:51 <gmaxwell> gavinandresen: For which application, though?  We need to be concrete about the application first, because different applications have different ideal solutions.
567 2012-09-10 17:30:24 <gavinandresen> gmaxwell: I'd say the applications that we've already seen people hacking around:  providing a refund address if you're using a shared wallet.  And attaching a public message to a transaction.
568 2012-09-10 17:31:16 <jgarzik> attaching a hash to a transaction
569 2012-09-10 17:31:20 <gavinandresen> gmaxwell: I'd like it to be generic enough that lots of interesting applications can be built, like private messages between sender and receiver.
570 2012-09-10 17:31:51 <gavinandresen> gmaxwell: ... and I think those interesting applications CAN be built if we can get an immutable hash attached to a transaction, as jgarzik says
571 2012-09-10 17:33:04 <gavinandresen> (e.g. private message from receiver back to sender can easily be done if the metadata includes my public gpg key and, maybe, my email address)
572 2012-09-10 17:33:28 <gavinandresen> (private message the other way can be done if we've got a payment protocol so I get the recipients public key, etc etc)
573 2012-09-10 17:33:30 <gmaxwell> gavinandresen: That doesn't work unless you have a cannel to get the metadata to the other end. If you have that you can just send the same metadata signed with the scriptsig's keys.
574 2012-09-10 17:34:08 <gavinandresen> gmaxwell: hmm?  gpg key plus email address is enough to send me a private message.
575 2012-09-10 17:34:50 <gavinandresen> gmaxwell: encrypt that bit of metadata with the recipient's public key and that opens up secure, private communication
576 2012-09-10 17:35:23 <gmaxwell> You don't have the recipents public key, not with any existing address type.
577 2012-09-10 17:35:34 <gavinandresen> right, I agree we need a payment protocol.
578 2012-09-10 17:36:14 <gmaxwell> And what did this buy?  If instead you have a minor addition to signmessage that lets you pick a transaction as the 'address' to sign with, you can use that same communication channel to do the binding.
579 2012-09-10 17:36:49 <gmaxwell> And it's been widely used for this??? it's how eligius updates user preferences.
580 2012-09-10 17:37:36 <gavinandresen> gmaxwell: as amiller says, it buys forward integrity
581 2012-09-10 17:39:04 <gmaxwell> which doesn't matter for any of the example applications, ?? amiller's refund address, but the binding doesn't buy forward integrity in what is probably the most common refund case??? zero confirm refunds??? which will only become more common as confirmation times increase.
582 2012-09-10 17:39:32 <jgarzik> it rather nicely ties together bond and payment ;p
583 2012-09-10 17:40:04 <gmaxwell> (And you can use the key agreement for forward integrity where required)
584 2012-09-10 17:40:31 <gmaxwell> As far as how that works, you'd have an addkey function that takes an existing address/pubkey and the message that you're binding.
585 2012-09-10 17:40:42 <gmaxwell> The sender would send to pubkey+message.
586 2012-09-10 17:41:14 <gavinandresen> ... and somehow tell the recipient message.  Lets figure out the somehow.
587 2012-09-10 17:41:35 <gmaxwell> gavinandresen: you have to have a communication channel in the committed case too. There isn't any escaping that.
588 2012-09-10 17:42:00 <gavinandresen> Right, that's the hard bit that is making people use the blockchain as the communication channel.  Lets fix that.
589 2012-09-10 17:42:26 <gmaxwell> It's either a payment protocol or something p2p. In the case of the key-agreement, you have the recipents pubkey, so we can actually do the p2p securely.
590 2012-09-10 17:43:21 <amiller> gmaxwell, it's okay to handwave over a p2p thing if the p2p thing consists strictly of:   get(hash(x)) -> x
591 2012-09-10 17:43:42 <gavinandresen> Ok, so do we do the payment protocol first or the p2p?  p2p has the advantage of working if you're firewalled.
592 2012-09-10 17:43:59 <gmaxwell> So, I think sipa would keep pointing to a payment protocol. But to be honest here, there are just too many bitcoin users who want to particpate at arms length with criminal activities and won't directly connect to anyone.
593 2012-09-10 17:44:07 <jgarzik> https://github.com/jgarzik/pybond does P2P :)
594 2012-09-10 17:44:47 <gavinandresen> p2p disadvantage is DoS vulnerability... are there any other advantages/disadvantages ?
595 2012-09-10 17:44:55 <gmaxwell> I think both should be done. But I think only p2p will get sufficent adoption in terms of deflecting people from blockchain storage.
596 2012-09-10 17:46:12 <gmaxwell> If the p2p goes hand in hand with our existing transactions it could be made dos resistant that way. E.g. each p2p push requires a valid transaction going with it. (identified by a common pubkey in the message and scriptsig)
597 2012-09-10 17:48:28 <gmaxwell> I think the p2p might look like... flooded, with filtering by leaf nodes. and the message would be txid:in_point, dest pubkeyhash, Encrypt(message, ecdh(destpubkey,txid:in_point's first pubkey))
598 2012-09-10 17:48:29 <justmoon> the scheme I described could be extended where you calculate q = HASH(E(M)) and then send to P_Q_ = P_M_ * q, give the DHT node P_M_ and E(M) and it will know that the ciphertext you've given it is associated with that transaction
599 2012-09-10 17:48:51 <justmoon> E() is an encryption function based on ECDH presumably
600 2012-09-10 17:49:01 <gavinandresen> gmaxwell: cool, that's the type of concrete straw-man-proposal I was hoping to see
601 2012-09-10 17:49:18 <gmaxwell> (If someone wants to talk about a DHT, be my guest, but I'm less clear how to make it robust and reliable as blockchain communications)
602 2012-09-10 17:50:26 <gavinandresen> gmaxwell: so before I send you bitcoins, I need your full public key. So either there's a new type of bitcoin address or a payment protocol for that.
603 2012-09-10 17:50:50 <gmaxwell> gavinandresen: right, you need a pubkey for this. I don't know a way around that. :(
604 2012-09-10 17:51:15 <gmaxwell> you can do things without it, but not encrypted things, and not forward integrity.
605 2012-09-10 17:51:34 <justmoon> well, if we assume a DHT the mapping pubkeyhash -> pubkey could be stored in there, it could also be part of the blockchain if the address has been used before
606 2012-09-10 17:51:36 <gmaxwell> I think any proposal that uses public communications for metadata is very important to have encrypted for legal stupidity:  I really don't want someone's explicit drug transaction memos in cleartext on my disk.
607 2012-09-10 17:51:59 <gavinandresen> gmaxwell: well, I think we should move to hierarchical determistic keys anyway, so either there's a new bitcoin address for those or a payment protocol for those....
608 2012-09-10 17:51:59 <justmoon> gmaxwell: agreed
609 2012-09-10 17:52:26 <gmaxwell> justmoon: we should not generally encourage address reuse, and really what I'd prefer is an address that has a regular [hash address, p2sh, etc]+pubkey and the pubkey is only used for messaging.
610 2012-09-10 17:52:45 <justmoon> gmaxwell: the address won't be reused
611 2012-09-10 17:52:58 <gmaxwell> justmoon: that was in reference to "it could also be part of the blockchain"
612 2012-09-10 17:53:07 <justmoon> my point stands
613 2012-09-10 17:53:12 <gmaxwell> But in general we don't want to break people's p2sh multisign security just to get messages.
614 2012-09-10 17:53:23 <justmoon> sure, that's true
615 2012-09-10 17:53:40 <justmoon> although I would say, it's not impossible that there will be shared secret based multisig
616 2012-09-10 17:54:30 <gmaxwell> but we don't have to. The address could be a payment address plus a pubkey for the messages. It could also potentially be encoded in a URL for direct payments.
617 2012-09-10 17:54:43 <justmoon> as for "no address reuse" - what I suggested is using the address once to "initialize it" the actual transactions are later dependent on the metadata hash, as long as that's hard to guess the transactions can't be associated with the address
618 2012-09-10 17:55:06 <gmaxwell> justmoon: you are not helping my goal of not adding excess immortal data to the blockchain. :P
619 2012-09-10 17:55:28 <justmoon> true
620 2012-09-10 17:56:03 <gmaxwell> and not exposing the pubkey has security properties that I'd rather not break. (it makes bitcoin have a degree of resistance to high complexity ECDSA breaks)
621 2012-09-10 17:58:07 <justmoon> the pubkey that is actually used to send money wouldn't be exposed
622 2012-09-10 17:58:16 <justmoon> until the money is respent of course
623 2012-09-10 17:58:43 <justmoon> I'm starting to talk about several different schemes now though
624 2012-09-10 17:59:24 <justmoon> this statement was regarding the version where the pubkey is communicated to the sender via some private channel
625 2012-09-10 17:59:45 <gmaxwell> justmoon: Ah I follow.  Still fails for "why the @#$ are you adding monetary irrelevant immortal data to the chain, for what is really an ephemeral communication"
626 2012-09-10 18:00:53 <justmoon> agreed
627 2012-09-10 18:01:12 <justmoon> maybe the solution lies with the aliases type proposals
628 2012-09-10 18:01:32 <gmaxwell> justmoon: Why don't you like just embedding the data in an 'address'?
629 2012-09-10 18:01:58 <gmaxwell> other than, I suppose, the addresses getting a big long.
630 2012-09-10 18:02:02 <gmaxwell> s/big/bit/
631 2012-09-10 18:02:27 <justmoon> I'm personally fine with that, was just brainstorming if we can avoid introducing a new address type
632 2012-09-10 18:03:05 <justmoon> @aliases: those proposals aimed at hiding long ugly bitcoin address from the end user, what is the current opinion on those proposals?
633 2012-09-10 18:03:09 <Eliel> hmm... there could be an universal return address scheme based on justmoon's idea. use the txid of the transaction to be returned to create a return address with the pubkeys used to sign the transaction originally.
634 2012-09-10 18:04:35 <gmaxwell> Eliel: no better than sending to that address.
635 2012-09-10 18:04:47 <gmaxwell> (Except perhaps you know what is being returned...)
636 2012-09-10 18:05:11 <gmaxwell> the case it solve there is, e.g. a shared wallet.
637 2012-09-10 18:05:14 <Eliel> gmaxwell: it is, even mixing webwallets can then easily detect whose money is coming in.
638 2012-09-10 18:05:24 <gmaxwell> oh.
639 2012-09-10 18:05:26 <gmaxwell> point!
640 2012-09-10 18:05:40 <gmaxwell> Hmmmmmmmmmmmmmmmmmmmmm!
641 2012-09-10 18:05:54 <Eliel> they can even add an invisible deposit address on each send to the user.
642 2012-09-10 18:05:59 <Eliel> for the return
643 2012-09-10 18:06:12 <Eliel> and that's all it'd take
644 2012-09-10 18:06:48 <gmaxwell> that has an elegance to it for sure!
645 2012-09-10 18:06:53 <justmoon> I'll leave you guys to it, good night all!
646 2012-09-10 18:07:01 <gavinandresen> Eliel: good idea.
647 2012-09-10 18:09:49 <gmaxwell> Eliel: makes it really really important to make txids non-malleable.
648 2012-09-10 18:10:02 <Eliel> aren't they already?
649 2012-09-10 18:10:11 <gmaxwell> No. :'(
650 2012-09-10 18:10:19 <gmaxwell> we're slowly working on that.
651 2012-09-10 18:10:30 <Eliel> ah, then it should be based on only the parts of the tx that are.
652 2012-09-10 18:10:47 <gavinandresen> Instead of using the txid could use hash(transaction with input scriptSigs emptied)
653 2012-09-10 18:12:19 <BlueMatt> need to think about clearing scriptPubKeys for non-SIGHASH_ALL
654 2012-09-10 18:13:49 <Eliel> it'll need some careful thinking how to do it with multisig or multiparty txs I guess :)
655 2012-09-10 18:16:44 <gmaxwell> gavinandresen: true.
656 2012-09-10 18:16:54 <gmaxwell> Eliel: yea, thats one problem with implicit behavior.
657 2012-09-10 18:17:01 <gmaxwell> And there are multiparty txn in the chain now.
658 2012-09-10 18:17:14 <gmaxwell> (I've been making them with people, if no one else)
659 2012-09-10 18:17:28 <gavinandresen> "I sent you the refund"  "I never got it"  "What version are you running?"  .... is the other problem with added implicit behavior
660 2012-09-10 18:17:47 <gmaxwell> gavinandresen: txn version... to flag it?
661 2012-09-10 18:18:43 <gavinandresen> gmaxwell: yeah, could do...  although the "please send any refunds to my cold wallet" is nice feature if it is explicit
662 2012-09-10 18:19:47 <gmaxwell> yes, though much better if that address is encrypted.
663 2012-09-10 18:20:22 <gmaxwell> which then goes back to that sketch of what we were talking about above.
664 2012-09-10 18:21:10 <gavinandresen> gmaxwell: yes. What do we still need to figure out to make the sketch a reality?
665 2012-09-10 18:22:09 <gmaxwell> whats an accepeable way to encode these extended addresses that have a [normal addr][pubkey][perhaps some optinal flags like how much you should [ay] e.g. payment protocol lite.
666 2012-09-10 18:22:42 <Eliel> also, an added bonus for this implicit method is that you can get nice statistics about how often funds get returned :)
667 2012-09-10 18:23:08 <gmaxwell> Eliel:  thats bad not good. hurts privacy.
668 2012-09-10 18:23:24 <gmaxwell> perhaps acceptable but not a good thing.
669 2012-09-10 18:24:54 <gavinandresen> gmaxwell: it feels like HD wallets aught to be used-- e.g. I get a public key + chaincode, then send payment to that address M and encode metadata with M/something ...
670 2012-09-10 18:26:09 <phantomcircuit> HD Wallets?
671 2012-09-10 18:26:12 <gmaxwell> right, this is really a special case of hdwallets... where the chaincode is replaced or suplimented by the message hash. Oh crap. right the forward integrity isnt compatible with p2sh outputs.
672 2012-09-10 18:26:17 <phantomcircuit> feels like dirty advertising
673 2012-09-10 18:26:20 <gavinandresen> phantomcircuit:   https://en.bitcoin.it/wiki/BIP_0032
674 2012-09-10 18:26:24 <phantomcircuit> should rename bitcoin HD MONEY!!
675 2012-09-10 18:26:32 <gmaxwell> e.g. we can do messages + any payment address but no forward integrity.
676 2012-09-10 18:26:51 <gmaxwell> or forward integrity but it must be a pay to address. (or pubkey, I suppose)
677 2012-09-10 18:26:52 <phantomcircuit> neat
678 2012-09-10 18:27:12 <gmaxwell> will need to ponder a bit.
679 2012-09-10 18:28:57 <phantomcircuit> thought
680 2012-09-10 18:29:06 <phantomcircuit> why define the branching logic like this
681 2012-09-10 18:29:20 <phantomcircuit> instead of simply having a new chain and having the client handle that?
682 2012-09-10 18:29:59 <gmaxwell> phantomcircuit: as a way to hand off branches without invalidating backups. also to just formally define what is possible... I don't know that we'd bother implementing creating all those cases.
683 2012-09-10 18:30:50 <phantomcircuit> hmm
684 2012-09-10 18:30:56 <phantomcircuit> i guess that would be useful
685 2012-09-10 18:31:20 <gmaxwell> e.g. it would be useful to give a pubkey branch to anyone who is paying you often.
686 2012-09-10 18:33:50 <jgarzik> amiller: any luck with httpsrv replacements?
687 2012-09-10 18:41:51 <Eliel> what's the average size of a transaction?
688 2012-09-10 18:42:13 <Eliel> ah, nevermind, blockexplorer knows
689 2012-09-10 18:43:41 <Eliel> except it doesn't work :/
690 2012-09-10 18:47:54 <gmaxwell> Eliel: a 1 in 2 out from a coinbase is something like 192 bytes.
691 2012-09-10 18:48:30 <gmaxwell> this is why I'm spazzy about adding 'just' 64 bytes of transaction irrelevant opdrop. It's a 1/3rd increase.
692 2012-09-10 18:52:44 <gmaxwell> 226 for spending from a compressed pubkey keyhash.
693 2012-09-10 18:53:33 <gmaxwell> obviously it's smaller with one output.
694 2012-09-10 18:57:44 <gmaxwell> (and if the op_drop is in the scriptpubkey thats 64 bytes op_drop added on top of ~22 bytes of txout set)
695 2012-09-10 18:59:29 <gmaxwell> so for a future txout tree full mode we're talking about something like 2.5x the storage (ignoring overhead) if OP_DROP in pubkeys were used in half the ouputs.
696 2012-09-10 19:00:28 <gmaxwell> almost 5x if used in all outputs.
697 2012-09-10 19:01:24 <midnightmagic> gmaxwell: by the by, sipa's leveldb ultraprune branch does indeed load the entire blockchain inside of about 3 hours on my slow machines.
698 2012-09-10 19:01:56 <helo> single core?
699 2012-09-10 19:02:02 <gmaxwell> midnightmagic: off network?
700 2012-09-10 19:02:14 <midnightmagic> quad-core, from a -connect=n.n.n.n
701 2012-09-10 19:02:23 <midnightmagic> (LAN address)
702 2012-09-10 19:02:29 <gmaxwell> midnightmagic: were you testing the threaded version?
703 2012-09-10 19:03:09 <gmaxwell> midnightmagic: whats slow about that quad core?
704 2012-09-10 19:03:10 <midnightmagic> gmaxwell: Not unless it's threaded by default as of commitid 81cca96a8c14c93000f32b5186ccd94e1fe9831a (Sep 4)
705 2012-09-10 19:03:31 <gmaxwell> yea no, thats not threaded.
706 2012-09-10 19:03:32 <midnightmagic> gmaxwell: It takes something like 2 days to rebuild normally
707 2012-09-10 19:03:48 <gmaxwell> midnightmagic: 0_o .. drum memory?
708 2012-09-10 19:03:52 <gmaxwell> punchcard disk?
709 2012-09-10 19:04:03 <jrmithdobbs> haha
710 2012-09-10 19:04:10 <midnightmagic> gmaxwell: lol I've been telling you about this for like 9 months or something now turkey
711 2012-09-10 19:04:17 <jrmithdobbs> is it a quad prescott?
712 2012-09-10 19:04:33 <midnightmagic> it is a..  AMD Phenom(tm) II X4 965 Processor
713 2012-09-10 19:04:39 <gmaxwell> I did 6 full syncs while testing the BIP30 stuff in here the other day.
714 2012-09-10 19:05:04 <jrmithdobbs> ya i did a full sync to an e3 2650 in <6 hours over internet the other day
715 2012-09-10 19:05:14 <jrmithdobbs> which is pretty comporable hardware when aes isn't involved
716 2012-09-10 19:05:26 <Luke-Jr> gmaxwell: it's really not as painful as it used to be ???
717 2012-09-10 19:05:45 <jrmithdobbs> nah, it's gotten *much* better so long as you don't get unlucky and pick a pad peer, and if you do you just restart
718 2012-09-10 19:06:39 <Luke-Jr> hmm, my TNIAB setup doesn't like master :/
719 2012-09-10 19:06:54 <Luke-Jr> nm, bad luck I guess
720 2012-09-10 19:06:58 <gmaxwell> midnightmagic: whats the storage? my fast syncs are tmpfs. :P
721 2012-09-10 19:07:10 <jrmithdobbs> midnightmagic: find a peer you can trust to -connect or -addseed with speeds it up tremendously as well
722 2012-09-10 19:07:12 <gmaxwell> though it's nowhere near that on disk either.
723 2012-09-10 19:07:28 <jrmithdobbs> (don't even need to trust that it has anything but assloads of bandwidth up to the checkpoint!)
724 2012-09-10 19:07:30 <midnightmagic> gmaxwell: I don't have enough empty space for tmpfs, storage is just a single SATA2 7200 blah blah 500GB
725 2012-09-10 19:07:46 <gmaxwell> hm. what OS/fs?
726 2012-09-10 19:07:52 <midnightmagic> jrmithdobbs: I run like 10 bitcoind inside my network now, so all I need to do is pick one of them to sync from.
727 2012-09-10 19:08:20 <jrmithdobbs> gmaxwell: nah man, that e3 box is openbsd, slowest/most non-existant fs cache in a modern os and it still took <6 hours (I want to say <4 but I *know* it was less than 6)
728 2012-09-10 19:08:26 <midnightmagic> gmaxwell: Linux, Ubuntu 10.10, ext4.
729 2012-09-10 19:08:37 <jrmithdobbs> gmaxwell: but it's disk is an intel 320 so ...
730 2012-09-10 19:09:07 <midnightmagic> gmaxwell: So that's kernel 2.6.35-22-server in x86_64 mode.
731 2012-09-10 19:09:33 <jrmithdobbs> midnightmagic: did you try it with -connect= to see if that improved it?
732 2012-09-10 19:09:37 <gmaxwell> midnightmagic: so I have a quad core old core2 @2.8ghz with a 7200rpm 2tb raid1 disk... synced last time (About a month ago in a few hours)
733 2012-09-10 19:09:43 <midnightmagic> jrmithdobbs: That's the only thing I use to rebuild.
734 2012-09-10 19:09:46 <jrmithdobbs> midnightmagic: also, use -printtoconsole or explicitly set the log to be on a different disk
735 2012-09-10 19:09:55 <midnightmagic> jesus raid1 and you're faster than I am?
736 2012-09-10 19:09:57 <midnightmagic> grr
737 2012-09-10 19:10:08 <jrmithdobbs> (-printtoconsole is the only thing I can think I did much different than "normal")
738 2012-09-10 19:10:23 <gmaxwell> midnightmagic: what libdb version do you have?
739 2012-09-10 19:10:35 <jrmithdobbs> using 4.8.30 on mine, for comparison
740 2012-09-10 19:10:41 <midnightmagic> lemme check. 4.7
741 2012-09-10 19:11:04 <midnightmagic> hrm. I just noticed something..
742 2012-09-10 19:11:14 <jrmithdobbs> midnightmagic: apt-get install lidb48 or w/e the name is
743 2012-09-10 19:11:33 <midnightmagic> it's *possible* the cpus were throttled back.
744 2012-09-10 19:12:07 <jrmithdobbs> how much? it was only consuming about 40% (average) of a single core for IBD for me
745 2012-09-10 19:12:30 <midnightmagic> the cpuinfo reports 800MHz
746 2012-09-10 19:12:34 <jrmithdobbs> LOL
747 2012-09-10 19:12:52 <midnightmagic> I'm trying to determine whether it stays that slow and crappy during heavy load
748 2012-09-10 19:14:46 <midnightmagic> I mean it's not a huge deal, which is why I haven't really bothered to try to fix it. It's just a miner, unimportant in the long run so long as the gpu hashrates are there..
749 2012-09-10 19:16:01 <jrmithdobbs> midnightmagic: on my core2 macbook air with FDE with the blockchain (and everything bitcoin related) going into a aes256 disk image *on top of* that, it still takes <18 hours (and it's all bdb thrashing through the disk layers)
750 2012-09-10 19:16:15 <midnightmagic> sigh
751 2012-09-10 19:16:31 <midnightmagic> your experience is pretty much universal, that much I'm certain of.
752 2012-09-10 19:16:44 <midnightmagic> "faster than me"
753 2012-09-10 19:16:58 <midnightmagic> er.. "faster than I"
754 2012-09-10 19:49:20 <md2k7> why does pwalletMain->GetKey(id, key) return false on me? id came from CBitcoinAddress.GetKeyID(), which got an address I received coins to
755 2012-09-10 19:49:48 <md2k7> does that make sense or am I doing sth the wrong way?
756 2012-09-10 19:52:52 <md2k7> http://pastebin.com/LSxbQ6Y6
757 2012-09-10 19:56:23 <amiller> jgarzik, nah i got distracted, i'll probably do it tonight and show you tomorrow morning
758 2012-09-10 20:01:47 <sipa> amiller: the wallet is encrypted, maybe?
759 2012-09-10 20:02:22 <sipa> jrmithdobbs: my record for full blockchain sync is 22 minutes :)
760 2012-09-10 20:05:02 <sipa> eh
761 2012-09-10 20:05:10 <sipa> md2k7: ^ wallet is encrypted?
762 2012-09-10 20:08:28 <md2k7> sipa: nope