1 2013-05-28 13:37:20 <Mad7Scientist> currently 25 threads and 520mb used. going in and out of 100% cpu and being frozen
2 2013-05-28 13:38:14 <lianj> what version?
3 2013-05-28 13:38:42 <Mad7Scientist> 0.8.1
4 2013-05-28 13:42:32 <Mad7Scientist> http://pastebin.ca/2383907
5 2013-05-28 13:42:40 <Mad7Scientist> backtrace after attaching to the 100% cpu thread
6 2013-05-28 13:45:24 <Mad7Scientist> up to 567MB of ram used now
7 2013-05-28 13:47:10 <BlueMatt> Mad7Scientist: you are mining on it
8 2013-05-28 13:47:29 <Mad7Scientist> yes
9 2013-05-28 13:47:51 <Mad7Scientist> been mining for a while
10 2013-05-28 13:47:52 <sipa> ok you're continuously asking for work
11 2013-05-28 13:47:59 <sipa> it can't keep up
12 2013-05-28 13:48:05 <BlueMatt> if that is indeed the bt of the bad thread, then you are pegging rpc
13 2013-05-28 13:48:20 <Mad7Scientist> what about the memory leak?
14 2013-05-28 13:48:47 <BlueMatt> upgrade to 0.8.2
15 2013-05-28 13:49:11 <Mad7Scientist> is the problem fixed?
16 2013-05-28 13:49:27 <sipa> depends what you call problem
17 2013-05-28 13:49:29 <gavinandresen> Speaking of 0.8.2??? I'd like to tag rc3 as 0.8.2 final either today or tomorrow.
18 2013-05-28 13:49:49 <Mad7Scientist> the lockup + memory leak I'm having
19 2013-05-28 13:49:54 <michagogo> gavinandresen: Is that another gitian build?
20 2013-05-28 13:50:00 <sipa> there is no memory leak, but there have been significant improvements in how much memory os used
21 2013-05-28 13:50:01 <gavinandresen> michagogo: yes, it will be
22 2013-05-28 13:50:03 <sipa> lockup?
23 2013-05-28 13:50:12 <Mad7Scientist> 1.2GB is not a lek?
24 2013-05-28 13:50:17 <michagogo> Any actual changes besides the version number?
25 2013-05-28 13:50:34 <BlueMatt> high memory usage isnt /always/ a memory leak
26 2013-05-28 13:50:36 <Mad7Scientist> up to 576MB already
27 2013-05-28 13:50:50 <gavinandresen> Mad7Scientist: please install 0.8.2 and let us know if that fixes the problem
28 2013-05-28 13:50:51 <sipa> Mad7Scientist: is that actual memory ised (resident set) or just allocated?
29 2013-05-28 13:51:24 <Mad7Scientist> virt 1248MB res 581MB
30 2013-05-28 13:51:36 <sipa> ok, the res counts
31 2013-05-28 13:51:52 <BlueMatt> do you have lots of connections?
32 2013-05-28 13:51:53 <sipa> i've seen it go 700 or so
33 2013-05-28 13:51:58 <Mad7Scientist> 8 connections
34 2013-05-28 13:52:08 <BlueMatt> ehhhh...wat?
35 2013-05-28 13:52:13 <sipa> 800 even
36 2013-05-28 13:52:23 <sipa> BlueMatt: with 0.8.2
37 2013-05-28 13:52:25 <michagogo> Hmm, I went to check mine
38 2013-05-28 13:52:28 <Mad7Scientist> usually 200MB res is typical
39 2013-05-28 13:52:37 <michagogo> I'm not having bitcoin use any memory at all
40 2013-05-28 13:52:39 <sipa> not anumore
41 2013-05-28 13:52:44 <michagogo> :-P
42 2013-05-28 13:52:45 <BlueMatt> sipa: 700m res on 0.8.2?
43 2013-05-28 13:52:57 <sipa> BlueMatt: yes, more
44 2013-05-28 13:52:59 <BlueMatt> with < 500 conn?
45 2013-05-28 13:53:08 <BlueMatt> have you heap profiled it?
46 2013-05-28 13:53:59 <sipa> BlueMatt: 185 connections
47 2013-05-28 13:54:22 <sipa> but it seems correlated with mempoll growth
48 2013-05-28 13:54:23 <Mad7Scientist> it got to 1.2GB this morning
49 2013-05-28 13:54:24 <BlueMatt> have you heap profiled it? (and how big is your mempool?)
50 2013-05-28 13:54:26 <Mad7Scientist> I had to kill -9
51 2013-05-28 13:54:50 <BlueMatt> looks like its time to actually work on that mempool limiter stuff...
52 2013-05-28 13:54:56 <BlueMatt> or...is gavinandresen working on that yet?
53 2013-05-28 13:55:06 <sipa> BlueMatt: not profiled yet, and it's also not just head
54 2013-05-28 13:55:13 <gavinandresen> BlueMatt: not yet, need to finish payment protocol
55 2013-05-28 13:55:30 <sipa> BlueMatt: though i doubt other changes affect it
56 2013-05-28 13:56:40 <BlueMatt> sipa: I choose to blame mempool and pretend it just /cant/ be anything else
57 2013-05-28 13:56:55 <michagogo> lol
58 2013-05-28 13:57:08 <sipa> only 1690 poolsz
59 2013-05-28 13:57:29 <BlueMatt> ugg, well...needs profiling then
60 2013-05-28 13:57:39 <sipa> indeed
61 2013-05-28 13:58:15 <BlueMatt> 700m on 0.8.2...1.2G on 0.8.1 seems reasonable :(
62 2013-05-28 13:59:26 <Mad7Scientist> 200 is typical
63 2013-05-28 13:59:31 <michagogo> bitcoin-qt is drawing 159,204K "Memory (Private Working Set)" and 168,164K "Commit Size"
64 2013-05-28 14:01:45 <sipa> that's... nothing
65 2013-05-28 14:06:09 <jgarzik> BlueMatt: well I was about to dive into mempool
66 2013-05-28 14:06:13 <jgarzik> for child-pays-for-parent
67 2013-05-28 14:06:16 <jgarzik> gavinandresen, ^
68 2013-05-28 14:06:35 <BlueMatt> jgarzik: the branch I have pulls out all the relevent things for coin selection into its own class
69 2013-05-28 14:06:39 <BlueMatt> might be useful if you want to use that
70 2013-05-28 14:06:52 <Luke-Jr> jgarzik: a 3rd implementation???
71 2013-05-28 14:06:55 <BlueMatt> (you can throw away the start I made on cpfp)
72 2013-05-28 14:07:17 <BlueMatt> Luke-Jr: are the other 2 any good? (ie are they optimal -> if they are, probably not)
73 2013-05-28 14:07:36 <Luke-Jr> BlueMatt: mine isn't very good; petertodd's sounds good, but I didn't review his code
74 2013-05-28 14:07:44 <Luke-Jr> and IIRC sipa said he was planning to do one as well
75 2013-05-28 14:07:44 <sipa> mine is non-functional and dicontinued :)
76 2013-05-28 14:07:53 <Luke-Jr> ok, nm sipa's then :P
77 2013-05-28 14:08:03 <sipa> bluematt understands the problem better than i do
78 2013-05-28 14:08:21 <BlueMatt> jgarzik: up through "Let TransactionsForBlock handle everything" on my fees branch
79 2013-05-28 14:08:28 <gmaxwell_> "rpc call out to mechnical turk"
80 2013-05-28 14:08:30 <Luke-Jr> petertodd's, as I understand it, was doing everything up front, so CreateNewBlock had not much to do
81 2013-05-28 14:08:42 <Luke-Jr> eg, recalculating priorities only when they changed
82 2013-05-28 14:08:57 <BlueMatt> jgarzik: (the rest is mempool rewrite to determine fees from watching mempool)
83 2013-05-28 14:08:58 <jgarzik> ok
84 2013-05-28 14:09:08 <jgarzik> nod
85 2013-05-28 14:09:40 <BlueMatt> oh, and Ill tip you if you rebase it for me :p
86 2013-05-28 14:09:55 <BlueMatt> gmaxwell_: stacksort?
87 2013-05-28 14:10:10 <sipa> jgarzik: i thought you were going to work on statistics?
88 2013-05-28 14:10:38 <sipa> jgarzik: i have a brnach that adds a framework to compute actual memiry usage for stl data structures
89 2013-05-28 14:10:51 <jgarzik> sipa, yes but that moves slowly -- acquiring servers, setting up an entity that can legally accept donations, etc.
90 2013-05-28 14:11:03 <jgarzik> sipa, REAL WORK (i.e. programming) can be done in the meantime ;p
91 2013-05-28 14:11:19 <BlueMatt> programming data collection and thinking about how to do that?
92 2013-05-28 14:11:30 <sipa> jgarzik: i'm pretty sure that acquiring statistics is a lot of real work
93 2013-05-28 14:11:37 <helo> with child-pays-for-parent, is that something that would work in a scenario where someone's tx hasn't confirmed for two weeks, and an owner of (the privkey to) one of its outputs wants to hurry things up?
94 2013-05-28 14:11:46 <Luke-Jr> helo: yes
95 2013-05-28 14:11:57 <jgarzik> generating data is easy. collating data and visualizing is different, and will depend on what people want to see.
96 2013-05-28 14:12:15 <BlueMatt> actually, how do you plan on generating data/
97 2013-05-28 14:12:22 <sipa> jgarzik: anyway, i was planning on trying to map our memory usage through that, see if all observed usage is accounted for
98 2013-05-28 14:12:23 <BlueMatt> aside from the easy things like node counts and such
99 2013-05-28 14:12:28 <Luke-Jr> jgarzik: anyhow, don't let me dissuade you if there's something wrong with petertodd's CPFP :P
100 2013-05-28 14:12:47 <BlueMatt> ACTION doesnt see petertodd's cpfp branch
101 2013-05-28 14:12:58 <Luke-Jr> BlueMatt: it's part of his replace-by-fee thing
102 2013-05-28 14:13:00 <jgarzik> re cp4p, I'm curious how that would work for long trees
103 2013-05-28 14:13:15 <jgarzik> not just child-parent, but full grouping of an entire tree, under a single fee rate?
104 2013-05-28 14:13:22 <sipa> jgarzik: bluematt has done some nice complexity analysis of the problem
105 2013-05-28 14:13:25 <Luke-Jr> jgarzik: my ugly implementation does a lot of caching to avoid it being bad
106 2013-05-28 14:13:30 <jgarzik> i.e. what to do for child-child-parent
107 2013-05-28 14:13:40 <jgarzik> parent->{child,child}->{children} etc.
108 2013-05-28 14:13:50 <BlueMatt> jgarzik: essentially, you cant do it optimally or you end up with n^3 in the case of huge dep trees
109 2013-05-28 14:13:58 <Luke-Jr> jgarzik: basically I'm just adding the size of parents in to the child's calculations, and adding them atomically with the child if the child is selected first
110 2013-05-28 14:14:07 <BlueMatt> (n^3 in the sense that the current stuff without cpfp is n^2)
111 2013-05-28 14:14:14 <jgarzik> it is trivial to group TXs together
112 2013-05-28 14:14:18 <jgarzik> should they be charged together?
113 2013-05-28 14:14:24 <BlueMatt> jgarzik: it really depends
114 2013-05-28 14:14:34 <sipa> Luke-Jr: but what if you can't get confirmed together?
115 2013-05-28 14:14:43 <sipa> *they
116 2013-05-28 14:14:53 <Luke-Jr> sipa: then the child isn't considered anymore
117 2013-05-28 14:15:03 <Luke-Jr> the parent still exists as a candidate on its own standing
118 2013-05-28 14:15:19 <sipa> but did the parent get the child's fee benefit?
119 2013-05-28 14:15:24 <Luke-Jr> nope
120 2013-05-28 14:15:32 <sipa> ah, but you have to restart
121 2013-05-28 14:15:36 <Luke-Jr> ?
122 2013-05-28 14:15:50 <BlueMatt> Luke-Jr: I see no cpfp in petertodd's one replace-by-fee commit
123 2013-05-28 14:15:52 <sipa> you have tried adding parent+child, that faed
124 2013-05-28 14:16:07 <sipa> so now you put the larent back in the queue
125 2013-05-28 14:16:16 <sipa> bah typing on mobile
126 2013-05-28 14:16:18 <Luke-Jr> the sorting/adding code just sees the parent and child as two different transactions, and the lower-level adding code treats the child as parent+child if the parent is needed
127 2013-05-28 14:16:37 <Luke-Jr> BlueMatt: hmm, I think he said he'd be home this week.. maybe he can elaborate
128 2013-05-28 14:16:50 <Luke-Jr> sipa: the parent was never removed from the queue
129 2013-05-28 14:17:21 <sipa> but its prioroty changes now that the child can't be added with it?
130 2013-05-28 14:17:33 <Luke-Jr> sipa: the priority of the parent is the parent alone, always
131 2013-05-28 14:17:45 <sipa> huh
132 2013-05-28 14:18:01 <sipa> then how do you get child-pays-for-parent behaviour?
133 2013-05-28 14:18:12 <Luke-Jr> sipa: the priority of the child, which is considered for inclusion independently from the parent, takes a hit from the parent not being confirmed yet
134 2013-05-28 14:18:19 <BlueMatt> Luke-Jr: when the parent is added, do all the children get recomputed?
135 2013-05-28 14:18:23 <Luke-Jr> if the child is selected, any parents it needs are then added
136 2013-05-28 14:18:28 <Luke-Jr> BlueMatt: yes
137 2013-05-28 14:18:35 <BlueMatt> so...n^3?
138 2013-05-28 14:19:05 <sipa> ah, you work the other way around
139 2013-05-28 14:19:10 <Luke-Jr> BlueMatt: not sure, you may have hit a performance concern with that
140 2013-05-28 14:19:15 <jgarzik> It's really not that complicated
141 2013-05-28 14:19:24 <Luke-Jr> jgarzik: I'm sure it can be done better
142 2013-05-28 14:19:25 <BlueMatt> jgarzik: you're dreaming
143 2013-05-28 14:19:31 <jgarzik> just sort into groups, then sort the groups
144 2013-05-28 14:19:39 <BlueMatt> nope, not nearly that easy
145 2013-05-28 14:19:43 <Luke-Jr> jgarzik: that's more or less what I just said? :P
146 2013-05-28 14:19:43 <sipa> jgarzik: then you haven't thought about it enough
147 2013-05-28 14:20:19 <BlueMatt> jgarzik: my algorithm does essentially that, but there are some really fun cases that you have to handle efficiently...
148 2013-05-28 14:20:42 <Luke-Jr> anyhow, the big performance hit right now I think is that it needs the temporary CCoinsView that sipa removed in 0.8.2
149 2013-05-28 14:21:18 <sipa> Luke-Jr: also, atomic adding of groups of transactions that lotentially fail is a huge burden (while you should be able to just kbow that, the only thing tbat can fail is size or sigops limits)
150 2013-05-28 14:21:23 <Luke-Jr> the best performance optimization of course would be just recalculating priority order etc when it changes (accept to mempool etc) instead of every CreateNewBlock
151 2013-05-28 14:21:47 <BlueMatt> ummm...no?
152 2013-05-28 14:21:59 <BlueMatt> CreateNewBlock is called less than mempool adds, no?
153 2013-05-28 14:22:04 <Luke-Jr> of course, that complicates the implementation
154 2013-05-28 14:22:09 <BlueMatt> (and cs_main vs not)
155 2013-05-28 14:22:28 <jgarzik> definitely quite separate, locking/thread/performance/execution count -wise
156 2013-05-28 14:22:29 <Luke-Jr> BlueMatt: CNB has to calculate for every mempool tx every time right now
157 2013-05-28 14:22:29 <sipa> depends how incrememtal the recomputation can be
158 2013-05-28 14:23:04 <BlueMatt> Luke-Jr: ummm...that sounds broken
159 2013-05-28 14:23:08 <jgarzik> CNB is tough no matter how you look at it, from a performance perspective. It locks the entire mempool, for the entirety of the runtime.
160 2013-05-28 14:23:11 <Luke-Jr> mempool adds only need to add themselves to a multimap or whatever
161 2013-05-28 14:23:26 <jgarzik> Ideally you could pull a copy, then do work
162 2013-05-28 14:23:27 <sipa> jgarzik: cs main locking is an orthogonal issue
163 2013-05-28 14:24:04 <sipa> jgarzik: yes sure that would be a nice improvement, but right now cnb is slow just jn sequential execution time
164 2013-05-28 14:24:12 <sipa> addkng cpfp only makes that worse
165 2013-05-28 14:24:23 <BlueMatt> ACTION -> out (I have to say memory-limited mempool may be higher priority than cpfp too...)
166 2013-05-28 14:24:31 <sipa> yes
167 2013-05-28 14:24:38 <jgarzik> yah, lunchtime here too *poof*
168 2013-05-28 14:24:53 <sipa> breakfast sounds like a nice idea
169 2013-05-28 14:25:11 <BlueMatt> dinner would be good
170 2013-05-28 14:37:50 <TuxBlackEdo> I has a question
171 2013-05-28 14:38:04 <TuxBlackEdo> http://krebsonsecurity.com/wp-content/uploads/2013/05/Liberty-Reserve-et-al.-Indictment.pdf
172 2013-05-28 14:38:26 <TuxBlackEdo> this may be a dark question
173 2013-05-28 14:38:28 <TuxBlackEdo> but seriously
174 2013-05-28 14:38:45 <TuxBlackEdo> What makes bitcoin devs think that the us government won't go after them?
175 2013-05-28 14:40:00 <eps> i think at this point they are too public
176 2013-05-28 14:40:18 <TuxBlackEdo> this line on the document
177 2013-05-28 14:40:36 <eps> this is why the foundation was created i think
178 2013-05-28 14:40:37 <TuxBlackEdo> well
179 2013-05-28 14:40:53 <eps> so the devs have a public presence
180 2013-05-28 14:41:06 <eps> they can't just dissapear without people noticing
181 2013-05-28 14:41:26 <TuxBlackEdo> the government could say "you could just open a piece of software and have a bank account with the bitcoin network without any identifying information"
182 2013-05-28 14:41:55 <jgm> TuxBlackEdo: "bank account" means something, though, and it doesn't match what happens with bitcoin
183 2013-05-28 14:42:36 <TuxBlackEdo> yeah
184 2013-05-28 14:42:41 <TuxBlackEdo> same with libery reserve
185 2013-05-28 14:43:09 <TuxBlackEdo> they could call "opening the bitcoin client" akin to "starting a bank account"
186 2013-05-28 14:43:16 <TuxBlackEdo> read the indictment
187 2013-05-28 14:43:48 <TuxBlackEdo> It's not like they went after the exchanges of liberty reserve
188 2013-05-28 14:44:02 <TuxBlackEdo> they went after the developers
189 2013-05-28 14:44:05 <eps> TuxBlackEdo: it's not the same thing though, LR was effectively a bank
190 2013-05-28 14:44:06 <TuxBlackEdo> and founders
191 2013-05-28 14:44:16 <eps> and centralized
192 2013-05-28 14:44:23 <jgm> Can't say I'm particularly interested in reading the indictment, was just responding to your comment above. If the US government want to redefine bank account to mean anything that can be used to hold some nominal value then they're going to have to outlaw more things than just Bitcoin.
193 2013-05-28 14:44:29 <jgm> Pockets, for one.
194 2013-05-28 14:44:31 <eps> locking up the devs wouldn't actually achieve anything either
195 2013-05-28 14:44:34 <TuxBlackEdo> well, they went after the maintainers of the system
196 2013-05-28 14:44:36 <eps> bitcoin will still exist
197 2013-05-28 14:44:45 <TuxBlackEdo> sure
198 2013-05-28 14:44:53 <TuxBlackEdo> that's why satoshi deicded to remain anonymous
199 2013-05-28 14:45:09 <TuxBlackEdo> which is probably what every bitcoin dev should have done
200 2013-05-28 14:45:27 <eps> TuxBlackEdo: yeah the maintainers of a centeralized system, a company which they believed to be knowingly and directly benefitting from crimnal activity
201 2013-05-28 14:47:04 <buZz> did you see that satoshi got demasked?
202 2013-05-28 14:47:15 <eps> buZz: by ted nelson?
203 2013-05-28 14:47:21 <buZz> http://www.youtube.com/watch?v=emDJTGTrEm0
204 2013-05-28 14:47:23 <buZz> yes
205 2013-05-28 14:47:26 <buZz> THE ted nelson
206 2013-05-28 14:47:27 <buZz> :P
207 2013-05-28 14:47:32 <Vinnie_win> That video again...
208 2013-05-28 14:47:33 <eps> hardly definitive ;)
209 2013-05-28 14:47:37 <buZz> of course
210 2013-05-28 14:47:42 <buZz> he looks dementing
211 2013-05-28 14:47:47 <buZz> still makes valid arguments
212 2013-05-28 14:48:33 <eps> sure, it could be that guy
213 2013-05-28 14:48:41 <eps> he hasn't proved anything though
214 2013-05-28 14:53:11 <jouke> stupid question, but how do I "send" a payment request to the client?
215 2013-05-28 15:00:44 <sipa> jouke: i don't think that's implemented
216 2013-05-28 15:00:52 <sipa> you need a payment protocol server
217 2013-05-28 15:01:14 <sipa> well, gavin has a working test setup, but it's not part of the client itself afaik
218 2013-05-28 15:06:44 <jouke> Hmmm
219 2013-05-28 15:10:28 <mhanne> FYI, http://webbtc.com/relay_tx now displays details about validation errors. if you ever have a tx and don't know what's wrong with it, throw it in there and it'll tell you :)
220 2013-05-28 15:11:54 <michagogo> Ha, looks like brainwallet.org generates random strings now
221 2013-05-28 15:12:01 <michagogo> Rather than using chbs as the default
222 2013-05-28 15:12:08 <sipa> chbs?
223 2013-05-28 15:14:32 <wumpus> correct horse battery staple I suppose :p
224 2013-05-28 15:27:57 <midnightmagic> TuxBlackEdo: Oh good grief, did you see pp. 22? They (allegedly) even chatted amongst themselves about being an illegal, money-laundering operation that hackers use.
225 2013-05-28 15:30:59 <midnightmagic> TuxBlackEdo: Unless their english is really bad, which I suppose is a possibility.
226 2013-05-28 15:32:00 <midnightmagic> lol! They set up a portal for government to monitor the transactions for illicit activity but the data was mostly fake!
227 2013-05-28 15:32:16 <sipa> who is 'they' ?
228 2013-05-28 15:32:24 <midnightmagic> sipa: Liberty Reserve owners.
229 2013-05-28 15:32:46 <midnightmagic> I'm confident that unless the bitcoin devs have a whole lot of stuff they're hiding, the gov't can't go after them the same way they're going after LR.
230 2013-05-28 15:33:06 <sipa> let me get this straight: the gov asked them for a way to monitor LR transactions, and LR fed them fake data?
231 2013-05-28 15:33:23 <midnightmagic> sipa: Allegedly, according to the indictment that TuxBlackEdo linked to above.
232 2013-05-28 15:33:46 <sipa> if that is true, they are idiots...
233 2013-05-28 15:34:53 <midnightmagic> yeah, brutal. Internal communications between defendants, allegedly shows that the anti-money-laundering portal data was mostly "fake" and could be manipulated to hide data that LR did not want regulators to see.
234 2013-05-28 15:35:27 <jaakkos> ahh gotta love how LR ~= Bitcoin in media
235 2013-05-28 15:35:46 <midnightmagic> jaakkos: What media?
236 2013-05-28 15:35:48 <jaakkos> CIA is like "we can't shut bitcoin down" ages ago, then some centralized money laundering site gets shut down and media is like "This is what happens when a digital currency, like Bitcoin, gets shut down"
237 2013-05-28 15:35:54 <jaakkos> http://www.itechpost.com/articles/9817/20130527/what-happens-when-digital-currency-bitcoin-gets-shut-down.htm
238 2013-05-28 15:35:58 <jaakkos> http://www.cnbc.com/id/100769961
239 2013-05-28 15:36:06 <sipa> did the CIA ever say anything about btc?
240 2013-05-28 15:36:21 <jaakkos> i think they did
241 2013-05-28 15:36:44 <midnightmagic> jaakkos: Excellent examples. I'm not surprised.
242 2013-05-28 15:37:04 <jaakkos> or, fbi...
243 2013-05-28 15:37:58 <midnightmagic> jaakkos might be talking about the FBI internal doc that was cleaned up and reposted thanks to a bitcoin bounty, that quoted #bitcoin-otc specifically.
244 2013-05-28 15:38:12 <jaakkos> there is at least this www.wired.com/images_blogs/threatlevel/2012/05/Bitcoin-FBI.pdf
245 2013-05-28 15:38:40 <midnightmagic> I don't think CIA ever said anything about it, unless gavinandresen heard them say something all that time ago.
246 2013-05-28 15:38:50 <jaakkos> though i haven't read it, i actually trusted (!! damn) what someone said.
247 2013-05-28 15:39:03 <gmaxwell> jaakkos: fool
248 2013-05-28 15:39:38 <jaakkos> yes
249 2013-05-28 15:40:14 <sipa> midnightmagic: afaik, gavin's reaction to the question "what did the cia think?" after his presentation there was "the CIA does not tell you what they think
250 2013-05-28 15:40:18 <midnightmagic> gmaxwell: Dude have you read the indictment? It just gets better and better.. this stuff is better than a spy novel.. lol
251 2013-05-28 15:41:35 <midnightmagic> sipa: Ah, I seem to recall something like that. I recall being suspicious about that. I guess that was before I realised you guys are probably not crazy. :)
252 2013-05-28 15:44:10 <midnightmagic> The statutory allegations are a little chilling though. Many of those things could be said to be true about bitcoin as well, except the direct "knowingly" parts..
253 2013-05-28 15:45:26 <BlueMatt> midnightmagic: welcome to the us, if the govt wants to fuck you, they will fuck you
254 2013-05-28 15:47:30 <gavinandresen> There is no "the govt" ??? if somebody powerful wants to fuck you, then you're fucked. I think that is pretty much true everywhere, and has been true everyewhere forever.
255 2013-05-28 15:47:53 <BlueMatt> well, ok good point
256 2013-05-28 15:48:08 <gavinandresen> Probably less true now, here, than lots of other places.
257 2013-05-28 15:48:11 <midnightmagic> gavinandresen: Less so these days. If you touch a nobleman's daughter, he can't just run you through the heart with his sword these days in public and get away with it.
258 2013-05-28 15:48:22 <BlueMatt> well, yes, its not china or n korea
259 2013-05-28 15:48:38 <gmaxwell> midnightmagic: We just have different (more civilized???) ways of running you through now.
260 2013-05-28 15:49:09 <midnightmagic> gmaxwell: And yet it is still possible to stand up to a multi-million dollar company, and win, including in court, and reduce said company to, essentially, rubble.
261 2013-05-28 15:49:26 <midnightmagic> gmaxwell: I have a personal example of this as recent as 1980s.
262 2013-05-28 15:51:55 <jouke> gavinandresen: does your payment-request branch include a way to send paymentsrequests to? Like a call in debug to load url or something?
263 2013-05-28 15:52:44 <gavinandresen> jouke: two ways; pass a .bitcoinpaymentrequest-format-file on the command line, or the bitcoin: URI syntax is extended to fetch one.
264 2013-05-28 15:53:08 <gavinandresen> jouke: I'm debugging right now using server-side paymentrequest generating code at https://bitcoincore.org/~gavin/createpaymentrequest.php
265 2013-05-28 15:53:52 <gavinandresen> (actually, three ways, you can drag&drop a .bitcoinpaymentrequest file onto a running Bitcoin-Qt)
266 2013-05-28 15:54:02 <gavinandresen> (I think, haven't actually tested that yet)
267 2013-05-28 15:54:14 <nsh> midnightmagic, personal example requested please
268 2013-05-28 15:57:12 <jouke> gavinandresen: ok, thanks, I am allready using your sample php code (thanks, was really strugling to get protobuf working in php)
269 2013-05-28 15:58:52 <midnightmagic> nsh: A northern railway company's oil pipeline was forced to shut down (else risk a forced abandonment of the railway due to combined safety risk and legal railway land grant requirements) after they attempted to steal our livelihood. Now they are merely a passenger railway tourist company that runs a dock in a tourist trap. Their easy source of millions in fuel transport was completely destroyed thanks in essence to a single
270 2013-05-28 15:58:59 <midnightmagic> letter to a government regulatory body, after about 4 years of legal scholarship and research by a layman.
271 2013-05-28 15:59:21 <nsh> midnightmagic, fantastic
272 2013-05-28 15:59:36 <midnightmagic> The president of the company, before it was finished, had a heart attack from the stress and died.
273 2013-05-28 16:00:03 <midnightmagic> nsh: Poor people are used to strife and hardship. Rich people who are about to lose their money, are not.
274 2013-05-28 16:00:21 <nsh> as far as generalizations go... :)
275 2013-05-28 16:00:25 <midnightmagic> :)
276 2013-05-28 16:00:35 <midnightmagic> "in my experience"
277 2013-05-28 16:02:53 <midnightmagic> nsh: There are legal precedents in the BC Court of Appeals with our names on them right now, which nullified our contractual obligations after we discovered that the lease they were using to stomp on our necks was illegal.
278 2013-05-28 16:03:47 <nsh> in that regards the law is certainly a countervailing force against personally or corporately vested power
279 2013-05-28 16:04:05 <ProfMac> There is a pipeline going through tribal land in Red Lake Nation. Red Lake has always owned that land, it was not ceded to them in a treaty from the US, and they protect their sovreignty. They served an eviction notice to the pipeline company a month or so ago.
280 2013-05-28 16:04:07 <nsh> (where applied)
281 2013-05-28 16:04:12 <midnightmagic> nsh: It is why I still respect it. Occasionally, when it does work, it is.. fucking glorious.
282 2013-05-28 16:04:19 <nsh> indeed.
283 2013-05-28 16:04:24 <midnightmagic> ProfMac: Also glorious.
284 2013-05-28 16:06:09 <ProfMac> BP, on the other hand, was able to get Louisiana law enforcement to exclude Mac McClellan of Mother Jones from taking pictures of some public areas: "you don't need to see that."
285 2013-05-28 16:11:25 <michagogo> Hmm, is this a bug? Right-clicking on a transaction and clicking copy transaction ID appends "-000" to the txid
286 2013-05-28 16:11:31 <michagogo> daaef24f5ab868c89d2d6fa0f5ebc928f6f14831ee03a446b7053f83f74b272f-000, for example
287 2013-05-28 16:12:07 <sipa> the vout index perhaps?
288 2013-05-28 16:13:15 <michagogo> sipa: Hmm, maybe
289 2013-05-28 16:13:37 <michagogo> But it's annoying because I can't paste it into the console after getrawtransaction
290 2013-05-28 16:14:07 <michagogo> And it's not part of the txid...
291 2013-05-28 16:17:57 <midnightmagic> TuxBlackEdo: Whoahhhh! They're asking for $6 billion in forfeiture or repayment!
292 2013-05-28 16:19:51 <nsh> *Dr. Evil pinky finger*
293 2013-05-28 16:28:52 <michagogo> ;;tsltnb
294 2013-05-28 16:28:53 <gribble> Error: "tsltnb" is not a valid command.
295 2013-05-28 16:28:54 <michagogo> :-(
296 2013-05-28 16:29:09 <michagogo> How can I find out how long since there's been a testnet block?
297 2013-05-28 16:32:29 <gribble> Gribble - Bitcoin: <https://en.bitcoin.it/wiki/Gribble>; Using bitcoin-otc - bitcoin-otc wiki: <http://wiki.bitcoin-otc.com/wiki/Using_bitcoin-otc>; OTC Rating System - bitcoin-otc wiki: <http://wiki.bitcoin-otc.com/wiki/OTC_Rating_System>
298 2013-05-28 16:32:29 <nsh> ;;google gribble commands
299 2013-05-28 16:33:04 <nsh> not with gribble afaict
300 2013-05-28 16:33:43 <nsh> michagogo, there's: http://blockexplorer.com/testnet
301 2013-05-28 16:34:31 <michagogo> nsh: seems to be 1900 blocks behind
302 2013-05-28 16:39:29 <petertodd> re: replace-by-fee, child-pays-for-parent: the replace-by-fee code I have publicly released delibrately left out cpfp to ensure it wasn't suitable for mining yet to delay adoption
303 2013-05-28 16:40:10 <petertodd> basically without cpfp it is susceptable to DoS attacks, however it's actually trivial to just add a depth limit to the fee calculation, which I'm going to do in the next day or three
304 2013-05-28 16:41:20 <petertodd> my mempool rewrite with cpfp I'll put some more work into as well, but it's relatively complex and won't be ready for production as soon as a simplistic replace-by-fee implementation with limited recursive fee calc
305 2013-05-28 16:42:32 <petertodd> as for the dos attack: basically create a deep chain of unconfirmed, then replace the whole chain with a single replace-by-fee tx, if the delta fees paid by that tx are less than the fees required to broadcast that deep chain in the first place, you've created more network traffic than you paid fees for, potentially a lot more
306 2013-05-28 16:43:29 <petertodd> of course, in general accepting tx's to the mempool that are parts of really deep chains may not be a good thing anyway, nor does doing so reliably work; IE simplistic cpfp that solves the O(n^2) problem of calculating fees by just limiting recursion depth is probably fine
307 2013-05-28 16:45:45 <sipa> so you should calculate the delta fee on the entire replaced set?
308 2013-05-28 16:45:53 <petertodd> sipa: exactly
309 2013-05-28 16:49:16 <jgarzik> ACTION ponders
310 2013-05-28 16:49:36 <sipa> petertodd: then again, if you're going the fully-short-term-rational behaviour road (which i'm not sure i like just yet), a miner should probably accept any transaction that causes his net fee-per-byte to up in his mempool
311 2013-05-28 16:51:25 <petertodd> sipa: Well a side-effect of forcing the delta fee to pay for all children is that a replacement tx will never cause the net fees of your mempool to go down, and that side effect is mandatory to ensure you always pay for network bandwidth used.
312 2013-05-28 16:53:31 <sipa> but if you ignore a transaction because of too little (delta) fee, and another miner accepts it, you still have the bandwidth/validation costs
313 2013-05-28 16:53:39 <sipa> but without the income
314 2013-05-28 16:54:23 <petertodd> sipa: You have validation costs, because the tx isn't in your cache, but not bandwidth costs, because blocks are currently sent in full.
315 2013-05-28 16:54:39 <sipa> you received the transaction
316 2013-05-28 16:54:46 <sipa> you just didn't put it in your mempool
317 2013-05-28 16:54:47 <petertodd> In fact, come to think of it, the signature would be in the signature cache right?
318 2013-05-28 16:54:50 <sipa> ok, and you didn't relay it
319 2013-05-28 16:55:06 <sipa> "meh" i think validation costs will ultimately be UTXO set maintainance, not signature checking
320 2013-05-28 16:55:08 <petertodd> Yup, and by not relaying the problem isn't worse.
321 2013-05-28 16:55:26 <petertodd> Says the guy with magic signature checking code. :P
322 2013-05-28 16:56:02 <petertodd> Mainly I want to keep bandwidth down, and ensure that people are paying for bandwidth used. Everything else you can throw relatively cheap computer hardware at.
323 2013-05-28 16:56:53 <michagogo> Am I wrong to predict that http://blockchain.info/tx/b9bc3cd7981eac11671de0632127a96ce082c32ce5f1fe3599e280ea6a76f160 won't confirm?
324 2013-05-28 16:57:23 <sipa> petertodd: i'm just trying to follow your reasoning and see where it leads
325 2013-05-28 16:57:32 <Scrat> michagogo: you're wrong
326 2013-05-28 16:58:00 <sipa> petertodd: and it seems to me that in some cases, a selfish miner would accept a transaction into his mempool, even if it reduces total fee
327 2013-05-28 16:58:50 <petertodd> sipa: Total fee for the whole mempool, or what they can include in the block they are trying to mine?
328 2013-05-28 16:59:00 <Scrat> michagogo: seen several large ones that even had 0 fee confirm. it took up to a week but they did
329 2013-05-28 16:59:15 <michagogo> Scrat: Ones that created such huge amounts of pure dust?
330 2013-05-28 16:59:25 <Scrat> yes
331 2013-05-28 16:59:31 <sipa> petertodd: well, reduce total fee in the mempool, but increase what they can put in a block (because it increases fee per byte)
332 2013-05-28 16:59:35 <Scrat> let's see if I can dig one out for you
333 2013-05-28 17:01:46 <petertodd> sipa: Ah, yes, that's quite correct. However, relay nodes want to limit bandwidth, so the logic I've written meets the anti-flood requirements for a relay node, while being mostly optimal for a miner. Miners are welcome to change the logic further if it suits them.
334 2013-05-28 17:02:13 <petertodd> A large miner might, for example, want to run a public node for people to submit tx's to, and have different logic.
335 2013-05-28 17:03:19 <petertodd> Another subtly is that you probably want to take into account the presense of the tx is other miner's signature cache to account for increase/decreases in orphan rate.
336 2013-05-28 17:03:19 <sipa> petertodd: right
337 2013-05-28 17:04:27 <petertodd> And speaking of: Miners have an incentive to find out about new blocks created, and then until they think those blocks have propagated to >50% of the hashing power, mine much smaller blocks so that if they find the next block their block has the most chance of winning the race.
338 2013-05-28 17:04:51 <petertodd> (or just mine empty blocks on top of the previously block, empty to ensure their block would be invalid due to tx conflicts)
339 2013-05-28 17:05:05 <petertodd> A blockheaders via fast-UDP layer would work ideally for this.
340 2013-05-28 17:13:24 <jgarzik> petertodd, yes, it would...
341 2013-05-28 17:13:45 <jgarzik> petertodd, I worry a tiny bit about amplification and UDP
342 2013-05-28 17:14:27 <petertodd> jgarzik: Can't you just make the protocol have an initial setup phase where the other side acknowledges that it wants UDP packets?
343 2013-05-28 17:15:26 <jgarzik> petertodd, yes
344 2013-05-28 17:15:28 <nospinzy> any faucet owners here that i can speak with
345 2013-05-28 17:16:33 <MC1984> hey jgarzik
346 2013-05-28 17:16:59 <MC1984> looking at holepunching?
347 2013-05-28 17:17:03 <petertodd> jgarzik: Perfect. 512 byte UDP packets are also large enough to propagate whole blocks with a few tx's, a few dozen if txhashes are used.
348 2013-05-28 17:18:39 <jgarzik> petertodd, my ideal "expanded block header" would be block header + full tx id list
349 2013-05-28 17:18:49 <jgarzik> petertodd, where byte-count budget permits
350 2013-05-28 17:19:14 <jgarzik> (but full block is infeasible)
351 2013-05-28 17:19:15 <petertodd> Of course, it is perverse that nodes creating blocks that are large enough that some of the hashing power can't validate them will lead to even more blockspace pressure by other miners creating nearly empty blocks - the consequences with unlimited blocksizes and the large subsidy would be really bizzare.
352 2013-05-28 17:19:56 <petertodd> Leads to attacks too if people are building on blocks that they haven't validated, but that is rational miner behavior given the low chance of a block being created that is invalid.
353 2013-05-28 17:20:11 <jaakkos> oh my god this has got to be a troll http://www.businessweek.com/news/2013-05-28/liberty-reserve-indicted-in-alleged-money-laundering-scheme-1
354 2013-05-28 17:20:17 <jgarzik> petertodd, unlimited block size just means that the only people remaining on the P2P network are Goldman JPMC and HSBC ;p
355 2013-05-28 17:20:29 <BlueMatt> jaakkos: old news, read scollback
356 2013-05-28 17:20:33 <petertodd> jgarzik: Makes sense, how cheap is it to keep track of what tx's your peers have? Or just rely on them querying you?
357 2013-05-28 17:20:42 <jaakkos> BlueMatt: ah ;)
358 2013-05-28 17:20:59 <jgarzik> petertodd, correction, block header, coin base, txid list
359 2013-05-28 17:21:02 <petertodd> jgarzik: ...and Google with their new Blockchain Backup solution. :P
360 2013-05-28 17:21:08 <jgarzik> petertodd, under the theory that most have most TXs cached
361 2013-05-28 17:21:12 <BlueMatt> petertodd: we already do...
362 2013-05-28 17:21:41 <petertodd> jgarzik: Right, yeah, we know the coinbase is new... So allow for arbitrary tx or full tx, space permitting.
363 2013-05-28 17:21:58 <jgarzik> yep
364 2013-05-28 17:22:06 <petertodd> BlueMatt: I know, I'm asking how cheap that is. With UDP it would be sane to support many more than 8 peers.
365 2013-05-28 17:23:58 <BlueMatt> petertodd: you can get a few hundred connections on 1 GB memory pretty easily
366 2013-05-28 17:24:44 <jgarzik> petertodd, once you get much beyond ~4k or so, UDP starts fragmenting. _ideally_ you are under average MTU (as little as 1200 bytes). 512 bytes is the super-duper-safe UDP packet size chosen by some DNS implementations.
367 2013-05-28 17:24:47 <petertodd> BlueMatt: Not bad. In the long run a "I want to give x-MB and y-KB/s to the bitcoin network" setting is ideal.
368 2013-05-28 17:25:10 <jgarzik> "fragmenting" uselessly, I meant. Obviously it fragments before that.
369 2013-05-28 17:25:27 <BlueMatt> petertodd: ideally everything would be that simple...ideally never works out
370 2013-05-28 17:25:37 <dugo> giganew / easynews /eweka likely have the iron around to support unlimited blocks
371 2013-05-28 17:25:54 <petertodd> jgarzik: True, but IPv6 UDP requires fragmentation to be handled by the originator IIRC. Or is that done kernel-level?
372 2013-05-28 17:26:13 <petertodd> jgarzik: In any case, fragmentation is often broken by ICMP firewalling...
373 2013-05-28 17:26:16 <jgarzik> dugo, disk space is not the issue
374 2013-05-28 17:26:52 <dugo> jgarzik: guess how their peering servers keep track of which messages they have seen the past weeks
375 2013-05-28 17:27:27 <BlueMatt> dugo: yes, but somehow putting all our eggs in a few central servers...
376 2013-05-28 17:27:33 <jgarzik> dugo, I don't have to. I ran a Usenet news service in the 1990s.
377 2013-05-28 17:27:34 <BlueMatt> put basket in there somewhere
378 2013-05-28 17:27:38 <jgarzik> probably while you were still in school ;p
379 2013-05-28 17:27:55 <nsh> whatevs, i ran a usenet network from school
380 2013-05-28 17:27:57 <dugo> jgarzik: i ran one late 90s
381 2013-05-28 17:28:10 <dugo> we probably peered ;)
382 2013-05-28 17:28:11 <MC1984> doesnt UDP get pushed out by TCP congestion control
383 2013-05-28 17:28:13 <nsh> (not really, i made that up; i did print quite a few RFCs at school though)
384 2013-05-28 17:28:17 <jgarzik> spinne.com
385 2013-05-28 17:28:20 <jgarzik> was on the top 100
386 2013-05-28 17:28:28 <dugo> eu.net/kpnqwest
387 2013-05-28 17:28:43 <MC1984> which my mean nodes in homes may prop blocks slower?
388 2013-05-28 17:30:03 <petertodd> MC1984: Depends on a *lot* of factors.
389 2013-05-28 17:30:39 <MC1984> its a generally undesirable scenario though right
390 2013-05-28 17:31:17 <petertodd> MC1984: People running vast numbers of full-nodes in their homes is definitely desirable.
391 2013-05-28 17:31:22 <MC1984> im not going to aurgue against UDP transport though
392 2013-05-28 17:31:52 <sipa> MC1984: somewhat slower relaying nodes vs no such nodes at all... unsure
393 2013-05-28 17:32:05 <MC1984> i was going to suggest if anyone had looked at libutp, which i think has holepunching stuff in it too, but i bet thats a dumb suggestion
394 2013-05-28 17:32:27 <sipa> depends on the degree of selection of faster nodes
395 2013-05-28 17:32:31 <petertodd> MC1984: Speaking of, gmaxwell and lukejr and I were talking about adding code to the Bitcoin client for a "pooled-solo" mode where the miner builds the blocks, thus being a true miner, and the pool just keeps track of shares.
396 2013-05-28 17:32:56 <MC1984> i thought luke already had something like that
397 2013-05-28 17:33:02 <petertodd> MC1984: I'll post more tonight in the forums; I want to do a funding drive to at least be able to offer "thank-you" bounties to whomever makes it work.
398 2013-05-28 17:33:23 <petertodd> MC1984: That's the idea behind luke's GBT, but the whole solution hasn't been written yet.
399 2013-05-28 17:33:32 <petertodd> MC1984: Luke said he's interested in writing the code.
400 2013-05-28 17:33:47 <MC1984> that actually sounds like a significant improvement in affairs
401 2013-05-28 17:34:06 <MC1984> or to coin a phrase, a reduction in coercibility surface
402 2013-05-28 17:34:30 <petertodd> Absolutely. It would mean the worst a pool can do is steal funds, and in many cases, not even that. If it's widely used even a pool with >50% hashing power isn't a threat at all.
403 2013-05-28 17:34:50 <MC1984> then what of p2pool?
404 2013-05-28 17:34:55 <petertodd> Part of the effort needs to also be integrated tracking of share payouts to detect pool fraud.
405 2013-05-28 17:35:24 <MC1984> and how will you get poolops to agree to this
406 2013-05-28 17:35:26 <petertodd> MC1984: Good question. It's not to say p2pool becomes obsolete, but it does become less important.
407 2013-05-28 17:35:32 <gmaxwell> MC1984: we basically completely luke's original vision. Luke's prior thinking was more like the pool would be transparent and you could decide to mine there or not. Instead we propose the user make all the transaction/block decisions and the pool just coordinates pooling paying.
408 2013-05-28 17:35:56 <petertodd> MC1984: By getting miners to demand it - part of the effort needs to include the usual videos etc. advocacy once the code works.
409 2013-05-28 17:36:10 <MC1984> right
410 2013-05-28 17:36:17 <Luke-Jr> gmaxwell: well, one is easier to implement than the other :p
411 2013-05-28 17:36:47 <petertodd> Obviously for me one of the reasons I really like this idea is that by turning hashers into true miners, we make it clear that raising the blocksize degrades the decentralization of Bitcoin.
412 2013-05-28 17:37:16 <gmaxwell> meh. only if it does. :)
413 2013-05-28 17:37:24 <MC1984> petertodd you produced that blocksie vid right? Do you actually advocat 1MB forever, or just a conservative approach to the size
414 2013-05-28 17:37:28 <jaakkos> BlueMatt: oh, actually the businessweek one was not discussed before after all - they were the first one i found to directly confuse Bitcoin with LR, and further they talk about Bitcoin Inc. now they have modified the article a bit but Bitcoin Inc. is still there.
415 2013-05-28 17:38:09 <petertodd> MC1984: Very conservative. My threshold is "Can I easily mine anonymously?" - 1MB is already marginal with that respect, but technology changes over time so *maybe* in the future anonymous bandwidth will be easier to obtain.
416 2013-05-28 17:38:11 <Luke-Jr> ^ what gmaxwell said; whether it is a real problem or not, decentralziing things more is a good idea
417 2013-05-28 17:38:39 <MC1984> yes anonymous mining is important
418 2013-05-28 17:39:01 <MC1984> very conservative is my position too, an has been for about a year before that vid
419 2013-05-28 17:39:19 <petertodd> MC1984: Also, "Can I easily mine anonymously?" has to be true even if parties are trying to attack those mining anonymously, for instance by creating large blocks full of transactions unknown to the network.
420 2013-05-28 17:39:29 <MC1984> i thought it was a good vid, i see some people accusing you of shit though :/
421 2013-05-28 17:39:42 <Luke-Jr> ACTION probably won't know his position until block size becomes relevant for real
422 2013-05-28 17:40:01 <petertodd> MC1984: Thanks. It's a political issue, I'm not surprised I'm getting attacked.
423 2013-05-28 17:40:01 <sipa> still no fork?
424 2013-05-28 17:40:26 <MC1984> im not sure sure it is a political issue, if you think the whole thing trough logically
425 2013-05-28 17:40:28 <gmaxwell> Like lots of things in Bitcoin??? there are multiple complementary motivations. Making mining more decenteralized is in everyone's interest regardless of concerns about block size. We really need to get out of a situation where someone can blow up bitcoin by hacking two systems / people.
426 2013-05-28 17:40:36 <MC1984> moe like technical/engineering
427 2013-05-28 17:40:47 <MC1984> but i can see its become political and that alone makes me kinda sad
428 2013-05-28 17:41:26 <sipa> MC1984: the question is really about what we want bitcoin to be
429 2013-05-28 17:41:28 <petertodd> MC1984: See, the limitations are technical/engineering, but the acceptable tradeoffs in the face of those limitations are political. It's absolutely true the blocksize could be unlimited: VISA exists after all.
430 2013-05-28 17:41:35 <petertodd> sipa: +1
431 2013-05-28 17:41:42 <sipa> and there are many potentially useful outcomes
432 2013-05-28 17:41:50 <MC1984> i know what i want it to be
433 2013-05-28 17:41:57 <michagogo> What does "Error adding key to wallet (code -4)" mean?
434 2013-05-28 17:42:01 <michagogo> (what's code -4?)
435 2013-05-28 17:42:15 <sipa> michagogo: most likelythe key is already in there
436 2013-05-28 17:42:18 <MC1984> and the only "canonical" hist as to what it SHOULD be comes from what satoshi wrote in block 0
437 2013-05-28 17:42:32 <MC1984> but i dont even need that to have made my mind up about what it should be
438 2013-05-28 17:42:45 <petertodd> The political side of things is why at one point at the conference I was surrounded by a half-dozen very concerned investors from a country with capital controls.
439 2013-05-28 17:43:13 <MC1984> damn
440 2013-05-28 17:43:15 <sipa> MC1984: if there were no technical limitations, we could have a sysyem where both creating transactions and verifying the system were cheap/decentralized
441 2013-05-28 17:43:39 <sipa> unfortunately, technological constraints mean that favoring one side hurts the other
442 2013-05-28 17:43:47 <BlueMatt> can we be clear: increasing block size doesnt break anything, no matter what you want bitcoin to be
443 2013-05-28 17:43:50 <petertodd> sipa: Yup. Like if remote attesting TPM hardware was cheap and secure we wouldn't need mining at all...
444 2013-05-28 17:43:54 <BlueMatt> letting block size grow to infinity does
445 2013-05-28 17:44:09 <sipa> BlueMatt: all depends on what you tolerate
446 2013-05-28 17:44:20 <MC1984> i think that if we can keep a lid on blocksize sufficiently, and assuming tech and bandwidth increases, the equilibrium state of the system will tend towards decentralisation
447 2013-05-28 17:44:22 <sipa> i am not convinced infinite block sizes would be a real problem even
448 2013-05-28 17:44:26 <MC1984> thats how it seems in my head anyway
449 2013-05-28 17:44:28 <sipa> but i don't want to risk it
450 2013-05-28 17:44:37 <MC1984> the uncapped blocks people are loons
451 2013-05-28 17:44:41 <petertodd> BlueMatt: No we can't. Mining 1MB blocks anonymously and profitably is already somewhat dodgy, so any increase will make that harder.
452 2013-05-28 17:44:55 <BlueMatt> meh, getting miners to work over tor is up to people who design protocols like p2pool's
453 2013-05-28 17:44:55 <sipa> maybe
454 2013-05-28 17:45:08 <BlueMatt> there are technical issues (like what we saw with <0.8)
455 2013-05-28 17:45:24 <BlueMatt> petertodd: wrong
456 2013-05-28 17:45:27 <BlueMatt> just, wrong
457 2013-05-28 17:45:53 <sipa> i don't know: any increase of block sizes and utxo sizes hurts decentralization of validation
458 2013-05-28 17:45:56 <petertodd> BlueMatt: Sigh, there is no magical way to get 1MB of data out of a Tor connection in zero time.
459 2013-05-28 17:45:58 <gavinandresen> petertodd: you keep ignoring suggestions for how to scale up MASSIVELY with pretty simple changes.
460 2013-05-28 17:46:00 <BlueMatt> yes, if we go to 1GB blocks, sure things may break
461 2013-05-28 17:46:15 <petertodd> gavinandresen: I ignore them because they are suggestions that are broken in the face of attack.
462 2013-05-28 17:46:16 <sipa> to what extent that is acceptable is another matter entirely
463 2013-05-28 17:46:25 <BlueMatt> petertodd: there is no magical way to get 1MB of data out of ANY connection in zero time
464 2013-05-28 17:46:26 <sipa> gavinandresen: such as?
465 2013-05-28 17:46:49 <BlueMatt> petertodd: in any case, you dont have to get anywhere /near/ 1MB through instantly to mine
466 2013-05-28 17:46:51 <petertodd> BlueMatt: Exactly. So with a BW limited Tor, you want smaller blocks to keep profit reasonable.
467 2013-05-28 17:46:54 <BlueMatt> you already have the transactions
468 2013-05-28 17:47:14 <gavinandresen> such as broadcasting transactions over satellite, then anonymous miners connected through tor that just broadcast block + coinbase + listof(truncated transaction ids)
469 2013-05-28 17:47:16 <petertodd> BlueMatt: Assuming that you already have the transactions is a very big mistake.
470 2013-05-28 17:47:25 <sipa> assuming transactions are known to the p2p networks
471 2013-05-28 17:47:41 <BlueMatt> petertodd: meh, you have some subset of them
472 2013-05-28 17:47:42 <petertodd> gavinandresen: Yes, because satellites aren't subject to government takedown and are decentralized...
473 2013-05-28 17:47:56 <MC1984> a sattelite has a pretty high coercibility surface
474 2013-05-28 17:47:57 <jgarzik> :)
475 2013-05-28 17:48:01 <MC1984> satellite
476 2013-05-28 17:48:04 <BlueMatt> petertodd: Yes, because TOR isn't subject to government takedown and are decentralized...
477 2013-05-28 17:48:18 <gavinandresen> fine, replace satellites with "listen on a public network, broadcast over private"
478 2013-05-28 17:48:20 <BlueMatt> petertodd: go to china and tell me how well tor works
479 2013-05-28 17:48:20 <petertodd> The day satellites are a decentralized solution is the day I'm buying an underground bunker, for my protection!
480 2013-05-28 17:48:36 <marketanarchist> so i already talked about this earlier today but i thought i should try again at a better time. I have an idea for using an altcoin as a publishing media that could be used for things like decentralized markets. Basically what you do is have miners record the time that they recieved the previous block in the block that they are minting. Then you use this data to retarget max block size similarly to how bitcoin retargets PO
481 2013-05-28 17:49:07 <petertodd> gavinandresen: Those investors I were talking too actually brought that listen public solution up, and said they were scared as hell that people would believe it's an acceptable solution. You can't be seen running Bitcoin at all to be safe.
482 2013-05-28 17:49:35 <BlueMatt> petertodd: TOR doesnt work for that, either, btw
483 2013-05-28 17:49:36 <marketanarchist> discard blocks after like a month so that the blockchain never becomes overly cumbersome
484 2013-05-28 17:49:41 <sipa> petertodd: stop putting things in such a fatalistic way
485 2013-05-28 17:49:52 <marketanarchist> and give it a block reward that never deminishes
486 2013-05-28 17:50:14 <MC1984> i thought the general gist of the conf was that eeryone was tamping for regulation and stuff?
487 2013-05-28 17:50:18 <BlueMatt> petertodd: today, and for the conceivable future, there is no way to get on the internet anonymously for any long-term period
488 2013-05-28 17:50:21 <MC1984> the winkelvosses etc
489 2013-05-28 17:50:32 <marketanarchist> information published on this blockchain would be censorship resistant for the same reasons bitcoin is censorship resistant
490 2013-05-28 17:50:43 <marketanarchist> and there would be a legit market for getting infomration included in the blockchain
491 2013-05-28 17:50:45 <BlueMatt> marketanarchist: yes, and it easily is
492 2013-05-28 17:50:50 <gavinandresen> yes, if you want to solve the "decentralized, completely anonymous" problem then please start at the network level and deploy a nice p2p mesh network.
493 2013-05-28 17:50:52 <BlueMatt> marketanarchist: ehhh...no
494 2013-05-28 17:50:55 <petertodd> BlueMatt: Tor is an example, and it does work in China with some care.
495 2013-05-28 17:50:59 <jgarzik> MC1984, "everybody" being businesses who went to a business-focused payments conference ;p
496 2013-05-28 17:51:04 <jgarzik> selection bias
497 2013-05-28 17:51:04 <marketanarchist> no not anonymous
498 2013-05-28 17:51:09 <marketanarchist> not interested in that
499 2013-05-28 17:51:12 <marketanarchist> just censorsip resistance
500 2013-05-28 17:51:14 <gavinandresen> ??? and get back to me in a hundred years when you've managed to boil that ocean....
501 2013-05-28 17:51:14 <petertodd> BlueMatt: Stenography for example is another way, and again, it's much easier to use will smaller blocksizes.
502 2013-05-28 17:51:48 <BlueMatt> petertodd: anyway, you are putting this in such a fanatical frame that no one can agree with you, even those who share some of the principal that mining over tor should continue to be possible
503 2013-05-28 17:51:54 <MC1984> oh was it mainly a payments business conf? i havnt watched the talks yet
504 2013-05-28 17:51:56 <helo> marketanarchist: there's another conversation going on that i think is crossing wires with you a bit
505 2013-05-28 17:51:57 <MC1984> in fact i cant find them
506 2013-05-28 17:52:11 <gavinandresen> My big issue with the "PRIVACY AT ALL COSTS!!!!!" arguments is that it looks like most people aren't willing to pay for privacy. And who am I to say that they're idiots ?
507 2013-05-28 17:52:23 <petertodd> BlueMatt: Meh, I have $6k of donations from people who agree with me, and as jdillon pointed out it's from wallets with a lot of Bitcoins.
508 2013-05-28 17:52:38 <sipa> to me it's obvious: it is a compromise in any case, and increasing blocks and utxo size hurts decentralized validation in any case. that doesn't mean it's necessarily a problem, we just need to know what level is acceptable
509 2013-05-28 17:53:02 <petertodd> gavinandresen: How do you know that? I honestly don't know where most of the funds I have gotten in donatiosn come from.
510 2013-05-28 17:53:08 <BlueMatt> petertodd: yes, and some of the richest people in the us regularly donate to the tea party...we should put them in charge
511 2013-05-28 17:53:22 <BlueMatt> sipa: yes
512 2013-05-28 17:53:24 <BlueMatt> yes
513 2013-05-28 17:53:34 <sipa> andwhat is acceptable will depend on the economic value of the system we're protecting, and technological imlrovemts
514 2013-05-28 17:53:46 <sipa> *improvements
515 2013-05-28 17:54:27 <petertodd> sipa: Indeed. I represent the people who put the highest value on decentralization, (investors looking for a decentralized asset, among other others) Gavin and Mike seem to represent the people who put the lowest. (big public companies)
516 2013-05-28 17:54:56 <petertodd> sipa: I do not know what the majority of Bitcoin users want, because the group wanting decentralization is inherently difficult to measure.
517 2013-05-28 17:55:30 <MC1984> besids making best efforts to maintain in in general, why would devs be concerned with how much economic value theyre protecting?
518 2013-05-28 17:55:42 <petertodd> MC1984: pitchforks?
519 2013-05-28 17:55:46 <MC1984> markets gonna do wht they do
520 2013-05-28 17:56:32 <petertodd> Heh, well, the devs may find themselves irrelevant if people stop installing their software. That's why my video specifically advocates taking that step.
521 2013-05-28 17:56:59 <MC1984> well, im not sure theres call for that just yet
522 2013-05-28 17:57:01 <BlueMatt> thats why your video is insane and over-the-top
523 2013-05-28 17:57:03 <BlueMatt> but, no, seriously
524 2013-05-28 17:57:12 <BlueMatt> go make anonymous-coin
525 2013-05-28 17:57:19 <BlueMatt> with 1kb blocks or something else tiny
526 2013-05-28 17:57:24 <petertodd> BlueMatt: go make non-anonymous-coin
527 2013-05-28 17:57:43 <BlueMatt> I never said I was trying to, I still do think mining over tor should be possible
528 2013-05-28 17:57:52 <BlueMatt> but I dont think that is the /ONLY/ concern there is here
529 2013-05-28 17:57:52 <petertodd> BlueMatt: Bitcoin already is very close to anonymous coin, so don't change it. That's exactly what I'm advocating.
530 2013-05-28 17:57:53 <MC1984> i mean i expct gavin to alteast be somewhat conservative with the blocksize when it does get increased
531 2013-05-28 17:57:57 <MC1984> and it will
532 2013-05-28 17:58:35 <gavinandresen> The plan is to get data on how large or small a block we can support right now (both over tor and not), and then figure out what to do.
533 2013-05-28 17:58:36 <petertodd> MC1984: I don't. The business strategy of the companies paying his salary depends on transactions in the blockchain right now.
534 2013-05-28 17:58:51 <gavinandresen> There's been too much talking about theoretical what-ifs, and too little actual data-gathering.
535 2013-05-28 17:59:05 <BlueMatt> this too ^
536 2013-05-28 17:59:05 <MC1984> gavin is pretty independent the way things are set up afaik
537 2013-05-28 17:59:05 <sipa> agree on that
538 2013-05-28 17:59:37 <petertodd> Data-gathering is silly right now. Bitcoin hasn't been attacked seriously at the core, so we just don't know.
539 2013-05-28 17:59:48 <BlueMatt> thats the point
540 2013-05-28 17:59:58 <gavinandresen> ACTION is THIS close to putting petertodd on /ignore....
541 2013-05-28 18:00:03 <BlueMatt> set up a test network, simulate it, attack it, destry it
542 2013-05-28 18:00:04 <dugo> we can attack the hell out of testnet
543 2013-05-28 18:00:13 <BlueMatt> but measure it
544 2013-05-28 18:00:20 <gavinandresen> BlueMatt: exactly.
545 2013-05-28 18:00:28 <sipa> we do need to know how slow actual network propagation is in function of block sizes
546 2013-05-28 18:00:31 <phantomcircuit> gavinandresen, tor is a wildcard, relays/exits can limit bandwidth as low as 20 kbps and still be used
547 2013-05-28 18:00:37 <sipa> we need to know how fast new blocks can be constructed
548 2013-05-28 18:00:43 <BlueMatt> sipa: I plan on simulating exactly that in real-world network
549 2013-05-28 18:00:46 <sipa> in function of the size of memory pools
550 2013-05-28 18:00:51 <BlueMatt> only issue is I need to figure out processing time...
551 2013-05-28 18:00:51 <michagogo> gavinandresen: Is 0.8.2final going to have any changes from rc3?
552 2013-05-28 18:00:54 <MC1984> everyone just chill, didnt mean to start a shitstorm :(
553 2013-05-28 18:01:11 <phantomcircuit> MC1984, lol
554 2013-05-28 18:01:15 <sipa> gavinandresen: i saw another assert error at shutdown yesterday... i couldn't reproduce it though
555 2013-05-28 18:01:16 <MC1984> gavins intention to gather actual data on the issue instead of navalgazing about it sounds reasonable
556 2013-05-28 18:01:16 <petertodd> Look, figuring out that larger than 1MB blocks is tricky to mine on tor in the face of attack is really easy. I've done that calculation and I'm convinced.
557 2013-05-28 18:01:25 <phantomcircuit> MC1984 IS TRYING TO BREAK BITCOIN, GET HIM
558 2013-05-28 18:01:31 <helo> be sure you attack it in all the ways that anyone will ever think of to attack it
559 2013-05-28 18:01:50 <gavinandresen> michagogo: unless we find a showstopper bug in the next 12 hours or so, no, 0.8.2final will just be 0.8.2rc3 with the 0.8.2 tag applied (and re-gitian-built, because binaries change when there is a newer tag)
560 2013-05-28 18:02:07 <petertodd> gavinandresen: re: ignore, go right head
561 2013-05-28 18:02:07 <phantomcircuit> gavinandresen, i actually have reasonable data on propogation times for transactions, it takes about 60 seconds for all of the connectable nodes to broadcast a transaction in the extreme
562 2013-05-28 18:02:09 <petertodd> *ahead
563 2013-05-28 18:02:28 <gavinandresen> helo: ??? and let the perfect be the enemy of the good???. umm, no.
564 2013-05-28 18:02:30 <BlueMatt> phantomcircuit: very edge isnt all that important
565 2013-05-28 18:02:32 <sipa> phantomcircuit: and how does block size affect that
566 2013-05-28 18:02:33 <MC1984> phantomcircuit obviously im a planted agent of discontent :/
567 2013-05-28 18:02:34 <michagogo> gavinandresen: Ah, okay
568 2013-05-28 18:02:38 <petertodd> phantomcircuit: Right, so 5% orphan rate to 51%, roughly speaking.
569 2013-05-28 18:02:40 <BlueMatt> phantomcircuit: even someone mining over tor can get better connected than that
570 2013-05-28 18:03:00 <petertodd> phantomcircuit: 60s seems wrong, likely it's not linear.
571 2013-05-28 18:03:00 <phantomcircuit> sipa, it's hard to say exactly but i dont think it would have a significant impact
572 2013-05-28 18:03:04 <michagogo> gavinandresen: Okay, so hopefully tomorrow I'll build for you guys
573 2013-05-28 18:03:16 <BlueMatt> phantomcircuit: and I have a feeling its a veeeeerrry long tail on that
574 2013-05-28 18:03:21 <sipa> yes
575 2013-05-28 18:03:25 <sipa> 100% also dones't matter
576 2013-05-28 18:03:29 <phantomcircuit> BlueMatt, yeah it is the vast majority were < 5 seconds
577 2013-05-28 18:03:33 <sipa> 60% may
578 2013-05-28 18:03:36 <BlueMatt> yea, thats what I care about
579 2013-05-28 18:03:38 <petertodd> phantomcircuit: That sounds more right.
580 2013-05-28 18:03:56 <phantomcircuit> i could start that script again but it generates about 10 GB of compressed logs/day
581 2013-05-28 18:04:10 <petertodd> phantomcircuit: What exactly does the script do?
582 2013-05-28 18:04:29 <phantomcircuit> petertodd, records every message it can find from every peer it can connect to
583 2013-05-28 18:04:42 <sipa> if you do it from a single bitcoind, you risk a selection bias
584 2013-05-28 18:04:52 <phantomcircuit> sipa, hmm?
585 2013-05-28 18:04:59 <sipa> as you relay peer Ip addresses, your peers have an increased chance of being connected to eachother
586 2013-05-28 18:05:01 <phantomcircuit> most of the data was just a peer id, timestamp, messae id
587 2013-05-28 18:05:03 <sipa> more so than random nodes
588 2013-05-28 18:05:09 <BlueMatt> jgarzik: oh, re: getting nodes for your stuff: I can host one on the uni network
589 2013-05-28 18:05:16 <petertodd> phantomcircuit: Right. Can you get an idea of what tx's are in what pools mempools? It'd be interesting to see what the increased orphan rate is for blocks with non-relayed tx's - I've got two pools who want to do replace-by-fee that would like to know.
590 2013-05-28 18:05:18 <BlueMatt> jgarzik: it'l be officially under my research, so its ok
591 2013-05-28 18:05:43 <phantomcircuit> petertodd, doing even basic analysis of the data (like propogation times) took several hours
592 2013-05-28 18:05:52 <BlueMatt> (and even if it weren't...doesnt matter)
593 2013-05-28 18:06:17 <phantomcircuit> remember this was literally generating 10 GB/day 80% of which was approximately 80 byte records
594 2013-05-28 18:06:33 <BlueMatt> you need...oracle db for that one!
595 2013-05-28 18:06:45 <phantomcircuit> BlueMatt, more like a super computing cluster...
596 2013-05-28 18:06:55 <petertodd> phantomcircuit: Figures, oh well, maybe a more targetted experiment would be in order. I'll throw up some nodes with NTP and just look at the logs.
597 2013-05-28 18:06:56 <BlueMatt> (who was that guy who came around and very strongly insisted that everything would be better if only we used commercial db stuff?)
598 2013-05-28 18:06:58 <phantomcircuit> ~135 million messages/day with only 4k nodes
599 2013-05-28 18:07:27 <phantomcircuit> petertodd, you need to do the analysis in real time
600 2013-05-28 18:07:39 <phantomcircuit> otherwise the volume of individual messages is just crushing
601 2013-05-28 18:07:48 <MC1984> nobodu found out about my GBT crash bug?
602 2013-05-28 18:07:56 <jgarzik> BlueMatt: good deal
603 2013-05-28 18:08:12 <BlueMatt> jgarzik: will 1 GBps be enough?
604 2013-05-28 18:08:21 <petertodd> phantomcircuit: Oh, I just mean to run, say, 6 nodes, and see if blocks mined by those pools with replaced tx's vs. ones without propgate differently. Not great data obviously.
605 2013-05-28 18:08:26 <jgarzik> BlueMatt: heh, most definitely
606 2013-05-28 18:08:40 <phantomcircuit> hmm?
607 2013-05-28 18:08:44 <BlueMatt> jgarzik: you're supposed to say no...
608 2013-05-28 18:08:49 <jgarzik> BlueMatt: hehehe
609 2013-05-28 18:09:13 <jgarzik> BlueMatt: well I could use it to crawl every node, once per minute. Because, you know, stress test mumble mumble.
610 2013-05-28 18:09:25 <petertodd> phantomcircuit: See, if you replace-by-fee a tx, that means it's not in the signature cache of the majority of the network, so your block will relay slower and your orphan rate goes up. So the question is, how much do you charge for that service?
611 2013-05-28 18:09:37 <BlueMatt> jgarzik: you could do every node every minute easily in 1 Gbps though
612 2013-05-28 18:10:02 <BlueMatt> at least by my guesstimating
613 2013-05-28 18:10:03 <jgarzik> first I need a good idea of incoming-TCP-port-reachable nodes on the total network
614 2013-05-28 18:10:09 <phantomcircuit> oh
615 2013-05-28 18:10:12 <phantomcircuit> petertodd, shrug
616 2013-05-28 18:10:13 <jgarzik> time for a crawl
617 2013-05-28 18:10:24 <BlueMatt> jgarzik: think 5-7k
618 2013-05-28 18:10:36 <BlueMatt> ehh, probably 6-8k
619 2013-05-28 18:10:50 <jgarzik> My guesstimates were 5-10k
620 2013-05-28 18:11:01 <jgarzik> in any case, not many
621 2013-05-28 18:12:30 <BlueMatt> jgarzik: Im pretty sure both 5-7k and 6-8k are within your 5-10k range
622 2013-05-28 18:13:06 <sipa> my crawler reports 4.5k "good" nodes, though the criteria are quite arbitrary
623 2013-05-28 18:17:02 <helo> if IBD time does not grow like O(log(height)) with commodity hardware, won't we continually lose full nodes over time?
624 2013-05-28 18:17:25 <Subo1978> is there not Client on IRC on lfnet?
625 2013-05-28 18:17:28 <sipa> nodes only do an IBD once
626 2013-05-28 18:17:42 <sipa> (... ideally)
627 2013-05-28 18:17:47 <BlueMatt> oh, btw, jgarzik now that you have free time, do you finally want to set up that seednode on the btcf dedicated server?
628 2013-05-28 18:18:00 <sipa> i have a seed running there
629 2013-05-28 18:18:17 <BlueMatt> sipa: meant seednode, not dnsseed
630 2013-05-28 18:18:21 <BlueMatt> also, testnet seednode
631 2013-05-28 18:18:21 <sipa> all that is needed is a dns entry pointing to it
632 2013-05-28 18:18:22 <sipa> ow
633 2013-05-28 18:18:25 <sipa> ok
634 2013-05-28 18:18:35 <BlueMatt> oh, yes, probably wanna add that dns entry at some point, no?
635 2013-05-28 18:19:03 <BlueMatt> ACTION votes against sipa running 2 dnsseeds, but maybe jgarzik can take this one, or...something
636 2013-05-28 18:19:24 <sipa> i have no problem someone running one, less work for me :)
637 2013-05-28 18:19:32 <sipa> +else
638 2013-05-28 18:19:42 <MC1984> helo if doing an IBD tends to increase even accounting for tech advancement then surely nodes tends to decrease simply as a function of entropy or something
639 2013-05-28 18:20:05 <BlueMatt> MC1984: by that point we'll be doing ibd through verifyable computation
640 2013-05-28 18:20:08 <MC1984> another good argument for smallishblox
641 2013-05-28 18:20:10 <BlueMatt> and then its O(something else)
642 2013-05-28 18:20:16 <MC1984> wat?
643 2013-05-28 18:20:26 <BlueMatt> yes
644 2013-05-28 18:20:47 <MC1984> the hell is verifiable computation
645 2013-05-28 18:20:55 <sipa> it's cs magic squared
646 2013-05-28 18:20:57 <phantomcircuit> helo, the current limitation is cpu time, assuming moores law holds and/or the prevalence of multicore systems increases (i would say the latter is more likely) then i dont expect it to be an issue
647 2013-05-28 18:21:04 <BlueMatt> https://www.google.com/search?q=verifyable+execution
648 2013-05-28 18:21:14 <funky> (7:37:02 PM) TuxBlackEdo: What makes bitcoin devs think that the us government won't go after them? it wont help
649 2013-05-28 18:21:20 <MC1984> maybe if verifying simply scales well with cores
650 2013-05-28 18:21:24 <MC1984> well be ok lol
651 2013-05-28 18:21:27 <funky> since satoshi system is peer to peer
652 2013-05-28 18:21:43 <BlueMatt> MC1984: well, it isnt lmgtfy...at least its actually google
653 2013-05-28 18:21:52 <BlueMatt> funky: because we know the eff will step up to defend us
654 2013-05-28 18:21:54 <BlueMatt> ...right?
655 2013-05-28 18:21:59 <funky> eff?
656 2013-05-28 18:21:59 <phantomcircuit> MC1984, at the moment it does and i expect it will continue to
657 2013-05-28 18:22:09 <BlueMatt> anyway, I dont have commit access, I'm not a dev :)
658 2013-05-28 18:22:16 <MC1984> has anyone ever tried doing an IBD into a ramdisk with a top of the line cpu and the sipspeed stuff
659 2013-05-28 18:22:22 <MC1984> -nocheckpoints
660 2013-05-28 18:22:25 <MC1984> mite b cool
661 2013-05-28 18:22:33 <funky> :)
662 2013-05-28 18:22:33 <funky> BlueMatt u can hide in my apt
663 2013-05-28 18:22:34 <BlueMatt> MC1984: in bitcoinj I have
664 2013-05-28 18:22:39 <sipa> ramdisk won't help if you have huge dbcache
665 2013-05-28 18:22:41 <BlueMatt> MC1984: and it takes almost no time at all
666 2013-05-28 18:22:44 <BlueMatt> in /bitcoinj/!
667 2013-05-28 18:22:47 <BlueMatt> JAVA
668 2013-05-28 18:22:55 <sipa> it simply doesn't touch disk as long as it fits in the dbcache
669 2013-05-28 18:22:58 <MC1984> well huge dbcache then
670 2013-05-28 18:23:11 <Subo1978> MC1984: whats Hughe?
671 2013-05-28 18:23:17 <sipa> a few gb
672 2013-05-28 18:23:20 <MC1984> my shitty keyboard
673 2013-05-28 18:23:27 <funky> folks I was reading many exchanges claim they keep client funds in cold storage, yet if exchange is automated means front end got some access to it right?
674 2013-05-28 18:23:46 <phantomcircuit> funky, not if they're doing it right
675 2013-05-28 18:24:01 <helo> if block size is allowed to be whatever a majority of full nodes can keep up with, it seems like IBD time may be growing too quickly versus hardware improvements
676 2013-05-28 18:24:03 <MC1984> some guy on reddit claimed that his new SSD was very very much > his old 5400rpm drive
677 2013-05-28 18:24:10 <MC1984> for IBD
678 2013-05-28 18:24:24 <funky> phantomcircuit: hmm for example I send 50 coins - then auto system got to access wallet to send transfer command
679 2013-05-28 18:24:32 <MC1984> didnt think that was supposed to matter much with leveldb
680 2013-05-28 18:24:41 <sipa> helo: if block sizes tend to infinity, full nodes will tend to be only miners
681 2013-05-28 18:24:57 <BlueMatt> MC1984: "old 5400rpm drive"
682 2013-05-28 18:25:13 <MC1984> most laptop drives are 5400
683 2013-05-28 18:25:19 <MC1984> and most computers are laptops
684 2013-05-28 18:25:25 <BlueMatt> most laptop drives are ssds these days...
685 2013-05-28 18:25:30 <MC1984> in fact most laptops are now tablets :/
686 2013-05-28 18:25:34 <funky> no!
687 2013-05-28 18:25:36 <BlueMatt> that too
688 2013-05-28 18:25:36 <sipa> wwith default dbcache, there is still frequent writing to disk
689 2013-05-28 18:25:41 <funky> laptops are better
690 2013-05-28 18:26:01 <MC1984> SSDs dont seem to be quite standard in laptops yet
691 2013-05-28 18:26:14 <BlueMatt> ACTION goes to plan out his haswell desktop-rebuild...32gb or ram...I will run EVERYTHING in ramdisk
692 2013-05-28 18:26:14 <MC1984> not long though i guess
693 2013-05-28 18:26:21 <helo> sipa: don't we want miners to be a minority of full nodes, so they can't dictate mining-selfish rule changes?
694 2013-05-28 18:26:46 <MC1984> yes
695 2013-05-28 18:27:52 <MC1984> <phantomcircuit> MC1984, at the moment it does and i expect it will continue to
696 2013-05-28 18:27:56 <MC1984> you mean for the IDB thing?
697 2013-05-28 18:28:21 <phantomcircuit> MC1984, loading blocks is largely cpu bound
698 2013-05-28 18:28:33 <phantomcircuit> i believe largely by OP_CHECKSIG
699 2013-05-28 18:28:42 <MC1984> yes but MAOR CORES
700 2013-05-28 18:28:52 <phantomcircuit> MC1984, right
701 2013-05-28 18:28:54 <MC1984> and sipaspeed
702 2013-05-28 18:28:59 <phantomcircuit> sipaspeed?
703 2013-05-28 18:29:00 <BlueMatt> ACTION ponders dual-cpu workstation...
704 2013-05-28 18:29:01 <phantomcircuit> wats dat
705 2013-05-28 18:29:06 <BlueMatt> sipa's ec library
706 2013-05-28 18:29:11 <BlueMatt> its pretty damn quick
707 2013-05-28 18:29:19 <funky> u want light sexy laptop
708 2013-05-28 18:29:21 <phantomcircuit> ah
709 2013-05-28 18:29:27 <funky> then u can work in garden
710 2013-05-28 18:29:29 <MC1984> 6x quicker apparently
711 2013-05-28 18:29:38 <MC1984> thats like instant 6x MOAR COARS
712 2013-05-28 18:29:40 <BlueMatt> funky: no, I have a light sexy (thinkpad sexy) i7 laptop...
713 2013-05-28 18:29:53 <phantomcircuit> BlueMatt, dual? why not quad http://www.thinkmate.com/System/HPX_XS5-4460-10G
714 2013-05-28 18:30:16 <BlueMatt> phantomcircuit: I already have case + wc setup + graphics card...Im just replacing motherboard + cpu + mem
715 2013-05-28 18:30:35 <jgarzik> BlueMatt: yes, need to tackle that too :)
716 2013-05-28 18:30:36 <BlueMatt> (also I dont have /that/ much money...)
717 2013-05-28 18:30:38 <jgarzik> todolist++
718 2013-05-28 18:30:45 <helo> i'm just paranoid... i'd like it if the rules ensure that decentralization grows over time given modest assumptions about commodity hardware speed, rather than trying to figure out just how much decentralization we need, assumming perpetual commodity hardware speed improvements (what if global economic collpase?), and running with it
719 2013-05-28 18:30:53 <phantomcircuit> BlueMatt, yeah i was mostly joking
720 2013-05-28 18:30:55 <BlueMatt> jgarzik: what happened to having all that free time to code on bitcoin? :p
721 2013-05-28 18:31:20 <jgarzik> BlueMatt: people like you keep filling it up
722 2013-05-28 18:31:21 <jgarzik> ACTION runs
723 2013-05-28 18:31:29 <Raccoon> T-2 minutes until launch of the Soyuz shuttle to the International Space Station (ISS) - http://www.space.com/17933-nasa-television-webcasts-live-space-tv.html
724 2013-05-28 18:31:38 <MC1984> helo it should level off in terms of economic activity, at some point far in the future
725 2013-05-28 18:31:44 <BlueMatt> ;;slap jgarzik
726 2013-05-28 18:31:45 <gribble> ACTION slaps jgarzik with a sleek GPG key
727 2013-05-28 18:31:46 <phantomcircuit> BlueMatt, you can put 1TB of ram into that system
728 2013-05-28 18:31:48 <MC1984> peobably as a funciton of human population leveling off......
729 2013-05-28 18:31:56 <phantomcircuit> you have 50k i can uh
730 2013-05-28 18:31:59 <phantomcircuit> "borrow"
731 2013-05-28 18:32:00 <BlueMatt> phantomcircuit: holy mother fucker...
732 2013-05-28 18:32:12 <MC1984> but capitalism stops working overall then so who knows, stock up on bullets kids
733 2013-05-28 18:32:53 <helo> MC1984: sounds reasonable... that seems to indicate a strict max blocksize so that IBD can be done in log(t) once speed increases taper off
734 2013-05-28 18:33:14 <MC1984> thats the conclusion ive come to
735 2013-05-28 18:33:29 <BlueMatt> MC1984: thats not true
736 2013-05-28 18:33:37 <MC1984> the trick is getting the system there withough knocking the marble off the saddle at some point
737 2013-05-28 18:33:40 <jgarzik> capitalism never stops working for me
738 2013-05-28 18:33:46 <BlueMatt> MC1984: I actually wasnt joking about verifyable computation
739 2013-05-28 18:33:58 <MC1984> homes im still trying to find out what that is
740 2013-05-28 18:34:19 <phantomcircuit> BlueMatt, lol yeah it's easy to configure a 75k usd system on that site
741 2013-05-28 18:34:27 <phantomcircuit> i wonder who actually buys them
742 2013-05-28 18:34:30 <phantomcircuit> im sure someone does
743 2013-05-28 18:34:32 <sipa> MC1984: no, much better than 6x more cores, as it doesn't cause contention between cores to scale up :)
744 2013-05-28 18:34:34 <BlueMatt> cryptographic proof that the data I'm giving you was generated by an accurate run of the given program
745 2013-05-28 18:34:52 <BlueMatt> phantomcircuit: the companies who have too much money and who's employees "need" it to dev
746 2013-05-28 18:34:56 <MC1984> smells like trusted computing......
747 2013-05-28 18:35:07 <BlueMatt> its trusted computing that is actually trustable :p
748 2013-05-28 18:35:10 <sipa> MC1984: no, that's related but not the same
749 2013-05-28 18:35:17 <BlueMatt> (and in software)
750 2013-05-28 18:35:20 <MC1984> first reaction is le nope
751 2013-05-28 18:35:25 <sipa> MC1984: this is based on cryptography, not on trusted hardware
752 2013-05-28 18:35:44 <BlueMatt> MC1984: yes, that is how most people responded to RSA initially
753 2013-05-28 18:36:19 <BlueMatt> hmm...4x8GB for $200...buy
754 2013-05-28 18:36:36 <sipa> i need to build me a new desktop system
755 2013-05-28 18:36:47 <sipa> just to get my mental hardware price reference up to date
756 2013-05-28 18:36:48 <MC1984> ok well without dismissing things out of hand, it sounds like a good way to entrench a system where you cant run exactly the code you want to
757 2013-05-28 18:37:04 <sipa> MC1984: that has nothing to do with it
758 2013-05-28 18:37:05 <BlueMatt> sipa: now's the time (well, in a month or two's the time)
759 2013-05-28 18:37:15 <BlueMatt> sipa: at least if you're building it yourself, that is
760 2013-05-28 18:37:22 <MC1984> ok i will reserve judgement
761 2013-05-28 18:37:27 <MC1984> not that my judgement matters
762 2013-05-28 18:37:46 <sipa> MC1984: you have a program, you give it to me, i run the program on secret input, and produce a small proof
763 2013-05-28 18:37:54 <sipa> MC1984: and the output
764 2013-05-28 18:38:16 <sipa> MC1984: you can verify that the output is actually the result of me running your program
765 2013-05-28 18:38:21 <sipa> MC1984: cheaply
766 2013-05-28 18:38:30 <sipa> MC1984: and without knowing the input i ran it on
767 2013-05-28 18:38:45 <MC1984> so a way to zero trust someone elses work verifying the entire chain?
768 2013-05-28 18:39:07 <sipa> where 'small' means: the proof is the proportional to size of the _program_, not to its runtime
769 2013-05-28 18:39:18 <sipa> producing the proof is expensive, though
770 2013-05-28 18:39:20 <BlueMatt> (which is ideal for the blockchain, because you dont care about the input, if you spv bootstrap then you know the best hash, and can ensure the chain state you just got is actually correct for that hash)
771 2013-05-28 18:39:25 <sipa> much more expensive than just running it
772 2013-05-28 18:40:03 <MC1984> so a way to zero trust someone elses work verifying the entire chain?
773 2013-05-28 18:40:15 <tholenst> MC1984: yes
774 2013-05-28 18:40:19 <sipa> using it for the bitcoin blockchain is probably hard
775 2013-05-28 18:40:33 <MC1984> sounds like leprechaun magic
776 2013-05-28 18:40:42 <BlueMatt> MC1984: isnt cryptography always?
777 2013-05-28 18:40:42 <tholenst> did Eli Ben-Sasson talk about that at bitcoin 2013?
778 2013-05-28 18:40:47 <sipa> yes
779 2013-05-28 18:40:55 <sipa> as in too computationally expensive to produce the proof for that
780 2013-05-28 18:41:25 <donpdonp> are any bitcoin2013 presentation videos online?
781 2013-05-28 18:41:40 <MC1984> if it onyl has to be done once, start a boinc project, i dunno....
782 2013-05-28 18:42:24 <BlueMatt> MC1984: more like a kickstarter to buy...all of ec2
783 2013-05-28 18:42:55 <MC1984> id fund it
784 2013-05-28 18:43:11 <MC1984> STRECH GOAL: we buy microsoft
785 2013-05-28 18:43:16 <sipa> gmaxwell has more numbers than i do
786 2013-05-28 18:43:27 <BlueMatt> MC1984: who would want that?
787 2013-05-28 18:43:33 <sipa> but iirc it required mostly an extremely high amount of RAM
788 2013-05-28 18:43:41 <sipa> BlueMatt: embrace & extinguish?
789 2013-05-28 18:43:52 <MC1984> buy ms, opensource everything, lulz
790 2013-05-28 18:44:12 <BlueMatt> MC1984: watch as windows gets ownd...harder than it does now (is that possible?)
791 2013-05-28 18:44:46 <MC1984> but it should get more secure eventually, the greater good :p
792 2013-05-28 18:44:53 <BlueMatt> wat?
793 2013-05-28 18:44:58 <MC1984> the world would probably literally burn before then but w/e
794 2013-05-28 18:45:01 <BlueMatt> since when does sipa leave?
795 2013-05-28 18:45:22 <MC1984> he'll be back
796 2013-05-28 18:45:50 <BlueMatt> (he's usually on a bouncer)
797 2013-05-28 18:46:03 <jgarzik> He Has Left The Building.
798 2013-05-28 18:46:39 <MC1984> datacenter people spilt beer on the servers again
799 2013-05-28 18:54:36 <phantomcircuit> BlueMatt, well hilariously if you can get a 2x performance improvement out of a dev an expenditure like that isn't even ridiculous
800 2013-05-28 18:55:01 <BlueMatt> phantomcircuit: yes, this is why that market exists
801 2013-05-28 18:55:11 <phantomcircuit> yup
802 2013-05-28 18:55:26 <BlueMatt> ACTION wishes someone would buy him a workstation like that...
803 2013-05-28 18:55:28 <phantomcircuit> people forget the average american worker is backed by ~100k usd in capital
804 2013-05-28 18:55:45 <BlueMatt> (per year)
805 2013-05-28 18:55:47 <phantomcircuit> which is a pretty bizarre thing to think about sitting here with my $400 desktop
806 2013-05-28 18:56:04 <phantomcircuit> BlueMatt, no i meant like the cost off infrastructure to support their work
807 2013-05-28 18:56:05 <BlueMatt> well, a white collar at least
808 2013-05-28 18:56:18 <BlueMatt> wat?
809 2013-05-28 18:56:29 <BlueMatt> well I suppose realestate is expensive as fuck
810 2013-05-28 18:56:31 <phantomcircuit> like construction workers driving around 50k usd equipment
811 2013-05-28 18:56:43 <BlueMatt> seems high
812 2013-05-28 18:56:49 <BlueMatt> well, yea, that makes sense
813 2013-05-28 18:57:13 <phantomcircuit> BlueMatt, i think being in tech sort of warps the view of how much capital it takes to do a lot of tings
814 2013-05-28 18:57:15 <phantomcircuit> things*
815 2013-05-28 18:57:25 <BlueMatt> I think someone mistakenly divided total capital by total workers and called it a day...
816 2013-05-28 18:57:28 <phantomcircuit> you can do some pretty amazing things on a shoe string budget in tech
817 2013-05-28 18:57:30 <phantomcircuit> like say
818 2013-05-28 18:57:31 <phantomcircuit> bitcoin
819 2013-05-28 18:57:32 <phantomcircuit> lol
820 2013-05-28 18:57:56 <BlueMatt> but I suppose if you define it that way 100k makes sense
821 2013-05-28 18:58:00 <phantomcircuit> BlueMatt, well yeah it's definitely skewed by extreme outliers
822 2013-05-28 18:58:16 <BlueMatt> anyway, Im off
823 2013-05-28 18:58:19 <phantomcircuit> the guy driving the million dollar coal mine dump truck for example
824 2013-05-28 18:58:41 <BlueMatt> heh, thats some expensive insurance...
825 2013-05-28 19:00:36 <dugo> if you count the capital required to give phantomcircuit a roof over his head and a powerplug things go in the direction of 100k quickly i suppose
826 2013-05-28 19:00:48 <jgarzik> "well hilariously if you can get a 2x performance improvement out of a dev an expenditure like that isn't even ridiculous" <<--- I spent $58,000 on a 1100 sq.ft. cabin as a super-office
827 2013-05-28 19:00:53 <jgarzik> all in the quest for productivity
828 2013-05-28 19:01:18 <phantomcircuit> dugo, never thought of it that way
829 2013-05-28 19:01:28 <phantomcircuit> jgarzik, did it work
830 2013-05-28 19:01:35 <jgarzik> hell yes
831 2013-05-28 19:01:49 <jgarzik> of course, then BitPay hired me, and now it's time to sell it ;p
832 2013-05-28 19:01:57 <phantomcircuit> lol
833 2013-05-28 19:02:05 <jgarzik> http://www.trulia.com/homes/North_Carolina/Raleigh/sold/1000887172-5524-Hester-Dr-Raleigh-NC-27606
834 2013-05-28 19:02:23 <phantomcircuit> so i believe i have narrowed down the problem with rpc to the boost::asio stuff
835 2013-05-28 19:02:30 <phantomcircuit> however i consider most of that to be black magic
836 2013-05-28 19:02:33 <phantomcircuit> so i give up
837 2013-05-28 19:02:52 <phantomcircuit> i'll just write rpc calls to do everything i need so each op is 1 rpc call
838 2013-05-28 19:03:45 <BlueMatt> hell look at how much the big tech guys spend on facilities...
839 2013-05-28 19:04:03 <phantomcircuit> on that note im off to get lunch on someone elses dime
840 2013-05-28 19:04:06 <phantomcircuit> horray
841 2013-05-28 19:04:32 <BlueMatt> jgarzik: is bitpay moving you out of Raleigh?
842 2013-05-28 19:04:39 <phantomcircuit> i assume atlanta
843 2013-05-28 19:04:45 <jgarzik> *moved