1 2012-06-19 00:00:42 <sipa> quite sure it is
2 2012-06-19 00:03:09 mmoya has quit (Ping timeout: 244 seconds)
3 2012-06-19 00:03:56 <sipa> i don't get it... suddenly my network code doesn't parse ipv6 address anymore
4 2012-06-19 00:04:22 <luke-jr> >_<
5 2012-06-19 00:04:26 <gmaxwell> sipa: did gavin merge that improved parser patch?
6 2012-06-19 00:04:37 <sipa> gmaxwell: yes, and that includes netbase tests
7 2012-06-19 00:04:48 <sipa> and those show that ipv6 addresses do not get parsed anymore
8 2012-06-19 00:05:00 <sipa> though i'm very sure that when i wrote the tests, they succeeded
9 2012-06-19 00:05:59 <luke-jr> sipa: my dnsseed seems to have exit()'d O.o
10 2012-06-19 00:06:06 <sipa> luke-jr: mine too
11 2012-06-19 00:06:23 <sipa> no time to look into it now; run it in a while true; do ./dnsseed; done :)
12 2012-06-19 00:06:28 <luke-jr> XD
13 2012-06-19 00:06:46 <luke-jr> weird, it just exit'd again in under a minute
14 2012-06-19 00:07:28 <luke-jr> sipa: no SIGPIPE handler?
15 2012-06-19 00:08:04 <sipa> i doubt that's the problem
16 2012-06-19 00:08:10 <luke-jr> sipa: gdb thinks it is
17 2012-06-19 00:08:16 <sipa> hmm
18 2012-06-19 00:08:36 <TheSeven> https://github.com/TheSeven/Bitcoin-WebUI
19 2012-06-19 00:10:23 hnz has quit (Ping timeout: 244 seconds)
20 2012-06-19 00:16:50 <sipa> oooh i get it
21 2012-06-19 00:17:04 <sipa> the IPv6 resolve code only runs when there is an IPv6 device
22 2012-06-19 00:17:13 <sipa> and my sixxs tunnel is down...
23 2012-06-19 00:18:35 <Dagger2> I'm assuming you're on Windows; there's a registry setting to force it, if that's helpful
24 2012-06-19 00:18:43 <Dagger2> (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dnscache\Parameters\AddrConfigControl = 0)
25 2012-06-19 00:18:51 <sipa> Dagger2: no, linux
26 2012-06-19 00:19:21 <Dagger2> ah, so the check is something in Bitcoin?
27 2012-06-19 00:19:39 <Dagger2> since I'm somewhat sure Linux does AAAA records regardless of it having a public v6 address or not
28 2012-06-19 00:19:51 <sipa> it's explicitly requested
29 2012-06-19 00:20:06 <sipa> AI_ADDRCONFIG
30 2012-06-19 00:20:30 <sipa> on supported systems, that means only return addresses in address families for which a configured device exists
31 2012-06-19 00:22:15 <Dagger2> ah, right. I'm not being helpful here, so I'll just relurk
32 2012-06-19 00:22:33 slush1 has joined
33 2012-06-19 00:22:53 slush has quit (Ping timeout: 246 seconds)
34 2012-06-19 00:22:54 <sipa> which makes a lot of sense, but for numeric addresses, i always want them
35 2012-06-19 00:26:38 graingert has quit (Remote host closed the connection)
36 2012-06-19 00:26:56 graingert has joined
37 2012-06-19 00:27:13 hnz has joined
38 2012-06-19 00:29:51 Zarutian has quit (Quit: Zarutian)
39 2012-06-19 00:31:25 att has quit (Ping timeout: 255 seconds)
40 2012-06-19 00:33:32 <xorgate> how does a block get orphaned? its predecessor has 2 blocks coming from it, and the other one gets a child?
41 2012-06-19 00:34:39 <luke-jr> O.o
42 2012-06-19 00:34:49 <sipa> blocks do not get orphaned; their coinbase transaction does become orphaned when we switch to another (longer) branch
43 2012-06-19 00:35:01 <luke-jr> sigh, yes they do
44 2012-06-19 00:35:21 <gmaxwell> luke-jr: an orphan is a person who has no parents anymore.
45 2012-06-19 00:35:27 <sipa> i refuse to use the term "orphan" as meaning anything but "without parents"
46 2012-06-19 00:35:29 <gmaxwell> Not someone who has no children.
47 2012-06-19 00:35:44 <luke-jr> xorgate: basically, orphans happen when two miners find the same block height at the same time (+/- a few seconds/minutes because they don't find out about the others' instantly)
48 2012-06-19 00:35:44 <gmaxwell> Is there even a word for having no children?
49 2012-06-19 00:35:45 <xorgate> oh my.. i'm reading https://en.bitcoin.it/wiki/Protocol_rules
50 2012-06-19 00:36:16 <gmaxwell> xorgate: sipa is being language pedantic, the answer to what you were asking is "yes" even if there is a dispute over the word. :)
51 2012-06-19 00:36:48 <xorgate> luke-jr yes, but 1 of those 2 'makes it'
52 2012-06-19 00:36:58 <gmaxwell> xorgate: or more broadly, a block is forgotten is its not part of the longest chain (for whatever reason).
53 2012-06-19 00:36:59 <xorgate> gmaxwell ok
54 2012-06-19 00:37:07 <sipa> xorgate: the one that gets extended first by someone else 'makes it'
55 2012-06-19 00:37:23 <xorgate> great! then i understand
56 2012-06-19 00:37:38 <sipa> though there is always a chance that the network switches back, if the older one does happen to be extended again and more
57 2012-06-19 00:37:58 <vragnaroda> Saying 2+2â 5 is being needlessly pedantic, even if there's debate over what 2 is. :p
58 2012-06-19 00:37:58 <gmaxwell> There could be ties on extension too... but that becomes more and more unlikely the longer the split.
59 2012-06-19 00:38:25 <xorgate> "The main branch is defined as the branch with highest total difficulty, summing the difficulties for each block in the branch"
60 2012-06-19 00:38:32 <sipa> xorgate: indeed
61 2012-06-19 00:38:47 <sipa> vragnaroda: what about extreme values for 2? ;)
62 2012-06-19 00:39:06 <vragnaroda> lol
63 2012-06-19 00:39:16 <xorgate> a block's difficulty is the hash? lower hash meaning 'more difficult' ? (aka more work)
64 2012-06-19 00:39:22 <sipa> xorgate: no
65 2012-06-19 00:39:41 <sipa> xorgate: the difficulty is determined by the network, based on its apparent hashing speed
66 2012-06-19 00:39:57 <xorgate> ok so the once-per-2016-blocks one
67 2012-06-19 00:39:58 <sipa> the hash has to be lower than a minimum value divided by the difficulty
68 2012-06-19 00:40:02 <sipa> indeed
69 2012-06-19 00:40:33 <sipa> but when reorganisations span the 2016-blocks boundary, the rule may have an influence on which branch gets chosen
70 2012-06-19 00:40:44 <sipa> in 99% of the cases though, it's just the longest branch
71 2012-06-19 00:40:48 <xorgate> yeah i was just thinking about that
72 2012-06-19 00:40:53 da2ce7 has quit (Ping timeout: 255 seconds)
73 2012-06-19 00:44:33 graingert has quit (Remote host closed the connection)
74 2012-06-19 00:44:37 <luke-jr> sipa: wouldn't it have to be a 2:3 block reorg for that?
75 2012-06-19 00:44:51 graingert has joined
76 2012-06-19 00:45:11 <xorgate> maybe orphaned isnt the right word but disowned is? "you're dead to me"
77 2012-06-19 00:45:41 <sipa> xorgate: in the source code: disconnected
78 2012-06-19 00:45:56 <sipa> luke-jr: yeah, i guess
79 2012-06-19 00:46:38 <gmaxwell> heh. "Disowned blocks leave orphan transactions"
80 2012-06-19 00:46:55 wizkid057 has quit (Read error: Operation timed out)
81 2012-06-19 00:47:52 wizkid057 has joined
82 2012-06-19 00:48:21 <xorgate> on a sidenote, what would be a decent dev environment for linux? one smart enough to do things like 'jump to definition' and such. I was already discouraged from even trying in windows
83 2012-06-19 00:48:52 <[Tycho]> What can be better than MSVC 6 ?
84 2012-06-19 00:48:55 <sipa> xorgate: i use mcedit *ducks*
85 2012-06-19 00:50:34 <phantomcircuit> sipa, i use gedit
86 2012-06-19 00:50:37 <phantomcircuit> seriously
87 2012-06-19 00:50:45 <xorgate> [Tycho] you have a working env to build bitcoind et al in windows?
88 2012-06-19 00:52:25 <luke-jr> xorgate: I use Kate.
89 2012-06-19 00:52:53 <Ukto> luke-jr: as long as she dont mind :P
90 2012-06-19 00:53:02 <luke-jr> â¦
91 2012-06-19 00:53:11 <phantomcircuit> lold
92 2012-06-19 00:54:27 tyn has joined
93 2012-06-19 00:54:42 rdponticelli has joined
94 2012-06-19 00:54:49 <xorgate> alright i think i'll try kate first
95 2012-06-19 00:54:58 <Ukto> talking about getting around..
96 2012-06-19 00:55:21 <Ukto> bet shes cheap/free too :P
97 2012-06-19 00:55:40 X-Scale has joined
98 2012-06-19 00:56:52 <luke-jr> git really needs a way to attribute multiple authorsâ¦
99 2012-06-19 00:59:29 drizztbsd has quit (Quit: Konversation terminated!)
100 2012-06-19 01:01:26 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
101 2012-06-19 01:08:43 slush1 has quit (Ping timeout: 260 seconds)
102 2012-06-19 01:09:14 <graingert> luke-jr: each time the person sat on the computer changes do a new commit
103 2012-06-19 01:09:32 <luke-jr> graingert: â¦
104 2012-06-19 01:11:02 vragnaroda is now known as `1
105 2012-06-19 01:11:50 `1 is now known as vragnaroda
106 2012-06-19 01:12:40 slush has joined
107 2012-06-19 01:13:06 Ahimoth_ has joined
108 2012-06-19 01:13:52 maaku has quit (Ping timeout: 245 seconds)
109 2012-06-19 01:14:50 DrHaribo_ has joined
110 2012-06-19 01:15:37 MiningBuddy- has joined
111 2012-06-19 01:15:57 Ahimoth has quit (Ping timeout: 264 seconds)
112 2012-06-19 01:15:58 DrHaribo has quit (Ping timeout: 264 seconds)
113 2012-06-19 01:15:58 Ahimoth_ is now known as Ahimoth
114 2012-06-19 01:15:58 MiningBuddy has quit (Ping timeout: 264 seconds)
115 2012-06-19 01:15:58 welterde has quit (Ping timeout: 264 seconds)
116 2012-06-19 01:19:08 terry has joined
117 2012-06-19 01:24:47 slush has quit (Ping timeout: 244 seconds)
118 2012-06-19 01:25:46 welterde has joined
119 2012-06-19 01:32:09 vragnaroda is now known as \\\\\\---\\\\\\\
120 2012-06-19 01:32:51 \\\\\\---\\\\\\\ is now known as vragnaroda
121 2012-06-19 01:36:01 AntKinGTube has quit (Quit: Leaving)
122 2012-06-19 01:39:10 da2ce7 has joined
123 2012-06-19 01:43:22 sytse has joined
124 2012-06-19 01:46:21 one_zero has joined
125 2012-06-19 01:53:03 eoss has quit (Read error: Connection reset by peer)
126 2012-06-19 01:54:40 graingert has quit (Remote host closed the connection)
127 2012-06-19 01:55:50 <BlueMattBot> Yippie, build fixed!
128 2012-06-19 01:55:51 <BlueMattBot> Project Bitcoin-Test build #316: FIXED in 29 min: http://jenkins.bluematt.me/job/Bitcoin-Test/316/
129 2012-06-19 01:55:51 <BlueMattBot> pieter.wuille: Fix netbase tests
130 2012-06-19 02:10:38 TheSeven has quit (Disconnected by services)
131 2012-06-19 02:10:46 [7] has joined
132 2012-06-19 02:14:31 genjix has quit (Ping timeout: 246 seconds)
133 2012-06-19 02:15:11 Hasbro has quit ()
134 2012-06-19 02:18:49 D34TH has quit (Ping timeout: 276 seconds)
135 2012-06-19 02:18:59 <luke-jr> BlueMatt: ping
136 2012-06-19 02:19:15 <luke-jr> BlueMatt: how do I call ConnectBlock directly after cblockstore-class ?
137 2012-06-19 02:19:48 jimbit has joined
138 2012-06-19 02:24:01 MobiusL has quit (Ping timeout: 276 seconds)
139 2012-06-19 02:25:06 rig1 has joined
140 2012-06-19 02:25:27 rig1 has quit (Quit: Leaving.)
141 2012-06-19 02:26:46 l1l1ll11l11 has joined
142 2012-06-19 02:27:14 <l1l1ll11l11> Hellow all
143 2012-06-19 02:27:55 sanchaz has quit (Ping timeout: 276 seconds)
144 2012-06-19 02:31:53 <jimbit> lol, rig1 has quit.. ll, hello
145 2012-06-19 02:33:47 MobiusL has joined
146 2012-06-19 02:40:29 D34TH has joined
147 2012-06-19 02:43:18 <jimbit> has there been any talk of 512, vs 256 because of the asic news ? or is this a stupid question?
148 2012-06-19 02:44:17 <Diablo-D3> no, and maybe
149 2012-06-19 02:44:21 <galambo> heh
150 2012-06-19 02:44:44 <gmaxwell> jimbit: I'm not following your question.
151 2012-06-19 02:45:11 <gmaxwell> Why would 512 vs 256 (what?) have to do with asic (what?) ?
152 2012-06-19 02:45:23 <galambo> hes asking if bfls ASIC is going to be so powerful that we have to "upgrade" to sha-512
153 2012-06-19 02:45:28 <jimbit> well, I have heard of talk of forking on purpose changing the proof of work from 256 to 512 because of the bfl asic news
154 2012-06-19 02:45:51 <gmaxwell> jimbit: heard "talk" where?
155 2012-06-19 02:46:04 <gmaxwell> And whats the justification given?
156 2012-06-19 02:46:09 <galambo> the bfl cult secret forum
157 2012-06-19 02:46:22 <jimbit> good question where.... the forums have become a park of trolling.
158 2012-06-19 02:46:25 onefourone has quit (Ping timeout: 244 seconds)
159 2012-06-19 02:46:32 <copumpkin> jimbit: a 512-bit hash wouldn't change anything
160 2012-06-19 02:46:42 <gmaxwell> IIRC the BFL announcement is regarding a product which will be available to the general public at sane sounding prices, and not otherwise compromising the bitcoin system.
161 2012-06-19 02:46:48 Ummon_ has quit (Ping timeout: 250 seconds)
162 2012-06-19 02:47:15 onefourone has joined
163 2012-06-19 02:47:19 <jimbit> so, then it is a question of just selling my gpus to gamers and buying the new stuff i guess.
164 2012-06-19 02:47:45 <gmaxwell> jimbit: that already seemed inevitable.
165 2012-06-19 02:48:45 <gmaxwell> after the reward halving no gpu operation would be profitable over power in any case... not unless a lot of gpus get shut off.
166 2012-06-19 02:48:53 <jimbit> then it will be important to have good timing
167 2012-06-19 02:48:58 <gmaxwell> or the bitcoin exchange rate doubles.
168 2012-06-19 02:49:17 <l1l1ll11l11> or free power
169 2012-06-19 02:49:23 <gmaxwell> l1l1ll11l11: no such thing.
170 2012-06-19 02:49:28 <jimbit> which i expect it will go up to just above what it cost to 'make' a btc, like any commodity will do
171 2012-06-19 02:49:55 <jimbit> so it will cost me about 4 bucks to make a btc after the half
172 2012-06-19 02:49:58 <gmaxwell> I mean, sure there are people here and there that don't pay for their power. But they aren't running large numbers of gpus and shouldn't care about asics or not.
173 2012-06-19 02:50:31 <jimbit> I think i am at about 1.80 USD per btc now
174 2012-06-19 02:50:31 <l1l1ll11l11> I'm running 45GH on zero (extra) cost power (included in my lease)
175 2012-06-19 02:50:56 <jimbit> l1l1ll11l11, shhh, dont tell anyone ;)
176 2012-06-19 02:51:00 <gmaxwell> jimbit: supply side economics are usually BS. Especially for things without long term concrete demands.
177 2012-06-19 02:51:11 <luke-jr> jimbit: also, were changing the hashing algorithm necessary for some reason, it wouldn't simply be to SHA512 most likely
178 2012-06-19 02:51:35 <luke-jr> jimbit: so long as BFL is playing nice, most likely the community would want to ensure their ASICs continue to be usable
179 2012-06-19 02:51:55 <Diablo-D3> bfl isnt playing nice
180 2012-06-19 02:52:05 <luke-jr> Diablo-D3: yes they are
181 2012-06-19 02:52:18 <galambo> anyone here have a bfl single?
182 2012-06-19 02:52:21 <l1l1ll11l11> I have 5
183 2012-06-19 02:52:24 <luke-jr> galambo: I do
184 2012-06-19 02:52:26 <jimbit> well, I cant say i understand alot about the algarithm. I plug in quality psu's and gpus and that is about it....
185 2012-06-19 02:52:27 <Diablo-D3> luke-jr: did you NOT see the thread I stickied?
186 2012-06-19 02:52:35 <luke-jr> Diablo-D3: nope
187 2012-06-19 02:52:36 <jimbit> I have 2 bfl singles
188 2012-06-19 02:52:44 <Diablo-D3> https://bitcointalk.org/index.php?topic=88363.0
189 2012-06-19 02:52:53 <l1l1ll11l11> BFL got a little snippy
190 2012-06-19 02:52:53 <galambo> luke-jr: okay i gyuess i can calm down about this then
191 2012-06-19 02:53:00 <gmaxwell> right, if we wanted to change something it would be a change to shut out a clear attacker, not someone who is behaving fairly and honestly and contributing to making the system secure against bad players that would use asics without cooperating.
192 2012-06-19 02:53:21 <l1l1ll11l11> BFL singles are rock solid, I've never had one go down, I was among the first 10 to order
193 2012-06-19 02:53:28 <jimbit> gmaxwell, sounds right!
194 2012-06-19 02:53:45 <luke-jr> Diablo-D3: trolling isn't hostile
195 2012-06-19 02:53:51 <gmaxwell> having good fast asics available to all miners will make it so that an attacker with asics isn't a risk unless he has a lot more asics than all the good users.
196 2012-06-19 02:53:53 <galambo> well i wasnt quite sure if they actually existed or not
197 2012-06-19 02:54:10 <jimbit> my bfls are good, albiet they throttle themselvs with just a little over 58C
198 2012-06-19 02:54:10 <galambo> everyone promoting the things seems kind of scammy (gigavps and inaba)
199 2012-06-19 02:54:11 <l1l1ll11l11> just a very, very poor track record of timing
200 2012-06-19 02:54:29 <l1l1ll11l11> 4-6 weeks really is 8-12 weeks
201 2012-06-19 02:54:38 Internet151 has joined
202 2012-06-19 02:54:38 <gmaxwell> Once asics made on modern process (at least 45nm) at prices which aren't extortionary are available I'll buy a bunch.
203 2012-06-19 02:54:46 <jimbit> yes, and OCT seeams a little quick too l1l1ll11l11
204 2012-06-19 02:55:35 <gmaxwell> engineering is hard, everyone inexpirenced misses their deadlines. The only reason expirenced places get them right is that they learn how to sandbag.
205 2012-06-19 02:55:39 <jimbit> with the prices they declared on the news release...well I will be at 1T myself
206 2012-06-19 02:55:46 onefourone has quit ()
207 2012-06-19 02:56:14 <jimbit> ftr: http://news.yahoo.com/butterfly-labs-announces-next-generation-asic-lineup-054626776.html
208 2012-06-19 02:56:31 <jimbit> 1 TH/s, priced at $29,899
209 2012-06-19 02:56:41 <galambo> i dont have an advanced academic degree or defense industry job that would enable someone to pay me to figure out FPGA
210 2012-06-19 02:56:43 <Diablo-D3> gmaxwell: Ill buy a bunch even before that
211 2012-06-19 02:57:04 <jimbit> timing will be important
212 2012-06-19 02:57:23 maaku has joined
213 2012-06-19 02:57:41 <jimbit> if you preorder too early, you tie up to much doe... too late and your late to the party
214 2012-06-19 02:58:55 <galambo> i know the basics and classmates did very simple things with fpga ( i guess sha-256 is simple too, without optimization )
215 2012-06-19 02:59:45 <l1l1ll11l11> The only way to strike it big in the switcharoo is to be in line for first wave of delivery
216 2012-06-19 02:59:51 <galambo> the spartan 6 guys are the most interesting to read about
217 2012-06-19 02:59:54 <galambo> they know the most, but apparantly that doesn't mean anything
218 2012-06-19 03:01:09 <l1l1ll11l11> Would be interesting if you coul dbe the fist to receive the 1TH unit, obviously all depends on how many are delivered the first wave, how much would 1TH make you that first day?
219 2012-06-19 03:01:26 <jimbit> hmmmmm
220 2012-06-19 03:02:10 <galambo> some parts of mining are interesting, but i think most of it is missing the point a bit
221 2012-06-19 03:02:20 RainbowDashh has joined
222 2012-06-19 03:02:39 <l1l1ll11l11> point being network stability/security?
223 2012-06-19 03:02:46 RainbowDashh has quit (Client Quit)
224 2012-06-19 03:03:13 <jimbit> galambo, tru, but if it wasnt for the profit, most would not mine.
225 2012-06-19 03:04:20 <l1l1ll11l11> which essentially means, long term, there must be a low cost way to mine, i.e. asics drawing tiny power
226 2012-06-19 03:04:35 <gmaxwell> l1l1ll11l11: That doesn't follow in fact.
227 2012-06-19 03:06:23 <gmaxwell> But what is important that the bulk of the honest miners can mine at least as cheap as some malicious miner so the malicious miner doesn't get a big advantage.
228 2012-06-19 03:06:27 <l1l1ll11l11> wouldn't continued network security require a huge amount of hash power?
229 2012-06-19 03:07:12 <l1l1ll11l11> It just seems that if the rewards were to cease today, hashing would just get tranaction fees, thus not many people would keep hashing, thus making it easier to overtake 51%
230 2012-06-19 03:07:41 <gmaxwell> And thus the rewards aren't going to cease today.
231 2012-06-19 03:09:02 <jimbit> and not for 20 years :)
232 2012-06-19 03:09:29 <gmaxwell> 20??
233 2012-06-19 03:09:47 <galambo> infinity?
234 2012-06-19 03:09:48 <gmaxwell> The rewards don't go to _0_ until 2140 and thats if bitcoin isn't changed to have more precision before then.
235 2012-06-19 03:10:21 <gmaxwell> Also, the correct word is subsidy, so I'll be using that in further comments. :)
236 2012-06-19 03:10:24 <galambo> the question is when do rewards go below the market determined (it will be in the future) transaction fees
237 2012-06-19 03:10:32 RainbowDashh has joined
238 2012-06-19 03:11:09 <gmaxwell> galambo: right, no way to tell until it becomes close I think.
239 2012-06-19 03:14:33 <jimbit> i just put 20 years out there cause then it will be down in low single digits
240 2012-06-19 03:22:00 osmosis has joined
241 2012-06-19 03:24:08 <gmaxwell> jimbit: sure but it's hard to know what the economic significance of that would be.
242 2012-06-19 03:27:05 <jimbit> yes, people need to start 'using' btcs, not just hoarding them or cashing them in
243 2012-06-19 03:27:21 <jimbit> I always give a transaction fee.
244 2012-06-19 03:28:33 <galambo> that wont happen
245 2012-06-19 03:29:21 <MysteryBanshee> whats wrong with hoarding?
246 2012-06-19 03:29:23 <jimbit> galambo, then we are dead in the water when it goes below 6.25
247 2012-06-19 03:29:38 <jimbit> unless they are 100bucks each
248 2012-06-19 03:29:47 <jimbit> :)
249 2012-06-19 03:30:06 <galambo> well they probably will increase in price
250 2012-06-19 03:30:47 <galambo> i think bitcoin will be more useful in the future as a backing for inflationary sub-currencies
251 2012-06-19 03:31:26 <jimbit> galambo, sub-currencies being fiat? or ?
252 2012-06-19 03:31:58 <galambo> issued by bitcoin banks basically
253 2012-06-19 03:32:03 <galambo> for lack of a better term
254 2012-06-19 03:32:38 <galambo> http://en.wikipedia.org/wiki/File:Delaware_Bridge_Company_Dollar.jpg
255 2012-06-19 03:32:42 <galambo> kind of like that
256 2012-06-19 03:33:06 <gmaxwell> galambo: they don't even have to be 'banks' they could themselves be distributed systems.
257 2012-06-19 03:33:14 <galambo> i agree
258 2012-06-19 03:36:02 <galambo> bitcoin can be a digital notary stamp for future subcurrencies, temporarily loaned out
259 2012-06-19 03:36:05 <jimbit> himmm jimbit dollars :)
260 2012-06-19 03:36:33 <galambo> basically, but the proof of work keeps you almost honest :)
261 2012-06-19 03:37:39 rdponticelli has quit (Ping timeout: 246 seconds)
262 2012-06-19 03:42:31 Motest003 has joined
263 2012-06-19 03:44:11 Diablo-D3 has quit (Ping timeout: 240 seconds)
264 2012-06-19 03:50:41 <[Tycho]> How many new TXes per second do you see currently ?
265 2012-06-19 03:51:59 BitByBit has joined
266 2012-06-19 03:53:08 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
267 2012-06-19 03:54:37 BitByBit has quit (Client Quit)
268 2012-06-19 04:00:52 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
269 2012-06-19 04:03:53 <devrandom> gmaxwell: Jenkins + gitian FTW
270 2012-06-19 04:04:00 <devrandom> gmaxwell: problems with lxc?
271 2012-06-19 04:05:50 X-Scale has left ()
272 2012-06-19 04:06:22 tyn has quit (Ping timeout: 245 seconds)
273 2012-06-19 04:28:07 maaku has quit (Quit: maaku)
274 2012-06-19 04:43:19 enquirer_ has joined
275 2012-06-19 04:44:42 guruvan has quit ()
276 2012-06-19 04:45:06 brwyatt is now known as brwyatt|Away
277 2012-06-19 04:45:42 enquirer has quit (Ping timeout: 246 seconds)
278 2012-06-19 04:45:45 enquirer_ is now known as enquirer
279 2012-06-19 04:46:02 osmosis has quit (Quit: Leaving)
280 2012-06-19 04:47:20 guruvan has joined
281 2012-06-19 04:54:15 Motest003 has quit (Remote host closed the connection)
282 2012-06-19 04:54:37 guruvan is now known as guruvan_
283 2012-06-19 05:10:16 MobiusL has quit (Quit: Ex-Chat)
284 2012-06-19 05:14:23 MobiusL has joined
285 2012-06-19 05:20:10 Quaix has joined
286 2012-06-19 05:21:40 <MysteryBanshee> Has anyone thought about making a plugin system for the official bitcoin client?
287 2012-06-19 05:21:51 <MysteryBanshee> I was thinking, there might be ideas that will make bitcoin appeal to a wider audience
288 2012-06-19 05:22:19 <MysteryBanshee> With features such as skinning, built-in charts, games, flexible backup system (to USB drive, CD, network, email)
289 2012-06-19 05:22:25 <MysteryBanshee> But also I realise people dont want feature creep
290 2012-06-19 05:22:45 <MysteryBanshee> So what if the dev team made a modular plugin system where features can be turned on and off at choice?
291 2012-06-19 05:23:33 <MysteryBanshee> Is this an idea?
292 2012-06-19 05:24:35 <MysteryBanshee> gmaxwell, [Tycho], sipa, anyone?
293 2012-06-19 05:24:41 <[Tycho]> Hello.
294 2012-06-19 05:24:46 <MysteryBanshee> Hi
295 2012-06-19 05:25:04 <[Tycho]> I'm not a client developer, sorry.
296 2012-06-19 05:25:25 <MysteryBanshee> oh
297 2012-06-19 05:25:59 jo__ has quit (Quit: Leaving)
298 2012-06-19 05:27:46 <gmaxwell> MysteryBanshee: Perhaps, but perhaps notâ it would depend on a lot of things.
299 2012-06-19 05:27:59 <MysteryBanshee> oh
300 2012-06-19 05:28:06 <MysteryBanshee> such as?
301 2012-06-19 05:28:16 <gmaxwell> MysteryBanshee: puting a lot of potentially untrusted code in the process handling the user's private keys doesn't sound wise. And things like 'skinning' would be pretty invasive to implement.
302 2012-06-19 05:28:43 <MysteryBanshee> what about if each plugin had its own process and used IPC to communicate?
303 2012-06-19 05:28:51 <gmaxwell> What might be interesting is first creating a tightly sandboxed sidecar pluging system that runs along side bitcoin and uses the RPC.
304 2012-06-19 05:29:06 <MysteryBanshee> yeh something like that
305 2012-06-19 05:29:29 <gmaxwell> That doesn't let you get skinning does it does allow things like games. Which I do think is a neat idea.
306 2012-06-19 05:29:39 <MysteryBanshee> Im just thinking, because, when people download the bitcoin client theres not alot to do... if we had like a MtGox plugin, an intersango plugin, a bitcoin-otc plugin, it would be much more intuitive
307 2012-06-19 05:29:45 <Ukto> games? 0,o build SD right into clients? :P
308 2012-06-19 05:29:50 <Ukto> create even more txn fodder?
309 2012-06-19 05:29:55 <MysteryBanshee> yes Ukto
310 2012-06-19 05:29:58 <gmaxwell> Ukto: they don't have to be TXN inefficient.
311 2012-06-19 05:30:22 <MysteryBanshee> I remember reading about probabilistic TXNs
312 2012-06-19 05:30:27 <Ukto> i think the standard client should just be a standard client
313 2012-06-19 05:30:29 <MysteryBanshee> that may be used in SD in the future
314 2012-06-19 05:30:38 <gmaxwell> MysteryBanshee: 'SD in the client' is a very bad idea and is perhaps an argument against such things.
315 2012-06-19 05:30:42 <Ukto> if someone wants to make a special client with bells/whistles/plugins, thats another deal
316 2012-06-19 05:30:49 <Ukto> but i do like the idea
317 2012-06-19 05:30:50 <Ukto> :)
318 2012-06-19 05:30:57 <gmaxwell> if SD wanted to not be so bloaty it wouldn't have to.
319 2012-06-19 05:31:10 <MysteryBanshee> Ukto: technically the client would come with nothing, its up to the user to browse/install/download what plugin he/she wants
320 2012-06-19 05:31:12 <Ukto> couldnt they just use sendmany anyways?
321 2012-06-19 05:31:17 <MysteryBanshee> perhaps with a plugin browser
322 2012-06-19 05:31:31 <gmaxwell> In any case. Making a sandboxed lua enviroment which can talk to a filtered subset of RPC.. sounds grand to me.
323 2012-06-19 05:31:33 l1l1ll11l11 has quit (Quit: Leaving.)
324 2012-06-19 05:31:50 <Ukto> hmm, isnt there a browser plugin that RPC's to the client?
325 2012-06-19 05:31:54 <gmaxwell> Ukto: they could do lots of things. Sendmany, have accounts, etc.
326 2012-06-19 05:31:57 <MysteryBanshee> gmaxwell: could you propose the idea to gavinandressen for me anyway :)
327 2012-06-19 05:32:22 <gmaxwell> he'll probably read it in the logs. But it's not something that would be high on the priority list for some time.
328 2012-06-19 05:32:22 <Ukto> MysteryBanshee: im sure he would be interested, but as he has said for other things, it would be pretty low on the list :)
329 2012-06-19 05:32:39 <gmaxwell> (The idea of plugins isn't at all a new thing)
330 2012-06-19 05:32:49 <MysteryBanshee> oh, its been proposed before?
331 2012-06-19 05:32:54 <gmaxwell> Yes, many times.
332 2012-06-19 05:33:02 <gmaxwell> If you'd personally like to work on it, thats somewhat interesting. Otherwise, meh.
333 2012-06-19 05:33:37 <MysteryBanshee> I have thought about a fork but to be honist, its beyond my skills right now to get it done securely and effieciently
334 2012-06-19 05:34:15 <gmaxwell> Trying is the best way to learn, even if you fail.
335 2012-06-19 05:34:52 <MysteryBanshee> :/
336 2012-06-19 05:36:32 <MysteryBanshee> Perhaps, lol, but I think someone with better coding skills than me would have far better luck
337 2012-06-19 05:36:49 <MysteryBanshee> Theres alot of features that would be really useful in the client that wouldnt even be hard to do... like for example, a calculator plugin
338 2012-06-19 05:37:05 <gmaxwell> probably, but no one with better coding skills is going to work on it soon.
339 2012-06-19 05:37:05 <MysteryBanshee> It would be nice if someone could write a proof of concept plugin system with like 1 or 2 plugins
340 2012-06-19 05:37:27 <MysteryBanshee> :)
341 2012-06-19 05:37:28 hahuang65 has joined
342 2012-06-19 05:37:57 ThomasV has joined
343 2012-06-19 05:42:26 <MysteryBanshee> I might consider putting a bounty for it :)
344 2012-06-19 05:42:43 <MysteryBanshee> I think it might really increase the number of users, just if it had a few simple plugins to begin with, like say a BTC Faucet plugin and a calculator plugin
345 2012-06-19 05:43:09 <MysteryBanshee> And perhaps a "Bitcoin Tutorial plugin"
346 2012-06-19 05:45:12 <gmaxwell> I'd probably recommend against that.
347 2012-06-19 05:45:20 <MysteryBanshee> oh, how come gmaxwell?
348 2012-06-19 05:45:23 l1l1ll11l11 has joined
349 2012-06-19 05:46:14 <gmaxwell> You'll get someone creating some quickest possible will never be merged ever thing in order to collect your bounty, and then you'll be in the uncomfortable state of either paying someone for something that isn't actually useful, or having to tell someone you won't pay them when they already put in work.
350 2012-06-19 05:46:28 <gmaxwell> Scoping out that sort of thing is an unsolved problem.
351 2012-06-19 05:46:37 <MysteryBanshee> oh
352 2012-06-19 05:46:53 <gmaxwell> And if you instead make the payment requirement getting it mergedâ the core devs don't want pressure from people trying to get stuff merged so they can get paid.
353 2012-06-19 05:47:26 <gmaxwell> I mean if you just want to offer a tiny bounty or something, I suppose thats no issue. But it probably won't motivate anyone to do it.
354 2012-06-19 05:47:32 <MysteryBanshee> what if one of the dev's escrowed the bounty payment and a condition of the payment was that it was acceptable to x number of devs
355 2012-06-19 05:47:44 <gmaxwell> MysteryBanshee: you get the pressure thing.
356 2012-06-19 05:48:17 <MysteryBanshee> oh
357 2012-06-19 05:48:19 <gmaxwell> We've got enough to do when not dealing with people who have income incentives.
358 2012-06-19 05:48:27 <gmaxwell> (Including a backlog of pull requests)
359 2012-06-19 05:49:19 <MysteryBanshee> is the bitcoin wiki free for any one to edit?
360 2012-06-19 05:49:42 <gmaxwell> Yes, you need to make an account.
361 2012-06-19 05:49:58 <MysteryBanshee> I wont try the bounty idea then... is it ok to just propose my idea there?
362 2012-06-19 05:51:12 <freewil> the forums are a better place for that unless you're going to carefully write up a proper BIP
363 2012-06-19 05:51:32 <freewil> ... bitcoin improvement proposal
364 2012-06-19 05:51:57 <freewil> and i think this might be too client-specific for a BIP
365 2012-06-19 05:53:12 <MysteryBanshee> it would be nice if the plugins were cross-client though
366 2012-06-19 05:53:27 <MysteryBanshee> ie, you could use a plugin in Electrum or the official client
367 2012-06-19 05:53:50 <gmaxwell> Well, personally I'd like a pony. A pony made of cake. :)
368 2012-06-19 05:54:04 <MysteryBanshee> lol
369 2012-06-19 05:54:37 <freewil> that sounds nice but probably a fantasy
370 2012-06-19 05:55:10 <gmaxwell> freewil: only .. half made of cake then?
371 2012-06-19 05:55:23 mmoya has joined
372 2012-06-19 05:55:46 <freewil> im going for the full on unicorn cake
373 2012-06-19 05:56:36 enquirer has quit (Ping timeout: 250 seconds)
374 2012-06-19 05:57:08 RazielZ has joined
375 2012-06-19 05:57:12 wereHamster has quit (Quit: Lost terminal)
376 2012-06-19 05:57:17 <MysteryBanshee> freewil: why a fantasy?
377 2012-06-19 05:57:32 <MysteryBanshee> if the plugin system was documented and used a popular scripting system like Lua
378 2012-06-19 05:57:37 <MysteryBanshee> why would that not be possible?
379 2012-06-19 05:57:38 <gmaxwell> MysteryBanshee: the functionality available in different clients is very different.
380 2012-06-19 05:57:43 <freewil> what about all the different gui elements
381 2012-06-19 05:58:01 <gmaxwell> I mean if the plugin had no interaction at all with bitcoin, then perhapsâ but whats the point of a plugin then?
382 2012-06-19 05:58:10 <MysteryBanshee> the plugin system could use its own window, and simply use a standardised protocol to communicate with the client
383 2012-06-19 05:58:21 <MysteryBanshee> gmaxwell: its purely for ease of use
384 2012-06-19 05:58:34 <freewil> why not just use rpc then
385 2012-06-19 05:58:52 <gmaxwell> freewil: it's not like anything _else_ offers the rpc interface.
386 2012-06-19 05:59:23 <MysteryBanshee> freewil: that is possible
387 2012-06-19 06:00:21 <freewil> gmaxwell, not sure what you mean there? sarcasm?
388 2012-06-19 06:01:20 <gmaxwell> freewil: No. It's a statement of fact. If it uses the rpc interface it won't be portable to other clients because the other clients have nothing like that.
389 2012-06-19 06:01:32 <freewil> oh
390 2012-06-19 06:01:52 <freewil> well i think the different guis would probably be the biggest hurdle
391 2012-06-19 06:02:21 <freewil> it'd be like trying to make a modern web app work in ie6
392 2012-06-19 06:02:48 <gmaxwell> A process seperated plugin can't be part of the same gui interface anyways, not without horribleness.
393 2012-06-19 06:03:57 <freewil> actually what if you made the gui html-based
394 2012-06-19 06:04:33 <gmaxwell> Have fun with that!
395 2012-06-19 06:06:04 <freewil> i guess you'd just have to use some sort of common gui interface
396 2012-06-19 06:06:11 <freewil> that could be html, xul, xaml whatever
397 2012-06-19 06:06:22 <freewil> just not sure how easy that would be to implement across all the clients
398 2012-06-19 06:06:39 <MysteryBanshee> freewil: HTML-based is possible indeed, there are many easy solutions
399 2012-06-19 06:07:03 <MysteryBanshee> its the scripting system that worries me, lol, how to implement that...
400 2012-06-19 06:07:41 <freewil> building a plugin system on the current satoshi client sounds like a real waste of time
401 2012-06-19 06:07:46 <freewil> plenty of more important things
402 2012-06-19 06:08:47 <MysteryBanshee> the current satoshi client is too complex to use...
403 2012-06-19 06:09:00 <gmaxwell> MysteryBanshee: two complex?!
404 2012-06-19 06:09:03 <MysteryBanshee> alot of features that are already in it, would be better as a module
405 2012-06-19 06:09:18 <gmaxwell> if it were any simpler there would just be one button that said GIVE ALL MY COIN TO SOMEONE AT RANDOM.
406 2012-06-19 06:09:18 <MysteryBanshee> or perhaps unintuitive
407 2012-06-19 06:09:27 <gmaxwell> s/two/too/
408 2012-06-19 06:09:30 ovidiusoft has joined
409 2012-06-19 06:09:48 <luke-jr> testnet3 is totally broken
410 2012-06-19 06:09:50 <luke-jr> sigh
411 2012-06-19 06:09:57 <gmaxwell> luke-jr: huh?
412 2012-06-19 06:10:16 <gmaxwell> luke-jr: it was adversely impacted by that bug I fixed a day ago.. but otherwise?
413 2012-06-19 06:10:16 <luke-jr> gmaxwell: it thinks there's 40k blocks to download, but never makes any progress
414 2012-06-19 06:10:31 <MysteryBanshee> gmaxwell: ok for most users here its simple, but I was thinking, how could you introduce bitcoin to a 8 year old
415 2012-06-19 06:10:36 <gmaxwell> luke-jr: Wow, wouldn't have expected that to fool you.
416 2012-06-19 06:10:42 D34TH has quit (Quit: kills self)
417 2012-06-19 06:10:44 <luke-jr> â¦
418 2012-06-19 06:10:58 <freewil> MysteryBanshee, 8-year olds dont need to play SD /s
419 2012-06-19 06:11:00 <gmaxwell> luke-jr: it's fully synced up. The report is because of the wonderful GUI code beleving the median of the peers claims.
420 2012-06-19 06:11:38 <gmaxwell> luke-jr: you've got some old peers, and they're telling you there is 40k blocks. In reality there are...
421 2012-06-19 06:11:53 <luke-jr> gmaxwell: I thought the magic bytes were changed so testnet3 wouldn't even talk to them?
422 2012-06-19 06:11:56 <gmaxwell> 7198.
423 2012-06-19 06:12:11 <gmaxwell> Were they?
424 2012-06-19 06:12:13 <gmaxwell> hm.
425 2012-06-19 06:12:24 <luke-jr> I have 7187 blocks
426 2012-06-19 06:12:38 <luke-jr> is there a peer I can addnode?
427 2012-06-19 06:12:43 <gmaxwell> sure.
428 2012-06-19 06:14:08 <luke-jr> can you tell me what it is?
429 2012-06-19 06:14:40 <luke-jr> <.<
430 2012-06-19 06:14:42 <gmaxwell> luke-jr: see PM
431 2012-06-19 06:14:45 <gmaxwell> (I did!)
432 2012-06-19 06:14:53 <luke-jr> o ty
433 2012-06-19 06:16:02 <gmaxwell> In any case, I don't think the network magic was changedâ though perhaps it should have been. But doing so would break tools that speak the network protocol.
434 2012-06-19 06:16:17 * luke-jr ponders a testnet mode that switches to a testnet "pool" only when its difficulty drops
435 2012-06-19 06:16:23 <luke-jr> (for miners)
436 2012-06-19 06:18:49 <gmaxwell> that would be nice, I have a hack now that makes testnet cpu mine when the difficulty drops.
437 2012-06-19 06:19:04 <gmaxwell> (because I was too lazy to do what you've done)
438 2012-06-19 06:19:25 <gmaxwell> might be better to even be able to set a time.. so that it only starts after a half hour or something. ::shrugs::
439 2012-06-19 06:20:11 <luke-jr> haven't done
440 2012-06-19 06:20:12 <luke-jr> just thought of
441 2012-06-19 06:20:32 <luke-jr> hmm, Bitcoin-Qt is segfaulting a lot trying to mine on it directly
442 2012-06-19 06:22:37 ThomasV has quit (Ping timeout: 245 seconds)
443 2012-06-19 06:30:39 l1l1ll11l11 has quit (Quit: Leaving.)
444 2012-06-19 06:31:16 RainbowDashh has joined
445 2012-06-19 06:31:42 <MysteryBanshee> gmaxwell/anyone else interested: I have created a draft of my idea... https://en.bitcoin.it/wiki/Plug-in_System any feedback?
446 2012-06-19 06:31:44 maaku has joined
447 2012-06-19 06:37:18 wizkid057 has quit (Read error: Operation timed out)
448 2012-06-19 06:41:03 yellowhat has quit (Ping timeout: 246 seconds)
449 2012-06-19 06:42:34 <luke-jr> MysteryBanshee: â¦
450 2012-06-19 06:42:50 <luke-jr> MysteryBanshee: that's already been invented a few times
451 2012-06-19 06:42:59 <luke-jr> it's called XUL, Chromium, and a few other names I think
452 2012-06-19 06:44:50 <MysteryBanshee> luke-jr: but its never been implemented in bitcoin
453 2012-06-19 06:44:54 <MysteryBanshee> in a bitcoin client :)
454 2012-06-19 06:45:06 <luke-jr> because it doesn't belong there.
455 2012-06-19 06:45:13 <MysteryBanshee> luke-jr: it doesnt?
456 2012-06-19 06:45:16 <luke-jr> no.
457 2012-06-19 06:45:26 <MysteryBanshee> why not?
458 2012-06-19 06:46:07 <luke-jr> because Bitcoin's goal is to be a currency, not a web browser
459 2012-06-19 06:46:42 <MysteryBanshee> im not proposing it becomes a web browser
460 2012-06-19 06:47:15 <MysteryBanshee> im just proposing that different services in bitcoin are brought under a single application
461 2012-06-19 06:47:33 <MysteryBanshee> so new users dont need to go around figuring out how to do everything
462 2012-06-19 06:48:41 <MysteryBanshee> it would be better to help people when they download teh software, than to have people flock to teh forums or irc all the time
463 2012-06-19 06:50:05 <weex> MysteryBanshee: i think the main concern with the wallet is security and that plugin system would have to offer some serious benefits to counter the potential security issues
464 2012-06-19 06:50:40 <wumpus> yeah, there's no way there will be html (except the limited qt rich text subset) anywhere near the client, just too much risk. This may be a good idea for one of the other (thin) wallets applications but not the satoshi client.
465 2012-06-19 06:50:45 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
466 2012-06-19 06:50:46 <gmaxwell> I mean the very first comment I made: 22:24 < gmaxwell> MysteryBanshee: puting a lot of potentially untrusted code in the process handling the user's private keys doesn't sound wise. And things like 'skinning' would be pretty invasive to implement.
467 2012-06-19 06:50:57 <gmaxwell> and now you're suggesting using a web browser in the client.
468 2012-06-19 06:51:29 <weex> you could see if one of the other clients wants to do that though
469 2012-06-19 06:52:54 yellowhat has joined
470 2012-06-19 06:53:01 <wumpus> and if you see how much trouble even merging URL support gives :-)
471 2012-06-19 06:53:27 <wumpus> anything that opens up an attack surface...
472 2012-06-19 06:54:50 <MysteryBanshee> gmaxwell: i thought we agreed the plugins would use a seperate process
473 2012-06-19 06:55:04 <MysteryBanshee> gmaxwell: it would not handle private keys, the client does that, the plugin simply sends requests via IPC
474 2012-06-19 06:55:10 RainbowDashh has joined
475 2012-06-19 06:55:18 <MysteryBanshee> gmaxwell: skinning im not sure how to do that safely, but im sure it can be done
476 2012-06-19 06:55:31 <wumpus> if it can send requests through IPC it can already do everything
477 2012-06-19 06:55:34 <gmaxwell> ... except your now predicating it on the client UI being in the same browser.
478 2012-06-19 06:55:48 <gmaxwell> Which breaks the process seperation.
479 2012-06-19 06:55:52 <wumpus> "skinning" you mean changing the theme? that's already possible with qt as-is
480 2012-06-19 06:55:52 <MysteryBanshee> gmaxwell: huh?
481 2012-06-19 06:56:11 <MysteryBanshee> ok, forget skinning for now
482 2012-06-19 06:56:23 <MysteryBanshee> the client UI is not the same as the plugin UI...
483 2012-06-19 06:56:25 <gmaxwell> wumpus: you could have a plugin executor that filters the IPC, so thats not a killer issue on its own.
484 2012-06-19 06:56:36 <weex> there are some clients to the rpc interface around right?
485 2012-06-19 06:57:38 <gribble> New news from bitcoinrss: xanatos opened pull request 1485 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1485>
486 2012-06-19 06:59:12 <wumpus> no issue is a killer issue on its own, it's just the combination of things and the added complexity and attack surface
487 2012-06-19 07:00:12 <MysteryBanshee> wumpus: and there would be many things to protect users, such as a feedback rating system on the plugins... and the option to disable the entire plugin system if a user chooses
488 2012-06-19 07:00:14 <wumpus> of course you could try to filter things, but those things tend to have subtle bugs, it's very hard to keep a sandbox airtight. And it would be a prime target...
489 2012-06-19 07:01:04 <MysteryBanshee> wumpus: most of the modules would be trusted and open-source and scrutinised heavily
490 2012-06-19 07:01:32 <MysteryBanshee> they could even be cryptographically signed by trusted developers
491 2012-06-19 07:01:37 <MysteryBanshee> before even being executed
492 2012-06-19 07:01:57 <wumpus> anyway, if there were many people dying to add features to bitcoin-qt that we are somehow unable to accept, we'd have noticed in the pull request list...
493 2012-06-19 07:01:59 <MysteryBanshee> to proove they are compiled from source
494 2012-06-19 07:02:40 <wumpus> the only thing mildly controversial at the moment is the coin control stuff, which goes very deep into the internals so wouldn't really work as a plugin anyway
495 2012-06-19 07:02:57 <MysteryBanshee> wumpus: plugin systems are often underestimated, look at winamp for example... the plugin system pretty much made that as popular as it is today... people may not see it yet, but years down the line it could make bitcoin much more popular/usable
496 2012-06-19 07:03:12 <MysteryBanshee> wumpus: it wouldnt control coins though...
497 2012-06-19 07:03:19 <MysteryBanshee> wumpus: it would simply send requests via IPC
498 2012-06-19 07:03:28 <gmaxwell> We do have a little backlog. But I don't see how plugins would address any of this at all, because some of the backloged stuff is backlogged in part because its scarry part touching.
499 2012-06-19 07:03:48 <wumpus> the backlog is generally the dangerous core stuff, not gui fun
500 2012-06-19 07:04:09 ThomasV has joined
501 2012-06-19 07:04:17 <gmaxwell> yea, the gui stuff gets merged pretty quickly in general.
502 2012-06-19 07:05:12 <MysteryBanshee> gmaxwell: plugins would reduce the bitcoin client to its minimal, and allow developers to focus on that, while other people develop plugins
503 2012-06-19 07:05:23 <MysteryBanshee> to make it more usable
504 2012-06-19 07:05:44 <wumpus> it is already pretty minimal.. it's not like we have kitchen sink syndrome
505 2012-06-19 07:05:47 <gmaxwell> They would also cure war, bringing peace to the world and save endangered speces.
506 2012-06-19 07:05:54 <gmaxwell> Think of the pandas!
507 2012-06-19 07:05:57 <wumpus> hehe
508 2012-06-19 07:05:59 <gmaxwell> Sad sad pandas.
509 2012-06-19 07:06:06 <luke-jr> sigh
510 2012-06-19 07:06:10 <MysteryBanshee> it would also reduce people making too many different clients, because instead of someone developing a new client just to add a few features they like, they can simply develop a new module instead
511 2012-06-19 07:06:14 <luke-jr> 85 more blocks till I can spend my TN3 coins
512 2012-06-19 07:06:25 <gmaxwell> luke-jr: if you wanted I would have just sent you some. :)
513 2012-06-19 07:06:32 <gmaxwell> luke-jr: gimme an address.
514 2012-06-19 07:06:51 <wumpus> the people developing their own clients usually have deep technical reasons
515 2012-06-19 07:07:05 <wumpus> not "hey, I want to add this and this feature"
516 2012-06-19 07:07:26 <luke-jr> gmaxwell: I did ask yesterday:P
517 2012-06-19 07:07:33 <luke-jr> n42rRpKcTpxkqkLBxEoqT3ddDGyLJmGZJJ
518 2012-06-19 07:07:47 copumpkin has quit (Ping timeout: 246 seconds)
519 2012-06-19 07:07:55 <gmaxwell> luke-jr: ?!
520 2012-06-19 07:08:07 <wumpus> also I don't think it's a problem that there are more clients
521 2012-06-19 07:08:12 <luke-jr> MysteryBanshee: more clients is a good thing; one problem with Bitcoin today is the software centralization
522 2012-06-19 07:08:17 <wumpus> yep...
523 2012-06-19 07:08:20 copumpkin has joined
524 2012-06-19 07:08:34 <MysteryBanshee> luke-jr: yes, but if there are 50 clients that will just spread the developers a bit thin wouldnt it?
525 2012-06-19 07:08:54 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
526 2012-06-19 07:09:06 <luke-jr> MysteryBanshee: even 2 would be an improvement
527 2012-06-19 07:09:13 <wumpus> I think you see that wrong.. the developers starting their own client would usually never join another project
528 2012-06-19 07:09:31 <luke-jr> wumpus: to be fair, I kindof did
529 2012-06-19 07:09:35 <MysteryBanshee> wumpus: yes, but with a plugin system that could change...
530 2012-06-19 07:09:56 <luke-jr> wumpus: my main reason for working on Spesmilo last year, was because it was Qt instead of wx ;)
531 2012-06-19 07:10:35 <gmaxwell> luke-jr: and you shall never be testnet hungry again.
532 2012-06-19 07:10:54 <luke-jr> gmaxwell: wow, thanks
533 2012-06-19 07:11:05 <luke-jr> gmaxwell: but you mean, until Gavin resets testnet again ;)
534 2012-06-19 07:11:20 <gmaxwell> or until I rewrite this chunk of the chain.
535 2012-06-19 07:11:22 <gmaxwell> :)
536 2012-06-19 07:11:30 <luke-jr> <.<
537 2012-06-19 07:11:48 <gmaxwell> maybe I'm already rewriting it. dum dum dum. :)
538 2012-06-19 07:12:47 <wumpus> luke-jr: yes, spesmilo was ahead of its time :)
539 2012-06-19 07:13:18 <MysteryBanshee> gmaxwell: so is the main problem with my idea just security?
540 2012-06-19 07:13:21 <wumpus> only reason for not using that was that I didn't think embedding python and pyqt4 was a good idea
541 2012-06-19 07:15:40 <luke-jr> wumpus: hah, now we have Matt embedding Python just for automatic upgrades <.<
542 2012-06-19 07:15:52 <wumpus> yes, the problem with your idea is security (not "just" security, security should be the main requirement)
543 2012-06-19 07:15:52 <luke-jr> MysteryBanshee: and the kitchen sink too
544 2012-06-19 07:16:18 <wumpus> luke-jr: in hindsight... :p
545 2012-06-19 07:16:40 <luke-jr> but more seriously, I think it'd be viable to modify Bitcoin-Qt to be embedable ;)
546 2012-06-19 07:16:43 <gmaxwell> MysteryBanshee: no the main problem with your idea is that it's missing the _most_ important part.
547 2012-06-19 07:16:56 <luke-jr> and have another program embed it and other "plugins"
548 2012-06-19 07:17:38 <gmaxwell> â a person who will actually implement something. But beyond that, yes, security should be a prime criteria in everything we do.
549 2012-06-19 07:17:57 <luke-jr> too true
550 2012-06-19 07:18:11 <luke-jr> nothing gets anywhere without a developer behind it :p
551 2012-06-19 07:19:10 <gmaxwell> and presumably someone who actually did something would throw out half your ideas, if not more, and replace them with whatever they think would be possible/useful to implement.
552 2012-06-19 07:19:21 <gmaxwell> Ideas are cheap. Show me the code. (says I... oh well)
553 2012-06-19 07:19:31 <wumpus> yes, people actually implementing something are also rare ... especially the people with big ideas generally disappear very fast when you ask them to implement something
554 2012-06-19 07:21:00 <MysteryBanshee> gmaxwell: well, im not sure who will do it, but i think the first step is to figure out how to design it best first
555 2012-06-19 07:21:26 <gmaxwell> And what makes you think you're qualified to do that when you don't think you're qualified to actually do the work?
556 2012-06-19 07:21:40 <MysteryBanshee> im not tbh
557 2012-06-19 07:21:50 <MysteryBanshee> which is why im asking you gmaxwell, you seem to be one of the most insightful people here
558 2012-06-19 07:22:00 <gmaxwell> (I'm not saying you're not qualified to do itâ I did after all encourage you to try)
559 2012-06-19 07:22:25 <gmaxwell> In any case, I'm not trying to discourage you. I think you should try. If you really don't know how you'll fail, but you'll learn a bunch of stuff in the process.
560 2012-06-19 07:22:46 <MysteryBanshee> i might give it a try, even if its just a simple system with a Hello World module that can get the balance from the client
561 2012-06-19 07:22:56 <gmaxwell> You should.
562 2012-06-19 07:23:07 wereHamster has joined
563 2012-06-19 07:24:09 <gmaxwell> What you learn will also influence what you think about the design of the idea. Or in the process you may even find something else to do instead which is a little less ambitious and more within your reach and we'll all benefit. There is nothing but upsides to trying.
564 2012-06-19 07:28:46 <luke-jr> wumpus: some of the people implement it, and get tired of rebasing for months ;)
565 2012-06-19 07:29:03 <wumpus> luke-jr: yes, I don't think it'd be too difficult technically, still thinking about a viable IPC protocol for the UI though... json-rpc just doesn't cut it if you want events/notifications
566 2012-06-19 07:29:35 <luke-jr> wumpus: I thought of that probably over a year ago now⦠it got hairy
567 2012-06-19 07:29:44 <ThomasV> MysteryBanshee: do you know about libbitcoin?
568 2012-06-19 07:29:48 <luke-jr> wumpus: https://en.bitcoin.it/wiki/Wallet_protocol
569 2012-06-19 07:29:56 <gmaxwell> wumpus: just limit it to simple buttons in order to bring up a UI actually provided by the plugin.
570 2012-06-19 07:30:21 <wumpus> luke-jr: yeah I've seen that page
571 2012-06-19 07:40:16 ThomasV has quit (Quit: Quitte)
572 2012-06-19 07:43:01 <luke-jr> hmm
573 2012-06-19 07:43:06 <luke-jr> all my transactions show 01/01/1970
574 2012-06-19 07:43:13 <luke-jr> I think maybe refactor_times has a bug <.<
575 2012-06-19 07:44:08 sirk390 has joined
576 2012-06-19 07:50:21 TD has joined
577 2012-06-19 07:53:55 wizkid057 has joined
578 2012-06-19 07:59:15 TD has quit (Quit: TD)
579 2012-06-19 08:01:00 gjs278 has quit (Quit: Konversation terminated!)
580 2012-06-19 08:01:15 gjs278 has joined
581 2012-06-19 08:10:19 t7 has joined
582 2012-06-19 08:15:56 Tykling has quit (Excess Flood)
583 2012-06-19 08:17:28 Tykling has joined
584 2012-06-19 08:17:48 Tykling has quit (Excess Flood)
585 2012-06-19 08:17:57 molecular has quit (Ping timeout: 252 seconds)
586 2012-06-19 08:18:12 RainbowDashh has joined
587 2012-06-19 08:18:41 wereHamster has quit (Ping timeout: 252 seconds)
588 2012-06-19 08:18:46 molecular has joined
589 2012-06-19 08:20:33 wereHamster has joined
590 2012-06-19 08:24:28 Tykling has joined
591 2012-06-19 08:27:02 leotreasure has joined
592 2012-06-19 08:36:29 maaku has quit (Quit: maaku)
593 2012-06-19 08:52:21 Prattler has joined
594 2012-06-19 08:57:34 [Tycho] has quit (Read error: Connection reset by peer)
595 2012-06-19 09:00:40 Quaix has quit ()
596 2012-06-19 09:02:48 m00p has joined
597 2012-06-19 09:11:19 <da2ce7> New Open Transactions build for Windows: https://bitcointalk.org/index.php?topic=77301 :)
598 2012-06-19 09:18:41 wizkid057 has quit (Read error: Operation timed out)
599 2012-06-19 09:19:35 wizkid057 has joined
600 2012-06-19 09:25:53 dvide has joined
601 2012-06-19 09:50:26 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
602 2012-06-19 09:52:33 toffoo has quit ()
603 2012-06-19 09:57:08 superjames has quit (Read error: Connection reset by peer)
604 2012-06-19 09:58:27 ThomasV has joined
605 2012-06-19 09:59:13 superjames has joined
606 2012-06-19 10:06:05 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
607 2012-06-19 10:07:18 erle- has joined
608 2012-06-19 10:16:56 drizztbsd has joined
609 2012-06-19 10:18:07 leotreasure has quit (Read error: Connection reset by peer)
610 2012-06-19 10:18:41 leotreasure has joined
611 2012-06-19 10:25:21 brwyatt is now known as brwyatt|Away
612 2012-06-19 10:25:30 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
613 2012-06-19 10:33:00 graingert_ecs has joined
614 2012-06-19 10:34:19 agricocb has quit (Quit: Leaving.)
615 2012-06-19 10:34:39 one_zero has quit ()
616 2012-06-19 10:36:15 genjix has joined
617 2012-06-19 10:37:21 wizkid057 has quit (Read error: Operation timed out)
618 2012-06-19 10:38:23 tyn has joined
619 2012-06-19 10:39:25 wizkid057 has joined
620 2012-06-19 10:40:57 genjix has quit (Ping timeout: 245 seconds)
621 2012-06-19 10:53:10 Turingi has joined
622 2012-06-19 10:58:57 tower has quit (Disconnected by services)
623 2012-06-19 10:59:09 tower has joined
624 2012-06-19 11:02:46 brwyatt is now known as brwyatt|Away
625 2012-06-19 11:03:21 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
626 2012-06-19 11:07:17 sgornick has joined
627 2012-06-19 11:07:56 tyn has quit (Ping timeout: 276 seconds)
628 2012-06-19 11:09:36 setkeh has joined
629 2012-06-19 11:15:30 agricocb has joined
630 2012-06-19 11:20:34 sanchaz has joined
631 2012-06-19 11:29:59 Turingi has quit (Read error: Connection reset by peer)
632 2012-06-19 11:36:24 egecko has joined
633 2012-06-19 11:53:44 datagutt has joined
634 2012-06-19 12:04:29 rdponticelli has joined
635 2012-06-19 12:20:12 tyn has joined
636 2012-06-19 12:25:39 jjjx has joined
637 2012-06-19 12:27:03 att has joined
638 2012-06-19 12:32:52 erle- has quit (Quit: erle-)
639 2012-06-19 12:44:53 rdponticelli_ has joined
640 2012-06-19 12:45:21 brwyatt is now known as brwyatt|Away
641 2012-06-19 12:46:05 rdponticelli has quit (Ping timeout: 276 seconds)
642 2012-06-19 12:49:44 genjix has joined
643 2012-06-19 12:49:59 darkee has quit (Ping timeout: 276 seconds)
644 2012-06-19 12:50:38 minimoose has joined
645 2012-06-19 12:51:38 ThomasV has quit (Ping timeout: 245 seconds)
646 2012-06-19 12:59:22 graingert_ecs has quit (Remote host closed the connection)
647 2012-06-19 12:59:44 graingert_ecs has joined
648 2012-06-19 13:03:14 darkee has joined
649 2012-06-19 13:08:16 wizkid057 has quit (Read error: Operation timed out)
650 2012-06-19 13:09:14 wizkid057 has joined
651 2012-06-19 13:12:21 att has quit (Quit: Leaving)
652 2012-06-19 13:19:04 moop has joined
653 2012-06-19 13:21:54 m00p has quit (Ping timeout: 246 seconds)
654 2012-06-19 13:23:52 copumpkin has quit (Quit: Computer has gone to sleep.)
655 2012-06-19 13:24:39 p0s has joined
656 2012-06-19 13:31:36 _Fireball has joined
657 2012-06-19 13:39:34 Turingi has joined
658 2012-06-19 13:39:34 Turingi has quit (Changing host)
659 2012-06-19 13:39:34 Turingi has joined
660 2012-06-19 13:41:56 copumpkin has joined
661 2012-06-19 13:58:35 erle- has joined
662 2012-06-19 13:58:47 wereHamster has quit (Remote host closed the connection)
663 2012-06-19 13:59:11 wereHamster has joined
664 2012-06-19 14:00:26 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
665 2012-06-19 14:02:54 cdecker has joined
666 2012-06-19 14:09:12 leotreasure has quit (Quit: leotreasure)
667 2012-06-19 14:10:51 ThomasV has joined
668 2012-06-19 14:13:56 leotreasure has joined
669 2012-06-19 14:22:18 wizkid057 has quit (Read error: Operation timed out)
670 2012-06-19 14:23:03 wizkid057 has joined
671 2012-06-19 14:23:10 tyn has quit (Ping timeout: 252 seconds)
672 2012-06-19 14:24:49 Clipse has quit (Ping timeout: 246 seconds)
673 2012-06-19 14:30:10 Cherothald has quit ()
674 2012-06-19 14:30:50 Cherothald has joined
675 2012-06-19 14:31:19 gavinandresen has joined
676 2012-06-19 14:36:50 tyn has joined
677 2012-06-19 14:39:14 cdecker has quit (Quit: Leaving.)
678 2012-06-19 14:39:29 cdecker has joined
679 2012-06-19 14:46:57 ThomasV has quit (Quit: Quitte)
680 2012-06-19 14:48:54 MC1984 has quit (Ping timeout: 260 seconds)
681 2012-06-19 14:49:24 rdponticelli_ has quit (Read error: Connection reset by peer)
682 2012-06-19 14:49:35 guruvan_ has quit (Ping timeout: 276 seconds)
683 2012-06-19 14:52:32 Diablo-D3 has joined
684 2012-06-19 14:52:45 guruvan_ has joined
685 2012-06-19 14:56:04 Clipse has joined
686 2012-06-19 14:57:51 dvide has quit ()
687 2012-06-19 14:59:01 Zarutian has joined
688 2012-06-19 14:59:05 rdponticelli has joined
689 2012-06-19 15:05:56 cdecker has quit (Quit: Leaving.)
690 2012-06-19 15:10:41 dvide has joined
691 2012-06-19 15:13:22 SphericalCow has joined
692 2012-06-19 15:17:49 SphericalCow has quit (Remote host closed the connection)
693 2012-06-19 15:18:34 smtmnyz has quit (Read error: No route to host)
694 2012-06-19 15:19:14 SphericalCow has joined
695 2012-06-19 15:19:15 smtmnyz has joined
696 2012-06-19 15:28:26 setkeh has quit (Ping timeout: 272 seconds)
697 2012-06-19 15:30:03 p0s has quit (Remote host closed the connection)
698 2012-06-19 15:31:55 sgornick has quit (Read error: Connection reset by peer)
699 2012-06-19 15:33:41 jurov is now known as away!aktooj@84.245.71.31|jurov
700 2012-06-19 15:35:38 dk5 has quit (Quit: Leaving)
701 2012-06-19 15:45:48 maaku has joined
702 2012-06-19 15:48:09 Ferroh has quit (Ping timeout: 244 seconds)
703 2012-06-19 15:50:57 maaku has quit (Quit: maaku)
704 2012-06-19 15:51:27 maaku has joined
705 2012-06-19 15:53:08 maaku has quit (Client Quit)
706 2012-06-19 15:54:02 da2ce7 has quit (Read error: Connection timed out)
707 2012-06-19 15:55:29 da2ce7 has joined
708 2012-06-19 15:56:32 gavinandresen has left ()
709 2012-06-19 16:00:38 t7 has quit (Remote host closed the connection)
710 2012-06-19 16:03:41 [Tycho] has joined
711 2012-06-19 16:08:54 p0s has joined
712 2012-06-19 16:08:59 faraday__ has quit (Quit: Connection closed for inactivity)
713 2012-06-19 16:17:32 setkeh has joined
714 2012-06-19 16:19:35 cdecker has joined
715 2012-06-19 16:23:34 <sipa> ;;bc,blocks
716 2012-06-19 16:23:34 <gribble> 185337
717 2012-06-19 16:25:48 leotreasure has quit (Quit: leotreasure)
718 2012-06-19 16:28:56 genjix has quit (Ping timeout: 252 seconds)
719 2012-06-19 16:31:46 titeuf_87 has joined
720 2012-06-19 16:34:04 da2ce720 has joined
721 2012-06-19 16:34:20 da2ce7 has quit (Ping timeout: 248 seconds)
722 2012-06-19 16:36:09 <luke-jr> wumpus: Diapolo wants me to troll you; is there a reason you use the integer 0 to initialize pointer types? :p
723 2012-06-19 16:37:39 <luke-jr> (as opposed to the pointer-type NULL)
724 2012-06-19 16:38:03 rdponticelli_ has joined
725 2012-06-19 16:38:47 rdponticelli has quit (Ping timeout: 276 seconds)
726 2012-06-19 16:38:48 rdponticelli_ is now known as rdponticelli
727 2012-06-19 16:39:07 <gmaxwell> luke-jr: At least in C 0 is defined to be acceptable as a NULL pointer (even when the null pointer isn't zero). I personally prefer to use NULL because its more clear what I mean, but styles differ.
728 2012-06-19 16:39:41 <Diablo-D3> no its not
729 2012-06-19 16:39:48 <drizztbsd> NULL is usually a (void*) 0
730 2012-06-19 16:40:05 <Diablo-D3> gmaxwell: C does not make NULL == an address of 0
731 2012-06-19 16:40:15 <gmaxwell> Diablo-D3: Read what I wrote again.
732 2012-06-19 16:40:21 <Diablo-D3> oh
733 2012-06-19 16:40:23 <Diablo-D3> the other way
734 2012-06-19 16:40:30 <drizztbsd> Diablo-D3: but if (NULL) should return false
735 2012-06-19 16:40:31 <Diablo-D3> yes, you can set your address to any bullshit value
736 2012-06-19 16:40:42 <Diablo-D3> as long as you're consistent
737 2012-06-19 16:40:44 TD has joined
738 2012-06-19 16:40:54 <Diablo-D3> drizztbsd: should, yes
739 2012-06-19 16:41:03 <Diablo-D3> I usually specifically do == NULL
740 2012-06-19 16:41:28 <drizztbsd> if (!strcmp(blablabla))
741 2012-06-19 16:41:30 <gmaxwell> Null doesn't have to be an address of zero, and it isn't on some things (mostly microcontrollers with memmapped hardware registers at zero). But on those devices the compiler is required to treat 0 pointers in the code as NULL too. E.g. NULL==0 will return true. Which is .. mildly psycho, but there you have it.
742 2012-06-19 16:41:41 <drizztbsd> oh sorry, wrong example
743 2012-06-19 16:41:46 PK has joined
744 2012-06-19 16:41:48 <drizztbsd> strcmp does not return NULL :P
745 2012-06-19 16:41:56 <drizztbsd> I mean strstr
746 2012-06-19 16:42:04 <Diablo-D3> gmaxwell: oh god thats example
747 2012-06-19 16:42:05 <Diablo-D3> er
748 2012-06-19 16:42:09 <Diablo-D3> gmaxwell: oh god that example is bad
749 2012-06-19 16:42:36 <luke-jr> gmaxwell: _wtf_
750 2012-06-19 16:42:45 <drizztbsd> often you can use MMU
751 2012-06-19 16:43:08 <Diablo-D3> see, this is why I write my code one way
752 2012-06-19 16:43:13 <zeiris> ;;help
753 2012-06-19 16:43:13 <gribble> The bot responds when you start a line with the ! character. A good starting point for exploring the bot is the !facts command. You can also visit the bot's website for a list of help topics and documentation: http://gribble.sourceforge.net/
754 2012-06-19 16:43:14 <Diablo-D3> "sane 32 and 64 bit platforms only"
755 2012-06-19 16:43:19 <sipa> so, casting the integer 0 to a pointer always yields the NULL pointer defined for that system?
756 2012-06-19 16:43:42 <Diablo-D3> but like I said, I always compare addresses properly
757 2012-06-19 16:43:44 <Diablo-D3> == NULL, etc
758 2012-06-19 16:43:50 <Diablo-D3> so its obvious what the code does
759 2012-06-19 16:43:54 <sipa> yeah
760 2012-06-19 16:43:57 <Diablo-D3> and theres nothing wrong with overly obvious code
761 2012-06-19 16:44:05 maaku has joined
762 2012-06-19 16:44:10 <sipa> i wish pointers were not castable to pointers, and NULL was a separately defined constant
763 2012-06-19 16:44:18 <Diablo-D3> sipa: errr
764 2012-06-19 16:44:21 <Diablo-D3> malloc void *.
765 2012-06-19 16:44:22 <sipa> eh
766 2012-06-19 16:44:22 <luke-jr> sipa: O.o?
767 2012-06-19 16:44:27 <Diablo-D3> how do you make objects now
768 2012-06-19 16:44:29 <drizztbsd> sipa: use ADA :P
769 2012-06-19 16:44:33 <sipa> *integers* not castable to pointer
770 2012-06-19 16:44:36 <luke-jr> ah
771 2012-06-19 16:44:38 <Diablo-D3> ahh
772 2012-06-19 16:44:43 <Diablo-D3> sipa: yes, but thats wrong too
773 2012-06-19 16:44:48 <luke-jr> Diablo-D3: also, C++ *does* forbid implicit casting with void* ;)
774 2012-06-19 16:44:56 <sipa> indeed
775 2012-06-19 16:44:57 <Diablo-D3> integers that arent special pointer c99 types not castable back and forth
776 2012-06-19 16:45:07 <Diablo-D3> like uintptr_t and shit
777 2012-06-19 16:46:12 <jrmithdobbs> yes they are, it just spits warnings according to the spec, it's not an error
778 2012-06-19 16:46:59 <sipa> jrmithdobbs: ok
779 2012-06-19 16:47:02 <sipa> could be
780 2012-06-19 16:47:36 <TD> sipa: NULL is defined to be __null in c++
781 2012-06-19 16:48:21 <jrmithdobbs> it should be avoided, of course, in most circumstances unless you're 100% sure of the results and doing it any other way would add complexity, but we all know that
782 2012-06-19 16:48:25 <jrmithdobbs> heh
783 2012-06-19 16:49:10 <zeiris> ;;thash
784 2012-06-19 16:49:10 <gribble> I do not know about 'thash', but I do know about these similar topics: 'trade'
785 2012-06-19 16:49:13 <zeiris> ;;total
786 2012-06-19 16:49:14 <gribble> Error: "total" is not a valid command.
787 2012-06-19 16:49:18 <gmaxwell> jrmithdobbs: wasn't it you that had that capabilities patch for bitcoin a while back?
788 2012-06-19 16:49:20 <zeiris> ;;blockchain
789 2012-06-19 16:49:21 <gribble> I do not know about 'blockchain', but I do know about these similar topics: 'blockchainsnapshot'
790 2012-06-19 16:49:33 <zeiris> ;;difficulty
791 2012-06-19 16:49:34 <gribble> Error: "difficulty" is not a valid command.
792 2012-06-19 16:49:35 <jrmithdobbs> gmaxwell: ya i think i accidentally killed that repo
793 2012-06-19 16:49:55 <jrmithdobbs> gmaxwell: i just added a function in main before logs or anything were open to do it, why?
794 2012-06-19 16:50:15 <gmaxwell> jrmithdobbs: Have you looked at seccomp mode 2 yet? It's pretty awesome. You install a berkley packet filter to ACL every syscall the app makes. Other than writing the filter it's as easy to use as capabilities.
795 2012-06-19 16:50:30 <gmaxwell> ( http://outflux.net/teach-seccomp/ )
796 2012-06-19 16:50:57 <jrmithdobbs> gmaxwell: no I haven't because you can already do similar with pf and most of my personal machines are free/openbsd ;p
797 2012-06-19 16:51:34 <gmaxwell> jrmithdobbs: huh? PF filters syscalls? E.g. preventing apps from performing I/O outside of their dot directory?
798 2012-06-19 16:51:44 <jrmithdobbs> oh i misread
799 2012-06-19 16:52:00 <jrmithdobbs> gmaxwell: looking now
800 2012-06-19 16:53:37 <jrmithdobbs> gmaxwell: ewww
801 2012-06-19 16:53:39 <jrmithdobbs> gmaxwell: that shit is ugly
802 2012-06-19 16:53:49 <jrmithdobbs> gmaxwell: cool concept, ugly api
803 2012-06-19 16:53:54 D34TH has joined
804 2012-06-19 16:54:37 <jrmithdobbs> gmaxwell: so you have to define it in the code? that's not like capabilities at all
805 2012-06-19 16:54:57 <gmaxwell> jrmithdobbs: you can have a launcher that does the sandboxing.
806 2012-06-19 16:55:08 <gmaxwell> They persist through exec, so...
807 2012-06-19 16:55:21 <gmaxwell> (and you can make them immutable)
808 2012-06-19 16:55:58 <jrmithdobbs> similar end result but completely app/code defined but not system/environment custmoizable without a wrapper at which point it almost might as well be an suid wrapper as far as the sys admin is concerned (there are more benefits to it, but the complexity of it is back to that of suid wrapper binaries instead of which capabilities how you can mark them in filesystem metadata)
809 2012-06-19 16:56:21 <jrmithdobbs> s/which capabilities/with capabilities/
810 2012-06-19 16:56:51 <jrmithdobbs> gmaxwell: caps persist through exec and can be made immutable as well so it's a different api for the same thing?
811 2012-06-19 16:57:57 <jrmithdobbs> it is much more fine grained though, which is cool
812 2012-06-19 16:58:08 <gmaxwell> Again, caps don't express anywhere near this level of flexiblity. You get full matching on all syscalls. So you can fully sandbox things. E.g. "append only for these files"
813 2012-06-19 16:58:11 <gmaxwell> right.
814 2012-06-19 16:58:41 <jrmithdobbs> well, a *lot* of the cool stuff you could do with it can be done in other long-accepted well defined ways
815 2012-06-19 16:59:19 <jrmithdobbs> but ya, i'll keep an eye on this, it could be very handy with a runit-like wrapper/helper app
816 2012-06-19 16:59:37 <jrmithdobbs> it's more the framework for cool stuff to come from instead of the resulting coll stuff ;p
817 2012-06-19 16:59:43 <jrmithdobbs> s/coll/cool/
818 2012-06-19 16:59:49 <gmaxwell> Yes, and in linux a lot of things this can do can be done with SELinux for example. But thats rather system level, while this can be dynamic. E.g. you could have he sandboxed app have a socket open to a helper which it asks to modify its filters.
819 2012-06-19 17:00:18 <jrmithdobbs> gmaxwell: ya, grsec and apparmor also provide a good chunk of this functionality
820 2012-06-19 17:00:23 <gmaxwell> so you could even have crazy stuff like the sandbox trapping on fault and prompting the user for permission to run the blocked syscall.
821 2012-06-19 17:00:34 <jrmithdobbs> gmaxwell: always interesting to see different ways of doing it, though
822 2012-06-19 17:00:35 <jrmithdobbs> for sure
823 2012-06-19 17:01:03 <gmaxwell> In any case, I thought you'd find it interesting. It was only recently added to the linux kernel, so the only distro with it yet is ubuntu 12.04.
824 2012-06-19 17:01:08 <jrmithdobbs> gmaxwell: ya, it does seem to provide a much nicer failure branch for elevated syscalls in user code
825 2012-06-19 17:01:42 <jrmithdobbs> gmaxwell: i'll keep an eye and watch for fun utilities for it because we're about to migrate an assload of stuff to 12.04
826 2012-06-19 17:02:20 <jrmithdobbs> gmaxwell: because we're sick of the shittastic xfs and nfs perf in <.32 ;p
827 2012-06-19 17:02:32 <jrmithdobbs> (what i mean is, we don't just upgrade to upgrade)
828 2012-06-19 17:19:12 <[Tycho]> ;;bc,blocks
829 2012-06-19 17:19:12 <gribble> 185342
830 2012-06-19 17:24:28 <gmaxwell> kinda odd, ran callgrind for an hour on a node not processing free txn... and basically all of the time it logged was time in loadblockindex on startup... which apparently makes about 533k calls to sha256.
831 2012-06-19 17:25:05 <gmaxwell> oh bleh. I bet it didn't follow the threads.
832 2012-06-19 17:26:32 gavinandresen has joined
833 2012-06-19 17:28:27 <luke-jr> still, should LoadBlockIndex be doing SHA256sums?
834 2012-06-19 17:29:20 l1l1ll11l1 has joined
835 2012-06-19 17:29:22 <gmaxwell> yea, this profile is still useful, just not what I wanted to measure:
836 2012-06-19 17:30:09 <sipa> luke-jr: i was positively surprised when i discovered that
837 2012-06-19 17:30:43 <sipa> luke-jr: it means someone can't give you a blockchain db, with a faked best chain in it
838 2012-06-19 17:30:50 <sipa> as that would require PoW
839 2012-06-19 17:30:54 <luke-jr> ah
840 2012-06-19 17:31:37 <phantomcircuit> PoW?
841 2012-06-19 17:31:48 <luke-jr> phantomcircuit: you shouldn't have to ask :P
842 2012-06-19 17:32:08 <sipa> phantomcircuit: proof of work
843 2012-06-19 17:32:10 <sipa> phantomcircuit: mining
844 2012-06-19 17:32:24 TD has quit (Quit: TD)
845 2012-06-19 17:32:50 <gmaxwell> sipa: sure but they can give you a chain with a randomly corrupted index.
846 2012-06-19 17:32:55 <gmaxwell> So, "meh"
847 2012-06-19 17:33:12 <phantomcircuit> if you sent someone a fake chain they would only be fooled until they connected to the first peer that told them otherwise
848 2012-06-19 17:33:25 <phantomcircuit> and i think a reorg that large causes the client to simply exit
849 2012-06-19 17:33:30 <sipa> phantomcircuit: not if the faked chain has more work in it
850 2012-06-19 17:33:33 <gmaxwell> https://people.xiph.org/~greg/bitcoin-start.png < here is the time spent on startup.
851 2012-06-19 17:33:51 <phantomcircuit> sipa, shrug if you did more work you could just do it on the open network anyways
852 2012-06-19 17:34:28 <sipa> phantomcircuit: my point is that since bitcoin checks the PoW at startup, you cannot create fake work by giving a corrupt db to someone
853 2012-06-19 17:34:44 <phantomcircuit> sipa, yeah i was agreeing
854 2012-06-19 17:34:48 maqr has quit (Ping timeout: 265 seconds)
855 2012-06-19 17:34:53 <sipa> phantomcircuit: sorry, i didn't notice you agreed :)
856 2012-06-19 17:35:15 <sipa> gmaxwell: then again, i don't want to claim we're safe when people start accepting untrusted block db's
857 2012-06-19 17:35:15 <phantomcircuit> gmaxwell, std::vector range_insert is weird
858 2012-06-19 17:35:42 <phantomcircuit> that should mostly be an append to a linked list which should be very cheap
859 2012-06-19 17:35:58 <sipa> std::vector is not a linked list
860 2012-06-19 17:36:07 <gmaxwell> It also spends about 20% of its time computing the difficulty of the blocks.
861 2012-06-19 17:36:43 <gmaxwell> phantomcircuit: well this is callgrind output.. it's estimates can be a little wonky. It has a very simplified view of instruction costs.
862 2012-06-19 17:36:44 <phantomcircuit> oh it's an array that's right
863 2012-06-19 17:37:01 <gmaxwell> It's mostly useful for looking at algorithmic complexity.
864 2012-06-19 17:37:27 <phantomcircuit> i wonder if there is anywhere that an std::vector is being used with insert
865 2012-06-19 17:37:39 <phantomcircuit> cause that can be super ridiculously expensive
866 2012-06-19 17:37:54 <sipa> in script it happens
867 2012-06-19 17:38:11 <phantomcircuit> shouldn't be running the scripts on startup though should it?
868 2012-06-19 17:38:21 <sipa> oh, no
869 2012-06-19 17:38:24 <sipa> certainly not
870 2012-06-19 17:38:33 <phantomcircuit> and the scripts are short enough that they'll fit in L2
871 2012-06-19 17:38:38 <phantomcircuit> so that should mostly not matter
872 2012-06-19 17:39:09 <phantomcircuit> but if there are inserts happening on anything that doesn't fit in L2 that could be a serious performance issue
873 2012-06-19 17:39:29 <Eliel> SHA-256 calculations take a bigger chunk than I'd have expected.
874 2012-06-19 17:39:39 <gmaxwell> That vector:range_insert is in CDatastream::write
875 2012-06-19 17:40:13 <sipa> oh, right
876 2012-06-19 17:40:23 <phantomcircuit> possibly the serializer should be changed to use a stack
877 2012-06-19 17:41:47 * Eliel thinks even non-mining clients would probably want to eventually get an accelerator for those.
878 2012-06-19 17:42:59 <phantomcircuit> also the sha256 ops are still naive
879 2012-06-19 17:43:12 <phantomcircuit> they should probably have runtime checks for cpu features
880 2012-06-19 17:43:19 <phantomcircuit> but that's getting into big risk of fuck ups
881 2012-06-19 17:43:38 <gmaxwell> I think we shouldn't be doing that sha256 at every startup. When someone gives you a chain you should loadblocks it. We should have a signature at the top of the blocks file to make it so that it knows if its foreign and then it does the check once or something like that.
882 2012-06-19 17:43:40 <Eliel> ah, they're unoptimized too?
883 2012-06-19 17:43:46 <gmaxwell> phantomcircuit: they wouldn't be subtle screwups.
884 2012-06-19 17:43:57 WKNiGHT has joined
885 2012-06-19 17:44:05 <gmaxwell> "bitcoin can't validate the genesis block on my computer!" no big deal.
886 2012-06-19 17:44:18 <phantomcircuit> gmaxwell, well it depends
887 2012-06-19 17:44:30 <phantomcircuit> it could be something that happens to only some fraction of blocks
888 2012-06-19 17:44:43 <phantomcircuit> so like the first 45k blocks would be fine but 45001 wouldn't
889 2012-06-19 17:45:28 <Eliel> well, the good thing about hash-algo bugs is that it won't look like it's working if it's not :)
890 2012-06-19 17:45:38 <Eliel> it'll be obvious it's failing :)
891 2012-06-19 17:45:52 <gmaxwell> phantomcircuit: thats pretty unlikely. Also, testnet has a max size block in it now.
892 2012-06-19 17:45:56 <sipa> gmaxwell: the txout dataset needs one more element: for coinbase transaction, you need to keep the height as well, to know when they become spendable
893 2012-06-19 17:46:50 <sipa> gmaxwell: combined with a few extra optimizations for amounts and low-txout-count transactions, the size is still only 65 MB
894 2012-06-19 17:48:22 onefourone has joined
895 2012-06-19 17:50:48 toffoo has joined
896 2012-06-19 17:52:18 justmoon has joined
897 2012-06-19 17:52:18 justmoon has quit (Changing host)
898 2012-06-19 17:52:18 justmoon has joined
899 2012-06-19 17:58:52 bob12321 has quit (Ping timeout: 244 seconds)
900 2012-06-19 17:59:01 drizztbsd has quit (Quit: Konversation terminated!)
901 2012-06-19 18:03:31 danbri_ has quit (Ping timeout: 244 seconds)
902 2012-06-19 18:03:51 <PK> odd, after crosscompiling bitcoin 0.6.2 for arm it just segfaults when I try to run it. I even recompiled all dependencies from scratch.
903 2012-06-19 18:06:40 <jrmithdobbs> PK: is your arm flavor big, little, or dual endian? ;p
904 2012-06-19 18:06:46 <amiller> i've never looked at patricia trees before
905 2012-06-19 18:06:51 <jrmithdobbs> PK: actually, it doesn't matter, you're going to need code changes unless it's little endian. lots of them. (unless you can flip it at compile time like on some arm platforms)
906 2012-06-19 18:06:52 <amiller> does that really give you O(k) worst case?
907 2012-06-19 18:07:45 <amiller> if we're storing 256 bit hashes, then 256 operations is a maximum lookup cost regardless of the size, up to 2^256 possible entries?
908 2012-06-19 18:08:00 <amiller> i guess log N <= k in any case
909 2012-06-19 18:08:22 <MysteryBanshee> blockchain.info still havent replied back to my 2 emails!
910 2012-06-19 18:08:27 <MysteryBanshee> :(
911 2012-06-19 18:09:04 <PK> I wish I had gdb on the arm box :( or at least a hint at the error.
912 2012-06-19 18:09:11 <gmaxwell> amiller: yea, level compressed tries with high fanout and probably pretty good for this sort of thing. But meh. libjudy is 30,000 lines of dense code.
913 2012-06-19 18:10:04 <amiller> one of the points made in the General Model for Authenticated Data Strucutres paper is that the fanout doesn't need to be related to the logical tree
914 2012-06-19 18:10:15 <amiller> you can take a red black tree and store it as an equivalent 2-3 tree or b-tree
915 2012-06-19 18:10:58 danbri has joined
916 2012-06-19 18:11:05 <amiller> the wikipedia page for Radix tree doesn't seem too complicated, so i'm not sure what the 30,000 lines are for unless there's more to it in libjudy...
917 2012-06-19 18:11:58 <gmaxwell> amiller: it does a lot of fancy stuff to control the tree shape to maximize cache locality.
918 2012-06-19 18:12:47 <gmaxwell> Considering how precious icache is these days its impressive that it performs so well in spite of its size.
919 2012-06-19 18:14:20 guruvan_ has quit (Ping timeout: 276 seconds)
920 2012-06-19 18:15:47 <PK> now it runs... removing PIE=1 made a difference.
921 2012-06-19 18:16:36 maqr has joined
922 2012-06-19 18:16:44 <luke-jr> [17:42:21] <sipa> gmaxwell: the txout dataset needs one more element: for coinbase transaction, you need to keep the height as well, to know when they become spendable
923 2012-06-19 18:16:46 <amiller> so it looks like a merkle trie would also require worst-case O(log N) effort, but it would be much simpler to balance, and you'd get the (useless) property that etotheipi likes, where any two trees with the same leaves are identical
924 2012-06-19 18:16:57 graingert_ecs has quit (Remote host closed the connection)
925 2012-06-19 18:17:01 <luke-jr> sipa: instead, it should be safe to just keep track of the last ~200 coinbase txids?
926 2012-06-19 18:17:42 <luke-jr> perhaps when connecting a block, just store its coinbase txid in a 0x100 entry table at the height modulo 0x100 position
927 2012-06-19 18:18:53 <luke-jr> even if you need to add it to the txout dataset for hash lookup purposes, you can at least cut it down to 1 octet this way
928 2012-06-19 18:24:17 setkeh has quit (Read error: No route to host)
929 2012-06-19 18:29:35 setkeh has joined
930 2012-06-19 18:29:51 m00p has joined
931 2012-06-19 18:32:03 kreal has quit ()
932 2012-06-19 18:33:06 moop has quit (Ping timeout: 264 seconds)
933 2012-06-19 18:34:08 <gmaxwell> amiller: I don't think that property is _useless_. I'd prefer it too if we could have it without giving up anything else.
934 2012-06-19 18:34:47 <amiller> how could you come into posession of a set of O(N) data that you _trust_, without also having an O(1) root hash that you trust?
935 2012-06-19 18:35:00 sytse has quit (Ping timeout: 248 seconds)
936 2012-06-19 18:35:56 <sneak> does theymos irc?
937 2012-06-19 18:37:23 <gmaxwell> amiller: by following the chain from the start? of course then you get the same structure anyways because you make the whole algorithim normative.
938 2012-06-19 18:37:51 <amiller> right, so if you follow the chain from the start, then you get the same structure
939 2012-06-19 18:38:04 <amiller> etotheipi keeps using the phrase 'construct the tree from scratch'
940 2012-06-19 18:38:10 <amiller> as in two people 'constructing the tree from scratch' will get identical trees
941 2012-06-19 18:38:20 <amiller> to construct a merkle tree from scratch, you must first invent the universe.
942 2012-06-19 18:38:22 <gmaxwell> amiller: the other advantage of the trie stuff is that its very space efficient. Though I still worry about creating local imbalances, though I guess the worst case isn't so bad.
943 2012-06-19 18:38:32 <amiller> space efficiency is entirely orthogonal
944 2012-06-19 18:38:36 <amiller> it doesn't matter how you store the trees
945 2012-06-19 18:39:22 <gmaxwell> amiller: I mean space efficiency for a fast lookup friendly structure, since you know we want people to actually perform queries.. and not just that perform queries for third parties hopefully for free.
946 2012-06-19 18:40:37 p0s has quit (Remote host closed the connection)
947 2012-06-19 18:41:16 <amiller> my point is that doesn't need to be part of the normative protocol
948 2012-06-19 18:41:25 <amiller> there are all sorts of different ways to efficiently store the same logical tree
949 2012-06-19 18:41:43 <amiller> no need to all have the same format there
950 2012-06-19 18:41:57 etotheipi_ has joined
951 2012-06-19 18:42:31 <gmaxwell> No, it doesn't. But whatever is normative needs to be very friendly with at least one efficient representation.
952 2012-06-19 18:42:32 <amiller> :]
953 2012-06-19 18:42:46 <amiller> yo etotheipi_
954 2012-06-19 18:42:52 <etotheipi_> I figured I should just come here instead of spamming the mailing list with this
955 2012-06-19 18:43:15 <amiller> lets hash this out!
956 2012-06-19 18:43:17 <etotheipi_> it's just that when I get on IRC, I tend to lose a couple hours of my life
957 2012-06-19 18:43:19 <etotheipi_> :)
958 2012-06-19 18:43:30 <gavinandresen> not lost, recorded for posterity
959 2012-06-19 18:43:42 <amiller> irc time is deductible, you get reimbursed for it at the gates of heavne
960 2012-06-19 18:43:53 sytse has joined
961 2012-06-19 18:44:05 guruvan has joined
962 2012-06-19 18:44:08 <etotheipi_> heh, is that how it works?
963 2012-06-19 18:44:17 Bwild has quit (Quit: leaving)
964 2012-06-19 18:44:18 <gmaxwell> Unfortunately IRC time is the opposite of time spent exercising, every hour on IRC subtracts two from your life.
965 2012-06-19 18:44:35 <gmaxwell> but oh what good hours they are.
966 2012-06-19 18:44:54 <etotheipi_> so am I the only one who doesn't like history-dependent tree structures?
967 2012-06-19 18:45:16 <BlueMatt> luke-jr: you dont, thats kinda the point...
968 2012-06-19 18:45:27 <etotheipi_> or rather, tree structures that have multiple valid representations for a given set of inputs
969 2012-06-19 18:45:36 <BlueMatt> sipa: no, jenkins uses the makefiles in git, and uses the default, is ipv6 not default?
970 2012-06-19 18:45:47 <gmaxwell> etotheipi_: Well they don't because the history of updates is the input.
971 2012-06-19 18:45:52 <amiller> there's only one representation for an ordered set of inputs
972 2012-06-19 18:47:04 Bwild has joined
973 2012-06-19 18:47:54 <amiller> i think you are beginning your scenario with "suppose you are in possession of the unordered set of N currently-valid unspent outputs" and then you want to build the tree
974 2012-06-19 18:48:18 <amiller> my question is, under what kind of circumstance could you acquire that set of outputs?
975 2012-06-19 18:48:44 <etotheipi_> amiller: that's exactly right -- and not because I know of a particular situation that could lead to that (the future may hold lots of situations we don't know about yet)...
976 2012-06-19 18:48:58 <amiller> either you have processed the blockchain history yourself, from the genesis, or else you are trusting someone else to give you the _correct_ set of N unspent outputs
977 2012-06-19 18:49:25 <amiller> or something in the middle, where you trust someone's opinion for time T, but you process all the transactions yourself from time T up to time T+M
978 2012-06-19 18:49:37 setkeh has quit (Read error: No route to host)
979 2012-06-19 18:49:41 <etotheipi_> it just seems like an unnecessary restriction to require not only all the tree nodes, but all the past tree nodes and the specific order of insertion and deletion
980 2012-06-19 18:49:48 <gmaxwell> My own belief that this was a requirement was removed by amiller pointing out to me that you can do provable not founds on queries without it.
981 2012-06-19 18:50:40 <etotheipi_> gmaxwell: I don't quite follow
982 2012-06-19 18:52:14 <gmaxwell> etotheipi_: I'd previously thought you could only be convinced that the tree with root X did not contain a particular leaf if you could know exactly where it was placed without having the whole tree. (e.g. if the ordering of the tree only depended on the direct data itself.
983 2012-06-19 18:52:53 <gmaxwell> amiller pointed out that a peer can trace a query through the tree and give you the hash nodes that you'd hit along the trace, which would prove the query was correct.
984 2012-06-19 18:54:05 <gmaxwell> as far as why the tree a function of inputs only is irrelevant: Either you're building the tree from scratch, so you can just get the same result by replaying the ordered updates. OR you trust someone to tell you the identity of the tree, so they can just give you the sate at some point in time.
985 2012-06-19 18:54:20 <jjjx> From an anonymity perspective, what are the benefits of routing Bitcoin through Tor? At what point is it possible to see what IP address a given Bitcoin address is 'receiving' from?
986 2012-06-19 18:54:35 <gmaxwell> Now, if we can have the tree be a pure function of the data in it, I agree thats better all things equal.
987 2012-06-19 18:54:56 <etotheipi_> well that's a feature of just about any of these structures, isn't it? You can basically ask for nodes between a lower bound and upper bound of your desired leaf node and confirm the validity
988 2012-06-19 18:54:56 <gmaxwell> jjjx: http://blockchain.info/ip-address/206.71.179.116
989 2012-06-19 18:55:44 <jjjx> gmaxwell: I see. Is this data stored in the blockchain itself, or simply captured by services like blockchain.info?
990 2012-06-19 18:55:46 <gmaxwell> etotheipi_: yea I was stupid for a moment because I hadn't considered that the intermediate nodes which aren't a function of the data would be part of the committed structure.
991 2012-06-19 18:55:57 <gmaxwell> jjjx: The latter, and anyone else who wants to.
992 2012-06-19 18:56:17 <etotheipi_> gmaxwell: so you're saying that you originally felt the way I do, and mainly because you were concerned about being able to prove that a node also *wasn't* in the tree
993 2012-06-19 18:56:45 <gmaxwell> etotheipi_: Correct. But now I see that you don't have to have a data-determinstic structure for that.
994 2012-06-19 18:56:51 <etotheipi_> gotcha
995 2012-06-19 18:57:41 Hasbro has joined
996 2012-06-19 18:57:59 <gmaxwell> So now I'd still prefer what you wantâ because it seems easier to test to me. But I suspect some alternative may give us better tradeoffs in some other dimension (e.g. query speed, space, resistance to worst cases in these).
997 2012-06-19 18:58:23 setkeh has joined
998 2012-06-19 18:59:09 <amiller> etotheipi_, i think where you're at now, you still feel like there's an example that might be able to be constructed, but i don't think you agree yet with what gmaxwell and i are saying, which is that _any possible_ example will either involve an iteration from genesis, or a trusted starting point somewhere
999 2012-06-19 18:59:32 <gmaxwell> Though n-way tries are usually very space efficient.. so.. I dunno.
1000 2012-06-19 18:59:43 <etotheipi_> amiller: I agree with that statement almost exactly
1001 2012-06-19 18:59:47 <etotheipi_> which is why I wanted more input
1002 2012-06-19 19:00:28 <etotheipi_> I believe they're both valid arguments -- but I feel that there's a great degree of inelegance in the history-based tree that I can't quantify... I figured gmaxwell would
1003 2012-06-19 19:00:29 <etotheipi_> :)
1004 2012-06-19 19:00:50 <amiller> okay well deferring that for now, the trie is really interesting
1005 2012-06-19 19:00:56 <amiller> it's far simpler than red black balancing, which is kind of a bitch
1006 2012-06-19 19:01:11 <gmaxwell> Yea, I can't come up with anything really compelling for amiller's question there. But I'd also offer amiller the counter: What do we gain from a structure which doesn't allow determinstic generation from the 'unordered' set of inputs?
1007 2012-06-19 19:01:14 <amiller> the worst case is worse than with the balanced tree
1008 2012-06-19 19:01:22 <etotheipi_> right... but tries are *not* so space efficient
1009 2012-06-19 19:01:36 <gmaxwell> Yes, but is it a worst case that requires colliding all of sha256 ? I'm not too worried about that.
1010 2012-06-19 19:01:49 <gmaxwell> In fact I _strongly_ prefer worst cases that reduce to "attack the hash function".
1011 2012-06-19 19:02:02 <etotheipi_> if you use a raw trie, branching on the next byte, each branch node requires storing 256 pointers, most of which will be null after the first few levels
1012 2012-06-19 19:02:02 <amiller> i'm just talking about worst case path length
1013 2012-06-19 19:02:11 <amiller> with a trie the worst case path length is k > log N
1014 2012-06-19 19:02:17 <etotheipi_> amiller: k is fixed
1015 2012-06-19 19:02:27 <gmaxwell> amiller: right but to get that you need hashes which share a lot of common bytes.
1016 2012-06-19 19:02:43 <amiller> and if you have fewer than that, then the balanced tree has a better worst case
1017 2012-06-19 19:02:48 <etotheipi_> k = 256, or 32, depending on whether you branch on bytes or bits
1018 2012-06-19 19:02:50 <amiller> etotheipi_, k may be fixed, but log N is bounded
1019 2012-06-19 19:03:02 <amiller> log N <= k
1020 2012-06-19 19:03:48 <etotheipi_> I don't understand: we have 1e+73 nodes in the tree: it still takes exactly 32 hops to find your data (or insert or delete)
1021 2012-06-19 19:03:57 <etotheipi_> same if you only have 1 node
1022 2012-06-19 19:05:07 <amiller> if we have more than 2^256 elements, then we have a big problem (guaranteed hash collision)
1023 2012-06-19 19:05:15 <etotheipi_> yes yes...
1024 2012-06-19 19:05:30 <etotheipi_> I'm just making the point that access/insert/delete time is exactly 32 under all circumstances
1025 2012-06-19 19:05:39 <etotheipi_> (with a raw trie)
1026 2012-06-19 19:05:50 <amiller> if you are branching by bytes rather than bits, then you also have buckets to worry about
1027 2012-06-19 19:06:01 <gmaxwell> etotheipi_: as far as my libjudy comment goesâ it's a well known level-compressed (256-ary) trie implementation which has excellent performance due to a lot of care taken to preserve cache locality. ... and its implementation is 30kloc of C. 0_o
1028 2012-06-19 19:06:40 <amiller> so you've got 32 + log N / 32
1029 2012-06-19 19:07:19 <jgarzik> sorry to intrude... has anyone successfully profiled "block propagation", i.e. traced the delay?
1030 2012-06-19 19:07:20 <etotheipi_> gmaxwell: so it sounds like a further-optimized PATRICIA tree
1031 2012-06-19 19:07:37 <etotheipi_> amiller: which buckets?
1032 2012-06-19 19:07:59 <gmaxwell> (oh actually seems it isn't actually level-compressed)
1033 2012-06-19 19:08:04 <gmaxwell> etotheipi_: correct.
1034 2012-06-19 19:08:16 <jgarzik> I'm wondering if the network simply needs well-placed nodes running on SSD + signature cache? or maybe we're just doing a whole lot of SHA256 per block?
1035 2012-06-19 19:08:41 <amiller> etotheipi_, suppose you branch by 256 bits
1036 2012-06-19 19:08:46 <amiller> then you only have to do one operation?
1037 2012-06-19 19:09:25 <gmaxwell> jgarzik: well I have a node running in callgrind for a profile right now. It's hard to say, the propagation times being observed in the wild don't seem justifyable with any obvious causes.
1038 2012-06-19 19:09:58 <gmaxwell> jgarzik: e.g. block processing is _slow_ even on tmpfs+fast cpu. .. where slow means, seconds. But seconds per hop don't really explain multiminute propagations.
1039 2012-06-19 19:10:20 <etotheipi_> gmaxwell: if we were to use a raw trie: then we'd be storing 256, 8-byte pointers at every level -- each node would take at least 2048 bytes -- and there are exactly 32-nodes on the way to any given leaf. The top 4 levels will have a high degree of sharing with other branches, but the bottom 28 will be mostly used to support single leafs
1040 2012-06-19 19:10:46 <etotheipi_> therefore, if we were to even consider a trie- structure, I think it would *have* to be level-compressed
1041 2012-06-19 19:11:13 <etotheipi_> which then gets out of the realm of "straightforward" in terms of implementation
1042 2012-06-19 19:11:23 <gmaxwell> etotheipi_: you can switch the order when the trie becomes too unsparse, I think thats what judy does.. been a long time.
1043 2012-06-19 19:12:12 <jgarzik> gmaxwell: one of my background projects is a bitcoin backbone. I've been wanting to set up hardware at key network points around the world, just running full peer nodes; making sure to have direct connections to popular pools and sites, etc.
1044 2012-06-19 19:12:47 <etotheipi_> amiller: that would be a hell of a root node!
1045 2012-06-19 19:12:56 <gmaxwell> jgarzik: sounds like a grand idea to me.
1046 2012-06-19 19:13:37 <gmaxwell> jgarzik: did you see what luke was proposing wrt relaying prior to validation. That would really cut the delay down for with pretty much any cause.
1047 2012-06-19 19:13:43 doublec has quit (Ping timeout: 240 seconds)
1048 2012-06-19 19:14:06 <etotheipi_> amiller: perhaps I just described your concern about tries in my previous comment. .. it's my concern too, which is why I wasn't taking them too seriously
1049 2012-06-19 19:14:28 <amiller> it just ends up working out to log N
1050 2012-06-19 19:14:31 doublec has joined
1051 2012-06-19 19:15:09 <etotheipi_> what works out to log(N)?
1052 2012-06-19 19:15:10 <jgarzik> if I had enough resources, I'd build a -nolisten bastion network to popular sites, then connect those to separate, public nodes for added security
1053 2012-06-19 19:15:32 TD[gone] has quit (Ping timeout: 248 seconds)
1054 2012-06-19 19:15:48 <jgarzik> gmaxwell: relay-before-validate seems very interesting, has anyone thought through the consequences?
1055 2012-06-19 19:16:19 <jgarzik> internally, it should be straightforward to create a pre-validated holding pen for blocks
1056 2012-06-19 19:16:29 <jgarzik> and then pipeline those through ProcessBlock
1057 2012-06-19 19:16:34 <BlueMatt> jgarzik: done
1058 2012-06-19 19:16:56 <jgarzik> BlueMatt: cool... part of CBlockStore? link?
1059 2012-06-19 19:17:10 <jgarzik> seems like something easily offload-able to a thread at that point
1060 2012-06-19 19:17:16 <gmaxwell> jgarzik: it got discussed some. There is some minor attack potential, but it has the cost of producing valid block headersâ because we can at least do all the cheap validaion first.
1061 2012-06-19 19:18:13 <amiller> if there is only a single root node (branch by 256 bits) then you might have to store up to N <= 2^256 elements in that node
1062 2012-06-19 19:18:19 guruvan has quit (Quit: oh noessss)
1063 2012-06-19 19:18:29 <BlueMatt> jgarzik: https://github.com/TheBlueMatt/bitcoin/commit/07672222debe0584a136babe43b5fc7803c452b3
1064 2012-06-19 19:18:59 <amiller> if you only branch by one bit, then you only need to store on item per node, you only have to do worst case k work, but there can't be more than 2^k elements anyway
1065 2012-06-19 19:19:04 guruvan has joined
1066 2012-06-19 19:19:06 <BlueMatt> jgarzik: (and, yes, its offloaded to another thread)
1067 2012-06-19 19:19:23 TD[gone] has joined
1068 2012-06-19 19:19:29 <amiller> there's a tradeoff between the size of k (the branch size) and the number of elements that must be stored in each node
1069 2012-06-19 19:19:57 <etotheipi_> amiller: I'm with you
1070 2012-06-19 19:20:24 <amiller> no where in between can you get better than log N worst case, given that N <= 2^256
1071 2012-06-19 19:20:28 <luke-jr> BlueMatt: I need to :p
1072 2012-06-19 19:20:37 <BlueMatt> luke-jr: why?
1073 2012-06-19 19:20:45 <luke-jr> BlueMatt: CheckNewBlock
1074 2012-06-19 19:20:57 <BlueMatt> link?
1075 2012-06-19 19:21:46 <luke-jr> https://github.com/bitcoin/bitcoin/pull/1246
1076 2012-06-19 19:22:43 maqr has quit (Ping timeout: 240 seconds)
1077 2012-06-19 19:25:06 <BlueMatt> luke-jr: let me rephrase: why do you need to call ConnectBlock directly instead of using ProcessBlock/EmitBlock?
1078 2012-06-19 19:25:51 <etotheipi_> amiller, give me a sec
1079 2012-06-19 19:26:25 <amiller> take your time, i'm having a blast :D (love me some merkle trees)
1080 2012-06-19 19:26:39 <Eliel> my feeling about a trie is that it sounds horribly space inefficient. Even with level compression.
1081 2012-06-19 19:26:40 <luke-jr> BlueMatt: ProcessBlock does way too much
1082 2012-06-19 19:26:43 <BlueMatt> luke-jr: if you are adding stuff to just check that inputs are connect-able in ConnectBlock, why not do that for ProcessBlock instead so that you get the additional checks in there?
1083 2012-06-19 19:27:01 <etotheipi_> amiller: we can agree about that, then
1084 2012-06-19 19:27:22 <amiller> :]
1085 2012-06-19 19:27:22 <etotheipi_> I'm one of the rare few that actually enjoyed data structures in college
1086 2012-06-19 19:28:01 <etotheipi_> so amiller, I just want to clarify: there are two different aspects to consider: space efficiency and access efficiency
1087 2012-06-19 19:28:12 <luke-jr> BlueMatt: ProcessBlock writes it to disk
1088 2012-06-19 19:28:18 <jjjx> How much did the core development team grow since the craziness of the 'bubble' and all the media hype surrounding it? Did many new developers flock to the project? Did any of them stick around?
1089 2012-06-19 19:28:22 <gmaxwell> Eliel: the actual node data can up in the intermediate nodes, this can make them very space efficient.
1090 2012-06-19 19:28:28 egecko has joined
1091 2012-06-19 19:28:30 <BlueMatt> luke-jr: ok, so add a fDontCheckWork that doesnt check work and doesnt write to disk?
1092 2012-06-19 19:29:10 <amiller> there are also two modes to consider, the normative specification, and everything else that's optional
1093 2012-06-19 19:29:30 <amiller> the normative spec needs to be about worst case bounds, but practical efficiency can be handled all sorts of ways
1094 2012-06-19 19:29:37 <amiller> storage, O(N), access, O(log N), worst case
1095 2012-06-19 19:29:39 <BlueMatt> luke-jr: anyway, the point of cblockstore is to encapsulate crap that no one should ever access directly...anyway, Im off
1096 2012-06-19 19:29:56 <amiller> underneath the big O, there are all sorts of different ways to store and access the trees on a real disk
1097 2012-06-19 19:30:01 <amiller> it's basically orthogonal to the balancing rules
1098 2012-06-19 19:30:18 <gmaxwell> amiller: I don't believe you about orthogonal.
1099 2012-06-19 19:30:23 <amiller> take a red black tree, store 32 nodes at a time
1100 2012-06-19 19:30:31 <amiller> now if you have to update any of those nodes, you need to update all 32 in a block
1101 2012-06-19 19:30:49 <amiller> or just cache however many of the top nodes you need, since you're going to be accessing those the most
1102 2012-06-19 19:31:07 <amiller> all of the optimizations come from cache locality in some sense, chunking node data together
1103 2012-06-19 19:31:17 guruvan has quit (Quit: oh noessss)
1104 2012-06-19 19:31:43 Ferroh has joined
1105 2012-06-19 19:32:54 RazielZ has quit (Ping timeout: 244 seconds)
1106 2012-06-19 19:33:27 Ferroh has quit (Client Quit)
1107 2012-06-19 19:33:31 <amiller> http://truthsayer.cs.ucdavis.edu/algorithmica.pdf this paper describes IO efficient schemes for storing the merkle search structures
1108 2012-06-19 19:33:43 Ferroh has joined
1109 2012-06-19 19:33:52 <amiller> it's a b-tree
1110 2012-06-19 19:33:54 guruvan has joined
1111 2012-06-19 19:34:35 has joined
1112 2012-06-19 19:34:44 <amiller> figures 6 and 7 especially
1113 2012-06-19 19:35:02 has quit (guruvan|!~guruvan@gateway/tor-sasl/guruvan|Remote host closed the connection)
1114 2012-06-19 19:35:33 <amiller> "This also emphasizes the fact that the Search DAG is only a logical view of the data, and need not restrict the publisherÂs physical implementation." is what i'm referring to by orthogonal
1115 2012-06-19 19:36:26 <amiller> any time you see VO in one of these papers, they mean Verification Object, which is just a path of data through the tree
1116 2012-06-19 19:36:42 <Eliel> how do you merkleize a trie?
1117 2012-06-19 19:36:57 <amiller> everywhere you have a pointer, store a hash right next to it
1118 2012-06-19 19:37:00 Raziel_ has joined
1119 2012-06-19 19:37:05 <Eliel> I don't think it'd work too well to need 256 sha-256 hashes to verify one level.
1120 2012-06-19 19:38:00 <amiller> you only need to verify the one you follow
1121 2012-06-19 19:38:47 <Eliel> you have the root hash, to verify the first level is correct, you'd need all 256 hashes it contains. Correct?
1122 2012-06-19 19:39:10 <Eliel> then to verify the second level, another 256 hashes
1123 2012-06-19 19:39:43 <Eliel> or am I missing something?
1124 2012-06-19 19:40:12 <TuxBlackEdo> Fujitsu and its Japanese partners have taken 148 days to carry out a cryptanalysis that had been estimated to take hundreds of thousands of years http://www.techweekeurope.co.uk/news/fujitsu-cryptography-standard-83185
1125 2012-06-19 19:40:15 <etotheipi_> Eliel: close, you only need hash a concatenation of all non-null pointers, I believe
1126 2012-06-19 19:40:16 <Eliel> ... ah, you could still organize those 256 in a merkle-like hierarchial structure.
1127 2012-06-19 19:40:20 <amiller> ah yeah you'd need to hash that much data 256*256
1128 2012-06-19 19:40:35 <amiller> but you don't have to compute that many hashes
1129 2012-06-19 19:40:49 <Eliel> so you'd need 16 to verify a level then.
1130 2012-06-19 19:40:50 <amiller> i'm not being very clear about hash (the act of computation) vs hash (the resulting data)
1131 2012-06-19 19:41:04 <sipa> luke-jr: good point, but it is 3 bytes per block now :)
1132 2012-06-19 19:42:02 <Eliel> ... oh wait, not 16, 8
1133 2012-06-19 19:42:33 <amiller> you need to compute one hash over a 256*256 bit chunk of data
1134 2012-06-19 19:43:17 DrHaribo_ is now known as DrHaribo
1135 2012-06-19 19:43:23 <Eliel> this needs to be space efficient enough that light clients can verify a leaf node without needing to download lots of data.
1136 2012-06-19 19:43:46 <amiller> okay so the client verification requirements are separate from the server's storage requirements as well
1137 2012-06-19 19:43:49 <PK> If I have a really mini-patch wish for bitcoind. Just a one liner. Who can I give the patch for that? I'd really like to have " obj.push_back(Pair("transactions", (int) pwalletMain->mapWallet.size())); " added to getinfo in bitcoinrpc.cpp around line 348. It doesn't have to be there, that was just the easiest way for me to do it not knowing the code that well. I need a total of the records that listtransactions can return.
1138 2012-06-19 19:43:54 <amiller> the client needs on the order of O(log N) data to verify a leaf node
1139 2012-06-19 19:44:35 Zarutian has quit (Quit: Zarutian)
1140 2012-06-19 19:44:40 <etotheipi_> I'm gonna need ot break out my whiteboard in a sec
1141 2012-06-19 19:44:45 <Eliel> yes, I think the amount of data client needs to verify a leaf is one of the primary purposes of this scheme.
1142 2012-06-19 19:44:57 <Eliel> to make that small
1143 2012-06-19 19:45:17 <amiller> well the verification data required is minimized when the fanout is minimized
1144 2012-06-19 19:45:24 <sipa> etotheipi_: hey
1145 2012-06-19 19:45:29 <etotheipi_> hey sipa
1146 2012-06-19 19:45:47 <sipa> etotheipi_: just so you know, i am working on pruning
1147 2012-06-19 19:46:06 <etotheipi_> sipa: an implementation? theory?
1148 2012-06-19 19:46:33 maqr has joined
1149 2012-06-19 19:46:34 <sipa> currently just by keeping a txid -> coins map, with very compact representation
1150 2012-06-19 19:46:44 <Eliel> also, the amount of data that needs hashing also makes a big difference for the updates. It makes up the constant multiplier for the O(log N)
1151 2012-06-19 19:46:53 <sipa> the entire map is serialized to 65 MB now
1152 2012-06-19 19:47:04 <sipa> without compression
1153 2012-06-19 19:47:29 <etotheipi_> Eliel, amiller: it sounds like in order for any trie structure to be ideal, it would be best to have minimal branching, but most importantly, level-compression
1154 2012-06-19 19:47:58 <sipa> etotheipi_: i have little time know, but i'll explain later if you like
1155 2012-06-19 19:48:07 <etotheipi_> sipa: yeah, I'd like to hear about that
1156 2012-06-19 19:48:15 <etotheipi_> unfortuantely I overwhelmed myself
1157 2012-06-19 19:48:21 <etotheipi_> so now's not a good time for me, either
1158 2012-06-19 19:48:49 <sipa> basically, i believe i can implement a fully validating node with 200 MB of storage
1159 2012-06-19 19:48:50 * Eliel likes data structures.
1160 2012-06-19 19:48:51 <etotheipi_> I hardly can keep up with this conversation
1161 2012-06-19 19:49:06 <etotheipi_> my debugger has been sitting at the same place for the last hour
1162 2012-06-19 19:50:34 <gmaxwell> luke-jr: so interesting, getmemorypool appears to be spending almost all its time doing signature validations.
1163 2012-06-19 19:50:46 <etotheipi_> sipa: I'd also like to hear your input on the two core components of my proposal, or how they could be modified: address/script-based aggregation in some tree structure, and using alternate chain to track the new data
1164 2012-06-19 19:51:36 <sipa> etotheipi_: i like it, because it can be done as an arbitrary chain
1165 2012-06-19 19:51:48 <Eliel> etotheipi_: I think index by script hash would work great. You can always calculate the script hash for regular transactions and P2SH transactions have it right there.
1166 2012-06-19 19:52:06 <luke-jr> gmaxwell: with or before CheckNewBlock?
1167 2012-06-19 19:52:23 <amiller> etotheipi_, i like that part too, gmaxwell suggested that in irc a few months ago
1168 2012-06-19 19:52:36 <sipa> etotheipi_: i don't think address->tx lookups should burden the core protocol, but as an extension, i don't care
1169 2012-06-19 19:52:38 <luke-jr> sipa: what happens if I reuse the same coinbase from an orphan? ;)
1170 2012-06-19 19:52:50 tyn has quit (Ping timeout: 260 seconds)
1171 2012-06-19 19:52:50 guruvan has quit (Quit: oh noessss)
1172 2012-06-19 19:52:52 <sipa> luke-jr: ?
1173 2012-06-19 19:52:54 <gmaxwell> luke-jr: I'm profiling 0.6.2.2 right now.
1174 2012-06-19 19:53:05 <etotheipi_> I don't think I can take credit for any single piece of the proposal
1175 2012-06-19 19:53:11 <amiller> oh, wait, no, gmaxwell just said that etotheipi_ wanted it http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/05/07/3#l3477735
1176 2012-06-19 19:53:13 <etotheipi_> I just was inspired and put it together
1177 2012-06-19 19:53:51 <luke-jr> sipa: just thinking it should be tested in the scenario where coinbase is at height X, orphaned, then again at height Y
1178 2012-06-19 19:53:54 <Eliel> etotheipi_: so you can take credit for the overall structure :)
1179 2012-06-19 19:53:59 <gmaxwell> amiller: I'd proposed that kind of indexing for namecoin litenode lookups, but I thought maintaining a balanced tree would be a really hard problem.
1180 2012-06-19 19:54:29 <sipa> luke-jr: the txout db only contains active open txouts in the currently connected branch
1181 2012-06-19 19:54:42 <Eliel> etotheipi_: that's pretty much what satoshi did when he put bitcoin together. Took already existing parts and put them together. :)
1182 2012-06-19 19:54:54 <luke-jr> sipa: i c; still would make a test case with that :P
1183 2012-06-19 19:56:17 <etotheipi_> it sounds like there's a lot of important people who like the overall concept
1184 2012-06-19 19:56:25 <etotheipi_> the question is, where is it lacking?
1185 2012-06-19 19:56:41 <etotheipi_> we are debating the specific tree structure to use, but I think we have too many options there, not too few
1186 2012-06-19 19:57:01 <etotheipi_> what is it that I have missed that I will find out, halfway through implementation, that this doesn't actually work?
1187 2012-06-19 19:57:20 <etotheipi_> or two months into people using, find some vulnerability
1188 2012-06-19 19:57:39 <amiller> etotheipi_, if you're inclined, you could look at my reference implementation and give some feedback on how to clarify it
1189 2012-06-19 19:57:40 <Eliel> etotheipi_: if that happens, then it's something that got past all of us.
1190 2012-06-19 19:57:49 <amiller> https://github.com/amiller/redblackmerkle/blob/master/redblack.py
1191 2012-06-19 19:57:56 <amiller> my goal in implementing it was to make it as clear as possible that it is secure
1192 2012-06-19 19:57:59 <etotheipi_> amiller: I will read that redblack paper
1193 2012-06-19 19:58:23 <amiller> they way that i did that is by having a single function definition for each operation, insert delete and so on
1194 2012-06-19 19:58:24 <etotheipi_> err.. code
1195 2012-06-19 19:58:30 <amiller> and then there are two modes, Record and Replay
1196 2012-06-19 19:58:48 <amiller> record simply collects every node it passes through, and replay only looks at input data after verifying it against the hash it already ahs
1197 2012-06-19 19:59:00 guruvan has joined
1198 2012-06-19 19:59:12 <amiller> ideally i would implement this in Coq and show that there is no way for two queries to return different results without constructing a hash collision
1199 2012-06-19 19:59:15 <etotheipi_> maybe I just prefer tries and patricia trees because I spent 17 hours programming the insert-function for a patricia treein college
1200 2012-06-19 19:59:38 <etotheipi_> and while I understood red-black trees, the implementation was my last assignment that I didn't do :)
1201 2012-06-19 19:59:43 <amiller> we would need to agree on a set of balancing rules, since that will be a normative part of the protocol
1202 2012-06-19 19:59:59 <amiller> although for a given set of balancing rules, there are still potentially many ways of serializing and storing the data, that doesn't need to be normative
1203 2012-06-19 20:00:22 titeuf_87 has quit (Disconnected by services)
1204 2012-06-19 20:00:29 <amiller> you could store it as a btree or a linked list for all it matters to the spec
1205 2012-06-19 20:00:42 titeuf_87 has joined
1206 2012-06-19 20:01:02 sacredchao has joined
1207 2012-06-19 20:01:03 <gmaxwell> amiller: (broken record) you do need to come up with at least one reasonable one just to show that your rules don't create problems for it.
1208 2012-06-19 20:01:25 <amiller> mm and i suppose there has to be an agreed-upon serialization format since thats what you would take the hash of
1209 2012-06-19 20:01:38 <amiller> gmaxwell, what would be the target for a reasonable one?
1210 2012-06-19 20:02:28 <luke-jr> gavinandresen: please don't make a 0.6.3 branch, there is already a 0.6.x
1211 2012-06-19 20:02:43 <gmaxwell> One consideration should be working things out so that distributed nodes work somewhat better. e.g. having reasonably high branching factor right at the root lets you easily load balance work.
1212 2012-06-19 20:03:23 <gmaxwell> amiller: You've got me. There should be some representation which is fast for the normal operations an which doesn't have a large space inflation. E.g. what would the reference implementation use?
1213 2012-06-19 20:03:25 <gavinandresen> luke-jr: ?
1214 2012-06-19 20:03:41 <luke-jr> gavinandresen: 0.6.3 is already a work-in-progress
1215 2012-06-19 20:03:52 <gavinandresen> says who?
1216 2012-06-19 20:04:01 <luke-jr> me
1217 2012-06-19 20:04:13 <luke-jr> I maintain the stable branches, in case you've not noticed
1218 2012-06-19 20:04:20 <amiller> gmaxwell, you could store every possible branch (N log N) and then do constant time lookups
1219 2012-06-19 20:04:22 <amiller> that would distribute well
1220 2012-06-19 20:04:45 <gavinandresen> I've repeatedly told you that I disagree with the notion of "stable" branches that nobody is testing.
1221 2012-06-19 20:05:02 <luke-jr> gavinandresen: so stop trying to reinvent them, and discourage people from testing them?
1222 2012-06-19 20:05:18 <luke-jr> if you disagree with 0.6.3, then why are you trying to reinvent it?
1223 2012-06-19 20:05:24 Turingi has quit (Read error: Connection reset by peer)
1224 2012-06-19 20:06:03 <amiller> gmaxwell, the difference between fast and slow will pretty much come down to cache locality, won't it?
1225 2012-06-19 20:06:13 <gavinandresen> If we were closer to a stable 0.7rc1 I wouldn't, but we aren't, and there are a couple of pressing issues that I think requires a 0.6.3
1226 2012-06-19 20:06:20 <amiller> maybe the target should be a parameterized storage model where you indicate the size of cache you want
1227 2012-06-19 20:06:20 <gmaxwell> gavinandresen: I take back my earlier comments, as far as I can tell all the interesting cpu time for both miners and regular nodes is in the ecdsa validation. The caches should help a lot.
1228 2012-06-19 20:06:30 <luke-jr> gavinandresen: then I'll roll a 0.6.3rc1
1229 2012-06-19 20:06:52 <gavinandresen> luke-jr: where's your 0.6.3 tree?
1230 2012-06-19 20:06:56 minimoose_ has joined
1231 2012-06-19 20:07:23 <luke-jr> gavinandresen: git://gitorious.org/+bitcoin-stable-developers/bitcoin/bitcoind-stable.git 0.6.x
1232 2012-06-19 20:07:29 tyn has joined
1233 2012-06-19 20:07:43 <gmaxwell> amiller: or disk locality. Bu also the branching factor. E.g. if throughput >> latency you want less branching.
1234 2012-06-19 20:09:08 <Eliel> etotheipi_: also, one thing that piques my interest with this approach is that my intuition keeps telling me this could perhaps allow for full validating nodes that function on headers only basis for storage.
1235 2012-06-19 20:09:26 <amiller> Eliel, most definitely
1236 2012-06-19 20:09:36 <gmaxwell> Eliel: ...
1237 2012-06-19 20:09:40 <gmaxwell> Eliel: thats the point.
1238 2012-06-19 20:09:43 <Eliel> etotheipi_: of course, for that, every transaction would need to be packaged with it's inputs
1239 2012-06-19 20:10:04 <gmaxwell> Eliel: or at least available from the peer that gave you the transaction.
1240 2012-06-19 20:10:37 minimoose has quit (Ping timeout: 244 seconds)
1241 2012-06-19 20:10:38 minimoose_ is now known as minimoose
1242 2012-06-19 20:11:26 <Eliel> gmaxwell: yes. It'd increase the bandwidth requirements though.
1243 2012-06-19 20:11:53 <gmaxwell> Eliel: but you can choose that trade-off at runtime rather than in the protocol.
1244 2012-06-19 20:11:57 minimoose_ has joined
1245 2012-06-19 20:12:57 <etotheipi_> heh... actually the point was to allow new nodes to get on the network (validating or not) and be ready to go with their wallet in a few minutes
1246 2012-06-19 20:13:06 <etotheipi_> regardless of how old that wallet is
1247 2012-06-19 20:13:51 <etotheipi_> err... the point was blockchain compression -- that just happened to have some nice by-products :)
1248 2012-06-19 20:13:56 <Eliel> I like that this approach would even allow mining without a need to store anything but blockchain headers :)
1249 2012-06-19 20:14:16 <Eliel> would push storage to each user's wallet.
1250 2012-06-19 20:14:50 <amiller> my original goal was to replace the proof of work system with a proof-of-throughput to the paths through the merkle tree
1251 2012-06-19 20:14:59 minimoose has quit (Ping timeout: 250 seconds)
1252 2012-06-19 20:14:59 minimoose_ is now known as minimoose
1253 2012-06-19 20:15:01 <amiller> this would unify the two main tasks in bitcoin, mining, and transaction validation
1254 2012-06-19 20:15:05 <etotheipi_> does merged mining provide the benefits I think it does, in this case?
1255 2012-06-19 20:15:35 <Eliel> etotheipi_: I think this would function best as it's own chain, but merged mining doesn't add any significant drawbacks. Just some extra data.
1256 2012-06-19 20:15:38 <etotheipi_> mainly that it's "free" for someone to participate, and once you have a significant proportion of miners doing it, it's got a comparable level of mining-majority-required-to-break security
1257 2012-06-19 20:16:28 <etotheipi_> Eliel: I think merged-mining is critical -- it means the miners supporting it don't have to divert mining power to provide the proof-of-work to keep the second chain secure
1258 2012-06-19 20:16:32 <Eliel> as a merged mining chain it lacks miner incentives though.
1259 2012-06-19 20:16:58 <etotheipi_> that is a minor point I wasn't worried about... but others might be
1260 2012-06-19 20:17:03 <etotheipi_> I don't think the second chain needs incentive
1261 2012-06-19 20:17:16 jjjx has quit (Remote host closed the connection)
1262 2012-06-19 20:17:21 <etotheipi_> if the computations are efficient and the code is already written... it basically costs nothing for miners to support the second chain through merged mining
1263 2012-06-19 20:17:23 jjjx has joined
1264 2012-06-19 20:17:52 <amiller> etotheipi_, i have another suggestion as well. Since the point is that lite clients could maintain the tree without having to store anything themselves, you could also just implement it as a centralized untrusted service
1265 2012-06-19 20:17:55 <Eliel> if this gets included with bitcoind someday, that removes the issue :)
1266 2012-06-19 20:18:27 <amiller> the way it would work is that a client has a root hash for block B. Then they look at the transactions for block B+1, add it to the tree, and they don't even need to query the service
1267 2012-06-19 20:18:30 <luke-jr> gavinandresen: if it helps, http://codepad.org/do2dlohf is a list of commits backported
1268 2012-06-19 20:18:38 <etotheipi_> Eliel: but the question is: will it make it off the ground without incentive?
1269 2012-06-19 20:19:00 <etotheipi_> I believe so --- and once it does, it can then, in the future, be integrated safely into the main chain, or just left where it is
1270 2012-06-19 20:19:56 <amiller> i think what i just said was contradictory so nevermind, etotheipi_ i like your alternate blockchain idea as well
1271 2012-06-19 20:20:14 <etotheipi_> amiller: hah
1272 2012-06-19 20:20:15 <amiller> especially as a staging area for future main chain features
1273 2012-06-19 20:21:07 <etotheipi_> I didn't think of it until galambo mentioned it in the thread: but it does seem "staging area" is a great analogy for it
1274 2012-06-19 20:21:16 <etotheipi_> stage-chain
1275 2012-06-19 20:21:24 <Eliel> etotheipi_: if not, there's always the option of forking bitcoin ;)
1276 2012-06-19 20:21:36 <Eliel> this is big enough improvement that it could take off.
1277 2012-06-19 20:21:54 <etotheipi_> is there a limit to the number of merged chains?
1278 2012-06-19 20:21:55 <Eliel> I mean forking both bitcoin and the blockchain
1279 2012-06-19 20:23:50 <Eliel> etotheipi_: I believe current miners care enough about bitcoin to merged mine this just to support bitcoin. As long as it's not too hard.
1280 2012-06-19 20:24:06 <amiller> etotheipi_, i've been thinking a lot about this problem
1281 2012-06-19 20:24:15 <gmaxwell> well, I think if bitcoin doesn't switch to this sort of thing it'll eventually become pointless because it will be too costly to validate.
1282 2012-06-19 20:24:27 <amiller> the trouble with merged mining is related to those miners that mine on bitcoin without having their unspent database
1283 2012-06-19 20:24:39 <amiller> every alternate blockchain has its own set of data that's needed to properly validate
1284 2012-06-19 20:25:03 <amiller> to validate namecoin, you need the namecoin database
1285 2012-06-19 20:25:24 <amiller> so to honestly mine on K merged chains, you need K extra databases
1286 2012-06-19 20:25:48 <etotheipi_> that brings up something else about the alt-chain.... it's intended for majority-mining-voting of the correct pruning solution... but could/should it be used for something else?
1287 2012-06-19 20:25:57 <etotheipi_> I don't envision any transactions on it
1288 2012-06-19 20:26:08 <etotheipi_> all information needed to produce the alt-chain headers comes from the main chian
1289 2012-06-19 20:26:43 <Eliel> gmaxwell: any hope of doing away with the need to merged mine this someday? I mean like planning a fork 2 years into the future to make this root hash a part of the main block headers.
1290 2012-06-19 20:27:04 <gmaxwell> Eliel: Sure.
1291 2012-06-19 20:27:08 <etotheipi_> it does make sense that other information could be included as "transactions" on the second chain, as supplementary information -- could be ignored by those who only want the pruned output
1292 2012-06-19 20:28:32 <amiller> etotheipi_, there would be no incentives on this alt chain, would ther?
1293 2012-06-19 20:28:34 <gmaxwell> We can't increase the bitcoin blocksize without a hardfork. I don't think we should increase the blocksize without something like this to drastically lower the cost of running a verifying node. If we don't increase the blocksize we'll be capped at an average of something like 6 transactions per second forever, and I don't think anyone thinks it needs to be so low.
1294 2012-06-19 20:28:35 <etotheipi_> ehh... I don't like it unless there's a really good reason for it -- I like the simplicity of a headers'only chain
1295 2012-06-19 20:30:01 <etotheipi_> amiller: I had envisioned the alt chain to not have incentives/blockrewards, and no transactions -- it really only exists as an information channel for majority-hashing power to "vote" on the correct pruning solution
1296 2012-06-19 20:31:27 <etotheipi_> though, I guess it would be easy for the top alt-block to be invalid: any miner could submit the wrong answer in their next real block, which will then temporarily look like hte longest chain to non-validating nodes
1297 2012-06-19 20:31:30 * Eliel wonders if there's a trick that'd allow clients that rely on this to pay fees only to miners that merged mine this chain.
1298 2012-06-19 20:31:48 <amiller> there's no additional information in the alt chain
1299 2012-06-19 20:31:50 <amiller> it's not really an alt chain at all
1300 2012-06-19 20:31:54 <gmaxwell> etotheipi_: right thats why merged chains are not silver bullets.
1301 2012-06-19 20:32:03 <amiller> it's just a derived piece of information from the regular chain
1302 2012-06-19 20:32:05 <etotheipi_> it would correct itself, since majority-yhashing power would not build off that block, though they'd just ignore it
1303 2012-06-19 20:32:13 <etotheipi_> (in fact, they wouldn't see it)
1304 2012-06-19 20:32:24 <gmaxwell> etotheipi_: cause unless all nodes enforce their rules _hard_ you can't have litenodes that only trust the committments.
1305 2012-06-19 20:33:11 <gmaxwell> etotheipi_: sure but if many nodes don't correctly enforce the rules it might get burried a fair ways. There would be no great incentive as a miner to bother inforcing the rules unless your block would be invalidated for not doing so.
1306 2012-06-19 20:33:42 <gmaxwell> and if its invalidated then its not an alt thing- its a mandatory protocol rule at that point.
1307 2012-06-19 20:37:16 Zarutian has joined
1308 2012-06-19 20:38:24 <amiller> it costs more to mine invalid bitcoin blocks than it does to mine valid blocks - if your blocks get accepted by the network, then you get (at least partially) reimbursed for your effort
1309 2012-06-19 20:38:32 JZavala has joined
1310 2012-06-19 20:38:44 <amiller> mine an invalid block, no reimbursement
1311 2012-06-19 20:39:02 <amiller> with unincentivized merge-mined alt chains, there's no reimbursement and no disincentive to mine invalid blocks
1312 2012-06-19 20:39:29 <amiller> and since it actually costs a bit to maintain whatever additional auxiliary structure you need, e.g. the namecoin table, it's slightly more profitable to mine invalid blocks on the merge chains
1313 2012-06-19 20:39:58 <amiller> there's something 'no free lunch'y about merged mining
1314 2012-06-19 20:40:40 <gmaxwell> amiller: there is a benefit, but no free lunch.
1315 2012-06-19 20:41:50 <etotheipi_> okay, so if there's no incentive, the altchain could fork (say if different nodes start optimizing their tree structures differently :)) and no one would have any incentive to figure out what happened
1316 2012-06-19 20:43:43 <etotheipi_> is there a way to incentivize it?
1317 2012-06-19 20:44:01 <amiller> i've been reading a lot of distributed systems research lately, and one of the topics is byzantine/altruistic/rational modeling
1318 2012-06-19 20:44:17 <amiller> it's like behavioral economics, in that you need to define a model for rationality, and then show that the incentives are properly aligned
1319 2012-06-19 20:44:29 <amiller> it's hard to say exactly what rational behavior means
1320 2012-06-19 20:44:46 <etotheipi_> well I think there's still incentives
1321 2012-06-19 20:45:03 <etotheipi_> even miners use non-mining nodes to connect to the network to spend their mining rewards
1322 2012-06-19 20:45:18 <gmaxwell> it's better to just make it mandatory.
1323 2012-06-19 20:45:28 <gmaxwell> at least eventually.
1324 2012-06-19 20:45:38 <etotheipi_> (miners == people who control mining nodes)
1325 2012-06-19 20:45:53 <amiller> in the satoshi paper, he uses the word "honest"
1326 2012-06-19 20:45:57 <amiller> which has always stuck out at me
1327 2012-06-19 20:46:10 <amiller> honest implies beyond-rational
1328 2012-06-19 20:46:18 <gmaxwell> amiller: meh, I think you're reading far too much into it.
1329 2012-06-19 20:46:26 <etotheipi_> I believe that "mandatory" is the correct direction to go... but I don't think you're going to get there with a hard-fork from a cold start
1330 2012-06-19 20:47:25 <gmaxwell> amiller: There is this elegant thought that basically selfish behavior is not really compatible with cooperation. E.g. if I want to behave dishonestly to benefit me, thats going to be a different behavior than the dishonest behavior that benefits you. And even if we have an agreement, there is always a benefit to defecting.
1331 2012-06-19 20:48:54 <gmaxwell> So in our model an honest node is synonymous with 'interests are decorrelated with any other subset of nodes', and I don't think that requires any beyond rationality or anything like that
1332 2012-06-19 20:50:12 tower has quit (Disconnected by services)
1333 2012-06-19 20:50:25 <amiller> the basic idea of BAR is that there are many models where if you have say 99% are raitonally self interested, and 1% are byzantine malicious "want to watch the world burn", then the byzantine guy can win
1334 2012-06-19 20:50:26 tower has joined
1335 2012-06-19 20:50:43 <amiller> but on the other hand if you have 98% rational self interested, 1% altruistic, and 1% byzantine, it cancels out and you have a successful protocol
1336 2012-06-19 20:50:59 <amiller> http://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/clement08BAR.pdf A BAR Primer
1337 2012-06-19 20:51:39 <amiller> one of the authors in this paper is Jean Phillipe-Martin from microsoft research, who wrote the irrelevant "bitcoin and red balloons" paper (which is about bitcoin as a message propagation network, rather than a consensus network)
1338 2012-06-19 20:52:17 <gmaxwell> The red balloons paper made me sad. Totally clever and also pretty obviously pointless. :)
1339 2012-06-19 20:52:41 <amiller> the basic approach is to tolerate the byzantine failures, incentivize the rational guys, and make optimal use of the altruistic people
1340 2012-06-19 20:52:55 <amiller> bittorrent for example, the cockroach of the internet, would not exist at all in a fully rational model
1341 2012-06-19 20:53:07 <amiller> on the other hand, the altruistic participants are utilized very well
1342 2012-06-19 20:54:26 <amiller> an alternate blockchain with no incentives but 51% "altruistic" will work just fine and tolerate 49% byzantine failures
1343 2012-06-19 20:55:09 <gmaxwell> amiller: bittorrent has a lot of weird incentives. You have byzantine-altruistic participants. (People who help the networkâ because they want it to do well distributing their malware infected files)
1344 2012-06-19 20:55:38 <amiller> yeah fair enough, i realized i was ignoring the fact that there _is_ an incentive scheme in bittorrent but it's not totally secure
1345 2012-06-19 20:56:01 <amiller> that doesn't matter though since the typical clients have cooperative code, so there's some effort involved in violating it
1346 2012-06-19 20:56:31 <gmaxwell> you also don't have certian kinds of attackers because attacks are hard to montize. E.g. you could flood out the DHT easily, but unless you're the MPAA that doesn't benefit you, and if you are the MPAA it almost certantly will get you sued.
1347 2012-06-19 20:56:48 dvide has quit (Ping timeout: 255 seconds)
1348 2012-06-19 20:56:57 dvide has joined
1349 2012-06-19 20:59:14 JZavala has quit (Ping timeout: 244 seconds)
1350 2012-06-19 20:59:38 <amiller> i thought i read that the mpaa openly hired people to fill bittorrent with junk
1351 2012-06-19 20:59:49 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 1486 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1486>
1352 2012-06-19 21:00:22 <gmaxwell> amiller: junk sure â fake torrentsâ but not knocking out the DHT because that would hit the legit users too.
1353 2012-06-19 21:00:43 <amiller> gotcha
1354 2012-06-19 21:00:50 <etotheipi_> I think it would be better to covertly fill bittorrent with seemingly-legit files that actually destroy your system in some way, then use your own resources to pump those up
1355 2012-06-19 21:01:57 <Eliel> the problem with filling bitcoin with crap is that the system is largely self-policing in that people won't share the crap.
1356 2012-06-19 21:02:04 <Eliel> that is, after they find it's crap
1357 2012-06-19 21:02:19 <Eliel> to work, it has to look like the real deal for quite a while
1358 2012-06-19 21:02:34 <amiller> it wouldn't be if bitcoin were an alt chain with no incentives, though
1359 2012-06-19 21:02:56 <etotheipi_> I would think the MPAA would have the resources to add 300 seeders to each of their fake torrents and add automated comments that are real enough
1360 2012-06-19 21:02:57 <amiller> but then again, i don't see a forest, i only see the limit as the number of trees approaches infinity
1361 2012-06-19 21:03:09 <Eliel> ah wait, I meant bittorrent :)
1362 2012-06-19 21:03:10 <amiller> also the trees are all merkle trees
1363 2012-06-19 21:03:20 <Eliel> too tired :)
1364 2012-06-19 21:03:23 <gmaxwell> etotheipi_: that also gets you in deep trouble if you're the MPAA.
1365 2012-06-19 21:03:25 <etotheipi_> I prefer patricia trees
1366 2012-06-19 21:03:27 cdecker has quit (Quit: Leaving.)
1367 2012-06-19 21:03:42 <gmaxwell> etotheipi_: "they're evil but not stupid. ... okay, not THAT stupid."
1368 2012-06-19 21:04:09 <BlueMatt> we kinda spend a lot of time in sha256: http://i.imgur.com/l2dvV.png
1369 2012-06-19 21:04:13 <gmaxwell> etotheipi_: also optimal strategy for an underground contact that they might secretly pay to do that: Claim to do it but don't.
1370 2012-06-19 21:04:18 <BlueMatt> (thats just in block commit thread)
1371 2012-06-19 21:04:27 <gmaxwell> BlueMatt: you saw my earlier picture?
1372 2012-06-19 21:04:39 <etotheipi_> I think the benefit to the network (and the operators of the miners themselves) is enough to keep the alt-chain going until it has support for becoming mandatory
1373 2012-06-19 21:04:41 <BlueMatt> gmaxwell: no
1374 2012-06-19 21:04:53 <gmaxwell> BlueMatt: https://people.xiph.org/~greg/bitcoin-start.png
1375 2012-06-19 21:05:04 <gmaxwell> BlueMatt: thats just the loadblockindex.
1376 2012-06-19 21:05:08 <BlueMatt> heh
1377 2012-06-19 21:05:19 Internet13 has quit (Read error: Connection reset by peer)
1378 2012-06-19 21:05:21 <BlueMatt> the one I linked was -loadblock=...
1379 2012-06-19 21:05:27 yellowhat has quit (Read error: Connection reset by peer)
1380 2012-06-19 21:05:31 grepix has quit (Read error: Connection reset by peer)
1381 2012-06-19 21:05:32 BurtyB has quit (Read error: Connection reset by peer)
1382 2012-06-19 21:05:40 word_ has joined
1383 2012-06-19 21:05:41 grepix has joined
1384 2012-06-19 21:05:47 JStoker has quit (Excess Flood)
1385 2012-06-19 21:05:47 <gmaxwell> actually running 0.6.2.2 nodes seem to spend all their time in ecdsa validation though, especially while getmemorypool mining. Running a profile on git master now.
1386 2012-06-19 21:05:48 jimbit_ has joined
1387 2012-06-19 21:05:55 yellowhat has joined
1388 2012-06-19 21:05:57 titeuf_87 has quit (Read error: Connection reset by peer)
1389 2012-06-19 21:06:22 <BlueMatt> gmaxwell: yea, but downloading blocks up to checkpoints you dont check any, and then you spend an unreasonable amount of your time in sha256,
1390 2012-06-19 21:06:30 <BlueMatt> after removing duplicate calls: http://i.imgur.com/9xc5S.png
1391 2012-06-19 21:06:39 slush has joined
1392 2012-06-19 21:06:49 da2ce7 has joined
1393 2012-06-19 21:08:02 <gmaxwell> the call count looks the same.
1394 2012-06-19 21:08:14 <gmaxwell> is that just because you're looking only under accept block there?
1395 2012-06-19 21:08:17 BurtyB has joined
1396 2012-06-19 21:08:22 da2ce720 has quit (Ping timeout: 246 seconds)
1397 2012-06-19 21:08:44 word has quit (Ping timeout: 246 seconds)
1398 2012-06-19 21:08:44 jimbit has quit (Ping timeout: 246 seconds)
1399 2012-06-19 21:08:47 <BlueMatt> the % listed in text is the % of total time in the single initial call to GetHash() of the block being accepted
1400 2012-06-19 21:08:57 <gmaxwell> BlueMatt: btw, right click on the map and you can turn off shading and turn on counts, makes it a bit more useful.
1401 2012-06-19 21:09:16 JStoker has joined
1402 2012-06-19 21:09:23 PK has quit ()
1403 2012-06-19 21:10:08 <BlueMatt> gmaxwell: in this case you cant accurately compare counts, they only load a /similar/ amount of blocks
1404 2012-06-19 21:10:49 <BlueMatt> but you can compare that a single call to GetHash() for each block loaded goes from 2.53% of cpu time to 5.2%...
1405 2012-06-19 21:10:56 Internet13 has joined
1406 2012-06-19 21:11:04 datagutt has quit (Quit: Computer has gone to sleep.)
1407 2012-06-19 21:11:08 tyn has quit (Ping timeout: 248 seconds)
1408 2012-06-19 21:14:58 <jjjx> Whoa what is this and how was it generated? https://people.xiph.org/~greg/bitcoin-start.png
1409 2012-06-19 21:15:25 <BlueMatt> its from callgrind
1410 2012-06-19 21:15:40 <BlueMatt> its where the cpu spent its time in AppInit2
1411 2012-06-19 21:15:54 <jjjx> That looks bloody useful
1412 2012-06-19 21:16:25 <jjjx> Does it let you step through the app as slowly as you want?
1413 2012-06-19 21:16:38 <jjjx> Or does it make logs of action at given points? How does it work?
1414 2012-06-19 21:16:44 <gmaxwell> jjjx: It's a program called 'kcachegrind' which processes the output from valgrind's callgrind module.
1415 2012-06-19 21:16:48 sgstair has quit (Read error: Connection reset by peer)
1416 2012-06-19 21:16:52 _sgstair has joined
1417 2012-06-19 21:16:53 _sgstair is now known as sgstair
1418 2012-06-19 21:17:03 <jjjx> I see.
1419 2012-06-19 21:17:20 <gmaxwell> Callgrind writes statstics on a whole run and you can navigate itâ including call tree cases, and execution time (estimates) to the line of source or even asm instruction level.
1420 2012-06-19 21:17:31 <jjjx> That's amazing.
1421 2012-06-19 21:17:35 <jjjx> I've never seen something like that before.
1422 2012-06-19 21:17:57 <gmaxwell> It also esimates branch predictor and cache behavior (poorly), and can record the outcome of every branch so you can get statistics on which conditional in expression should go first.
1423 2012-06-19 21:18:26 <gmaxwell> Alsoâ works okay on optimized binaries. Makes your program 10x slower though. :)
1424 2012-06-19 21:18:58 <jjjx> Damn.
1425 2012-06-19 21:19:06 <BlueMatt> 10x may be an understatement...
1426 2012-06-19 21:19:11 <jjjx> Does it work on Windows?
1427 2012-06-19 21:19:25 <BlueMatt> why would you develop on windows?
1428 2012-06-19 21:19:37 <gmaxwell> jjjx: No, but it's worth running Linux for valgrind alone.
1429 2012-06-19 21:19:58 <gmaxwell> Single most powerful development tool since the invention of the compiler.
1430 2012-06-19 21:20:11 <jjjx> I hope this app is going to lead to faster and faster Bitcoin app
1431 2012-06-19 21:20:14 <jjjx> gmaxwell: Looks like it!
1432 2012-06-19 21:21:03 <BlueMatt> jjjx: the bitcoin bottlenecks are already pretty well-known...
1433 2012-06-19 21:21:03 TD has joined
1434 2012-06-19 21:21:46 <gavinandresen> https://github.com/bitcoin/bitcoin/commits/0.6.3 ready for a little review before being tagged as v0.6.3rc1
1435 2012-06-19 21:22:19 slush1 has joined
1436 2012-06-19 21:22:33 <gmaxwell> gavinandresen: should 0.6.3 potentially have pulled testnet3 (I'm sorry to mention it lateâ thought of it before but didn't comment)
1437 2012-06-19 21:22:48 <gavinandresen> gmaxwell: I intentionally did NOT pull testnet3
1438 2012-06-19 21:23:02 <gmaxwell> Fine enough.
1439 2012-06-19 21:23:07 <gavinandresen> ... on the general principle of minimizing changes in a ..x release
1440 2012-06-19 21:25:38 <BlueMatt> heh, 44 commits in one pull request...now that has to be a record
1441 2012-06-19 21:25:49 Zarutian has quit (Quit: Zarutian)
1442 2012-06-19 21:28:25 Nachtwind has left ("Verlassend")
1443 2012-06-19 21:30:52 * BlueMatt really needs to stop extending the same branches...
1444 2012-06-19 21:31:06 Zarutian has joined
1445 2012-06-19 21:31:51 Turingi has joined
1446 2012-06-19 21:31:51 Turingi has quit (Changing host)
1447 2012-06-19 21:31:51 Turingi has joined
1448 2012-06-19 21:34:21 GTRsdk is now known as GTRsdk-work
1449 2012-06-19 21:35:44 wasabi1 has quit (Read error: Connection reset by peer)
1450 2012-06-19 21:35:52 grepix has quit (Read error: Connection reset by peer)
1451 2012-06-19 21:36:08 grepix has joined
1452 2012-06-19 21:36:13 wasabi has joined
1453 2012-06-19 21:38:51 minimoose_ has joined
1454 2012-06-19 21:40:00 minimoose has quit (Ping timeout: 244 seconds)
1455 2012-06-19 21:40:02 minimoose_ is now known as minimoose
1456 2012-06-19 21:48:48 _Fireball has quit (Quit: HydraIRC -> http://www.hydrairc.com <- Now with extra fish!)
1457 2012-06-19 21:55:18 ovidiusoft has quit (Ping timeout: 264 seconds)
1458 2012-06-19 21:56:38 tyn has joined
1459 2012-06-19 21:57:23 TD has quit (Quit: TD)
1460 2012-06-19 22:01:30 m00p has quit (Read error: Operation timed out)
1461 2012-06-19 22:02:16 wizkid057 has quit (Read error: Operation timed out)
1462 2012-06-19 22:02:25 agricocb has quit (Remote host closed the connection)
1463 2012-06-19 22:02:56 wizkid057 has joined
1464 2012-06-19 22:06:42 slush has quit (Read error: Connection reset by peer)
1465 2012-06-19 22:07:08 slush has joined
1466 2012-06-19 22:10:59 Zarutian has quit (Quit: Zarutian)
1467 2012-06-19 22:18:23 Internet13 has quit (Quit: Leaving)
1468 2012-06-19 22:19:16 Internet13 has joined
1469 2012-06-19 22:20:49 erle- has quit (Ping timeout: 246 seconds)
1470 2012-06-19 22:22:00 t7 has joined
1471 2012-06-19 22:23:16 Raziel_ has quit (Quit: Leaving)
1472 2012-06-19 22:23:51 slush has quit (Quit: Leaving.)
1473 2012-06-19 22:23:56 slush2 has joined
1474 2012-06-19 22:26:04 gavinandresen has quit (Quit: gavinandresen)
1475 2012-06-19 22:28:22 Zarutian has joined
1476 2012-06-19 22:29:35 slush2 has quit (Ping timeout: 246 seconds)
1477 2012-06-19 22:30:43 <Ukto> I think it would be nice to have a command (RPC'able) to check and return any needed txn fee
1478 2012-06-19 22:31:55 <Ukto> would be a neat addin for 7 :P
1479 2012-06-19 22:32:22 <Ukto> or sooner >,>
1480 2012-06-19 22:32:34 <xorgate> code it )
1481 2012-06-19 22:33:06 <Ukto> wrong language for me. :)
1482 2012-06-19 22:33:11 <Ukto> I wold be happy to if I coudl tho
1483 2012-06-19 22:33:15 erle- has joined
1484 2012-06-19 22:33:46 <freewil> Ukto, +1 for that
1485 2012-06-19 22:33:59 <freewil> seems it would not be a difficult thing to add
1486 2012-06-19 22:34:07 <freewil> assuming the coin selection is somewhat deterministic
1487 2012-06-19 22:34:09 <Ukto> mebbe sometime in the next few months I will sit down and make an attempt at the code
1488 2012-06-19 22:34:35 <luke-jr> freewil: it's not.
1489 2012-06-19 22:34:51 <BlueMatt> iirc coin selectiong isnt deterministic, so... but also you have to deal with an incoming tx after requesting fee required but before sending...
1490 2012-06-19 22:35:17 <Ukto> would be nice for the client too. *send btc* "Sending this BTC will require a X txn fee, are you sure?"
1491 2012-06-19 22:35:29 <BlueMatt> its in the -qt client, just not rpc
1492 2012-06-19 22:35:38 <freewil> BlueMatt, yeah that case would just be something you would have to deal with
1493 2012-06-19 22:35:40 <luke-jr> Ukto: I have a pullreq that does basically that
1494 2012-06-19 22:35:44 <BlueMatt> you could, however, do it the same as in the -qt client
1495 2012-06-19 22:35:45 <Ukto> ah
1496 2012-06-19 22:35:48 <luke-jr> Ukto: it lets you set a maximum fee to be paid
1497 2012-06-19 22:35:49 <freewil> but if you could always say i will use these inputs for this amount
1498 2012-06-19 22:35:56 <freewil> then it seems it would be easy to rejigger things
1499 2012-06-19 22:35:58 <dub> <Ukto> would be nice for the client too. *send btc* "Sending this BTC will require a X txn fee, are you sure?"
1500 2012-06-19 22:36:00 <Ukto> luke-jr: similar, but I was more after the RPC functionality
1501 2012-06-19 22:36:02 <luke-jr> Ukto: if bitcoind thinks it needs more, it errors
1502 2012-06-19 22:36:02 <dub> this already happens
1503 2012-06-19 22:36:07 <freewil> luke-jr, is it somewhat random?
1504 2012-06-19 22:36:08 <luke-jr> Ukto: yes, this is with RPC
1505 2012-06-19 22:36:10 <luke-jr> freewil: yes
1506 2012-06-19 22:36:23 <gmaxwell> RPC can't do it because the RPCs don't block the whole client.
1507 2012-06-19 22:36:38 <gmaxwell> what luke has is sane though.
1508 2012-06-19 22:36:55 <Ukto> luke-jr: i dont want it to go through, i just want to know if thre will be a fee
1509 2012-06-19 22:36:58 <Ukto> as a reaponse
1510 2012-06-19 22:37:02 <Ukto> the clien thing was a side idea
1511 2012-06-19 22:37:03 <gmaxwell> although ... well, it's a little odd now because the selection code doesn't even try to minimize fees.
1512 2012-06-19 22:37:07 <luke-jr> IIRC, it's held up because it has a hidden feature to force send against fee policies
1513 2012-06-19 22:37:12 O2made has joined
1514 2012-06-19 22:37:18 <luke-jr> Ukto: then set max fee to 0
1515 2012-06-19 22:37:22 <gmaxwell> so you can have fun stuff like "failed, needs a bigger maximum" and then you increase the maximum .. and it goes with no fee.
1516 2012-06-19 22:37:33 <Ukto> luke-jr: great, but that doesnt do what I am asking.
1517 2012-06-19 22:37:37 <luke-jr> Ukto: or -1
1518 2012-06-19 22:37:47 Zarutian has quit (Quit: Zarutian)
1519 2012-06-19 22:38:01 <Ukto> I am asking to return the required fee. beit 0 or not. I dont want it to actually send
1520 2012-06-19 22:38:05 <BlueMatt> having the send* commands return the fee paid wouldnt be hard, but you can do that by requesting the tx from the hash already returned
1521 2012-06-19 22:38:06 <luke-jr> warning: i didn't test -1
1522 2012-06-19 22:38:16 O2made has quit (Read error: Connection reset by peer)
1523 2012-06-19 22:38:25 <gmaxwell> Ukto: the required fee is not a function!
1524 2012-06-19 22:38:38 <freewil> is it possible to add a rpc call that calculates the fee and saves the coin selection for a following send call
1525 2012-06-19 22:38:39 <gmaxwell> Ukto: you can ask.. and a nanosecond later its different.
1526 2012-06-19 22:38:47 <luke-jr> meh, -1 errors
1527 2012-06-19 22:38:50 <gmaxwell> freewil: it would be possible to do that, yes.
1528 2012-06-19 22:39:01 <BlueMatt> freewil: sort of, as long as you dont get a new tx before sending
1529 2012-06-19 22:39:05 <gmaxwell> freewil: though any other spend would invalidate that selection.
1530 2012-06-19 22:39:08 <BlueMatt> but you can just error there
1531 2012-06-19 22:39:16 <luke-jr> BlueMatt: getting a new tx won't invalidate coin selection
1532 2012-06-19 22:39:21 <gmaxwell> BlueMatt: well you could ignore the rx at least.
1533 2012-06-19 22:39:23 <BlueMatt> luke-jr: it can
1534 2012-06-19 22:39:29 <BlueMatt> gmaxwell: well yea
1535 2012-06-19 22:39:31 <Ukto> gmaxwell: Ah, I was under the impression it was nly based off of amount, age and bytesize. (didnt think age was acocunted to the nano second) :)
1536 2012-06-19 22:39:42 <BlueMatt> might not want to as it could get you a lower fee though...
1537 2012-06-19 22:39:50 <luke-jr> Ukto: and random()
1538 2012-06-19 22:39:57 <gmaxwell> Ukto: Age of _inputs_ in confirmations, but the inputs are not determinstic.
1539 2012-06-19 22:39:58 <Ukto> .. why is there a random?
1540 2012-06-19 22:40:19 <luke-jr> Ukto: bitcoind doesn't even try to minimize the fee really
1541 2012-06-19 22:40:21 <gmaxwell> Ukto: because (1) privacy, and (2) the solver can fail.
1542 2012-06-19 22:40:38 <Ukto> hm, alright
1543 2012-06-19 22:40:39 <gmaxwell> It tries to minimize the number of inputs which sometimes minmizes the fee indirectly.
1544 2012-06-19 22:40:47 <Ukto> was just an idea if it could have been done. :)
1545 2012-06-19 22:40:56 tsche has quit ()
1546 2012-06-19 22:42:08 <gmaxwell> in any case, the fee can't ever be over 0.05 btc with default settings.
1547 2012-06-19 22:43:06 <gmaxwell> (because it's unwilling to max a txn larger than 100kb)
1548 2012-06-19 22:46:54 copumpkin has quit (Quit: Computer has gone to sleep.)
1549 2012-06-19 22:48:53 epscy has quit (Ping timeout: 245 seconds)
1550 2012-06-19 22:52:25 epscy has joined
1551 2012-06-19 22:56:00 jjjx has quit (Quit: Lost terminal)
1552 2012-06-19 23:04:57 copumpkin has joined
1553 2012-06-19 23:07:25 <Diablo-D3> background: #fff url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEX%2F%2F%2F9ISEhr7AOpAAAAAXRSTlMAQObYZgAAACVJREFUCNdjYEACHAIMMhYMdjUM8j8Y%2BD8wsD9gYD7AwNiArAQAd4oFaCu14IQAAAAASUVORK5CYII%3D);
1554 2012-06-19 23:07:30 <Diablo-D3> well aint that fucking clever
1555 2012-06-19 23:09:45 <gmaxwell> you just discovered data urls?
1556 2012-06-19 23:10:10 Prattler has quit (Remote host closed the connection)
1557 2012-06-19 23:10:27 jimbit has joined
1558 2012-06-19 23:13:21 jimbit_ has quit (Ping timeout: 276 seconds)
1559 2012-06-19 23:19:01 minimoose_ has joined
1560 2012-06-19 23:20:24 tower has quit (Ping timeout: 265 seconds)
1561 2012-06-19 23:22:13 maaku has quit (Quit: maaku)
1562 2012-06-19 23:23:08 minimoose has quit (Ping timeout: 246 seconds)
1563 2012-06-19 23:23:08 minimoose_ is now known as minimoose
1564 2012-06-19 23:26:50 thesheff17 has joined
1565 2012-06-19 23:27:06 tower has joined
1566 2012-06-19 23:29:31 sgstair has quit (Read error: Connection reset by peer)
1567 2012-06-19 23:29:56 sgstair has joined
1568 2012-06-19 23:30:12 t7 has quit (Remote host closed the connection)
1569 2012-06-19 23:30:13 mmoya has quit (Ping timeout: 240 seconds)
1570 2012-06-19 23:30:15 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
1571 2012-06-19 23:30:20 slush has joined
1572 2012-06-19 23:32:21 RainbowDashh has joined
1573 2012-06-19 23:34:09 copumpkin has quit (Ping timeout: 276 seconds)
1574 2012-06-19 23:34:42 copumpkin has joined
1575 2012-06-19 23:38:25 sirk390 has quit (Quit: Leaving.)
1576 2012-06-19 23:43:18 erle- has quit (Quit: erle-)
1577 2012-06-19 23:47:16 EricLombrozo has joined
1578 2012-06-19 23:47:37 <EricLombrozo> is there a maximum limit to the script size in a transaction?
1579 2012-06-19 23:49:30 <luke-jr> yes
1580 2012-06-19 23:49:39 <EricLombrozo> what is it?
1581 2012-06-19 23:51:13 <EricLombrozo> is there a per-input and per-output limit? or are you only limited by the total transaction size limit?
1582 2012-06-19 23:51:35 <TuxBlackEdo> 1mb
1583 2012-06-19 23:51:40 <TuxBlackEdo> 1mb block size
1584 2012-06-19 23:52:14 <EricLombrozo> so in principle you could have a block containing only one transaction with an output script that is nearly 1MB in length?
1585 2012-06-19 23:52:25 <TuxBlackEdo> yes
1586 2012-06-19 23:52:31 <TuxBlackEdo> probably?
1587 2012-06-19 23:52:39 <EricLombrozo> no, not probably - I need to know for sure
1588 2012-06-19 23:52:42 <EricLombrozo> :)
1589 2012-06-19 23:52:54 <TuxBlackEdo> you mine a block with the payout address for like 100000 outputs
1590 2012-06-19 23:53:01 <EricLombrozo> I don't want to be changing my data model later on once I've build this database
1591 2012-06-19 23:53:22 <TuxBlackEdo> actually
1592 2012-06-19 23:53:24 <EricLombrozo> I'm not asking per transaction - I'm asking per input or output
1593 2012-06-19 23:53:34 <TuxBlackEdo> ignore me, i might be completely wrong
1594 2012-06-19 23:53:35 <EricLombrozo> one transaction with one input (coinbase) and one output
1595 2012-06-19 23:54:10 <TuxBlackEdo> ;;bc,wiki protocol rules
1596 2012-06-19 23:54:10 <gribble> https://en.bitcoin.it/wiki/Protocol_rules | The wiki substantially documents the Bitcoin protocol, but equally important are the rules used by the client to process messages. It's crucial that clients follow ...
1597 2012-06-19 23:54:53 <EricLombrozo> I see a block size limit. are there any other structure length limits?
1598 2012-06-19 23:55:10 Backburn has quit (Remote host closed the connection)
1599 2012-06-19 23:55:17 <jgarzik> EricLombrozo: no more than 50,000 entries in an "inv" message
1600 2012-06-19 23:55:18 <EricLombrozo> I do see restrictions on the coinbase transactions
1601 2012-06-19 23:55:32 Backburn has joined
1602 2012-06-19 23:55:36 <EricLombrozo> "8.For the coinbase (first) transaction, scriptSig length must be 2-100"
1603 2012-06-19 23:56:08 <EricLombrozo> did I miss any others?
1604 2012-06-19 23:56:23 <TuxBlackEdo> ;;bc,wiki protocol specification
1605 2012-06-19 23:56:23 <gribble> https://en.bitcoin.it/wiki/Protocol_specification | Mar 27, 2012 ... Protocol specification ... Type names used in this documentation are from the C99 standard. For protocol used in mining, see Getwork.
1606 2012-06-19 23:56:37 <TuxBlackEdo> not sure if helping...
1607 2012-06-19 23:56:56 <EricLombrozo> I understand the protocol datatypes - just trying to understand the limits imposed by the bitcoin rules
1608 2012-06-19 23:57:28 <EricLombrozo> the bitcoin protocol datatypes in principle support data structures of obscene size
1609 2012-06-19 23:58:54 <EricLombrozo> I see a MAX_BLOCK_SIZE = 1MB and the first scriptSig length must be between 2-100 bytes
1610 2012-06-19 23:59:30 <EricLombrozo> are there any other rule restrictions on size? (not talking about what the datatypes could actually support)
1611 2012-06-19 23:59:40 <luke-jr> yes
1612 2012-06-19 23:59:42 <luke-jr> read the code
1613 2012-06-19 23:59:49 AntKinGTube has joined