1 2012-08-21 00:00:06 Gladamas has joined
2 2012-08-21 00:05:57 Joric has quit ()
3 2012-08-21 00:07:35 <sipa> amiller: anyway, as said, ultraprune was originally just an experiment about how small i could get the storage requirements for a validating node; there are certainly more performant solutions, but the bottleneck (right now) is signature verification anyway, so i could optimize storage further :)
4 2012-08-21 00:08:12 D34TH_ is now known as D34TH
5 2012-08-21 00:08:19 D34TH has quit (Changing host)
6 2012-08-21 00:08:19 D34TH has joined
7 2012-08-21 00:09:26 iocor has quit (Quit: Computer has gone to sleep.)
8 2012-08-21 00:10:20 B0g4r7 has joined
9 2012-08-21 00:13:12 Gladamas has quit (Read error: Connection reset by peer)
10 2012-08-21 00:13:22 Gladamas has joined
11 2012-08-21 00:15:01 paraipan has quit (Quit: Saliendo)
12 2012-08-21 00:18:01 iocor has joined
13 2012-08-21 00:18:05 iocor has quit (Changing host)
14 2012-08-21 00:18:05 iocor has joined
15 2012-08-21 00:26:21 one_zero has joined
16 2012-08-21 00:26:25 brwyatt is now known as brwyatt|Away
17 2012-08-21 00:30:15 gavinandresen has quit (Quit: gavinandresen)
18 2012-08-21 00:31:51 <sipa> amiller: it was actually in #haskell-blah that i discovered bitcoin :)
19 2012-08-21 00:36:02 pickett has quit (Ping timeout: 276 seconds)
20 2012-08-21 00:36:04 Gladamas is now known as priateat40
21 2012-08-21 00:38:29 pickett has joined
22 2012-08-21 00:44:26 priateat40 is now known as [pirateat40]
23 2012-08-21 00:45:15 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
24 2012-08-21 00:46:59 [pirateat40] is now known as pireteat40
25 2012-08-21 00:48:41 pireteat40 has quit (Read error: Connection reset by peer)
26 2012-08-21 00:48:51 Gladamas has joined
27 2012-08-21 00:51:26 BTCTrader is now known as pirateat-halfoff
28 2012-08-21 00:52:06 rdponticelli has joined
29 2012-08-21 00:59:25 iocor has quit (Quit: Computer has gone to sleep.)
30 2012-08-21 01:01:43 Maged has quit (Disconnected by services)
31 2012-08-21 01:01:52 Maged__ has joined
32 2012-08-21 01:02:07 Maged__ is now known as Maged
33 2012-08-21 01:05:58 <jgarzik> ok, pynode can create blocks
34 2012-08-21 01:06:18 <jgarzik> now to teach it getwork.. ugh. I hope I don't have to implement sha256 in python, just to get the useless midstate
35 2012-08-21 01:11:31 gruez has joined
36 2012-08-21 01:12:17 <gruez> does anyone have 0.7.0 RC binaries?
37 2012-08-21 01:12:24 <gruez> for windows
38 2012-08-21 01:13:46 <Luke-Jr> there is no RC yet
39 2012-08-21 01:13:54 D34TH has quit (Quit: Leaving)
40 2012-08-21 01:15:56 robocoin has quit (Quit: Verlassend)
41 2012-08-21 01:18:02 <gruez> aww
42 2012-08-21 01:18:03 <gruez> :(
43 2012-08-21 01:24:20 PhantomSpark has quit (Read error: Connection reset by peer)
44 2012-08-21 01:24:51 gruez has quit (Quit: Page closed)
45 2012-08-21 01:26:49 JudgeTheDude has joined
46 2012-08-21 01:27:31 rickbauss has joined
47 2012-08-21 01:30:54 PhantomSpark has joined
48 2012-08-21 01:31:29 denisx has quit (Quit: denisx)
49 2012-08-21 01:35:46 vampireb has joined
50 2012-08-21 01:36:14 JudgeTheDude has quit (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
51 2012-08-21 01:38:08 <BlueMatt> when relaying a block as header+coinbase+vector<tx hash> what would you call the message name of that object on p2p
52 2012-08-21 01:38:56 <jgarzik> PPCoin dev: "The current checkpoint policy leaves up to 4 hours window for folks to try mounting double-spending attacks"
53 2012-08-21 01:39:13 <BlueMatt> ...
54 2012-08-21 01:40:25 Zarutian has joined
55 2012-08-21 01:40:40 <gmaxwell> jgarzik: I'm confused by that because their checkpoints were issued right against the top of the chain. And orphaned my little test node at least once.
56 2012-08-21 01:42:53 Mad7Scientist is now known as root
57 2012-08-21 01:43:25 root is now known as Guest4750
58 2012-08-21 01:43:28 Guest4750 is now known as Mad7Scientist
59 2012-08-21 01:43:56 Maged has quit (Disconnected by services)
60 2012-08-21 01:44:05 Maged_ has joined
61 2012-08-21 01:44:17 Maged_ has quit (Client Quit)
62 2012-08-21 01:45:48 Maged has joined
63 2012-08-21 01:50:59 MC-Eeepc has quit (Ping timeout: 240 seconds)
64 2012-08-21 01:55:46 gigatube is now known as imsaguy
65 2012-08-21 01:55:50 <jgarzik> meh
66 2012-08-21 01:55:57 bdcs is now known as bdcs_wants_voice
67 2012-08-21 01:56:07 <jgarzik> I'm just not going to support 'hash1' and 'midstate' bits of 'getwork' RPC
68 2012-08-21 01:56:31 rickbauss has quit (Read error: Connection reset by peer)
69 2012-08-21 01:58:41 bdcs_wants_voice is now known as bdcs
70 2012-08-21 01:58:50 brwyatt is now known as brwyatt|Away
71 2012-08-21 01:59:23 MC-Eeepc has joined
72 2012-08-21 01:59:46 SnapSnap has joined
73 2012-08-21 02:01:21 <SnapSnap> My client is telling me: "WARNING: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade." I'm running 0.6.3. Should I worry about this?
74 2012-08-21 02:01:59 <gmaxwell> SnapSnap: can you pastebin your debug.log?
75 2012-08-21 02:07:09 hahuang65 has joined
76 2012-08-21 02:07:18 <BlueMatt> ;;later tell TD, the reason I didnt think through the merkleBlock.vtx[0]).size() check is that the comment in bitcoinj was incorrectly pointing out a more efficient way of handling the tree edge, fixed now
77 2012-08-21 02:07:18 <gribble> Error: "0" is not a valid command.
78 2012-08-21 02:07:27 <BlueMatt> ;;later tell TD the reason I didnt think through the merkleBlock.vtx[0]).size() check is that the comment in bitcoinj was incorrectly pointing out a more efficient way of handling the tree edge, fixed now
79 2012-08-21 02:07:27 <gribble> Error: "0" is not a valid command.
80 2012-08-21 02:07:43 <BlueMatt> nanotube: whats up?
81 2012-08-21 02:08:33 <SnapSnap> It's pretty big
82 2012-08-21 02:10:11 dust-otc has joined
83 2012-08-21 02:10:52 <SnapSnap> gmaxwell, the site is still uploading it
84 2012-08-21 02:12:42 <SnapSnap> It's 10.2 MB. Is that normal?
85 2012-08-21 02:12:59 <SnapSnap> Only had this particular wallet a couple days
86 2012-08-21 02:13:21 <gmaxwell> it's not abnormal.
87 2012-08-21 02:17:57 minimoose has joined
88 2012-08-21 02:26:15 dbe has joined
89 2012-08-21 02:30:15 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
90 2012-08-21 02:32:06 <SnapSnap> gmaxwell, wouldn't upload on pastebin. Figured out a solution: https://docs.google.com/open?id=0B25-dSIaJwdJLWczNC1RTm1FcjA
91 2012-08-21 02:37:14 rofer has quit (Read error: Connection reset by peer)
92 2012-08-21 02:38:04 <amiller> HAH!
93 2012-08-21 02:38:49 <amiller> (log M) is bounded by 50.
94 2012-08-21 02:39:15 <amiller> that's how many satoshis there are, and we can't have more than one UTXO per satoshi
95 2012-08-21 02:41:43 drazak has quit (Ping timeout: 244 seconds)
96 2012-08-21 02:42:35 darkee has joined
97 2012-08-21 02:43:11 <amiller> this ratio is important, too, because at some point you're able to birthday-attack UTXOs efficiently.
98 2012-08-21 02:43:38 <amiller> (logM) < 50x5 < 256 = k
99 2012-08-21 02:44:58 minimoose has quit (Quit: minimoose)
100 2012-08-21 02:46:03 darkee has quit (Ping timeout: 276 seconds)
101 2012-08-21 02:46:59 dust-otc is now known as dust-afk
102 2012-08-21 02:49:58 <SnapSnap> gmaxwell, any ideas?
103 2012-08-21 02:51:14 olp has quit (Ping timeout: 276 seconds)
104 2012-08-21 02:51:38 minimoose has joined
105 2012-08-21 02:52:30 <nanotube> BlueMatt: [] is syntax for nested commands. to avoid parsing quote the message in double quotes.
106 2012-08-21 02:52:48 <BlueMatt> nanotube: oh, heh dur I knew that...sorry
107 2012-08-21 02:53:24 * cjd waves to nano
108 2012-08-21 02:54:43 <nanotube> BlueMatt: :)
109 2012-08-21 02:54:48 <nanotube> cjd: hey ltns!
110 2012-08-21 02:54:52 <cjd> indeed
111 2012-08-21 02:55:51 <cjd> joined to ask around and see if anyone knew what happened to cia.vc.. found out the conference in London is upon us so trying to figure out if it'll work to go..
112 2012-08-21 02:58:07 SnapSnap has left ("Leaving")
113 2012-08-21 03:00:45 <gmaxwell> amiller: yes we can, have more UTXO than satoshi. :( but thats idiotcy that should be fixed.
114 2012-08-21 03:01:01 <amiller> lol how
115 2012-08-21 03:01:02 <gmaxwell> sneak: that link gives me not found.
116 2012-08-21 03:07:37 minimoose has quit (Quit: minimoose)
117 2012-08-21 03:07:40 Z0rZ0rZ0r_ has joined
118 2012-08-21 03:09:56 Z0rZ0rZ0r has quit (Ping timeout: 268 seconds)
119 2012-08-21 03:09:56 localhost has quit (Quit: Do fish get thirsty?)
120 2012-08-21 03:10:20 Zarutian has quit (Quit: Zarutian)
121 2012-08-21 03:11:36 Gladamas_ has joined
122 2012-08-21 03:14:22 Gladamas has quit (Ping timeout: 240 seconds)
123 2012-08-21 03:15:39 <jgarzik> 'getwork' RPC for pynode pushed
124 2012-08-21 03:15:56 <jgarzik> incompatible with existing mining software, but that will be fixed shortly
125 2012-08-21 03:17:08 <Luke-Jr> jgarzik: why incompatible?
126 2012-08-21 03:17:18 osmosis has quit (Quit: Leaving)
127 2012-08-21 03:17:25 <jgarzik> easier
128 2012-08-21 03:17:38 <Luke-Jr> you know only DiabloMiner requires midstate/hash1 now?
129 2012-08-21 03:17:39 minimoose has joined
130 2012-08-21 03:17:59 olp has joined
131 2012-08-21 03:18:07 <Luke-Jr> https://en.bitcoin.it/wiki/Getwork_support
132 2012-08-21 03:19:05 da2ce772 has joined
133 2012-08-21 03:23:21 <MC-Eeepc> why are people still not using p2pool
134 2012-08-21 03:23:26 <MC-Eeepc> lazyness?
135 2012-08-21 03:24:10 <MC-Eeepc> dont pools get dossed all the time
136 2012-08-21 03:24:17 <MC-Eeepc> arnt people get sick of that shit
137 2012-08-21 03:24:31 TheSeven has quit (Disconnected by services)
138 2012-08-21 03:24:41 [7] has joined
139 2012-08-21 03:24:42 <cjd> community
140 2012-08-21 03:24:52 <cjd> the reason why people mine in pools
141 2012-08-21 03:24:59 in has quit (Ping timeout: 252 seconds)
142 2012-08-21 03:25:09 <cjd> same reason bittorrent "won out" over other protocols
143 2012-08-21 03:25:48 TRefgh has quit (Quit: Leaving)
144 2012-08-21 03:25:54 <MC-Eeepc> private p2pools can be made though
145 2012-08-21 03:27:12 <MC-Eeepc> well atleast deepbit is waning
146 2012-08-21 03:27:34 <MC-Eeepc> but it looks like someone could control a huge amount of the new hashpower
147 2012-08-21 03:27:37 <MC-Eeepc> asics and shit
148 2012-08-21 03:28:56 in has joined
149 2012-08-21 03:30:05 wereHamster has quit (Remote host closed the connection)
150 2012-08-21 03:31:04 wereHamster has joined
151 2012-08-21 03:33:05 <Luke-Jr> MC-Eeepc: p2pool is just another pool, and more vulnerable to DDoSs
152 2012-08-21 03:33:26 brwyatt is now known as brwyatt|Away
153 2012-08-21 03:33:30 <Luke-Jr> the p2p aspect to it is in many ways a bad thing
154 2012-08-21 03:33:40 asa has joined
155 2012-08-21 03:34:33 <jgarzik> you forgot </heavy bias> tag
156 2012-08-21 03:34:45 <MC-Eeepc> trolling
157 2012-08-21 03:36:10 in has quit (Ping timeout: 260 seconds)
158 2012-08-21 03:36:59 da2ce772 has quit (Ping timeout: 265 seconds)
159 2012-08-21 03:41:09 <Luke-Jr> jgarzik: no bias there
160 2012-08-21 03:41:41 <Luke-Jr> the bias was MC-Eeepc's original comments
161 2012-08-21 03:41:48 <cjd> hey Luke, any idea what happened to cia.vc?
162 2012-08-21 03:42:07 <doublec> doesn't eligius have some form of decentralized mining?
163 2012-08-21 03:42:29 <Diablo-D3> cia.vc is down due to ip renumbering
164 2012-08-21 03:42:37 <Luke-Jr> cjd: apparently the maintainer doesn't consider it a priority; #cia suggests it might be up soon tho
165 2012-08-21 03:42:42 <Luke-Jr> doublec: yes
166 2012-08-21 03:42:47 <gmaxwell> Centeralized payout, quasi solo work generation.
167 2012-08-21 03:42:51 <Diablo-D3> or rather, its down for you
168 2012-08-21 03:42:51 <Diablo-D3> clear your dns cache
169 2012-08-21 03:42:53 <cjd> ahh cool, thanks
170 2012-08-21 03:42:56 <gmaxwell> Which is not a bad thing.
171 2012-08-21 03:43:00 <Diablo-D3> unlike luke, I actually talk to the right people
172 2012-08-21 03:43:17 <Luke-Jr> Diablo-D3: it's not up until IRC gets project commits
173 2012-08-21 03:43:17 <cjd> down for github is the problem
174 2012-08-21 03:43:22 <Diablo-D3> btw, its the same reason why predictinator was down
175 2012-08-21 03:45:12 <Diablo-D3> Luke-Jr: the bots are up though
176 2012-08-21 03:45:52 <Diablo-D3> [11:40:12] --- [CIA-1] (cia@198.71.88.9) : CIA Bot (http://cia.vc)
177 2012-08-21 03:45:52 <Diablo-D3> [11:40:12] --- [CIA-1] calvino.freenode.net :Milan, IT
178 2012-08-21 03:45:52 <Diablo-D3> [11:40:12] --- [cia-1] End of WHOIS list.
179 2012-08-21 03:46:32 <Luke-Jr> Diablo-D3: but they're completely silent
180 2012-08-21 03:48:06 skeledrew has quit (Remote host closed the connection)
181 2012-08-21 03:48:16 * Diablo-D3 shrugs
182 2012-08-21 03:48:18 <Diablo-D3> not my problem
183 2012-08-21 03:48:21 <Diablo-D3> blame the guys who invented DNS
184 2012-08-21 03:48:23 <cjd> just have to wait till github's http requestor can reach the domain they post to
185 2012-08-21 03:48:24 * jgarzik reviews his own pyminer code
186 2012-08-21 03:48:27 darkee has quit (!~darkee@gateway/tor-sasl/darkee|Ping timeout: 276 seconds)
187 2012-08-21 03:48:28 <Diablo-D3> scanlime updated the dns
188 2012-08-21 03:48:32 <jgarzik> this byte-reversing in getwork is just stupid
189 2012-08-21 03:48:36 <jgarzik> one more reason to hate getwork
190 2012-08-21 03:48:38 skeledrew has joined
191 2012-08-21 03:48:46 <Diablo-D3> jgarzik: no fucking shit
192 2012-08-21 03:48:48 <Diablo-D3> it took me a fucking hour to figure out why it didnt work
193 2012-08-21 03:48:55 <Diablo-D3> NETWORK ORDER IS BIG ENDIAN, FAGGOTS
194 2012-08-21 03:48:58 * jgarzik hasn't done a deep-dive in this area of code in ~12 months
195 2012-08-21 03:48:59 <Luke-Jr> Diablo-D3: you want blaming DNS, how about the stupid .st TLD being down for a day?
196 2012-08-21 03:49:10 <Diablo-D3> Luke-Jr: lol voo.st
197 2012-08-21 03:49:15 <Luke-Jr> Diablo-D3: eligius.st too
198 2012-08-21 03:49:16 <jgarzik> Diablo-D3: all satoshi needed to do was return the first 80 bytes, serialized. sigh.
199 2012-08-21 03:49:17 <Diablo-D3> faggot was bitching on HN about that
200 2012-08-21 03:49:29 <Diablo-D3> this is why you dont use fancy two letter domains
201 2012-08-21 03:49:31 <jgarzik> we already have a fixed byte order thanks to serialization
202 2012-08-21 03:49:36 <Diablo-D3> they might have a regime change like bit.ly ;)
203 2012-08-21 03:49:52 <Diablo-D3> jgarzik: BUT THAT'D BE TOO MUCH FU.....
204 2012-08-21 03:49:53 <Diablo-D3> er
205 2012-08-21 03:49:54 <Diablo-D3> dude
206 2012-08-21 03:49:58 <Diablo-D3> satoshi didnt write getwork
207 2012-08-21 03:50:03 <Luke-Jr> he didn't?
208 2012-08-21 03:50:06 <Diablo-D3> no
209 2012-08-21 03:50:14 <Diablo-D3> that was created for poclbm
210 2012-08-21 03:50:26 <jgarzik> Bzzt. Yes, he did. Satoshi took poclbm's getwork patch and rewrote it.
211 2012-08-21 03:50:29 <jgarzik> compare the two
212 2012-08-21 03:50:34 <Luke-Jr> Diablo-D3: 776d0f34595fd616129d4816a337662ff39de7c6 Author: s_nakamoto <s_nakamoto@1a98c847-1fd6-4fd8-948a-caf3550aa51b>
213 2012-08-21 03:50:34 <Diablo-D3> satoshi didnt merge it though
214 2012-08-21 03:50:43 <Diablo-D3> erm
215 2012-08-21 03:50:48 <Diablo-D3> then theres something rather funny
216 2012-08-21 03:50:53 <Diablo-D3> because I remember someone saying they merged it
217 2012-08-21 03:51:01 roconnor has quit (Ping timeout: 252 seconds)
218 2012-08-21 03:51:05 <Diablo-D3> and satoshi has never been on irc
219 2012-08-21 03:51:41 <Diablo-D3> and yes, I know what was merged was not the patch written for poclbm
220 2012-08-21 03:51:42 <copumpkin> not under that name, anyway!
221 2012-08-21 03:51:48 <Diablo-D3> I had to change DM's code to compensate
222 2012-08-21 03:52:05 <Diablo-D3> copumpkin: yeah, but its someone whos still here
223 2012-08-21 03:52:09 <Diablo-D3> I just cant remember who
224 2012-08-21 03:52:22 <Luke-Jr> Diablo-D3: so are you going to implement midstate so DM works with jgarzik's pynode? :P
225 2012-08-21 03:52:33 <Diablo-D3> Luke-Jr: sure, when someone sends me the patch
226 2012-08-21 03:52:38 <jgarzik> Diablo-D3: ignore Luke-Jr
227 2012-08-21 03:52:53 <Diablo-D3> jgarzik: but its so fun to troll his fake religion
228 2012-08-21 03:52:58 <jgarzik> ;)
229 2012-08-21 03:53:04 <Luke-Jr> jgarzik: why? you want DM to not be compatible? O.o
230 2012-08-21 03:53:39 * cjd remembers why he left.. too much lols == no work ever getting done
231 2012-08-21 03:53:43 <jgarzik> <jgarzik> incompatible with existing mining software, but that will be fixed shortly
232 2012-08-21 03:53:49 <jgarzik> re-read second half of compound sentence
233 2012-08-21 03:53:59 <Luke-Jr> OH, you meant you were adding hash1/midstate?
234 2012-08-21 03:54:13 <Luke-Jr> I took it to mean you were going to email all miner maintainers <.<
235 2012-08-21 03:54:36 <Diablo-D3> seriously, I will merge a patch that ignores midstate
236 2012-08-21 03:54:42 <Diablo-D3> its like 10 lines
237 2012-08-21 03:55:11 <Luke-Jr> jgarzik: are you going to implement SHA256 in Python, or use the midstate C module?
238 2012-08-21 03:55:11 <jgarzik> I need to update cpuminer. the base pkg still requires midstate and hash1 :/
239 2012-08-21 03:55:34 <jgarzik> poclbm already implemented sha256 in python
240 2012-08-21 03:55:38 <Luke-Jr> jgarzik: I think pooler calls his fork "cpuminer" 2.x.y
241 2012-08-21 03:55:39 da2ce7_d is now known as da2ce7
242 2012-08-21 03:55:43 <Luke-Jr> jgarzik: fwiw
243 2012-08-21 03:56:16 cjd has left ()
244 2012-08-21 03:57:13 * jgarzik wonders if p2pool works with testnet.
245 2012-08-21 03:57:26 <jgarzik> that would permit testing of getblocktemplate + pynode
246 2012-08-21 03:57:49 <Luke-Jr> it works with litecoin at least
247 2012-08-21 03:58:39 MC-Eeepc has quit (Ping timeout: 245 seconds)
248 2012-08-21 03:59:03 da2ce772 has joined
249 2012-08-21 04:01:27 Maged has quit (Ping timeout: 276 seconds)
250 2012-08-21 04:03:35 da2ce772 has quit (Ping timeout: 268 seconds)
251 2012-08-21 04:05:46 Gladamas has joined
252 2012-08-21 04:07:29 Gladamas_ has quit (Ping timeout: 244 seconds)
253 2012-08-21 04:10:01 imsaguy2 has quit (Read error: Connection reset by peer)
254 2012-08-21 04:10:58 imsaguy2 has joined
255 2012-08-21 04:12:04 <forrestv> jgarzik, p2pool works with bitcoin testnet
256 2012-08-21 04:12:08 <forrestv> run p2pool with the --testnet flag
257 2012-08-21 04:12:20 rdponticelli has quit (Ping timeout: 260 seconds)
258 2012-08-21 04:12:48 <jgarzik> forrestv: sweet, thanks. any plans for updating it to work with the new 'getblocktemplate' RPC?
259 2012-08-21 04:13:10 <forrestv> you mean BIP 0022?
260 2012-08-21 04:13:21 <forrestv> the version of p2pool in git already has support
261 2012-08-21 04:14:10 olp has quit (Ping timeout: 244 seconds)
262 2012-08-21 04:14:58 <jgarzik> forrestv: yep, BIP 22. Just double-checking, because BIP 22 changed in recent weeks.
263 2012-08-21 04:15:24 Gladamas has quit (Read error: Connection reset by peer)
264 2012-08-21 04:17:32 olp has joined
265 2012-08-21 04:18:12 wizkid057 has quit (Read error: Connection reset by peer)
266 2012-08-21 04:18:28 wizkid057 has joined
267 2012-08-21 04:18:49 <jgarzik> I think I am going to add getblocktemplate and "getworkhdr". "getworkhdr" is simply target + data[80]
268 2012-08-21 04:18:58 <jgarzik> i.e. what getwork should have been
269 2012-08-21 04:21:36 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
270 2012-08-21 04:23:12 dvide has quit ()
271 2012-08-21 04:27:24 <jgarzik> forrestv: what do you think about getblocktemplate's dual mode of (a) submitting work or (b) getting work?
272 2012-08-21 04:27:54 <jgarzik> forrestv: seems like it would be nice to have a separate submitwork RPC, and getblocktemplate only does the mode=template stuff
273 2012-08-21 04:28:07 <midnightmagic> hey luke, have you used next-test-201208xx to rebuild the blk* databases?
274 2012-08-21 04:28:11 <amiller> hah. so i think it works out that it's safe to bet on two blockchains at once, even if you havent finished validating either of them
275 2012-08-21 04:28:12 <jgarzik> simplifies the implementation
276 2012-08-21 04:28:13 <midnightmagic> er.. Luke-Jr ^^
277 2012-08-21 04:28:48 <amiller> the reason why is that if you spend equal time validating both, eventually you'll eventually find it, and when you do, at most half of your work went on an invalid chain
278 2012-08-21 04:29:20 <Luke-Jr> jgarzik: BIP22 originally had separate RPC calls, but some bitcoind dev (I forget who) insisted on combining them
279 2012-08-21 04:29:25 <midnightmagic> jgarzik: p2pool works with testnet3 if you change the magic string in the p2pool p2p objects, as how testnet3 changed its magic string.
280 2012-08-21 04:29:35 <Luke-Jr> midnightmagic: ?
281 2012-08-21 04:31:02 <Luke-Jr> jgarzik: also, it's a bit ambiguous which RPC call proposals would fall under; something to consider if you want to push to split it up again
282 2012-08-21 04:31:32 <midnightmagic> Luke-Jr: I'm reconstructing blk* and next-test-20120813 can't get past 192468 (so, 192469, a block stuffed with satoshidice, refuses to load into a fresh blk* set)
283 2012-08-21 04:31:52 <Luke-Jr> midnightmagic: debug.log?
284 2012-08-21 04:32:00 in has joined
285 2012-08-21 04:32:16 <jgarzik> Luke-Jr: there should be a separate "putwork <serialized data>" call, and that functionality removed from getblocktemplate
286 2012-08-21 04:32:51 <gmaxwell> er... hey..
287 2012-08-21 04:32:51 <jgarzik> (and yes, I'm happy to implement this in bitcoind)
288 2012-08-21 04:33:23 <Luke-Jr> jgarzik: it was called submitblock; and that doesn't clarify where proposals go :p
289 2012-08-21 04:33:39 <jgarzik> getblocktemplate and getwork code looks like this: if (switch) { do one thing } else { do something wholly and totally different }
290 2012-08-21 04:33:40 <gmaxwell> okay 192468 isn't where anyone else appears to have been stuck.
291 2012-08-21 04:34:21 <jgarzik> 08/21/12 04:19:51 receive version message: version 60001, blocks=194128, us=99.4
292 2012-08-21 04:34:21 <jgarzik> 3.178.25:38612, them=24.61.172.8:8333, peer=24.61.172.8:8333
293 2012-08-21 04:34:47 <jgarzik> gmaxwell: I noticed the above just now when reconnecting w/ git HEAD... remote stuck at #194128 perhaps?
294 2012-08-21 04:35:10 <midnightmagic> Luke-Jr, gmaxwell: here http://pastebin.com/vRt5A7XT
295 2012-08-21 04:35:11 <gmaxwell> jgarzik: stuck or just still downloading...
296 2012-08-21 04:35:15 <jgarzik> Luke-Jr: submitblock or submitwork is fine with me
297 2012-08-21 04:35:28 <jgarzik> gmaxwell: doesn't seem to be requesting from me, at least (not that that means much)
298 2012-08-21 04:35:40 <midnightmagic> gmaxwell: note, this is luke's next-test-20120813 branch with all the extra features in it.
299 2012-08-21 04:35:49 <gmaxwell> jgarzik: it won't until a new block happens on the network.
300 2012-08-21 04:35:54 <midnightmagic> Luke-Jr: note that the remote end is the prior next-test-201207xx
301 2012-08-21 04:36:13 <gmaxwell> jgarzik: a node won't pull from you unless you're the first it connects to, or if its not currently pulling, you feed it a new block first.
302 2012-08-21 04:36:30 <gmaxwell> (and it could be pulling from someone else right now, no way to tell if its height is advancing)
303 2012-08-21 04:36:49 <Luke-Jr> 08/21/12 03:33:03 ERROR: CheckBlock() : hashMerkleRoot mismatch
304 2012-08-21 04:36:51 <Luke-Jr> hmm
305 2012-08-21 04:37:32 <Luke-Jr> jgarzik: for reference, last revision to include submitblock: https://en.bitcoin.it/w/index.php?title=BIP_0022&oldid=26379
306 2012-08-21 04:38:25 <midnightmagic> Luke-Jr: Probably because one of the prior tx were rejected, but it looks like the first entry was rolled over and doesn't exist.
307 2012-08-21 04:40:05 <midnightmagic> urrrrg how infuriating. four nodes now "WARNING: Displayed transactions may not be correct!"
308 2012-08-21 04:42:06 minimoose has quit (Quit: minimoose)
309 2012-08-21 04:42:26 <Luke-Jr> jgarzik: ⦠you were here when gmaxwell asked for submitblock to be folded into getmemorypool, and even supported him for it -.-
310 2012-08-21 04:42:49 <jgarzik> well it's a mess for implementation
311 2012-08-21 04:42:56 <Luke-Jr> [Tuesday, May 08, 2012] [8:42:58 PM] <jgarzik> we need a special github label for "luke-jr's opinion requires outside confirmation" <-- when I said submitblock should be separate
312 2012-08-21 04:43:01 <jgarzik> separate, simple RPC calls are better
313 2012-08-21 04:43:41 dust-afk is now known as dust-otc
314 2012-08-21 04:43:48 <Luke-Jr> well, you and gmaxwell can battle that out. I don't care enough to get back into another shedpainting argument
315 2012-08-21 04:43:49 Motest031 has joined
316 2012-08-21 04:44:09 <Luke-Jr> let me know the conclusion >_<
317 2012-08-21 04:44:19 Motest003 has quit (Ping timeout: 240 seconds)
318 2012-08-21 04:44:19 <midnightmagic> is that cross-eyed?
319 2012-08-21 04:44:37 <Luke-Jr> midnightmagic: no
320 2012-08-21 04:44:59 <midnightmagic> A woman's midsection?
321 2012-08-21 04:45:35 <Luke-Jr> I'm not certain if squinting is the right word.
322 2012-08-21 04:45:43 <jgarzik> Luke-Jr: I think that was way back when getmemorypool was more bloated than getblocktemplate is now
323 2012-08-21 04:46:46 <jgarzik> even if I am arguing with an earlier jgarzik, I am right right now ;)
324 2012-08-21 04:48:04 <Luke-Jr> no, that was actually when it was quite tiny and supported only a fraction of what it does now :p
325 2012-08-21 04:48:22 <Luke-Jr> but I really don't care which way it goes, so..
326 2012-08-21 04:49:15 <gmaxwell> Luke-Jr: yea, sorryâ In general I am against rpcbloatâ we should avoid having four ways to do 99% the same thing, but kitchen sink calls are bad too. I'm generally happy to bend to the opinion of anyone who's actually thought about a particular case and has an opinion.
327 2012-08-21 04:50:12 <gmaxwell> Fortunately none of us are in politicsâ which is the only field where being willing to reconsider your past positions is concerned a flaw.
328 2012-08-21 04:50:26 * copumpkin wears flip flops
329 2012-08-21 04:50:49 <Luke-Jr> ok, so consensus has come around to split it up again then?
330 2012-08-21 04:51:06 <jgarzik> sadly I cannot neuter 'getwork' in the same way, due to compat
331 2012-08-21 04:51:31 <Luke-Jr> so, where does that leave proposals?
332 2012-08-21 04:51:33 <gmaxwell> Luke-Jr: I don't recall the prior discussion well enough to have a position now.
333 2012-08-21 04:51:37 <midnightmagic> Luke-Jr: -maxreceivebuffer had to be increased, it was disconnecting due to flood control, I'm past that part now.
334 2012-08-21 04:51:41 <Luke-Jr> gmaxwell: May 8
335 2012-08-21 04:51:49 <jgarzik> Luke-Jr: pull request coming RSN
336 2012-08-21 04:52:03 <doublec> you should see the merge mining patches in the alt coins. rpc calls that do different things depending on 4 or 5 different arguments.
337 2012-08-21 04:52:05 <gmaxwell> midnightmagic: er!!
338 2012-08-21 04:52:33 <jgarzik> Luke-Jr: modify BIP 22 to (a) add submitwork RPC, (b) remove getblocktemplate mode=submit and data stuff. getblocktemplate _only_ get's data, never put's.
339 2012-08-21 04:52:35 <midnightmagic> gmaxwell: hrm?
340 2012-08-21 04:52:37 <gmaxwell> doublec: weird. even in my own local hacks I add more rpcs because having code that changes behavior based on arguments with this json stuff is a pita.
341 2012-08-21 04:52:55 <Luke-Jr> jgarzik: so proposals stick with getblocktemplate?
342 2012-08-21 04:52:57 <gmaxwell> Luke-Jr: what weird flood controll related patches are you running?
343 2012-08-21 04:53:09 <midnightmagic> gmaxwell: awesome ones!!
344 2012-08-21 04:53:19 <Luke-Jr> gmaxwell: I don't recall any of those off-hand, but all are listed on the forum post :P
345 2012-08-21 04:53:19 <jgarzik> Luke-Jr: stick with BIP 22, with the slight modifications above
346 2012-08-21 04:54:06 <jgarzik> Luke-Jr: BIP 22-compatible getblocktemplate to receive input data about building a block. new RPC call 'submitwork' to submit a new block to the network.
347 2012-08-21 04:55:39 <Luke-Jr> jgarzik: submitblock fits better, since this is paired with getblocktemplate, not getwork
348 2012-08-21 04:55:53 <copumpkin> is there some way the wallet-specific data could be kept in a separate folder from the blockchain data files in bitcoin-qt?
349 2012-08-21 04:55:57 <jgarzik> Luke-Jr: fine, submitblock it is
350 2012-08-21 04:56:00 <copumpkin> or the usual bitcoin impl
351 2012-08-21 04:56:08 <copumpkin> a lot of backup software is by-folder
352 2012-08-21 04:56:16 <copumpkin> and I don't want to back up the blockchain data
353 2012-08-21 04:56:22 <midnightmagic> copumpkin: You might be able to symlink. Older bdb used to be just fine with that.
354 2012-08-21 04:56:37 <copumpkin> I was considering just symlinking the files I cared about into another dir
355 2012-08-21 04:56:41 <copumpkin> that might be easier
356 2012-08-21 04:57:10 da2ce772 has joined
357 2012-08-21 04:58:12 nsh has quit (Ping timeout: 248 seconds)
358 2012-08-21 04:59:53 <doublec> gmaxwell: I completely agree
359 2012-08-21 05:00:12 <Luke-Jr> jgarzik: BIP22 updated
360 2012-08-21 05:00:44 * Luke-Jr hopes it won't break backward compatibility for miners already using the older BIP22 draft
361 2012-08-21 05:01:47 sacarlson has quit (Read error: Connection reset by peer)
362 2012-08-21 05:01:51 <midnightmagic> gmaxwell: is there a way to overwrite a found bad block @ height n, with proper block data from another source? (Used -checkblock=0 and it failed with "*** found bad lock at N")
363 2012-08-21 05:02:07 <gmaxwell> midnightmagic: no. It thinks it already has it.
364 2012-08-21 05:02:12 <jgarzik> Luke-Jr: what is workid? the new RPC will not take an Object parameter, just a hex string
365 2012-08-21 05:02:31 <jgarzik> Luke-Jr: also, your table for submitblock still reads 'getblocktemplate'
366 2012-08-21 05:02:34 <Luke-Jr> jgarzik: a unique identifier tying the submission to the template
367 2012-08-21 05:02:36 <gmaxwell> "*** found bad lock at N" sounds like it was unable to reorg?
368 2012-08-21 05:03:12 <Luke-Jr> the new RPC needs to take an Object for workid at least
369 2012-08-21 05:03:14 <midnightmagic> gmaxwell: It was corrupted data back in time. It was around that time that that particular node failed and had to be hard-reset..
370 2012-08-21 05:03:39 <jgarzik> Luke-Jr: bitcoind never uses workid. it can be an optional parameter #2
371 2012-08-21 05:03:39 <midnightmagic> though why it would fail and then continue onwards, afterwards, totally beyond me
372 2012-08-21 05:03:42 Joric has joined
373 2012-08-21 05:03:45 <jgarzik> Luke-Jr: Object == complicated.
374 2012-08-21 05:04:00 <Luke-Jr> jgarzik: Object == extensible
375 2012-08-21 05:04:01 tsche has quit (Ping timeout: 268 seconds)
376 2012-08-21 05:04:40 <Luke-Jr> how about an optional Object param #2, that way bitcoind can just ignore it and future extensions can still use it?
377 2012-08-21 05:04:45 <jgarzik> Luke-Jr: you're welcome to make param #2 an Object. I will add code to ignore param #2
378 2012-08-21 05:04:51 <jgarzik> Luke-Jr: <grin> just typing same thing :)
379 2012-08-21 05:06:15 ovidiusoft has joined
380 2012-08-21 05:08:31 <Luke-Jr> jgarzik: done
381 2012-08-21 05:09:35 <jgarzik> Luke-Jr: BIP 22 submitblock table still wants updating
382 2012-08-21 05:09:46 <jgarzik> Luke-Jr: "submitblock parameters"
383 2012-08-21 05:09:56 <Luke-Jr> what needs updating?
384 2012-08-21 05:10:38 <Luke-Jr> clarify it to "submitblock parameters (2nd argument)" ?
385 2012-08-21 05:10:57 <jgarzik> Luke-Jr: "mode" is implicit in the RPC name
386 2012-08-21 05:11:13 <jgarzik> Luke-Jr: that clarification would help, yes
387 2012-08-21 05:11:47 <Luke-Jr> true
388 2012-08-21 05:11:58 nsh has joined
389 2012-08-21 05:12:01 brwyatt is now known as brwyatt|Away
390 2012-08-21 05:12:02 copumpkin has quit (Ping timeout: 244 seconds)
391 2012-08-21 05:12:20 <Luke-Jr> jgarzik: how's that?
392 2012-08-21 05:12:30 nsh has quit (Changing host)
393 2012-08-21 05:12:30 nsh has joined
394 2012-08-21 05:12:35 copumpkin has joined
395 2012-08-21 05:14:02 <jgarzik> Luke-Jr: ACK
396 2012-08-21 05:17:40 <midnightmagic> gmaxwell: What was the magic recipe you were using to super-rapidly reload a blk* pair? -checklevel=0 or something?
397 2012-08-21 05:17:51 <midnightmagic> (aside from run on tmpfs)
398 2012-08-21 05:17:58 drazak_ has joined
399 2012-08-21 05:18:57 <gmaxwell> midnightmagic: huh? you use loadblock. run on tmpfs. Thats it.
400 2012-08-21 05:25:48 cande has joined
401 2012-08-21 05:26:36 egecko has quit (Ping timeout: 276 seconds)
402 2012-08-21 05:26:41 <jgarzik> Luke-Jr: just caught a potentially ugly security bug too...
403 2012-08-21 05:28:11 <midnightmagic> :-( 20s on some blocks to acceptance..
404 2012-08-21 05:28:54 <Luke-Jr> jgarzik: ?
405 2012-08-21 05:29:18 <Luke-Jr> midnightmagic: hence why they should be relaying in realtime <.<
406 2012-08-21 05:29:22 <jgarzik> Luke-Jr: need to wrap "ssData >> block" inside a try{} to caught all de-ser errors
407 2012-08-21 05:29:26 <Luke-Jr> midnightmagic: but note that's actually pretty hard to do right now :<
408 2012-08-21 05:29:46 <jgarzik> Luke-Jr: otherwise a remote numbskull might crash bitcoind with crafted hex data
409 2012-08-21 05:29:49 tonikt has joined
410 2012-08-21 05:29:53 <Luke-Jr> jgarzik: that crashes itâ?
411 2012-08-21 05:30:05 <Luke-Jr> I'd expect that to be caught by the JSON-RPC code and returned as an error :/
412 2012-08-21 05:32:27 <midnightmagic> Luke-Jr: if I could just force it to rewrite the bad blocks, I could checkpoint the db file, restore it (for structural integrity)
413 2012-08-21 05:33:07 <midnightmagic> .. and then tell it to pull again the broken pieces.
414 2012-08-21 05:37:39 in has quit (Quit: Computer has gone to sleep.)
415 2012-08-21 05:41:29 <jgarzik> Luke-Jr: getblocktemplate's lone object parameter is not needed either
416 2012-08-21 05:41:41 <jgarzik> Luke-Jr: it just became [optional-obj-param]
417 2012-08-21 05:43:48 <Luke-Jr> jgarzik: it is needed to check that "mode" isn't something besides "template" at least
418 2012-08-21 05:44:20 <gmaxwell> midnightmagic: dude. cat block files into some other (non blk named file). delete indexes. -loadblock= done.
419 2012-08-21 05:44:21 <jgarzik> Luke-Jr: bitcoind doesn't care. you are free to leave it in the spec.
420 2012-08-21 05:44:46 <jgarzik> Luke-Jr: without 'mode', which is implicit in the operation (now that submitblock is separate), the Object is empty.
421 2012-08-21 05:45:11 <jgarzik> Luke-Jr: therefore, bitcoind's getblocktemplate accepts and ignores the first param, Object
422 2012-08-21 05:45:33 <midnightmagic> gmaxwell: 31349ms to accept block :-( it's just taking a while for the larger blocks is all.. the last thousand or two blocks are really chunking
423 2012-08-21 05:45:36 <jgarzik> default operation is now quite simple: getblocktemplate
424 2012-08-21 05:45:36 <Luke-Jr> jgarzik: it should error if there's a different mode provided
425 2012-08-21 05:46:07 <jgarzik> Luke-Jr: that's overengineering -- it adds unneeded checks to bitcoind for a rarely if ever hit case
426 2012-08-21 05:46:28 <Luke-Jr> jgarzik: solo miners would likely hit it
427 2012-08-21 05:47:15 <jgarzik> Luke-Jr: the impact will be the same due to the fact that we are moving mode=submit to submitblock. there is no _additional_ impact.
428 2012-08-21 05:47:51 <Luke-Jr> jgarzik: you're forgetting mode=proposal ?
429 2012-08-21 05:48:42 <jgarzik> Luke-Jr: no such thing in bitcoind
430 2012-08-21 05:48:55 RazielZ has joined
431 2012-08-21 05:49:01 <Luke-Jr> jgarzik: yes, that's why bitcoind needs to error when it gets it
432 2012-08-21 05:49:17 <Luke-Jr> miners will be using it unless it fails
433 2012-08-21 05:50:19 <jgarzik> Luke-Jr: getblocktemplate is brand new, so that's not true
434 2012-08-21 05:50:24 OneFixt_ has joined
435 2012-08-21 05:50:38 <Luke-Jr> jgarzik: why does that make it any less true?
436 2012-08-21 05:52:18 <forrestv> * p2pool now works with testnet3
437 2012-08-21 05:52:42 <jgarzik> uh... because (a) getblocktemplate is brand new and (b) that would always error out in git HEAD, so it would be dumb and pointless to code that way :)
438 2012-08-21 05:52:53 OneFixt has quit (Ping timeout: 246 seconds)
439 2012-08-21 05:53:06 <Luke-Jr> jgarzik: getblocktemplate isn't focussed on bitcoind
440 2012-08-21 05:53:22 <Luke-Jr> probably very few people will be using it directly to bitcoind
441 2012-08-21 05:53:52 <jgarzik> Luke-Jr: all that is fine, and mode=foo checking does not impact bitcoind then
442 2012-08-21 05:54:15 <Luke-Jr> jgarzik: except that when bitcoind doesn't error, miners will interpret the new template as a failure/change
443 2012-08-21 05:54:53 <jgarzik> fine, will re-add it. it's not worth arguing over, and it's your toy.
444 2012-08-21 05:55:36 <Luke-Jr> thank you
445 2012-08-21 05:59:35 B0g4r7__ has joined
446 2012-08-21 05:59:42 OneFixt_ is now known as OneFixt
447 2012-08-21 06:01:17 asa has quit (Remote host closed the connection)
448 2012-08-21 06:03:00 B0g4r7 has quit (Ping timeout: 276 seconds)
449 2012-08-21 06:03:00 B0g4r7__ is now known as B0g4r7
450 2012-08-21 06:03:09 Gladamas has joined
451 2012-08-21 06:03:56 Joric has quit ()
452 2012-08-21 06:05:50 ThomasV has joined
453 2012-08-21 06:10:27 olp has quit (Ping timeout: 244 seconds)
454 2012-08-21 06:12:14 agricocb has joined
455 2012-08-21 06:17:47 CodesInChaos has joined
456 2012-08-21 06:32:11 Joric has joined
457 2012-08-21 06:32:11 Joric has quit (Changing host)
458 2012-08-21 06:32:11 Joric has joined
459 2012-08-21 06:32:45 <jgarzik> Luke-Jr: submitblock RPC work... https://github.com/bitcoin/bitcoin/pull/1691
460 2012-08-21 06:36:20 <Luke-Jr> jgarzik: submitblock needs to return null (no errors) or a string rejection reasonâ¦
461 2012-08-21 06:36:30 _flow_ has quit (Ping timeout: 260 seconds)
462 2012-08-21 06:37:13 <jgarzik> Luke-Jr: why?
463 2012-08-21 06:37:48 <jgarzik> Luke-Jr: it returns an error code + string rejection reason
464 2012-08-21 06:37:49 <Luke-Jr> jgarzik: so miners can properly differentiate between a JSON-RPC error and a block acceptance rejection
465 2012-08-21 06:38:00 in has joined
466 2012-08-21 06:39:00 <Luke-Jr> eg https://en.bitcoin.it/wiki/BIP_0022#Appendix:_Example_Rejection_Reasons
467 2012-08-21 06:39:06 <jgarzik> Luke-Jr: they can do that already
468 2012-08-21 06:39:23 <Luke-Jr> jgarzik: at present, it requires a non-standard HTTP header for getwork
469 2012-08-21 06:40:42 <Luke-Jr> rejections aren't (usually) errors
470 2012-08-21 06:40:47 <jgarzik> Luke-Jr: I don't mind returning a string on reject, but null is odd and strange for success
471 2012-08-21 06:40:53 <jgarzik> Luke-Jr: true makes more sense
472 2012-08-21 06:41:27 <Luke-Jr> jgarzik: 0/null for success is fairly common in standards O.o
473 2012-08-21 06:41:44 <jgarzik> Luke-Jr: bitcoind's choice is rather binary. it could return true/false.
474 2012-08-21 06:41:56 <jgarzik> Luke-Jr: obviously pool servers might return much more
475 2012-08-21 06:42:14 <Luke-Jr> jgarzik: it could, but having two formats complicates it unnecessarily
476 2012-08-21 06:42:41 <jgarzik> Luke-Jr: false. your spec already defines three formats: null, string or object.
477 2012-08-21 06:43:18 <Luke-Jr> null vs string is usually interpretable as a single format. I forgot about the merged mining stuff
478 2012-08-21 06:45:27 <Luke-Jr> still, it's nice that miners can skip a bunch of type checking for the common case right now by just doing if (!rejectionReason) { ⦠}, and one would hope bitcoind eventually supports specific rejection reasons someday
479 2012-08-21 06:48:00 <Luke-Jr> jgarzik: is it really worth adding booleans in every miner just for legacy "bitcoind can't currently determine the reason it's rejecting it"?
480 2012-08-21 06:48:30 <jgarzik> Luke-Jr: quit whining and hit reload
481 2012-08-21 06:50:40 ThomasV has quit (Quit: Quitte)
482 2012-08-21 06:53:10 * Luke-Jr wonders if ParseHex should throw errors, but that's another matter entirely
483 2012-08-21 06:53:48 <jgarzik> Luke-Jr: it returns a null vector, which throws errors elsewhere
484 2012-08-21 06:54:35 <Luke-Jr> jgarzik: unless I'm missing something, it returns whatever parsed out before the error
485 2012-08-21 06:54:38 phantomcircuit has quit (Quit: Leaving)
486 2012-08-21 06:55:07 <jgarzik> Luke-Jr: correct. which then will probably (but not guaranteed) fail deserialize because the data is truncated.
487 2012-08-21 06:56:19 olp has joined
488 2012-08-21 06:56:54 <jgarzik> Luke-Jr: OK, pulled. Start testing ;p
489 2012-08-21 06:56:58 <jgarzik> forrestv: ^^
490 2012-08-21 07:07:34 osxorgate has joined
491 2012-08-21 07:07:51 <Luke-Jr> oh hey, CIA is working again
492 2012-08-21 07:08:49 lunchtime has joined
493 2012-08-21 07:09:26 lunchtime is now known as luncht1me
494 2012-08-21 07:13:32 sirk390 has joined
495 2012-08-21 07:13:35 _W_ has quit (Read error: Operation timed out)
496 2012-08-21 07:13:35 _W_ has joined
497 2012-08-21 07:18:34 Marf has joined
498 2012-08-21 07:20:38 dbe has quit (Remote host closed the connection)
499 2012-08-21 07:20:52 fpgaminer has quit (Ping timeout: 256 seconds)
500 2012-08-21 07:28:51 fpgaminer has joined
501 2012-08-21 07:30:01 Diablo-D3 has quit (Ping timeout: 244 seconds)
502 2012-08-21 07:31:05 Nicksasa has quit (Quit: ZNC - http://znc.sourceforge.net)
503 2012-08-21 07:32:47 Nicksasa_ has joined
504 2012-08-21 07:36:31 sirk390 has quit (Quit: Leaving.)
505 2012-08-21 07:49:21 dbe has joined
506 2012-08-21 07:51:48 <amiller> roconnor, sipa, i said that my red black tree protocol i adopted was formally defined in haskell, i dont think i also mentioned that it is formally defined in haskell, and the fact that it is deterministically balance follows from haskell's type checker
507 2012-08-21 07:52:17 <amiller> http://www.cs.kent.ac.uk/people/staff/smk/redblack/rb.html
508 2012-08-21 07:53:39 <amiller> i think that if its complexity guarantee is verifiable by haskell's type checker, then it's as simple as can be
509 2012-08-21 07:53:39 davout has joined
510 2012-08-21 07:53:39 davout has quit (Changing host)
511 2012-08-21 07:53:39 davout has joined
512 2012-08-21 07:53:43 <amiller> "no moving parts"
513 2012-08-21 07:54:41 Mobius_ has joined
514 2012-08-21 07:56:45 MobiusL has quit (Ping timeout: 276 seconds)
515 2012-08-21 07:56:58 Mobius_ is now known as MobiusL
516 2012-08-21 08:00:57 OneFixt_ has joined
517 2012-08-21 08:01:18 Karmaon1 has quit (Ping timeout: 276 seconds)
518 2012-08-21 08:03:17 <amiller> you know what, i found an "efficient verified redblack tree" in coq http://www.cs.princeton.edu/~appel/papers/redblack.pdf
519 2012-08-21 08:03:53 <amiller> i think it uses a slightly different balancing rule but has the same guarantees everywhere
520 2012-08-21 08:03:55 OneFixt has quit (Ping timeout: 260 seconds)
521 2012-08-21 08:04:32 luncht1me has quit (Quit: âI-n-v-i-s-i-o-nâ 3.3 (November '11) , You know what time it is)
522 2012-08-21 08:10:16 OneFixt_ is now known as OneFixt
523 2012-08-21 08:11:18 bitfoo has quit (Ping timeout: 256 seconds)
524 2012-08-21 08:13:25 in is now known as DashhSleeps
525 2012-08-21 08:13:46 LuaKT has joined
526 2012-08-21 08:13:46 LuaKT has quit (Changing host)
527 2012-08-21 08:13:46 LuaKT has joined
528 2012-08-21 08:14:01 DashhSleeps has quit (Quit: Computer has gone to sleep.)
529 2012-08-21 08:14:27 Gabit has joined
530 2012-08-21 08:15:03 davout has quit (Remote host closed the connection)
531 2012-08-21 08:15:26 toffoo has quit ()
532 2012-08-21 08:15:42 Goilio has joined
533 2012-08-21 08:16:54 OneFixt has quit (Read error: Connection reset by peer)
534 2012-08-21 08:17:07 ByronJohnson has quit (Read error: Operation timed out)
535 2012-08-21 08:17:21 OneFixt has joined
536 2012-08-21 08:17:25 <Gabit> Hi there :) I hope that someone here has energy to answer me, as google has failed me for explanation. Question is: How SatoshiDice can operate with zero confirmations? I could understand it if the wallet was empty, but there is over 16K. What is the mechanism?
537 2012-08-21 08:18:15 dstien_ is now known as dstien
538 2012-08-21 08:22:13 <Joric> Gabit, all transactions are ordered by nature and cryptographically strong idk what to answer
539 2012-08-21 08:23:40 MobiusL has quit (Quit: Ex-Chat)
540 2012-08-21 08:24:04 davout has joined
541 2012-08-21 08:24:32 <weex> Gabit: if someone wins, the transaction that sends them the funds depends on their bet being valid
542 2012-08-21 08:24:42 <Gabit> Ok, let me explain this how I understand it (dumdum) If I have understood this right, when some send money to SD, it goes in some sort of a que (probably there is a name for it). SD server then looks that and sees a transaction and plays out the game. But how can it be certain that the money is not double spent?
543 2012-08-21 08:26:07 <edcba> it can't i guess
544 2012-08-21 08:26:20 <edcba> if it works at 0 confirmation that is
545 2012-08-21 08:26:33 MobiusL has joined
546 2012-08-21 08:27:58 <Gabit> yea. That what i thought.. but it wouldn't be much of a money generator if it didn't work as it should. People of course would exploit it.
547 2012-08-21 08:27:59 <Joric> satoshidice includes part of the bet in a return payout if it was double spent the whole return transaction considered invalid
548 2012-08-21 08:28:12 Mobius_ has joined
549 2012-08-21 08:28:20 MobiusL has quit (Remote host closed the connection)
550 2012-08-21 08:28:42 <Gabit> ok that i understand. but how? What part of transaction is used?
551 2012-08-21 08:28:44 Mobius_ is now known as MobiusL
552 2012-08-21 08:28:52 <Gabit> id?
553 2012-08-21 08:29:01 <Gabit> sum is not valid, that i know
554 2012-08-21 08:29:29 <Joric> part of the bet amount
555 2012-08-21 08:29:35 denisx has joined
556 2012-08-21 08:29:45 <Gabit> is all sums in different id?
557 2012-08-21 08:30:05 <Gabit> how they can say this bet sum is this and not other in the waller
558 2012-08-21 08:30:14 <Gabit> *wallet
559 2012-08-21 08:30:33 <Joric> if your money were spent miners won't confirm the return because it includes spent money
560 2012-08-21 08:31:17 <weex> Gabit: https://en.bitcoin.it/wiki/Transaction
561 2012-08-21 08:31:55 da2ce772 has quit (Ping timeout: 260 seconds)
562 2012-08-21 08:32:00 <Gabit> there it goes again. Me dumdum. reading that link gets back to you :)
563 2012-08-21 08:33:03 <weex> i haven't touched that page but it might be worth some streamlining
564 2012-08-21 08:34:52 <Joric> satoshidice builds transaction the way it includes your own money, if they already went somewhere else this transaction will be dropped.
565 2012-08-21 08:36:31 denisx has quit (Remote host closed the connection)
566 2012-08-21 08:36:53 denisx has joined
567 2012-08-21 08:36:58 <weex> sd uses the output of your be transaction as one of the inputs to your (with luck) payout transaction
568 2012-08-21 08:37:06 <weex> s/be/bet/
569 2012-08-21 08:38:08 <Gabit> ok. how is it done? via txid (not probably=?
570 2012-08-21 08:38:51 <Gabit> what determines how you calculate the output?
571 2012-08-21 08:40:51 root2 has joined
572 2012-08-21 08:41:04 <Gabit> Transaction A is coming in, I see it. How I actually calculate the output from that so I can send payout? As I have understood it it contains return address (where the gambler is sending the money from).
573 2012-08-21 08:41:30 <Gabit> but that return address is still valid even if he double spends it
574 2012-08-21 08:43:13 <Gabit> I'll be back shortly.. I try to figure out that transaction wiki. Takes time.. :p
575 2012-08-21 08:43:14 <Joric> well yes it uses your txid as one of the inputs it's all chained
576 2012-08-21 08:50:03 da2ce7 has quit (Ping timeout: 276 seconds)
577 2012-08-21 08:51:41 bitfoo has joined
578 2012-08-21 08:53:29 <Gabit> Ok. Am I anywhere near the ballpark? All tx are chained. So you actually do not ever send value over, you just send the transaction order (-5bc from address x). So to calculate how much is in someones wallet is block id + tx1 + tx2 and so forth?
579 2012-08-21 08:53:45 <Joric> yeah yeah
580 2012-08-21 08:54:11 <Gabit> ok. now it starts to make sense :) Thank you :)
581 2012-08-21 08:59:56 tower has quit (Ping timeout: 244 seconds)
582 2012-08-21 09:00:29 <Gabit> one more. Wheres the que located? How a miner can check what tx are supposed to put in a block?
583 2012-08-21 09:00:51 da2ce7 has joined
584 2012-08-21 09:01:59 bitfoo has quit (Ping timeout: 240 seconds)
585 2012-08-21 09:02:50 dbe has quit (Remote host closed the connection)
586 2012-08-21 09:03:07 <weex> miners listen like any other node for new transactions and for new blocks
587 2012-08-21 09:05:33 tower has joined
588 2012-08-21 09:05:34 <Joric> blkindex.dat helps to speed it up (tx hash -> blockchain offset)
589 2012-08-21 09:07:29 <weex> is anyone keeping track of which companies have run bitcoin nodes? by ip?
590 2012-08-21 09:08:41 bitfoo has joined
591 2012-08-21 09:10:06 TD has joined
592 2012-08-21 09:17:32 ByronJohnson has joined
593 2012-08-21 09:22:30 paraipan has joined
594 2012-08-21 09:23:33 t7 has joined
595 2012-08-21 09:26:51 cande has quit (Ping timeout: 272 seconds)
596 2012-08-21 09:32:44 ThomasV has joined
597 2012-08-21 09:34:09 Anduck has joined
598 2012-08-21 09:41:06 tonikt has quit (Quit: Leaving)
599 2012-08-21 09:47:05 cande has joined
600 2012-08-21 09:51:33 agricocb has quit (Ping timeout: 272 seconds)
601 2012-08-21 09:52:33 cande has quit (Ping timeout: 265 seconds)
602 2012-08-21 09:55:19 <genjix> amiller: hey, do you prefer a talk or a classroom style workshop?
603 2012-08-21 09:57:51 zveda has joined
604 2012-08-21 09:58:11 <zveda> so if we do a hard fork, will that need a fork for all of the thin clients too ?
605 2012-08-21 09:58:28 <zveda> somehow I dont think it will . .
606 2012-08-21 09:58:55 <zveda> at least not electrum
607 2012-08-21 10:03:41 Zarutian has joined
608 2012-08-21 10:07:03 Goilio has quit (Ping timeout: 240 seconds)
609 2012-08-21 10:09:55 tonikt has joined
610 2012-08-21 10:12:16 tsche has joined
611 2012-08-21 10:15:21 bitfoo has quit (Ping timeout: 246 seconds)
612 2012-08-21 10:17:10 Joric has quit ()
613 2012-08-21 10:19:25 tower has quit (Ping timeout: 272 seconds)
614 2012-08-21 10:23:50 tower has joined
615 2012-08-21 10:23:59 Z0rZ0rZ0r_ has quit (Quit: Leaving)
616 2012-08-21 10:24:07 Clipse has quit (Quit: Clipse)
617 2012-08-21 10:25:02 Marcel has joined
618 2012-08-21 10:26:19 danbri has joined
619 2012-08-21 10:27:41 bitfoo has joined
620 2012-08-21 10:28:33 agricocb has joined
621 2012-08-21 10:29:44 root2 has quit ()
622 2012-08-21 10:32:51 davout has quit (Remote host closed the connection)
623 2012-08-21 10:33:30 davout has joined
624 2012-08-21 10:33:31 davout has quit (Changing host)
625 2012-08-21 10:33:31 davout has joined
626 2012-08-21 10:33:38 Clipse has joined
627 2012-08-21 10:46:43 dust-otc has quit (Remote host closed the connection)
628 2012-08-21 10:47:55 tower has quit (Disconnected by services)
629 2012-08-21 10:47:55 towerr has joined
630 2012-08-21 10:48:10 towerr is now known as tower
631 2012-08-21 10:48:56 darkee has joined
632 2012-08-21 10:50:52 PhantomSpark has quit (Ping timeout: 246 seconds)
633 2012-08-21 10:57:14 zveda has quit (Quit: Ex-Chat)
634 2012-08-21 10:57:33 Marf has quit (Read error: Operation timed out)
635 2012-08-21 11:05:56 cande has joined
636 2012-08-21 11:08:05 olp has quit (Ping timeout: 252 seconds)
637 2012-08-21 11:16:16 JudgeTheDude has joined
638 2012-08-21 11:22:04 sgstair has quit (Read error: Connection reset by peer)
639 2012-08-21 11:22:04 Gladamas has quit (Read error: Connection reset by peer)
640 2012-08-21 11:22:04 Gladamas has joined
641 2012-08-21 11:22:05 sgstair has joined
642 2012-08-21 11:23:58 danbri has quit (Remote host closed the connection)
643 2012-08-21 11:24:36 torsthaldo has quit (Remote host closed the connection)
644 2012-08-21 11:25:20 iocor has joined
645 2012-08-21 11:26:03 mmoya has quit (Ping timeout: 245 seconds)
646 2012-08-21 11:28:08 olp has joined
647 2012-08-21 11:30:17 LuaKT has quit (Ping timeout: 244 seconds)
648 2012-08-21 11:39:09 mmoya has joined
649 2012-08-21 11:39:59 rdponticelli has joined
650 2012-08-21 11:43:01 imsaguy has quit (Ping timeout: 268 seconds)
651 2012-08-21 11:46:01 pebbles has quit (Ping timeout: 245 seconds)
652 2012-08-21 11:46:11 pebbles has joined
653 2012-08-21 11:47:04 ThomasV has quit (Quit: Leaving)
654 2012-08-21 11:48:58 bitcoinbulletin has quit (Ping timeout: 245 seconds)
655 2012-08-21 11:50:15 JudgeTheDude has quit (Ping timeout: 260 seconds)
656 2012-08-21 11:58:18 bitcoinbulletin has joined
657 2012-08-21 11:58:24 danbri has joined
658 2012-08-21 12:04:29 coblee has quit (Ping timeout: 245 seconds)
659 2012-08-21 12:04:43 t7 has quit (Quit: ChatZilla 0.9.88-rdmsoft [XULRunner 1.9.0.17/2009122204])
660 2012-08-21 12:06:10 rickbauss has joined
661 2012-08-21 12:11:11 coblee has joined
662 2012-08-21 12:12:45 <sipa> amiller: wait? are you saying your red-black tree is deterministic given the set it represents, or deterministic given a sequence of update operations?
663 2012-08-21 12:13:37 Gladamas has quit (Read error: Connection reset by peer)
664 2012-08-21 12:13:43 Gladamas_ has joined
665 2012-08-21 12:16:54 <sipa> jgarzik, gmaxwell, Luke-Jr: regarding the block-preview idea: what about splitting of just signature checking in a separate thread (or even multiple), but accepting a block before the signatures are verified?
666 2012-08-21 12:17:21 rickbauss has quit (Remote host closed the connection)
667 2012-08-21 12:32:13 bd___ has quit (Ping timeout: 240 seconds)
668 2012-08-21 12:32:24 bd__ has joined
669 2012-08-21 12:32:49 olp has quit (Ping timeout: 245 seconds)
670 2012-08-21 12:34:00 rdponticelli has quit (Ping timeout: 260 seconds)
671 2012-08-21 12:34:14 cande has quit (Ping timeout: 256 seconds)
672 2012-08-21 12:38:04 rdponticelli has joined
673 2012-08-21 12:47:02 olp has joined
674 2012-08-21 12:47:21 <jgarzik> sipa: I was thinking about doing same in pynode. check block sans sigs, then multiple processes (python restriction) to check sigs.
675 2012-08-21 12:47:56 <jgarzik> sipa: have not yet thought through implications of propagating blocks _then_ checking sigs though. What is best for the overall network, if we do after-the-relay checking?
676 2012-08-21 12:48:27 <jgarzik> sipa: if -most- are doing this, what is collective behavior for block with invalid sigs?
677 2012-08-21 12:48:46 <sipa> worst case, someone tries to attack the network using entirely valid blocks, but with invalid sigs (which is an expensive thing to do)
678 2012-08-21 12:49:17 <sipa> worst case, the block gets propagated through the entire network before someone (and then suddently everyone) realizes the sigs are wrong
679 2012-08-21 12:49:55 <sipa> so i guess you'll get a block that causes invalid 1-confirmation for the transactions in it, for a few seconds
680 2012-08-21 12:49:58 robocoin has joined
681 2012-08-21 12:50:05 Marf has joined
682 2012-08-21 12:51:02 <sipa> but that is combining relaying and accepting; you could relay before sig-checking, but only accept afterwards
683 2012-08-21 12:51:15 <sipa> which moves the invalid effect to SPV nodes
684 2012-08-21 12:51:19 random_cat has quit (Remote host closed the connection)
685 2012-08-21 12:51:20 guruvan has quit (Remote host closed the connection)
686 2012-08-21 12:51:20 guruvan_ has quit (Remote host closed the connection)
687 2012-08-21 12:51:20 darkee has quit (!~darkee@gateway/tor-sasl/darkee|Write error: Connection reset by peer)
688 2012-08-21 12:51:20 da2ce7 has quit (Write error: Connection reset by peer)
689 2012-08-21 12:51:20 paraipan has quit (Write error: Connection reset by peer)
690 2012-08-21 12:51:21 devrandom has quit (Write error: Broken pipe)
691 2012-08-21 12:51:55 paraipan has joined
692 2012-08-21 12:53:19 da2ce7 has joined
693 2012-08-21 12:53:21 random_cat has joined
694 2012-08-21 12:55:00 guruvan has joined
695 2012-08-21 12:58:05 devrandom has joined
696 2012-08-21 12:58:05 <jgarzik> sipa: I wish we had another message, something to let the SPV and older nodes know the block they just received might have invalid sigs, and needs a lower trust level
697 2012-08-21 12:59:36 <jgarzik> if remote_node_version > X { send "proposeblock <block>" } else { wait for sig check, before announcing to this node }
698 2012-08-21 13:01:19 <sipa> jgarzik: indeed; gmaxwell suggested that before; for any check that can go wrong, the ability to create a small proof that is verifiable by anyone
699 2012-08-21 13:02:49 <sipa> ah, you mean introducing a separate message for relay-before-sig-verification?
700 2012-08-21 13:03:23 <jgarzik> sipa: that's what the latter statement suggests, yes. I admit the last two statements are somewhat separate proposals
701 2012-08-21 13:03:29 <jgarzik> (thinking off the cuff does that :))
702 2012-08-21 13:04:49 <jgarzik> I rather like that last: older nodes and SPV nodes get a relay announce after sig checks, the normal way. newer nodes get a "relayblock" message, and know that that block has not been checked for sigs.
703 2012-08-21 13:05:41 nsh has quit (Ping timeout: 248 seconds)
704 2012-08-21 13:07:02 lilalaunebaer has joined
705 2012-08-21 13:07:15 <jgarzik> On a separate note, I had also thought about simply maintaining some special nodes at the DNS seeds, that would simply not bother to check sigs before relaying.
706 2012-08-21 13:07:24 guruvan- has joined
707 2012-08-21 13:08:22 <jgarzik> The idea being have some fast relay nodes at the core, and push sig checking to the rest. Of course, that works until somebody decides to stream blocks-with-invalid-sigs through said nodes.
708 2012-08-21 13:08:43 <sipa> jgarzik: the worst case is when a miner starts working based on a block that has an invalid signature
709 2012-08-21 13:08:57 t7 has joined
710 2012-08-21 13:09:04 <jgarzik> sipa: indeed
711 2012-08-21 13:09:20 <jgarzik> sipa: or an SPV node doesn't know any better
712 2012-08-21 13:09:28 lilalaunebaer has left ()
713 2012-08-21 13:10:03 <sipa> hmm, a block can contain up to 20k sigops
714 2012-08-21 13:10:03 <jgarzik> sipa: not bad for network in general, but an SPV node without checking sigs of old txs could be in for a surprise. But I guess that's true anyway. And a very targeted attack.
715 2012-08-21 13:10:10 CodeLion has joined
716 2012-08-21 13:10:50 <jgarzik> sipa: a block could intentionally be crafted to propagate slowly, and another block intentionally crafted to propagate rapidly.
717 2012-08-21 13:11:28 * jgarzik wonders if that would further enable any double-spend attacks
718 2012-08-21 13:11:48 <CodeLion> Hey guess what? I just discovered that my n-spire calculator has bitwise functions, program editing with extensive logic and loops, and a pretty cool IO system via USB. I'm writing bitcoin functions on it for fun, what is involved in generating an address? Tried to google but failed
719 2012-08-21 13:13:51 torsthaldo has joined
720 2012-08-21 13:13:55 <sipa> CodeLion: from public key to address: SHA256, then RIPEMD160, then adding a byte, double SHA256 and using the first 4 bytes of it, concatenate some bytes, convert to a big integer, represent in base 58, and map the digits to characters
721 2012-08-21 13:13:59 cande has joined
722 2012-08-21 13:14:24 <sipa> from private key to public key: multiplication in the elliptic curve group that bitcoin uses
723 2012-08-21 13:14:39 <sipa> i wouldn't want to write any of those on a calculator :)
724 2012-08-21 13:14:54 <CodeLion> OFC not in practice but it would be fun to see what happens
725 2012-08-21 13:15:11 <CodeLion> I've got about 90% of SHA256 done, looks like it will take apr 0.5 seconds per round. :D
726 2012-08-21 13:16:07 <CodeLion> It's just for fun, not for practical purposes. If I was trying to be practical.. I don't deserve to know how to program
727 2012-08-21 13:17:03 <jgarzik> still liking multi-stage: 1) block arrives, 2) all checks sans sigs, 3) send "unchecked-inv" message to nodes >= version X, 4) check sigs, 5) send regular "inv" message, to nodes <= version X.
728 2012-08-21 13:17:34 <jgarzik> firewalls unchecked data away from SPV and older nodes, at a penalty that they see data later
729 2012-08-21 13:18:10 <jgarzik> er, regular "inv" to nodes < XD
730 2012-08-21 13:18:15 <jgarzik> nodes < X
731 2012-08-21 13:19:18 <sipa> with 20K sigchecks/block, my CPU (quad core) should be able to verify a block in 2.88s
732 2012-08-21 13:19:37 <sipa> that's the absolute maximum without a hard fork
733 2012-08-21 13:21:06 * sipa thinks we shouldn't worry
734 2012-08-21 13:21:59 <gmaxwell> it's not the sigchecks that really take the time, it's the IO; unforunately.
735 2012-08-21 13:22:20 one_zero has quit ()
736 2012-08-21 13:22:28 <gmaxwell> hopefully ultraprune mostly fixes that.
737 2012-08-21 13:24:07 copumpkin has quit (Ping timeout: 252 seconds)
738 2012-08-21 13:24:12 datagutt has joined
739 2012-08-21 13:24:45 copumpkin has joined
740 2012-08-21 13:25:01 vampireb_ has joined
741 2012-08-21 13:25:21 rdponticelli has quit (Ping timeout: 260 seconds)
742 2012-08-21 13:25:27 <jgarzik> sipa: "should" or "can"? :)
743 2012-08-21 13:25:51 <jgarzik> sipa gmaxwell: should be reasonable to do single-block checks, relay to newer nodes, then index?
744 2012-08-21 13:26:02 <jgarzik> well single-block + spent-ness
745 2012-08-21 13:26:15 <jgarzik> that avoids sig checks and disk writes
746 2012-08-21 13:27:12 <jgarzik> sipa: I bet a maximally filled block w/ 20k sigops takes far longer than 2.88s to check, if you include all the CTransaction copying in SignatureHash()
747 2012-08-21 13:27:16 <jgarzik> even in C++ that has a cost
748 2012-08-21 13:27:38 <jgarzik> pynode, for example, really hurts when you have a lot of inputs, because that's a lot of CTransaction copying
749 2012-08-21 13:27:55 <sipa> jgarzik: my result of 1735 sigchecks/s was obtained by importing with and without sigchecking enabled
750 2012-08-21 13:28:27 <sipa> so it should include all that overhead
751 2012-08-21 13:28:27 <jgarzik> sipa: OK, so that includes CTransaction copying in SignatureHash() then
752 2012-08-21 13:28:30 <jgarzik> good
753 2012-08-21 13:29:21 <sipa> gmaxwell: a benchmark last night imported blocks 184333-185333 (without sig check) in 50s, blocks 185333-186333 (with sig checks) in 319s
754 2012-08-21 13:29:44 <sipa> just with normal size cache bdb, nothing in ram or tmpfs
755 2012-08-21 13:30:13 <sipa> that is however with batch block connection of on average 15 blocks at once
756 2012-08-21 13:30:33 <sipa> so in the normal relaying situation, the overhead of bdb commits becomes 15 times larger
757 2012-08-21 13:31:01 <sipa> hmm, and the batches are smaller when sigchecks are enabled, so it's not a fair comparison
758 2012-08-21 13:32:13 rdponticelli has joined
759 2012-08-21 13:33:20 <jgarzik> of course
760 2012-08-21 13:33:37 <jgarzik> sig checking is cached, and amortized over time. if the block has known tx's, the sig checking should be quite minimal.
761 2012-08-21 13:33:50 <sipa> true
762 2012-08-21 13:34:54 <sipa> gmaxwell: anyway, i think i can say that sig checking takes the majority of the time
763 2012-08-21 13:35:08 <jgarzik> related: IIRC 0.7 has a few improvements in this measure, and a pool or two has reported faster propagation with git HEAD than current release.
764 2012-08-21 13:35:23 <jgarzik> so simply getting 0.7 out the door should help the network
765 2012-08-21 13:36:02 <sipa> when was sig caching introduced?
766 2012-08-21 13:36:06 <jgarzik> sipa: gmaxwell is right that there's a big disk hit with each block, right now. disk probably takes majority of time, for those without SSD/tmpfs partitions
767 2012-08-21 13:36:17 * jgarzik tries to remember. sig checking might be in 0.6.3.
768 2012-08-21 13:36:55 <gmaxwell> sipa: it's in 0.6.3 IIRC
769 2012-08-21 13:37:16 <jgarzik> https://bitcointalk.org/index.php?topic=89877.0
770 2012-08-21 13:37:21 <jgarzik> 0.6.3 release announce
771 2012-08-21 13:37:56 <sipa> indeed, 0.6.3
772 2012-08-21 13:38:11 <sipa> jgarzik: right now, in some setups, sure
773 2012-08-21 13:38:53 <sipa> then again, moving sig checking to a separate thread not only means the ability to parallelize it, but also doing it simultaneously with disk I/O, as that has low CPU usage anyway
774 2012-08-21 13:39:10 rickbauss has joined
775 2012-08-21 13:41:49 <gmaxwell> hm. it seems 0.6.3's highest checkpoint never made it into git master.
776 2012-08-21 13:42:02 <jgarzik> gmaxwell: yeah, it was poorly branched IMO
777 2012-08-21 13:42:22 <jgarzik> sipa: "disk I/O" == indexing, or writing block too?
778 2012-08-21 13:43:01 <jgarzik> sipa: would be nice to have network node running in parallel with sig checks _and_ disk I/O, but network node requires at least access to raw block file for the new data, implying that some large disk I/O has already occurred
779 2012-08-21 13:43:28 <jgarzik> could keep the blocks in RAM until indexed. that would make for fast relaying.
780 2012-08-21 13:43:36 <sipa> jgarzik: right, i'm assuming IBD here, which is not very appropriate
781 2012-08-21 13:43:48 <sipa> jgarzik: i meant doing sig checks of the previous block while writing/indexing the next
782 2012-08-21 13:44:14 <Cryo> mmap() all the things!
783 2012-08-21 13:44:36 <sipa> gmaxwell: good point; we can use a new checkpoint for 0.7
784 2012-08-21 13:44:39 <jgarzik> sipa: for IBD, I would definitely do all sig checking in a multi-CPU pipeline
785 2012-08-21 13:45:08 cande has quit (Ping timeout: 252 seconds)
786 2012-08-21 13:45:14 <sipa> indeed
787 2012-08-21 13:47:03 <sipa> jgarzik: my idea would be have a queue of sigcheck operations to perform, each tagged with the block they are in
788 2012-08-21 13:47:40 <sipa> have some threads that consume (blocks of) sigchecks from the queue, and keep a counter per block how many sigchecks there are left
789 2012-08-21 13:47:41 <gmaxwell> I do generally want to move in the direction of being able to discover that a block is invalid after the fact and still handle it gracefully.
790 2012-08-21 13:47:41 * jgarzik was thinking about this for pynode: one process for network, one process for database (all I/O), and N processes for sig checking
791 2012-08-21 13:47:54 <jgarzik> bitcoind version would s/process/thread/
792 2012-08-21 13:48:15 <sipa> gmaxwell: yes, working towards that; once that is done, we're actually remarkably close to initial headers-only
793 2012-08-21 13:48:25 <sipa> if you can accept a block in several stages
794 2012-08-21 13:48:34 <jgarzik> gmaxwell: def "graceful" :) I had on-disk corruption at block #130xxx the other day. That caused a 60,000-block reorg ;-)
795 2012-08-21 13:48:42 <jgarzik> sipa: yes
796 2012-08-21 13:51:17 nsh has joined
797 2012-08-21 13:51:31 nsh has quit (Changing host)
798 2012-08-21 13:51:32 nsh has joined
799 2012-08-21 13:52:16 [7] has quit (Disconnected by services)
800 2012-08-21 13:52:25 TheSeven has joined
801 2012-08-21 13:53:47 Luke-Jr has quit (Ping timeout: 260 seconds)
802 2012-08-21 13:53:52 <jgarzik> sipa gmaxwell: was there ever any consensus on RPC locking patch? Last night I was tempted to pick one and pull it, just to catalyze others into action/response :)
803 2012-08-21 13:54:03 Luke-Jr has joined
804 2012-08-21 13:57:22 <sipa> jgarzik: either are fine to me; putting locking in a table is somewhat more organized for now, but eventually we have no choice but to push down anyway
805 2012-08-21 14:00:24 <gmaxwell> Likewise, no opionion on how we do it; though I feel like generally we have inadequate rpc testing tools.
806 2012-08-21 14:01:16 <jgarzik> agreed. I was thinking that we should be able to add some unit tests that directly call the RPC functions, without worrying about setting up a full bitcoind
807 2012-08-21 14:01:40 <jgarzik> of course, that only gets a few RPCs. full RPC testing implies full bitcoind state, really.
808 2012-08-21 14:02:18 <sipa> RPC should be split up in wallet-interaction, blockchain-interaction, network-interaction, ...
809 2012-08-21 14:02:31 <CodeLion> Sipa: is there a wiki entry or some well written psuedocode or python about generating an address and detecting code sent to it?
810 2012-08-21 14:02:33 <sipa> each of those has very different requirements for testing
811 2012-08-21 14:02:37 <CodeLion> not code
812 2012-08-21 14:02:38 <CodeLion> coins
813 2012-08-21 14:02:53 <jgarzik> agreed, though things like getinfo are a mess, with many dependencies
814 2012-08-21 14:02:58 * CodeLion is starting to miss-speak from lack of the sleep
815 2012-08-21 14:03:03 <sipa> CodeLion: to detect coins sent to an address, you need a network node implementation
816 2012-08-21 14:03:11 <sipa> CodeLion: which basically means a large part of bitcoin
817 2012-08-21 14:03:15 <CodeLion> oh
818 2012-08-21 14:03:17 <jgarzik> that's why I created rpcmining last night
819 2012-08-21 14:03:30 <CodeLion> Well Is this documented?
820 2012-08-21 14:03:41 <CodeLion> Like a 'hello world' into the programming side of bitcoins?
821 2012-08-21 14:03:43 <CodeLion> :D
822 2012-08-21 14:04:28 <sipa> jgarzik: i saw it; good thing
823 2012-08-21 14:05:22 <sipa> CodeLion: there is certainly simple scripting code available to check whether an address is valid, and maybe for doing the private key -> public key -> address part
824 2012-08-21 14:05:36 <sipa> CodeLion: but for anything more, you'll typically interact through RPC with a bitcoin node
825 2012-08-21 14:05:40 <sipa> or some other interface
826 2012-08-21 14:07:04 <CodeLion> I'm working (not related to the calculator) on implementing some bitcoin functions in python for a MMO I wrote a while back.
827 2012-08-21 14:07:22 <CodeLion> I can easily write the code, I was just looking for documentation
828 2012-08-21 14:07:41 <sipa> CodeLion: on the wiki there is a list of RPC calls
829 2012-08-21 14:07:55 <sipa> and probably some examples for how to use it from other languages as well
830 2012-08-21 14:08:05 cande has joined
831 2012-08-21 14:08:06 <CodeLion> I looked, perhaps I don't know what to search for. That would be RCP as in Rich Client Platform right?
832 2012-08-21 14:08:21 <sipa> RPC is remote procedure call
833 2012-08-21 14:08:22 minimoose has joined
834 2012-08-21 14:08:41 <jgarzik> OK, I'm going to whip up a quick pull req, creating rpcwallet.cpp. That only leaves a few RPCs remaining in bitcoinrpc.cpp, related to the block chain (getblock, getblockcount, getblockhash, etc.)
835 2012-08-21 14:08:46 spitteler has joined
836 2012-08-21 14:08:49 <jgarzik> then I will redo table-driven RPC locking patch
837 2012-08-21 14:08:51 <sipa> jgarzik: please do
838 2012-08-21 14:09:09 <CodeLion> oh thank you sipa
839 2012-08-21 14:09:38 <CodeLion> Thanks JGarzik. I'm also going to re-search the wiki for "rcp"
840 2012-08-21 14:09:53 <sipa> CodeLion: RPC, not RCP
841 2012-08-21 14:09:54 <jgarzik> CodeLion: RPC, not rcp
842 2012-08-21 14:10:00 <CodeLion> ooh
843 2012-08-21 14:10:04 <jgarzik> Remote Procedure Call
844 2012-08-21 14:10:06 * CodeLion read that wrong, thanks
845 2012-08-21 14:10:17 <CodeLion> https://en.bitcoin.it/wiki/API_reference_(JSON-RPC) ?
846 2012-08-21 14:10:24 <sipa> CodeLion: that's it
847 2012-08-21 14:10:29 <CodeLion> cool
848 2012-08-21 14:10:37 <CodeLion> JSON is easy to use... *whew*
849 2012-08-21 14:10:59 Zarutian has quit (Quit: Zarutian)
850 2012-08-21 14:11:16 * CodeLion parties because there are python examples on the page. w00t
851 2012-08-21 14:11:18 <CodeLion> :D
852 2012-08-21 14:11:36 <sipa> jgarzik: while you're at it, maybe we can rename bitcoinrpc.cpp to rpccore.cpp or something too
853 2012-08-21 14:12:33 <BlueMatt> (and split out ~1/2 of it to rpc*.cpp)
854 2012-08-21 14:13:15 copumpkin has quit (Quit: Computer has gone to sleep.)
855 2012-08-21 14:13:25 <jgarzik> sipa: I like bitcoinrpc.cpp for RPC client/server generic code, and rpc*.cpp for individual RPC implementations
856 2012-08-21 14:14:08 <jgarzik> I don't mind a rename, but it seems sufficient to move all implementations out of bitcoinrpc.cpp
857 2012-08-21 14:14:15 <BlueMatt> (oh, and can we use *.h for definitions of specific rpc commands instead of putting the method signature in bitcoinrpc.cpp, that just seems busted
858 2012-08-21 14:14:20 <sipa> oh, that'd even be better
859 2012-08-21 14:15:11 asa has joined
860 2012-08-21 14:17:51 rdponticelli has quit (Ping timeout: 260 seconds)
861 2012-08-21 14:18:23 <CodeLion> Hmm last question before I stop pestering you all with my noobyness: Does anyone know of a good general cryptography channel?
862 2012-08-21 14:18:34 <CodeLion> Clarify: channel about cryptography
863 2012-08-21 14:19:44 Diapolo has joined
864 2012-08-21 14:20:22 rdponticelli has joined
865 2012-08-21 14:20:37 Turingi has joined
866 2012-08-21 14:20:37 Turingi has quit (Changing host)
867 2012-08-21 14:20:37 Turingi has joined
868 2012-08-21 14:21:36 <jgarzik> BlueMatt: yes
869 2012-08-21 14:22:14 <sipa> btw, if you move code and change it at the same time, please do it in separate commits
870 2012-08-21 14:22:33 <sipa> (easier for rebasing other patches)
871 2012-08-21 14:23:20 asa has quit (Remote host closed the connection)
872 2012-08-21 14:23:28 minimoose has quit (Read error: Connection reset by peer)
873 2012-08-21 14:24:08 asa has joined
874 2012-08-21 14:24:47 ThomasV has joined
875 2012-08-21 14:28:34 <sipa> my node can't find other testnet nodes
876 2012-08-21 14:28:45 <sipa> a bug in the irc code, or is the irc channel empry?
877 2012-08-21 14:34:59 rickbauss has quit (Quit: Leaving.)
878 2012-08-21 14:35:23 Joric has joined
879 2012-08-21 14:37:29 Zarutian has joined
880 2012-08-21 14:37:42 <sipa> CodeLion: ##crypto ?
881 2012-08-21 14:37:49 <sipa> (note the double dash)
882 2012-08-21 14:37:54 <sipa> s/dash/hash/
883 2012-08-21 14:38:13 Marf has quit (Ping timeout: 240 seconds)
884 2012-08-21 14:38:50 roconnor has joined
885 2012-08-21 14:40:51 <CodeLion> Sipa: again, thank you. I've really got to find a better way of finding things... disorder makes it tough though
886 2012-08-21 14:43:02 <jgarzik> sipa: yes, of course changes go in separate commits from code movement...
887 2012-08-21 14:43:19 <jgarzik> it is a cardinal sin to "hide" changes inside big code movement patches
888 2012-08-21 14:44:08 Muis has joined
889 2012-08-21 14:44:18 <gmaxwell> So what the heck should we do about "-noconnect" ... I could go change all the mapArgs usage to check the size, but that seems ugly.
890 2012-08-21 14:45:24 <gmaxwell> sipa: have any ideas on resolving [] ? We have that issue on other array taking RPCs too.
891 2012-08-21 14:49:11 slush has quit (Read error: Connection reset by peer)
892 2012-08-21 14:50:21 copumpkin has joined
893 2012-08-21 14:50:22 slush has joined
894 2012-08-21 14:51:03 <Diapolo> gmaxwell: what about a whitelist for allowed -noXYZ?
895 2012-08-21 14:51:36 <sipa> gmaxwell: the real solution is having a dispatch table for all command-line options, so we can also raise an error if an unknown option is used :)
896 2012-08-21 14:53:06 phantomcircuit has joined
897 2012-08-21 14:55:06 <sipa> gmaxwell: and a formal grammar for the documentation of the arguments :)
898 2012-08-21 14:56:16 phantomcircuit has quit (Client Quit)
899 2012-08-21 14:56:21 slush has quit (Ping timeout: 260 seconds)
900 2012-08-21 14:57:23 MC-Eeepc has joined
901 2012-08-21 14:58:47 slush has joined
902 2012-08-21 14:59:54 <sipa> forum down?
903 2012-08-21 15:00:12 <kinlo> seems so
904 2012-08-21 15:00:18 <sipa> MagicalTux: poke
905 2012-08-21 15:00:21 <kinlo> seems to be an index
906 2012-08-21 15:00:23 <kinlo> question is
907 2012-08-21 15:00:26 <kinlo> why myisam
908 2012-08-21 15:00:29 <kinlo> why mysql :)
909 2012-08-21 15:00:31 <BlueMatt> "Table 'smf_sessions' is marked as crashed and should be repaired"
910 2012-08-21 15:00:35 <Diapolo> same here Incorrect key file for table './bitcoin/smf_sessions.MYI'; try to repair it
911 2012-08-21 15:00:59 <kinlo> nobody else but MagicalTux that can repair it?
912 2012-08-21 15:01:08 <MagicalTux> it's checking mysql
913 2012-08-21 15:01:16 <kinlo> ha :)
914 2012-08-21 15:01:34 <BlueMatt> kinlo: we have a very low bus factor around here
915 2012-08-21 15:01:56 <MagicalTux> the vm seem to have froze
916 2012-08-21 15:02:52 <kinlo> BlueMatt: I don't get it :)
917 2012-08-21 15:03:11 <BlueMatt> http://en.wikipedia.org/wiki/Bus_factor
918 2012-08-21 15:03:18 <kinlo> that I already found and read
919 2012-08-21 15:04:10 <BlueMatt> we have several services that are managed/run by one individual
920 2012-08-21 15:04:17 <BlueMatt> s/one/one or two/
921 2012-08-21 15:04:23 <BlueMatt> the forum being one of them
922 2012-08-21 15:04:30 Diapolo has left ()
923 2012-08-21 15:04:55 <MagicalTux> BlueMatt: actually I do not manage nor run the forums
924 2012-08-21 15:05:03 <MagicalTux> but just happen to be the first on the scene this time again
925 2012-08-21 15:05:04 <kinlo> oh, bus factor is the amount of people to be hit, so low is bad
926 2012-08-21 15:05:26 <BlueMatt> MagicalTux: last I checked only one/two people had access to the actual machine?
927 2012-08-21 15:05:35 <BlueMatt> kinlo: yep
928 2012-08-21 15:05:36 <sipa> MagicalTux: who else but you has access to the hardware (or VM) it is running on?
929 2012-08-21 15:05:49 <MagicalTux> sipa: nobody, but there are apis to restart the vm externally
930 2012-08-21 15:05:59 <sipa> ok
931 2012-08-21 15:08:03 Marf has joined
932 2012-08-21 15:08:33 <sipa> BlueMatt: that's something that came to mind, some years ago when i was on a conference; there was a workshop about a particular very small subdomain (the CHR language), and we went to have lunch with +- all people of the workshop; i realized that if that building would burn down or something, CHR wouldn't exist anymore :)
933 2012-08-21 15:10:12 <sipa> bus factor 15 or so :)
934 2012-08-21 15:10:53 <kinlo> sipa: something unavoidable for every conference :)
935 2012-08-21 15:11:22 <jgarzik> RPC code movement - https://github.com/bitcoin/bitcoin/pull/1693
936 2012-08-21 15:11:23 rdponticelli has quit (Ping timeout: 272 seconds)
937 2012-08-21 15:11:41 <jgarzik> quick ACKs requested. Will check back in ~20 min, after Mexican food is consumed for breakfast.
938 2012-08-21 15:11:45 MC-Eeepc has quit (Quit: Leaving)
939 2012-08-21 15:20:37 coiax has quit (Changing host)
940 2012-08-21 15:20:37 coiax has joined
941 2012-08-21 15:21:48 olp has quit (Read error: Connection reset by peer)
942 2012-08-21 15:22:07 olp has joined
943 2012-08-21 15:22:54 <sipa> gmaxwell: fixing the -noconnect infinite loop
944 2012-08-21 15:25:12 gavinandresen has joined
945 2012-08-21 15:30:03 <epscy> somone asked in #bitcoin if the blockchain is compressed, is it?
946 2012-08-21 15:30:11 <sipa> it is not
947 2012-08-21 15:30:28 <epscy> because it needs to accessed a lot by bitcoind?
948 2012-08-21 15:31:06 <sipa> because that's how satoshi did it; i don't think he considered blockchain size becoming too large a high priority
949 2012-08-21 15:31:35 <epscy> really?
950 2012-08-21 15:31:37 CodeLion has quit (Read error: Connection reset by peer)
951 2012-08-21 15:31:44 <epscy> seems like compression would be an easy win then
952 2012-08-21 15:31:59 <epscy> though it would put more load on the cpu when you read it back i guess
953 2012-08-21 15:32:39 <Eliel> epscy: there's things in works that will improve both performance as well as necessary datasize.
954 2012-08-21 15:32:46 <sipa> i'm working on changing the block validation logic to not use a block/tx index as database, but a set of unspent coins maintained separately
955 2012-08-21 15:32:53 <sipa> and its coin database is somewhat compressed
956 2012-08-21 15:33:03 <Eliel> 80MB was it?
957 2012-08-21 15:33:08 pickett_ has joined
958 2012-08-21 15:33:19 <epscy> sounds cool
959 2012-08-21 15:33:41 <sipa> Eliel: serialized, something like that; on disk in a database is somewhat more
960 2012-08-21 15:33:53 <Eliel> ah, what's the database overhead?
961 2012-08-21 15:34:02 <sipa> a lot
962 2012-08-21 15:34:14 <sipa> my coins.dat database here is 160 MB
963 2012-08-21 15:34:27 rdponticelli has joined
964 2012-08-21 15:35:17 <Eliel> hmm, yes, indexes takes quite some space.
965 2012-08-21 15:35:37 <Eliel> although, I expect it's not just indexes that matter in the case of bdb
966 2012-08-21 15:39:10 pickett_ has quit (Quit: Leaving)
967 2012-08-21 15:49:55 Gladamas_ is now known as Gladamas
968 2012-08-21 15:50:06 <jgarzik> sipa: thanks
969 2012-08-21 15:50:51 <jgarzik> sipa: speaking of net loops, if you are able to connect to testnet3, you will see the network code trying to connect to the same hosts, over and over again, every few seconds. My gut feeling is that addrman works poorly when the total number of peers known, in all buckets, is very small.
970 2012-08-21 15:51:16 <gavinandresen> jgarzik: ACK on splitting up bitcoinrpc.cpp
971 2012-08-21 15:52:00 * jgarzik breaks everyone's RPC patches :)
972 2012-08-21 15:52:01 <sipa> jgarzik: indeed
973 2012-08-21 15:52:21 <kinlo> git should follow in file moves, not?
974 2012-08-21 15:52:28 <kinlo> it should apply just fine
975 2012-08-21 15:52:45 <jgarzik> gavinandresen: I'm going to go with the table-driven RPC lock patch. I agree with sipa that we'll do the RPC push-down eventually
976 2012-08-21 15:52:47 <sipa> kinlo: file moves: yes; splitting files: less so
977 2012-08-21 15:52:56 rdponticelli has quit (Ping timeout: 260 seconds)
978 2012-08-21 15:53:11 <gavinandresen> jgarzik: good. I agree, too, but I still think table-driven is safer and better.
979 2012-08-21 15:53:14 <kinlo> I'll know soon enough when applying my patches :)
980 2012-08-21 15:53:35 osxorgate has quit (Remote host closed the connection)
981 2012-08-21 15:53:47 <gavinandresen> jgarzik: (eventually we will have a table completely full of "routine handles locking itself", which is just fine)
982 2012-08-21 15:53:58 <jgarzik> yep
983 2012-08-21 15:54:18 darkee has joined
984 2012-08-21 15:54:41 <sipa> gavinandresen: at some point, when cs_main and cs_wallet become hidden behind safe blockchain- and wallet-interfaces, there will be no way anymore for the RPC code to access it at all; at that point, we don't need a table-approach anymore
985 2012-08-21 15:54:47 <sipa> before that, it's safer; agree
986 2012-08-21 15:55:57 <gmaxwell> sipa: do we really want to give up on connecting after 100 tries?
987 2012-08-21 15:56:08 <gavinandresen> should be 111
988 2012-08-21 15:56:18 <sipa> gmaxwell: no, but the break will just cause the outer loop to re-iterate
989 2012-08-21 15:56:19 * gavinandresen runs away before the flying fruit hits him
990 2012-08-21 15:56:32 <sipa> but the outer loop does things like releasing locks, and waiting
991 2012-08-21 15:56:43 <gmaxwell> sipa: ah. darnit. need to read diffs in context. Fine enough.
992 2012-08-21 15:57:18 <sipa> all that is basically a hack for addrman not keeping an index of "want-to-connect-to" nodes
993 2012-08-21 15:57:33 <sipa> but except in some pathological cases, it works well
994 2012-08-21 15:59:28 olp has quit (Ping timeout: 244 seconds)
995 2012-08-21 15:59:53 olp has joined
996 2012-08-21 15:59:55 <gavinandresen> jgarzik: src/bitcoinrpc.h:75: error: âint64â does not name a type
997 2012-08-21 16:00:13 <gavinandresen> (compiling 32-bit on my mac)
998 2012-08-21 16:00:29 <jgarzik> gavinandresen: hum, I wonder why I don't see that on makefile.unix. Anyway... #include util.h
999 2012-08-21 16:02:18 ahihi2 has quit (Read error: Connection reset by peer)
1000 2012-08-21 16:02:45 <sipa> where is that downloadable block file full of reorgs?
1001 2012-08-21 16:03:09 <gavinandresen> jgarzik: ACK, that fixes it. I'll push that and then a mac-specific fix (pthread_setname not supported on OSX 10.5)
1002 2012-08-21 16:04:10 <jgarzik> gavinandresen: thanks
1003 2012-08-21 16:04:45 <jgarzik> sipa: I have a copy at http://gtf.org/garzik/bitcoin/blk0001.dat.bz2
1004 2012-08-21 16:04:58 <jgarzik> sipa: full of chain forks due to accepting invalid p2sh
1005 2012-08-21 16:05:11 <sipa> ooh, interesting challenge :)
1006 2012-08-21 16:05:28 att has joined
1007 2012-08-21 16:05:35 ahihi2 has joined
1008 2012-08-21 16:05:38 <jgarzik> sipa: original source http://eu1.bitcoincharts.com/blockchain/ but that URL only keeps N recent copies
1009 2012-08-21 16:06:14 <sipa> jgarzik: but that still has reorgs, no?
1010 2012-08-21 16:06:36 <copumpkin> amiller: people seem to be talking about your stuff on reddit, if you wanna chime in
1011 2012-08-21 16:06:40 <copumpkin> amiller: http://www.reddit.com/r/Bitcoin/comments/yjm3o/bitcoin_geniuses_creating_future_to_socrates1024/
1012 2012-08-21 16:08:30 <jgarzik> sipa: (trying to be very specific:)) it has chain forks that trigger reorg, yes
1013 2012-08-21 16:08:56 <sipa> right, agree; a reorg is an action, and the file only contains data that causes reorg on import
1014 2012-08-21 16:08:56 <jgarzik> sipa: however, when parsing, it -might not- trigger a reorg if it simply sees an invalid block
1015 2012-08-21 16:09:15 <BlueMatt> sipa: I already tried the "safe blockchain- and wallet-interfaces" thing, no one was ever interested in reviewing it...
1016 2012-08-21 16:10:37 rdponticelli has joined
1017 2012-08-21 16:10:40 LuaKT has joined
1018 2012-08-21 16:10:40 LuaKT has quit (Changing host)
1019 2012-08-21 16:10:40 LuaKT has joined
1020 2012-08-21 16:10:50 <sipa> BlueMatt: sorry for that; it will be a thorough change no matter what, and doubtfully one that will get accepted easily, but that doesn't mean it isn't something we want
1021 2012-08-21 16:11:35 <jgarzik> OK, rebased RPC-lock-table, https://github.com/bitcoin/bitcoin/pull/1493
1022 2012-08-21 16:12:11 iocor has quit (Quit: Computer has gone to sleep.)
1023 2012-08-21 16:14:08 <BlueMatt> has the bitinstant credit-card come up in here yet?
1024 2012-08-21 16:14:32 JStoker has quit (Excess Flood)
1025 2012-08-21 16:14:48 <tonikt> hi guys. if you remember the frozen gui problem which I reported yesterday - it does not happen after I built the exe with gitian, but...
1026 2012-08-21 16:15:01 <sipa> but?
1027 2012-08-21 16:15:06 <tonikt> it took me the whole day to do it, because the building scripts are a bit messy
1028 2012-08-21 16:15:33 <sipa> well, you shouldn't need to do a gitian build
1029 2012-08-21 16:15:39 <tonikt> let me finish..
1030 2012-08-21 16:16:27 <tonikt> fist of all, the new windows yml file refers to boost-win32-1.49.0-gitian2.zip
1031 2012-08-21 16:16:55 <tonikt> so I had to build it - I tried with 1.47, but it didnt build so I just decided to switch my staff to 1.49
1032 2012-08-21 16:17:24 <tonikt> but it did not go smoothly because boost-win32.yml has a syntax error
1033 2012-08-21 16:17:51 <sipa> being?
1034 2012-08-21 16:18:05 <tonikt> there is echo that creates useboottime.patch to patch one file in the original boost sorces and this echo has some @@ which cause the script to crash'
1035 2012-08-21 16:18:23 <sipa> BlueMatt: ^ ?
1036 2012-08-21 16:18:31 <tonikt> so after i pathecg the file manually and removed the 2 lines - I managed to finally get the boost-win32-1.49.0-gitian2.zip
1037 2012-08-21 16:18:43 <tonikt> but then - the bitcoin build - 2 issues here
1038 2012-08-21 16:19:09 <tonikt> first: the makefile still referst (with -I and -L) to boost_1_47_0
1039 2012-08-21 16:19:22 <tonikt> second: there is a "moc command used
1040 2012-08-21 16:19:37 <tonikt> and make cannot find it since the path is not set
1041 2012-08-21 16:19:51 <tonikt> and that is basically the whole story
1042 2012-08-21 16:20:11 <BlueMatt> tonikt: all the current makefiles refer to 1_49...
1043 2012-08-21 16:20:13 <tonikt> plus, the giu still hangs after I buld the bitcion-qt.exe on my windows
1044 2012-08-21 16:20:37 <BlueMatt> tonikt: also, were you running the gitian script on windows in mingw or smth, or on linux?
1045 2012-08-21 16:20:47 <tonikt> well - i had the error of includes notfound and had to create a symbolic link form 47 to 49
1046 2012-08-21 16:20:58 <BlueMatt> then you were building an old version
1047 2012-08-21 16:21:21 <tonikt> I do git clone https://github.com/bitcoin/bitcoin.git
1048 2012-08-21 16:21:25 <tonikt> how can it be old?
1049 2012-08-21 16:21:38 <tonikt> Let me check it
1050 2012-08-21 16:21:43 <tonikt> I will get back to you
1051 2012-08-21 16:21:46 <BlueMatt> dunno, but control-f in makefile.*mingw has no 47
1052 2012-08-21 16:22:07 <sipa> tonikt: do 'git log'; which commit is at the top?
1053 2012-08-21 16:22:38 JudgeTheDude has joined
1054 2012-08-21 16:22:38 <sipa> BlueMatt: gitian-win32.yml still refers to boost 1.47
1055 2012-08-21 16:22:42 <BlueMatt> re the @@ being a syntax error, thats a bug in your shell, its within "", and Im not aware of @@ meaning...anything
1056 2012-08-21 16:22:46 <tonikt> sipa: commit 143acc7672a2b6c863af3ee8a023d640b7e9527a
1057 2012-08-21 16:23:21 dvide has joined
1058 2012-08-21 16:23:27 <BlueMatt> sipa: hmm...odd, well not sure why thats there
1059 2012-08-21 16:23:30 <tonikt> But I dont have my shell - I just use gitian
1060 2012-08-21 16:23:36 vampireb has quit (Disconnected by services)
1061 2012-08-21 16:23:43 vampireb_ is now known as vampireb
1062 2012-08-21 16:23:45 <BlueMatt> anyway...I have to go to class, later tell me anything interesting
1063 2012-08-21 16:24:10 <tonikt> Just wanted to share my feedback with you - if I can help somehow, just tell me what to do
1064 2012-08-21 16:24:56 <sipa> tonikt: where is that @@ exactly?
1065 2012-08-21 16:25:16 <tonikt> in boost-win32.yml
1066 2012-08-21 16:25:23 <tonikt> line 22
1067 2012-08-21 16:25:52 <sipa> right, but that's inside "" indeed, where it shouldn't mean anything
1068 2012-08-21 16:26:19 <tonikt> I know - but it crashes the building process. No idea why - I'm nore a windows guy
1069 2012-08-21 16:26:32 <tonikt> I can tell you the exact error it gies
1070 2012-08-21 16:26:35 <tonikt> gives
1071 2012-08-21 16:26:36 <sipa> can you copy-paste some output?
1072 2012-08-21 16:26:38 <sipa> yes, please
1073 2012-08-21 16:26:44 <tonikt> give me a minute
1074 2012-08-21 16:27:51 Marf has quit (Ping timeout: 244 seconds)
1075 2012-08-21 16:28:00 <tonikt> http://pastebin.com/hxxkcpuX
1076 2012-08-21 16:28:53 <sipa> seems indeed that gitian can't deal with it
1077 2012-08-21 16:30:19 <tonikt> I patched the file manually in the archive and removed the echo and the patch lines from yml - and then it finished without problems
1078 2012-08-21 16:30:29 <amiller> sipa, it's deterministic, in scenario 1) "given a sequence of updates", or in scenario 2) "given a root hash" - i'm saying the scenario involving "given a set" doesn't have any reason to occur
1079 2012-08-21 16:30:37 <amiller> can you tell me why "given a set" is relevant?
1080 2012-08-21 16:30:45 <amiller> i've tried to explain why 1) and 2) are relevant
1081 2012-08-21 16:31:22 <sipa> amiller: for example in the case of reorganisations, and i use undo data instead of keeping a copy of the old tree?
1082 2012-08-21 16:31:48 <tonikt> single quotes also dont work - same error
1083 2012-08-21 16:32:03 Clipse has quit (Quit: Clipse)
1084 2012-08-21 16:32:27 <jgarzik> OK, RPC locking table pulled. I'm through futzing with big RPC changes for the moment... test test test
1085 2012-08-21 16:32:31 rdponticelli_ has joined
1086 2012-08-21 16:32:35 <amiller> instead of _you_ keeping a copy of the old tree, which presumes a tamper proof disk you keep under your own personal watch at all times, _someone_ has to keep a copy of the old tree, on s3
1087 2012-08-21 16:32:36 <sipa> amiller: you can again argue that the undo data can be based on structural changes to the tree, instead of describing changes to the set
1088 2012-08-21 16:32:49 <amiller> _you_ should probably just keep a copy of the block headers
1089 2012-08-21 16:33:02 <amiller> that way you can just look up the root hash for T-rollbacklength or whatever
1090 2012-08-21 16:33:10 <jgarzik> ./test_bitcoin sure is quieter now (thanks to gavinandresen I'm betting)
1091 2012-08-21 16:33:12 <amiller> and if you want to download the whole tree then you can verify it yourself
1092 2012-08-21 16:33:18 <sipa> amiller: i think it is wrong to assume a particular mode of operation
1093 2012-08-21 16:33:19 <jgarzik> nice that it does not fill a screen or three
1094 2012-08-21 16:33:43 rdponticelli has quit (Ping timeout: 272 seconds)
1095 2012-08-21 16:33:54 <amiller> sipa, i am not assuming a particular mode of operation, but i am narrowing my focus to the plight of the lite clients, since they are the ones that are protected by the merkle roots
1096 2012-08-21 16:34:10 <sipa> amiller: well, lite clients aren't the only ones on the network, right?
1097 2012-08-21 16:35:13 <amiller> handling a reorg is never harder than simulating the behavior of a lite client
1098 2012-08-21 16:35:44 JStoker has joined
1099 2012-08-21 16:36:26 <sipa> wait, what?
1100 2012-08-21 16:36:35 <amiller> it requires O(N log M) data to store _all_ the data, for all the trees, forever
1101 2012-08-21 16:36:41 <amiller> but there is no one that needs a _trusted_ copy of that much data
1102 2012-08-21 16:36:57 <amiller> do you see why i am distinguishing between trusted data and untrusted data
1103 2012-08-21 16:37:01 <amiller> maybe i'm not being at all clear about that
1104 2012-08-21 16:37:05 <sipa> yes i see that
1105 2012-08-21 16:37:42 <amiller> so the undo information in any case is at least O(N).
1106 2012-08-21 16:37:42 <sipa> but i think it's wrong to not look at what consequences your ideas have for full nodes, which have full storage and do keep whatever necessary to reorg the entire tree quickly
1107 2012-08-21 16:38:01 <amiller> "full nodes" in that sense get bumpbed from O(N) to O(N log M) then
1108 2012-08-21 16:38:39 <amiller> but "full nodes" are not worth catering to when it comes to defining the security protocol, because the distinguishing factor of a fullnode then is that it has plenty of trusted storage to spare
1109 2012-08-21 16:40:05 <sipa> but your protocol limits how a full node can function (what i just described; keep the current utxo set in fast memory, keep undo data in slower memory) is only possible when the undo data also contains structural changes to the tree
1110 2012-08-21 16:40:33 <sipa> not saying that is necessarily a bad thing, but it's wrong to just ignore what repercussions your suggestions have for them
1111 2012-08-21 16:40:55 danbri has quit (Remote host closed the connection)
1112 2012-08-21 16:41:52 <sipa> as far as i can see, lite nodes only do queries for a limited number of addresses/txids they are interested in anyway; the load of reorg is one carried by nodes that do keep the entire UTXO set around?
1113 2012-08-21 16:43:49 <sipa> amiller: maybe i'm missing things, and you see the future mode of operation entirely different, but to me it seems you're just looking at the asymptotical behaviour of one part which is assumed to be the hardest
1114 2012-08-21 16:43:50 PhantomSpark has joined
1115 2012-08-21 16:43:55 Motest003 has joined
1116 2012-08-21 16:44:14 Motest031 has quit (Ping timeout: 240 seconds)
1117 2012-08-21 16:44:22 <amiller> i am trying to make a big distinction between trusted and untrusted data because untrusted data is easy to shard and distributed among untrusted peers
1118 2012-08-21 16:44:34 <amiller> a "reorg" is something lite clients do too
1119 2012-08-21 16:44:48 <amiller> but they have access to an untrusted set of data, like a cloud host
1120 2012-08-21 16:45:04 <sipa> yes, i see what you do (i think)
1121 2012-08-21 16:45:45 <jgarzik> ChainDb: height 195018, block 00000000000003b5eb85332c363f36db000b1727d589011274d759578c307e6d
1122 2012-08-21 16:45:45 <jgarzik> MemPool: blk.vtx.sz 32, neverseen 32, poolsz 304
1123 2012-08-21 16:46:01 <jgarzik> grump. There's that miner again... block with 100% neverseen TX's, and zero from the active TX pool.
1124 2012-08-21 16:46:03 <sipa> 32 unseen transactions in a block?
1125 2012-08-21 16:46:39 <jgarzik> "neverseen" == TX first appeared when block was received, and was never broadcast as an individual TX on the network
1126 2012-08-21 16:46:59 <jgarzik> i.e. was never in the TX memory pool first, was not sig-cached, etc.
1127 2012-08-21 16:47:11 <sipa> maybe it was, but it never reached your node, as it conflicted with a tx your peers already had in their mempool?
1128 2012-08-21 16:47:37 <jgarzik> sipa: possible for individual TX's... but 100% neverseen is highly unlikely
1129 2012-08-21 16:47:40 ahihi2 has quit (Remote host closed the connection)
1130 2012-08-21 16:47:43 <sipa> agree
1131 2012-08-21 16:49:03 <jgarzik> one presumes it's miner payouts or something. It's just disappointing that not a single mempool TX was mined, alongside those payout TX's.
1132 2012-08-21 16:49:48 Clipse has joined
1133 2012-08-21 16:50:46 <lianj> also, zero fees
1134 2012-08-21 16:53:01 <amiller> i'm presuming that it's preferable to store O(N log M) data on a shardable untrusted cloud disk (where it may amortized across many mutually untrusting peers) rather than require clients to store O(M+N) data on a tamper-proof trusted disk
1135 2012-08-21 16:53:18 <amiller> if you want to store absolutely everything yourself, then this is about an increase in storage from O(M+N) to O(N log M)
1136 2012-08-21 16:53:40 <jgarzik> yeah, long term the problem nicely solves itself. miners will want lucrative TX fees, and block reward will be far less significant.
1137 2012-08-21 16:54:12 NxTitle has joined
1138 2012-08-21 16:54:26 <sipa> amiller: i just don't think it's viable (in particular for miners) to have everything on potentially slow cloud storage
1139 2012-08-21 16:55:04 <amiller> long forks are potentially slow
1140 2012-08-21 16:55:24 <amiller> validating new transactions only requires the current utxo
1141 2012-08-21 16:55:44 <sipa> so they will want the entire utxo on fast storage
1142 2012-08-21 16:55:55 ahihi2 has joined
1143 2012-08-21 16:55:58 <amiller> or they will want fast access to it
1144 2012-08-21 16:56:02 <amiller> you can still shard it / distributed it untrusted
1145 2012-08-21 16:56:08 <sipa> sure
1146 2012-08-21 16:56:09 <amiller> but you're likely to hit the UTXO with random access queries
1147 2012-08-21 16:56:24 <amiller> even lite clients validate novel transactions by making random queries to the current utxo
1148 2012-08-21 16:57:17 <amiller> so sure, many people will probably want to keep the current utxo on local storage
1149 2012-08-21 16:57:34 <amiller> i don't assume that you have to do it that way, but practically many people will
1150 2012-08-21 16:57:57 <amiller> that's O(M) storage, not any worse than now
1151 2012-08-21 16:58:24 <Luke-Jr> CVE-2012-2459 at 79% now btw
1152 2012-08-21 16:59:01 <jgarzik> sipa: miners only need history for validating current TX's. In theory you could keep a working set of N recent blocks in local storage, and >6 months old in cloud storage.
1153 2012-08-21 16:59:01 <Luke-Jr> gavinandresen: gmaxwell thought you had something planned?
1154 2012-08-21 16:59:39 <jgarzik> sipa: I was even pondering a storage-free mode in pynode, where a miner could remote-retrieve anything not in RAM cache
1155 2012-08-21 16:59:52 <gavinandresen> Luke-Jr: huh what? something planned for what?
1156 2012-08-21 17:00:12 <jgarzik> sipa: (that implies cloud storage has an archival all-unspent-tx -> block index somewhere)
1157 2012-08-21 17:00:25 <Luke-Jr> gavinandresen: disclosure of CVE-2012-2459
1158 2012-08-21 17:01:06 Marf has joined
1159 2012-08-21 17:01:19 <gavinandresen> Luke-Jr: are we at 77% ?
1160 2012-08-21 17:01:25 <Luke-Jr> gavinandresen: 79% now
1161 2012-08-21 17:01:33 <Luke-Jr> 77% was about a week ago IIRC
1162 2012-08-21 17:02:16 <gavinandresen> good! is forrestv here?
1163 2012-08-21 17:02:18 <sipa> jgarzik: that's not possible right now
1164 2012-08-21 17:02:43 <jgarzik> sipa: with a cloud-stored txhash->blkhash index, sure it is
1165 2012-08-21 17:02:52 <sipa> jgarzik: as you can't get an certifiable answer to queries "was this transaction output already spent
1166 2012-08-21 17:03:06 <gavinandresen> forrestv: you found the CVE-2012-2459 vulnerability, want to write it up and announce it?
1167 2012-08-21 17:03:24 <sipa> jgarzik: so the cloud can lie to you
1168 2012-08-21 17:03:26 <amiller> maybe jgarzik is just already thinking in "post merkle" mode
1169 2012-08-21 17:03:38 <sipa> (i did say "right now")
1170 2012-08-21 17:03:52 <jgarzik> sipa: sure, but you quickly detect that as soon as you snarf the full block
1171 2012-08-21 17:03:58 <sipa> how so?
1172 2012-08-21 17:04:01 <jgarzik> sipa: which you do via normal means
1173 2012-08-21 17:04:08 <sipa> you don't know which block to fetch
1174 2012-08-21 17:04:55 <jgarzik> sipa: blkhash = cloud_query(txhash)
1175 2012-08-21 17:05:07 <sipa> jgarzik: that gives you the block which contains a transaction
1176 2012-08-21 17:05:17 <amiller> yeah, that's not secure at all
1177 2012-08-21 17:05:20 <sipa> it cannot give you the block which contains the potential transaction that already spent it
1178 2012-08-21 17:05:21 <jgarzik> sipa: you can prove everything else manually, by walking blocks and checking
1179 2012-08-21 17:05:47 <amiller> when you get the block data, you can check that it contains your transaction, but you can't be sure it's the correct block
1180 2012-08-21 17:05:47 <sipa> jgarzik: in particular, the cloud can never guarantee you that a particular txout was not yet spent
1181 2012-08-21 17:06:02 <jgarzik> as long asyou have block headers (w/ merkle root), life is good
1182 2012-08-21 17:06:10 davout has quit (Remote host closed the connection)
1183 2012-08-21 17:06:30 <amiller> okay sure, so you check that the blockhash you get back is one of the blocks in your header index
1184 2012-08-21 17:06:37 <amiller> and that it contains the transaction
1185 2012-08-21 17:06:49 <sipa> you can ask "give me a transaction", and the cloud can prove to you (who has the block headers) that it indeed is in the currently active chain
1186 2012-08-21 17:06:58 <jgarzik> with 'getheaders', bootstrapping into this mode is quick and entirely RAM-based
1187 2012-08-21 17:07:02 <sipa> but you cannot ask whether its outputs were already spent
1188 2012-08-21 17:07:43 <sipa> if you keep the UTXO set locally, and just walk the chain until the current point, sure
1189 2012-08-21 17:07:54 <amiller> you do if you have your own utxo, yeah i think that's what he means
1190 2012-08-21 17:07:55 <sipa> but for that you don't even need the ability to fetch arbitrary transactions
1191 2012-08-21 17:08:20 iocor has joined
1192 2012-08-21 17:08:31 <jgarzik> amiller: yep
1193 2012-08-21 17:09:20 <sipa> ok, but that is a) not storage-free and b) doesn't require a txid->block index
1194 2012-08-21 17:09:32 <sipa> but it's certainly possible
1195 2012-08-21 17:10:05 <jgarzik> it can be storage-free, and the txid->block index was remote, not non-existent
1196 2012-08-21 17:10:42 <sipa> a) you need to store the UTXO set locally, so it's not storage-free and b) there is no need for even a remote txid->block index
1197 2012-08-21 17:11:25 <jgarzik> if you don't mind losing the occasional old TX you don't even need to store UTXO
1198 2012-08-21 17:11:44 <sipa> you don't want to do that as a miner
1199 2012-08-21 17:13:59 <amiller> anyone who wants to relay valid transactions at least needs to hit the UTXO with arbitrary queries
1200 2012-08-21 17:14:29 <amiller> that includes lite clients
1201 2012-08-21 17:17:11 danbri has joined
1202 2012-08-21 17:17:31 bdcs has quit (Read error: Connection reset by peer)
1203 2012-08-21 17:18:17 <amiller> maybe one way of explaining how a "reorg" works is that you have an O(M) working set of UTXO data, and you have O(N log M) of slower archival data
1204 2012-08-21 17:18:42 <amiller> (neither of those need to be trusted if you use merkle trees (or merkle tries))
1205 2012-08-21 17:19:02 <amiller> a reorg is when you swap out O(M) data from the archival set into your working set
1206 2012-08-21 17:19:45 <sipa> yes, semantically
1207 2012-08-21 17:19:46 <amiller> if you want to validate two forks at once, you could have two working sets, one for each candidate fork
1208 2012-08-21 17:29:09 <amiller> it would take on the order of 10GB or something to store all the N log M data up to this point
1209 2012-08-21 17:29:35 <amiller> that's like all the information you could possibly want to store, and you could do a "reorg" instantaneously
1210 2012-08-21 17:30:16 <sipa> it's only around 1GB if you keep it all as set-undo-data
1211 2012-08-21 17:30:28 <sipa> which does not permit instantaneous reorgs, of course
1212 2012-08-21 17:31:00 <amiller> so is that a worthwhile tradeoff in order to support lite clients
1213 2012-08-21 17:31:52 <amiller> like Luke-Jr could put 10 gigabytes on his website and anyone could reorg off it without any trust needed
1214 2012-08-21 17:32:10 iocor has quit (Quit: Computer has gone to sleep.)
1215 2012-08-21 17:32:25 <amiller> it's preferable to have 10GB you don't need to store yourself, rather than 1GB you do need to store yourself
1216 2012-08-21 17:32:39 <sipa> sometimes
1217 2012-08-21 17:33:00 <Luke-Jr> some people have stupidly low transfer quotas
1218 2012-08-21 17:33:39 <amiller> it doesn't mean you can't store it yourself, just that you aren't reliant on doing so
1219 2012-08-21 17:34:27 <amiller> this is a little bit like the argument about protocol changes that make it easier for certain behaviors of miners
1220 2012-08-21 17:34:35 <amiller> merkle trees are about a better security model for light clients
1221 2012-08-21 17:35:04 <TD> this idea keeps coming up
1222 2012-08-21 17:35:07 <TD> i am still unconvinced
1223 2012-08-21 17:35:21 <TD> it's insufficient to know outputs are unspent
1224 2012-08-21 17:35:44 <TD> you must also know there are no other transactions that spend them. lightweight clients won't be listening to all transactions in future as bandwidth usage goes up
1225 2012-08-21 17:35:49 <TD> so they cannot easily know that
1226 2012-08-21 17:36:04 <TD> (they won't have the mempool)
1227 2012-08-21 17:36:20 <amiller> if light clients aren't listening to all transactions then they necessarily they are not 100% validating the chain
1228 2012-08-21 17:36:22 <sipa> TD: if a UTXO merkle hash is stored in the coinbase, light nodes can effectively query whether a txout has been spent or not
1229 2012-08-21 17:36:44 <TD> amiller: yes. because they're light.
1230 2012-08-21 17:37:01 <sipa> sure, they won't validate
1231 2012-08-21 17:37:14 <TD> so why does this scheme provide a better security model for light clients?
1232 2012-08-21 17:37:27 <amiller> i'm using a different definition of light clients, i'm saying a light client is something that fits on a smart card
1233 2012-08-21 17:37:31 <amiller> but listens to al the transactions
1234 2012-08-21 17:37:36 <amiller> the point is that it has no storage
1235 2012-08-21 17:38:09 <sipa> no trusted storage, you should say, i think
1236 2012-08-21 17:38:11 da2ce7_d has joined
1237 2012-08-21 17:38:19 Marf has quit (Ping timeout: 272 seconds)
1238 2012-08-21 17:38:23 <amiller> you could fit the whole validating client on a usb dongle
1239 2012-08-21 17:38:34 <amiller> you plug it into some untrusted computer, and it fetches data for you and churns throguh it
1240 2012-08-21 17:38:39 <sipa> no storage (i.e., relying on remote nodes for everything) is not viable efficiency-wise, imho
1241 2012-08-21 17:38:41 <TD> can we please standardize on terminology?
1242 2012-08-21 17:38:53 <TD> mostly people use "lightweight" to mean SPV, or possibly electrum style clients
1243 2012-08-21 17:39:07 <TD> runs on a smartcard but somehow processes multiple transactions per second is not a model that's been proposed before, afaik
1244 2012-08-21 17:39:09 <TD> it should have a new name
1245 2012-08-21 17:39:10 OneFixt has quit (Ping timeout: 276 seconds)
1246 2012-08-21 17:39:24 <amiller> O(1)-storage client?
1247 2012-08-21 17:39:27 justmoon has joined
1248 2012-08-21 17:39:38 <sipa> cloud node?
1249 2012-08-21 17:39:39 <TD> no, in future SPV clients will have constant storage costs too
1250 2012-08-21 17:39:49 skeledrew has quit (Ping timeout: 276 seconds)
1251 2012-08-21 17:40:00 <amiller> whatever it is, it's like the worst-possible case, so anything that it can do, anyone else can do too just possibly more efficiently
1252 2012-08-21 17:40:07 Luke-Jr has quit (Ping timeout: 260 seconds)
1253 2012-08-21 17:40:18 <amiller> SPV has constant storage but relies on trust
1254 2012-08-21 17:40:33 <amiller> zero-trust lite client?
1255 2012-08-21 17:40:34 pusle has joined
1256 2012-08-21 17:40:36 <TD> so does your system. you trust that the merkle tree is correct.
1257 2012-08-21 17:40:36 <sipa> TD: right, but if you're talking about current SPV + filtered links, they do have lower security than what amiller is proposing
1258 2012-08-21 17:40:40 Luke-Jr has joined
1259 2012-08-21 17:40:54 <sipa> TD: SPV + filtered links relies on nodes which do not filter too much
1260 2012-08-21 17:41:02 <Luke-Jr> it's impossible to know outputs are unspent periodâ¦
1261 2012-08-21 17:41:03 <sipa> and there is no way for them to prove that they are not filtering too much
1262 2012-08-21 17:41:07 da2ce7 has quit (Ping timeout: 276 seconds)
1263 2012-08-21 17:41:08 <TD> if you're going to listen to all transactions, i don't see any benefit. you may as well run a full node. you still have to keep up with the network.
1264 2012-08-21 17:41:30 <TD> "runs on a smart card but processes multiple transactions per second" is a bizarre model. where do you find a smartcard powerful enough to do that?
1265 2012-08-21 17:41:38 <gmaxwell> TD: because it's actually possible to bootstrap one of these things in a sane duration on a system which could merely keep up with the network.
1266 2012-08-21 17:41:53 <TD> you can bootstrap a full node today just by downloading a database with your client.
1267 2012-08-21 17:41:59 <TD> i mean, bootstrap immediately.
1268 2012-08-21 17:42:02 <amiller> you have to trust the database
1269 2012-08-21 17:42:03 <sipa> but that requires trusting that database!
1270 2012-08-21 17:42:07 <TD> you have to trust the code
1271 2012-08-21 17:42:26 <sipa> haha, the justmoon(TM)-argument
1272 2012-08-21 17:42:29 <TD> if you don't trust the database you downloaded why would you trust the code? the code can even have a checkpoint of the database in it
1273 2012-08-21 17:42:30 <justmoon> ^^
1274 2012-08-21 17:43:01 <sipa> there is a difference, but mostly a theoretical one
1275 2012-08-21 17:43:02 <Luke-Jr> TD: I can audit the code.
1276 2012-08-21 17:43:05 theymos has joined
1277 2012-08-21 17:43:06 <sipa> if there is a mistake in the code, you can see it
1278 2012-08-21 17:43:08 <TD> the proposals for these UXTOs are all (a) hard forking and (b) very complicated, so there has to be a really strong arguments for them
1279 2012-08-21 17:43:28 <sipa> you cannot theoretically find a bug in a specially-crafted malicious database download
1280 2012-08-21 17:43:34 <TD> Luke-Jr: if you can afford the time to audit all the code, you can afford the time to build your own database or revalidate it. do them in parallel.
1281 2012-08-21 17:43:40 <Luke-Jr> :p
1282 2012-08-21 17:43:43 <TD> in reality very few people will do it
1283 2012-08-21 17:43:50 <TD> so it's not a use case worth big protocol changes for
1284 2012-08-21 17:44:17 ahihi2 has quit (Read error: Connection reset by peer)
1285 2012-08-21 17:44:24 <Luke-Jr> an infinitely growing blockchain would be worth protocol changes to fix
1286 2012-08-21 17:44:26 iocor has joined
1287 2012-08-21 17:44:57 * TD doesn't think it's a big deal
1288 2012-08-21 17:45:00 <sipa> TD: however, if we put a merkle-root of the UTXO in the coinbase, and do a "soft-fork" to a state where miners validate that (and that is not expensive), you can have a full node bootstrap from a downloaded UTXO set, with the same security guarantees an SPV client has today
1289 2012-08-21 17:45:10 <sipa> I do think that is something worth having
1290 2012-08-21 17:45:14 <gmaxwell> TD: Because you can audit the code, and someone who compromises it takes a severe risk of their hand being caught in the cookie jar. You can't audit an opaque database.
1291 2012-08-21 17:45:14 davout has joined
1292 2012-08-21 17:45:15 davout has quit (Changing host)
1293 2012-08-21 17:45:15 davout has joined
1294 2012-08-21 17:45:25 <TD> if it gives you the same security guarantees as SPV then it's by definition not a full node
1295 2012-08-21 17:45:45 <sipa> it is a fully validating node
1296 2012-08-21 17:45:52 <gmaxwell> The bootstrap has SPV security, the continued operation has full validation security.
1297 2012-08-21 17:45:53 <TD> gmaxwell: you can audit it by comparing it to a known good copy, which lots of people will have, because they're already running nodes
1298 2012-08-21 17:45:55 <sipa> it's not the same as a current full node, no
1299 2012-08-21 17:46:11 ahihi2 has joined
1300 2012-08-21 17:46:14 <TD> gmaxwell: especially if all you want to compare is the unspent outputs
1301 2012-08-21 17:46:39 <TD> but again, i don't see this as being worth the enormous amount of time and upgrade complexity it'd involve. full nodes just aren't that big a deal to run or bootstrap.
1302 2012-08-21 17:46:58 <gmaxwell> TD: They are a big deal to run and bootstrap already and it will get worse.
1303 2012-08-21 17:47:26 <gmaxwell> The decenteralization of bitcoin depends on it being cheap enough to be widely distributed; if it's costly to run a full node then only parties which can profit from doing so will do so.
1304 2012-08-21 17:47:29 <TD> ok, append "for people who care" to the end of that. you download the software, put it on a machine that can handle the load and set it going. come back when it's done.
1305 2012-08-21 17:47:54 <TheSeven> gmaxwell: +1
1306 2012-08-21 17:48:03 <gmaxwell> TD: N years later. A node that can handle 2x the steady state rate takes N/2 years to sync a year of data.
1307 2012-08-21 17:48:03 <TD> i don't think it'll be that costly. even if you assume very high traffic levels with the optimizations being coded up right now, it's still going to be just one decent server machine
1308 2012-08-21 17:48:44 user has joined
1309 2012-08-21 17:48:51 <TheSeven> that blockchain compression proposal on the forums looked promising to me
1310 2012-08-21 17:49:06 <sipa> TheSeven: eto's?
1311 2012-08-21 17:49:09 <TD> so those people will take a database copy from somewhere trustworthy - like the place they got the code. again, i don't see this as being worth the complexity. it solves a problem that doesn't, exist outside this channel, of people who can obtain a trusted copy of the source code but not of a database.
1312 2012-08-21 17:49:14 OneFixt has joined
1313 2012-08-21 17:49:27 cande has quit (Quit: Lämnar)
1314 2012-08-21 17:49:32 <TheSeven> with a mergemined altchain that basically takes snapshots of balances
1315 2012-08-21 17:49:56 <TheSeven> so you don't have to process all the history to bootstrap a node
1316 2012-08-21 17:49:59 <gmaxwell> TD: Again, you do not have to trust the source code. You can audit it. You can write your own (or can someday when we have better specs).
1317 2012-08-21 17:50:48 <gmaxwell> TD: If you like you can look like the utxo set proposals as making auditing by the entire network impressively cheap.
1318 2012-08-21 17:50:51 <TD> "auditing" the database, by rebuilding it, is infinitely easier and cheaper than auditing source code. if you want it to go faster use a sharded node that holds the whole thing in RAM and then run it on 1000 machines requisitioned from Amazon or Google.
1319 2012-08-21 17:51:06 <TD> as you only have to do it once, it's not a problem
1320 2012-08-21 17:51:24 <TD> your own time to read and understand the code (let alone write your own) is far more expensive than the machine resources needed to rebuild the database
1321 2012-08-21 17:51:25 <justmoon> wow I was typing the same response as TD, only about 60% slower
1322 2012-08-21 17:51:28 <justmoon> :D
1323 2012-08-21 17:51:37 <roconnor> justmoon: hi
1324 2012-08-21 17:51:38 <gmaxwell> TD: utxo sets are also important for giving lite nodes secure access to the open txn set for contracts.
1325 2012-08-21 17:51:45 <justmoon> roconnor: hey man, how's it going?
1326 2012-08-21 17:51:55 <roconnor> justmoon: good
1327 2012-08-21 17:52:06 <gmaxwell> td: _today_ Twenty years from now? And if we uncapp that 1MB maximum at some point?
1328 2012-08-21 17:52:07 <justmoon> roconnor: will you be in london?
1329 2012-08-21 17:52:11 <roconnor> justmoon: nope
1330 2012-08-21 17:52:15 <justmoon> aw :(
1331 2012-08-21 17:52:17 <TD> 20 years from now it'll be even easier
1332 2012-08-21 17:52:18 <sipa> TD: and putting a hash of the database in the coinbase, and have miners validate it as part of their operation, gives everyone continuously access to an audited database
1333 2012-08-21 17:52:22 <roconnor> justmoon: what's in london?
1334 2012-08-21 17:52:27 <TD> the basic debate here, i think, is whether technology will scale faster than bitcoin
1335 2012-08-21 17:52:28 <TD> i think it will
1336 2012-08-21 17:52:36 <justmoon> roconnor: bitcoin conference!
1337 2012-08-21 17:52:39 <roconnor> ah
1338 2012-08-21 17:52:41 <TD> but then i work in an environment where hosting the entire web in RAM is commonplace
1339 2012-08-21 17:52:46 <sipa> TD: haha!
1340 2012-08-21 17:52:48 <TD> so i can see why this might be a dispute i'm on the minority side of :)
1341 2012-08-21 17:53:46 <TD> gmaxwell: you need the entire memory pool as well, and arguably you need to verify all their signatures, so you aren't really light at that point.
1342 2012-08-21 17:53:49 <gmaxwell> TD: It might, but regardless of what it is. UTXO set gets you all these things for almost free. The cost is only making a normative form for the rapid access index for accessing the utxo set, instead of every full node being able to do whatever they like for that data structure. And, of course, some one time development costs.
1343 2012-08-21 17:54:02 <TD> and the cost of maintaining the tree
1344 2012-08-21 17:54:11 <gmaxwell> TD: not having to have _any_ data stored except headers makes you pretty light.
1345 2012-08-21 17:54:24 <sipa> the cost of maintaining that tree is lower than bitcoin's current database code, for heaven's sake
1346 2012-08-21 17:54:35 <gmaxwell> TD: a full node has to maintain the tree anyways, the only question is do they do it all the same way or do nodes have their own versions.
1347 2012-08-21 17:55:08 <gmaxwell> (there is an index being maintained in BDB too, you know. Just because its hidden from you and can differe from node to node doesn't mean it isn't there)
1348 2012-08-21 17:55:11 <TD> storage is really the cheapest thing. even entry-level phones come with gigabytes of storage these days. lightness comes from low bandwidth and cpu usage
1349 2012-08-21 17:55:23 <TD> as those things have proven to scale not quite as well, at least at the consumer level
1350 2012-08-21 17:55:47 <gavinandresen> I wonder if there will be enough interesting use cases that most people will want to maintain full history anyway. Like the 'taint checking' that a fair number of people seem to want.
1351 2012-08-21 17:55:54 <gmaxwell> TD: Great, thats also the same deal. Because you only need the bandwidth and cpu usage to verify the transactions you're interested in if you're not interested in doing full validation.
1352 2012-08-21 17:56:09 <sipa> TD: i can guarantee you that downloading an UTXO set takes less bandwidth and CPU power than rebuilding it from the entire history
1353 2012-08-21 17:56:19 <sipa> :)
1354 2012-08-21 17:56:20 Nicksasa_ is now known as Nicksasa
1355 2012-08-21 17:56:21 Marf has joined
1356 2012-08-21 17:56:30 Nicksasa has quit (Changing host)
1357 2012-08-21 17:56:30 Nicksasa has joined
1358 2012-08-21 17:56:31 <justmoon> gavinandresen: I think a lot of those use cases are adequately covered by a DHT, especially with a merkle tree proposal in place that allows verification of most things
1359 2012-08-21 17:56:35 <amiller> roconnor, would you glance at this paper and tell me, based on it, if i'm justified in claiming that redblack trees are simple and have no moving parts? https://www.cs.princeton.edu/~appel/papers/redblack.pdf
1360 2012-08-21 17:56:46 <TD> you can't verify a transaction in any useful way only by knowing if a transaction was spent. you need the memory pool too, and if you aren't going to trust the remote nodes (but want to trust cpu power), you also have to verify all the signatures of pending transactions
1361 2012-08-21 17:56:52 <TD> this is going round in circles ...
1362 2012-08-21 17:57:02 <TD> sorry, if a transactions inputs were spent.
1363 2012-08-21 17:57:10 <roconnor> amiller: it's going to be hard to convince me of that statement, but I will have a look.
1364 2012-08-21 17:57:26 <gmaxwell> TD: you only have to verify the signatures on tractions potentially spending the input int question.
1365 2012-08-21 17:57:27 <roconnor> amiller: by thier nature balancing trees have moving parts
1366 2012-08-21 17:57:40 ThomasV_ has joined
1367 2012-08-21 17:57:44 <gmaxwell> TD: I'm generally confused as to where your opposition is coming from here.
1368 2012-08-21 17:57:53 <TD> you need to verify all of them otherwise there might be a double spend
1369 2012-08-21 17:57:54 <roconnor> gah
1370 2012-08-21 17:58:07 * roconnor wants someday to have a *portable* document format
1371 2012-08-21 17:58:07 <TD> the point of this setup is you don't trust your peers. you trust that 51% of the hash power is owned by rule-followers
1372 2012-08-21 17:58:37 <TD> so if you say to a peer "please give me a transaction that is relevant to me", and they do, you can verify the inputs are signed properly and connect to unspent outputs
1373 2012-08-21 17:58:37 <gmaxwell> TD: UTXO set is _strictly superior_ with the exception of some implementation freedom (mining nodes must use a normative datastructure to store the UTXO set, perhaps in addition to another; but that would be silly)
1374 2012-08-21 17:58:49 <gmaxwell> TD: No. It's far more powerful than 51% of hash power is owned by rule-followers.
1375 2012-08-21 17:58:54 <TD> but you cannot verify there are no other transactions that do the same thing, unless you have been listening to broadcasts and know about all pending transactions (and have verified them)
1376 2012-08-21 17:59:04 att has quit (Ping timeout: 255 seconds)
1377 2012-08-21 17:59:04 ThomasV has quit (Remote host closed the connection)
1378 2012-08-21 17:59:11 ThomasV_ has quit (Client Quit)
1379 2012-08-21 17:59:35 * midnightmagic shudders to think what his constantly-corrupting databases would do to a working utxo set..
1380 2012-08-21 17:59:35 ThomasV has joined
1381 2012-08-21 17:59:35 <sipa> TD: that is in the assumption that you are at all interested in 0-conf transactions
1382 2012-08-21 17:59:55 B0g4r7__ has joined
1383 2012-08-21 18:00:06 <amiller> midnightmagic, i am interested in distinguishing between "Trusted" and "Untrusted" storage
1384 2012-08-21 18:00:15 <amiller> since the UTXO only needs to be stored in untrusted storage, corruption is not a problem
1385 2012-08-21 18:00:17 <amiller> it's failfast
1386 2012-08-21 18:00:22 <gmaxwell> TD: With UTXO set plus notice of trechery you get "security so long as their exists one honest node that can communitate with you who has validated the history, and any node that can keep up can become such a watchdog"
1387 2012-08-21 18:00:54 <midnightmagic> amiller: failfast as in rapidly obvious that it has failed, or failfast as in "fast" against failing, or in some fashion self-recoverable?
1388 2012-08-21 18:01:07 <midnightmagic> amiller: are you using some kind of erasure-code-like structure?
1389 2012-08-21 18:01:20 <TD> you can get that anyway, you just need the nodes to provide the double-spent transaction, the merkle branch and both the spending transactions.
1390 2012-08-21 18:01:22 <amiller> rapidly obvious that it has failed
1391 2012-08-21 18:01:33 <midnightmagic> amiller: ah
1392 2012-08-21 18:01:37 MC-Eeepc has joined
1393 2012-08-21 18:02:08 LolcustBackup has joined
1394 2012-08-21 18:02:20 <TD> ok, so from a lightweight client perspective this new data structure lets you verify blocks assuming you trust 51% of the hash power up to the point where you start verifying, but you can't do anything with unconfirmed transactions (as today), and you still need to download full block contents and process them, which isn't exactly light
1395 2012-08-21 18:02:35 <TD> i mean, i'm not going to use this data structure in the android client, right? it's not intended for that
1396 2012-08-21 18:02:48 <gmaxwell> TD: No, because you can't become a watchdog easily, even if you can keep upâ I don't think you responded to my comment before: Even if you can validate at 2x the speed of the network, it will take you half a year to valdate a year of its history in steady state.
1397 2012-08-21 18:02:57 <gmaxwell> TD: you could if you found it useful. Otherwise you don't.
1398 2012-08-21 18:03:03 <TD> so to say "merkle trees are about a better security model for light clients" as before, doesn't seem accurate to me
1399 2012-08-21 18:03:10 <gmaxwell> It basically allows a number of degrees of security between SPV and full.
1400 2012-08-21 18:03:12 <TD> i did respond
1401 2012-08-21 18:03:13 B0g4r7 has quit (Ping timeout: 276 seconds)
1402 2012-08-21 18:03:14 Marf has quit (Ping timeout: 240 seconds)
1403 2012-08-21 18:03:14 B0g4r7__ is now known as B0g4r7
1404 2012-08-21 18:03:27 <TD> i said if for some bizarre reason you want to do that, you can throw machine power at it until you're caught up
1405 2012-08-21 18:03:32 <TD> which is cheap and getting cheaper fast
1406 2012-08-21 18:04:19 <TD> but in reality, there is probably a source of a database i can trust, at least as much as i trust the downloaded code/binaries/compiler i'm using/whatever. i only need a ton of computational power if i want to fully audit the code
1407 2012-08-21 18:04:22 <TD> which is going to be rare
1408 2012-08-21 18:04:53 <gmaxwell> TD: It's okay that its rare. When you find trechery you can communicate it, people can be thrown in jail, life goes on.
1409 2012-08-21 18:04:58 <TD> ok, so to rephrase my point, if we define "lightweight client" to mean something like the Android client today (computationally limited, it's what we've been calling a lightweight client up to now), it doesn't seem useful to me.
1410 2012-08-21 18:05:13 <sipa> TD: neither does it to me
1411 2012-08-21 18:05:32 <roconnor> amiller: delete on red-black trees is so difficult that they didn't even write the algorithm in the paper.
1412 2012-08-21 18:05:37 <sipa> it sure has interesting possibilities for such clients, but i'm unconvinced they will become the common case
1413 2012-08-21 18:05:46 <gmaxwell> TD: well you're attacking a strawman there. E.g. go look at where I originally wrote about this idea: https://bitcointalk.org/index.php?topic=21995.0
1414 2012-08-21 18:05:48 <sipa> my point is this: a merkle root of the UTXO set in coinbases would allow bootstrapping a fully-validating node with SPV-level trust in history (which is close to what we have now with signature checks before the checkpoints), without downloading and processing the entire history
1415 2012-08-21 18:05:56 <gmaxwell> "
1416 2012-08-21 18:05:57 <gmaxwell> Beyond the namecoin/funky distributed contract case/ this would also permit semi-lite clients which track only the headers and open transactions and are allowed to forget about very old open transactions because they can be reminded of them by untrusted peers but can still do full validation. This might be helpful for network health in the future"
1417 2012-08-21 18:06:14 <amiller> roconnor, that's not true - this paper is a response to many other papers who left out delete
1418 2012-08-21 18:06:22 <TD> i started talking in the channel today after i saw this comment by amiller "merkle trees are about a better security model for light clients" in the context of UXTOs
1419 2012-08-21 18:06:36 skeledrew has joined
1420 2012-08-21 18:06:37 <TD> i think we've reached consensus that this is not true
1421 2012-08-21 18:06:42 <roconnor> in Coq. I use the same kind of Ltac proof automation.
1422 2012-08-21 18:06:43 <roconnor> But the delete algorithm is bigger than for insert, and so are the proofs. Here I will just
1423 2012-08-21 18:06:45 <roconnor> show the Kahrsâs invariant for his del function, translated into Coq:
1424 2012-08-21 18:06:59 <sipa> TD: amiller assumes a future where everything is stored in the cloud, and only asymptotic behaviour matters
1425 2012-08-21 18:07:06 <TD> anyway, it's 8pm and i'm still at the office .... :) need to get home and eat.
1426 2012-08-21 18:07:06 <sipa> that doesn't mean his ideas are useless :)
1427 2012-08-21 18:07:06 <TD> bbl
1428 2012-08-21 18:07:08 <gmaxwell> It just allows more degrees instead of this hard switch. It means that _most_ server and desktop nodes could realistically be full validating, vs a very few that did special efforts to buy years of CPU time to bootstrap in a reasonable amount of time.
1429 2012-08-21 18:07:18 * gavinandresen feels like he's listening to monks arguing about angels dancing on pins.....
1430 2012-08-21 18:07:34 <amiller> "I combine min elt (ï¬nd the minimum element) and delete into a single operation delete min that does not have to do any comparisons at all"
1431 2012-08-21 18:07:49 <gmaxwell> TD: I think you're misunderstanding there. If I rephrased that to say "a better security model for not full clients" would you be happier?
1432 2012-08-21 18:07:52 <TD> ok, i didn't say there are no use cases for a UXTO, just that lightweight clients such as mobile clients doesn't seem to be one of them. so for other use cases, go right ahead and make the case ...
1433 2012-08-21 18:08:14 <NxTitle> 18:01 * gavinandresen feels like he's listening to monks arguing about angels dancing on pins.....
1434 2012-08-21 18:08:17 <gmaxwell> TD: He didn't say "the android client" â I think lightclients are the set of all clients that aren't not light e.g. aren't full.
1435 2012-08-21 18:08:20 <NxTitle> that's an interesting way of putting
1436 2012-08-21 18:08:21 <NxTitle> it
1437 2012-08-21 18:09:01 <amiller> roconnor, er, well even if the text of the code is omitted from the paper, it still counts as "no moving parts" if it is a construction by refinement, doesn't it?
1438 2012-08-21 18:09:27 <gmaxwell> TD: and I do think there are some applications for mobile clients, e.g. contracts, namecoin like usage (e.g. I can securely give you a NXDOMAIN), etc. though you're absolutely right, weren't not going to have android clients doing full validation.
1439 2012-08-21 18:13:38 TD has quit (Quit: TD)
1440 2012-08-21 18:16:22 <amiller> roconnor, this is the full code from Karhs (including delete) that is deterministic and balanced-by-construction http://www.cs.kent.ac.uk/people/staff/smk/redblack/Typed.hs
1441 2012-08-21 18:16:37 molecular has quit (Read error: Connection reset by peer)
1442 2012-08-21 18:17:10 molecular has joined
1443 2012-08-21 18:17:16 <justmoon> amiller: what's the status of your reference implementation? last time I was here it got to block 140k and it sounded like you wanted to some fundamental optimization
1444 2012-08-21 18:18:34 davout_ has joined
1445 2012-08-21 18:18:53 att has joined
1446 2012-08-21 18:18:55 <amiller> i haven't optimized it yet, i'm still trying to figure out what to focus on in order to address the biggest concerns
1447 2012-08-21 18:21:28 davout has quit (Ping timeout: 245 seconds)
1448 2012-08-21 18:21:46 <justmoon> amiller: ok, thanks for the update - just let me know when it makes sense for me to start trying to port it
1449 2012-08-21 18:26:00 dbe has joined
1450 2012-08-21 18:30:51 rdponticelli has joined
1451 2012-08-21 18:31:36 rdponticelli_ has quit (Ping timeout: 260 seconds)
1452 2012-08-21 18:42:13 Detritus has quit (Ping timeout: 276 seconds)
1453 2012-08-21 18:43:00 theymos has quit (Remote host closed the connection)
1454 2012-08-21 18:55:57 nsh has quit (Read error: Connection timed out)
1455 2012-08-21 18:56:53 nsh has joined
1456 2012-08-21 19:02:13 user has quit (Read error: Connection reset by peer)
1457 2012-08-21 19:06:49 user has joined
1458 2012-08-21 19:08:20 JudgeTheDude has quit (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
1459 2012-08-21 19:08:54 LuaKTT has joined
1460 2012-08-21 19:09:28 LuaKT has quit (Ping timeout: 250 seconds)
1461 2012-08-21 19:09:36 LuaKTT is now known as LuaKT
1462 2012-08-21 19:10:06 LuaKT is now known as Guest86867
1463 2012-08-21 19:10:43 andyrossy has quit (Quit: Lost terminal)
1464 2012-08-21 19:10:45 vigilyn has quit (Ping timeout: 252 seconds)
1465 2012-08-21 19:10:50 davout_ has quit (Remote host closed the connection)
1466 2012-08-21 19:11:36 D34TH has joined
1467 2012-08-21 19:15:11 JudgeTheDude has joined
1468 2012-08-21 19:15:46 JudgeTheDude has quit (Client Quit)
1469 2012-08-21 19:20:01 TD has joined
1470 2012-08-21 19:22:11 rdponticelli has quit (Ping timeout: 272 seconds)
1471 2012-08-21 19:22:31 asa has quit (Read error: Connection reset by peer)
1472 2012-08-21 19:23:54 osmosis has joined
1473 2012-08-21 19:28:11 davout has joined
1474 2012-08-21 19:28:11 davout has quit (Changing host)
1475 2012-08-21 19:28:11 davout has joined
1476 2012-08-21 19:29:28 <roconnor> amiller: I don't know what you mean by no-moving-parts
1477 2012-08-21 19:29:40 <roconnor> amiller: you mean no arbitrary choices?
1478 2012-08-21 19:30:08 <amiller> no ambiguous or questionable choices, i suppose
1479 2012-08-21 19:30:20 <sipa> that sounds subjective
1480 2012-08-21 19:30:21 <amiller> "arbitrary" on its own isn't necessarily a bad thing
1481 2012-08-21 19:30:41 <amiller> i agree that there are many possible balancing rules and i am picking one arbitrarily, but any of them are sufficient
1482 2012-08-21 19:31:14 <amiller> the one i picked is the most well studied and it's also verifiable that it produces a balanced tree
1483 2012-08-21 19:31:35 <amiller> "well defined"
1484 2012-08-21 19:31:59 datagutt has quit (Quit: kthxbai)
1485 2012-08-21 19:32:28 davout has quit (Remote host closed the connection)
1486 2012-08-21 19:32:35 <roconnor> amiller: so the claim is that there is only one choice of deletion implementation that satifies the red-black condition and the complexity constraint?
1487 2012-08-21 19:33:17 sirk390 has joined
1488 2012-08-21 19:33:20 <amiller> no that's not the claim, there many be many others that work just as well
1489 2012-08-21 19:33:32 <amiller> we need to pick a sufficient one
1490 2012-08-21 19:33:39 <sipa> i think he just means that the resulting tree given a sequence of inserts/deletes is deterministic, and that the rule for describing that is "somewhat easy"
1491 2012-08-21 19:33:59 <sipa> (correct me if i'm wrong)
1492 2012-08-21 19:34:08 <amiller> (that sounds right)
1493 2012-08-21 19:36:07 davout has joined
1494 2012-08-21 19:36:08 davout has quit (Changing host)
1495 2012-08-21 19:36:08 davout has joined
1496 2012-08-21 19:38:38 paul0 has joined
1497 2012-08-21 19:45:36 rdponticelli has joined
1498 2012-08-21 19:45:58 toffoo has joined
1499 2012-08-21 19:46:10 ForceMajeure has quit (Read error: Connection reset by peer)
1500 2012-08-21 19:47:29 p0s has joined
1501 2012-08-21 19:48:32 JudgeTheDude has joined
1502 2012-08-21 19:48:35 Marf has joined
1503 2012-08-21 19:51:12 D34TH has quit (Read error: Connection reset by peer)
1504 2012-08-21 19:53:04 <sipa> meh... what if someone concocts an evil txout script which contains OP_CHECKSIG OP_NOT ?
1505 2012-08-21 19:53:33 <Eliel> why would that be a problem?
1506 2012-08-21 19:53:38 jurov is now known as away!xzbnxup@84.245.71.31|jurov
1507 2012-08-21 19:53:42 <sipa> using parallel sigchecking would imply originally assuming all sigchecks succeed
1508 2012-08-21 19:54:11 <sipa> so you'd kill the spend as invalid, even if it's only invalid if it has a valid signature
1509 2012-08-21 19:54:48 <gavinandresen> parallelize higher, at the scriptSig+scriptPubKey level.
1510 2012-08-21 19:55:20 <sipa> you mean: don't do any script checking initially, instead of not doing any sig checking initally?
1511 2012-08-21 19:55:41 * Luke-Jr wonders why he's the only one who's noticed that gitian-win32 hasn't built in weeks <.<
1512 2012-08-21 19:55:47 <sipa> that's probably easier to implement as well
1513 2012-08-21 19:55:55 D34TH has joined
1514 2012-08-21 19:56:21 <c_k> .j #bitcoin-otc
1515 2012-08-21 19:56:24 <c_k> oops
1516 2012-08-21 19:57:11 <Eliel> Luke-Jr: no-one else cares? :P
1517 2012-08-21 19:57:40 <sipa> Luke-Jr: i'm sure tonikt noticed
1518 2012-08-21 19:58:29 <gavinandresen> my excuse is I was on vacation....
1519 2012-08-21 19:58:52 <tonikt> what?
1520 2012-08-21 19:59:59 <tonikt> so far i only know that i've noticed my name being mentioned :)
1521 2012-08-21 20:00:21 <sipa> tonikt: you did notice there were problems with the gitian-win32 build
1522 2012-08-21 20:01:38 <tonikt> few of - yea
1523 2012-08-21 20:01:55 <tonikt> i know how to fix them
1524 2012-08-21 20:02:54 <tonikt> at least i will know tomorrow, after i get back sober :)
1525 2012-08-21 20:03:19 tonikt has quit (Quit: Leaving)
1526 2012-08-21 20:03:35 tonikt has joined
1527 2012-08-21 20:14:10 pooler has quit (Ping timeout: 244 seconds)
1528 2012-08-21 20:15:23 davout_ has joined
1529 2012-08-21 20:15:43 drazak__ has joined
1530 2012-08-21 20:15:44 drazak__ has quit (Client Quit)
1531 2012-08-21 20:15:58 pusle has quit ()
1532 2012-08-21 20:18:11 davout_ has quit (Remote host closed the connection)
1533 2012-08-21 20:18:56 davout has quit (Ping timeout: 260 seconds)
1534 2012-08-21 20:20:15 davout has joined
1535 2012-08-21 20:20:15 davout has quit (Changing host)
1536 2012-08-21 20:20:16 davout has joined
1537 2012-08-21 20:21:44 danbri_ has joined
1538 2012-08-21 20:22:26 danbri has quit (Ping timeout: 244 seconds)
1539 2012-08-21 20:23:47 pooler has joined
1540 2012-08-21 20:23:56 Diablo-D3 has joined
1541 2012-08-21 20:31:47 Guest86867 has quit ()
1542 2012-08-21 20:32:11 Karmaon1 has joined
1543 2012-08-21 20:32:14 Guest86867 has joined
1544 2012-08-21 20:32:27 Guest86867 is now known as LuaKT
1545 2012-08-21 20:32:38 LuaKT has quit (Changing host)
1546 2012-08-21 20:32:38 LuaKT has joined
1547 2012-08-21 20:34:42 Matt_von_Mises has joined
1548 2012-08-21 20:35:57 sebicas has joined
1549 2012-08-21 20:36:09 OneFixt has quit (Read error: Connection reset by peer)
1550 2012-08-21 20:36:51 <Matt_von_Mises> I'd just like to confirm: When running the P2SH script, it resets the limits in the interpreter. For instance it allows for another 200 op codes?
1551 2012-08-21 20:37:04 OneFixt has joined
1552 2012-08-21 20:37:38 <sebicas> Hello, I am working on a new Bitcoin Project and need to listen to BlockChain Events⦠was is my best option? BitcoinJS?
1553 2012-08-21 20:38:11 rdponticelli has quit (Ping timeout: 260 seconds)
1554 2012-08-21 20:42:15 <sipa> Matt_von_Mises: they're counted separately during execution
1555 2012-08-21 20:43:00 <sipa> Matt_von_Mises: but the sigop limits combine those in the scriptsig and the scriptpubkey
1556 2012-08-21 20:43:12 phantomcircuit has joined
1557 2012-08-21 20:44:15 <Matt_von_Mises> sipa: Thanks that's what I thought.
1558 2012-08-21 20:45:29 <sipa> there is a GetLegacySigOpCount() for counting those in traditional outputs, and GetP2SHSigOpCount for counting those in P2SH outputs
1559 2012-08-21 20:55:12 <Luke-Jr> tonikt: I left some hints in bugs I opened I think :p
1560 2012-08-21 20:55:38 <Luke-Jr> (I had to fix it for the last 2 next-test, but I don't recommend using those hacks)
1561 2012-08-21 20:56:09 vigilyn has joined
1562 2012-08-21 20:56:35 <tonikt> thx
1563 2012-08-21 20:56:43 jurov is now known as jurov|away
1564 2012-08-21 20:57:42 ForceMajeure has joined
1565 2012-08-21 21:02:28 Bachfischer has joined
1566 2012-08-21 21:06:49 random_cat has quit (Remote host closed the connection)
1567 2012-08-21 21:07:19 dbe has quit (Remote host closed the connection)
1568 2012-08-21 21:08:06 random_cat has joined
1569 2012-08-21 21:09:22 dbe has joined
1570 2012-08-21 21:10:49 tonikt has quit (Read error: Connection reset by peer)
1571 2012-08-21 21:11:04 <Marf> lol thomosV
1572 2012-08-21 21:11:09 Maged has joined
1573 2012-08-21 21:11:16 <Marf> no gribblecommands in pirates channel allowed ;)
1574 2012-08-21 21:14:40 <sebicas> Hello, I am working on a new Bitcoin Project and need to listen to BlockChain Events⦠was is my best option? BitcoinJS?
1575 2012-08-21 21:17:23 p0s has quit (Remote host closed the connection)
1576 2012-08-21 21:17:31 <sipa> sebicas: what kind of blockchain events?
1577 2012-08-21 21:17:35 <helo> sebicas: i would look at pynode, if it does what you need and you are familiar with python
1578 2012-08-21 21:18:03 <sebicas> I need to know every time a block & a transaction is received
1579 2012-08-21 21:18:21 <Luke-Jr> sebicas: might look at tcatm's supybot plugin (used in #bitcoin-watch)
1580 2012-08-21 21:18:32 darksk1ez has quit (Ping timeout: 260 seconds)
1581 2012-08-21 21:18:37 <Luke-Jr> it has a very minimal implementation of stuff
1582 2012-08-21 21:18:42 <sipa> bitcoind has a -blocknotify option, which lets you execute some code for each received block
1583 2012-08-21 21:18:43 <Luke-Jr> pynode if you need to to complex stuff
1584 2012-08-21 21:19:15 <sebicas> Perfect...
1585 2012-08-21 21:19:21 <sebicas> And to send payments?
1586 2012-08-21 21:19:59 <sipa> use the bitcoind RPC interface
1587 2012-08-21 21:20:06 <sebicas> Regular bitcoin client via JSON-RCP?
1588 2012-08-21 21:20:08 <sipa> yes
1589 2012-08-21 21:20:28 [\\\] has joined
1590 2012-08-21 21:21:21 <sebicas> supybot work alone or in combination with bitcoind ?
1591 2012-08-21 21:22:25 <Luke-Jr> usually in combination, since it has no verification of its own
1592 2012-08-21 21:22:31 <sebicas> sipa: Besides blocknotify does bitcoind also have some sort of transaction notify?
1593 2012-08-21 21:22:34 danbri_ has quit (Remote host closed the connection)
1594 2012-08-21 21:22:48 [\\\] is now known as imsaguy
1595 2012-08-21 21:23:09 <sipa> sebicas: you can check the transactions in received blocks of course; there is no similar command for memory pool transactions though (0-conf)
1596 2012-08-21 21:23:47 <sebicas> Ok, thanks!
1597 2012-08-21 21:24:15 <sebicas> And what is the best best way to listen to transactions on memory pool?
1598 2012-08-21 21:24:34 <sipa> what do you need them for?
1599 2012-08-21 21:24:52 davout has quit (Remote host closed the connection)
1600 2012-08-21 21:24:56 <sebicas> Is to display some statistics in real time..
1601 2012-08-21 21:25:04 Bachfischer has quit (Quit: ZNC - http://znc.in)
1602 2012-08-21 21:25:23 <sipa> the 0.7 release will have a command to dump the contents of the memory pool
1603 2012-08-21 21:25:32 <sipa> so you can poll that from time to time
1604 2012-08-21 21:25:39 <sebicas> Via RCP-JSON?
1605 2012-08-21 21:25:48 <sebicas> Or via Events?
1606 2012-08-21 21:25:48 <sipa> yes
1607 2012-08-21 21:25:52 <sipa> JSON-RPC
1608 2012-08-21 21:26:58 <Luke-Jr> sebicas: if you use the supybot plugin code, it just connects like a peer and gets sent stuff as it arrives
1609 2012-08-21 21:27:32 <sebicas> Luke-Jr: Ok, I will check on that! Thanks a lot!
1610 2012-08-21 21:28:46 rdponticelli has joined
1611 2012-08-21 21:28:47 darksk1ez has joined
1612 2012-08-21 21:30:26 Detritus has joined
1613 2012-08-21 21:30:41 user has quit (Quit: Leaving)
1614 2012-08-21 21:34:44 tester707 has joined
1615 2012-08-21 21:44:32 davout has joined
1616 2012-08-21 21:44:32 davout has quit (Changing host)
1617 2012-08-21 21:44:32 davout has joined
1618 2012-08-21 21:45:55 ThomasV has quit (Quit: Quitte)
1619 2012-08-21 21:45:58 JudgeTheDude has quit (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
1620 2012-08-21 21:46:19 JudgeTheDude has joined
1621 2012-08-21 21:48:38 RazielZ has quit (Ping timeout: 246 seconds)
1622 2012-08-21 21:50:24 Bachfischer has joined
1623 2012-08-21 21:51:51 att has quit (Quit: Leaving)
1624 2012-08-21 21:54:01 rdponticelli has quit (Ping timeout: 260 seconds)
1625 2012-08-21 21:54:24 MobiusL has quit (Remote host closed the connection)
1626 2012-08-21 21:54:26 da2ce7_d has quit (Remote host closed the connection)
1627 2012-08-21 21:55:12 graingert has joined
1628 2012-08-21 21:56:00 MobiusL has joined
1629 2012-08-21 21:56:14 da2ce7_d has joined
1630 2012-08-21 21:59:05 user has joined
1631 2012-08-21 22:03:00 asa has joined
1632 2012-08-21 22:08:21 ovidiusoft has quit (Ping timeout: 244 seconds)
1633 2012-08-21 22:08:33 Joric has quit ()
1634 2012-08-21 22:10:10 rdponticelli has joined
1635 2012-08-21 22:10:10 <amiller> suppose i'm running a full node on my laptop and my hard drive fails completely
1636 2012-08-21 22:11:09 <amiller> however, i backup just my current root hash every night, to a smart card i keep on me
1637 2012-08-21 22:12:02 <amiller> if i replace my hard drive, what steps do i have to take to get back up to mining
1638 2012-08-21 22:12:54 <amiller> i only need to validate a short chain, no longer than a day's worth of blocks
1639 2012-08-21 22:13:22 <amiller> in order to do that, i need the UTXO from the last block i backed up
1640 2012-08-21 22:16:53 tower has quit (Ping timeout: 245 seconds)
1641 2012-08-21 22:16:55 <amiller> but i don't have to download the whole UTXO to validate that chain extension, since all I need to validate it are the deltas
1642 2012-08-21 22:17:29 <amiller> so i can start a download of the UTXO, checking that it matches my backup block
1643 2012-08-21 22:18:31 imsaguy has quit (Ping timeout: 260 seconds)
1644 2012-08-21 22:18:54 Nesetalis has quit (Read error: Connection reset by peer)
1645 2012-08-21 22:19:04 <amiller> i don't have to wait for it to finish in order to catch up to the front of the chain
1646 2012-08-21 22:19:23 <amiller> so i can start validating transactions before relaying them right away
1647 2012-08-21 22:19:41 rdponticelli has quit (Ping timeout: 260 seconds)
1648 2012-08-21 22:19:43 <amiller> and if i'm mining in a pool, i can start validating my blocks before working on them right away too
1649 2012-08-21 22:19:54 Diablo-D3 has quit (Remote host closed the connection)
1650 2012-08-21 22:20:14 <amiller> this is a realistic scenario, it's about a kind of hardware failure
1651 2012-08-21 22:21:38 Diablo-D3 has joined
1652 2012-08-21 22:21:39 Matt_von_Mises has quit (Quit: Leaving.)
1653 2012-08-21 22:21:52 <amiller> it's similar to "checkpoints" except it isn't about trusting a third party
1654 2012-08-21 22:22:40 TD has quit (Quit: TD)
1655 2012-08-21 22:22:54 <amiller> it's about making it easy to keep safe backups
1656 2012-08-21 22:23:06 tower has joined
1657 2012-08-21 22:23:37 <amiller> i store my bitcoin wallet and gpg private keys on a usb drive in a hidden place
1658 2012-08-21 22:24:40 <amiller> i can't fit a whole copy of the blockchain on there, but i keep a few block headers around, because i do not want to have to revalidate the chain again from the beginning of time, nor am i willing to trust anyone else
1659 2012-08-21 22:25:06 davout has quit (Remote host closed the connection)
1660 2012-08-21 22:26:49 <graingert> amiller: block headers are easy
1661 2012-08-21 22:27:01 <graingert> amiller: it's the transactions that need manual verification
1662 2012-08-21 22:27:12 <amiller> i've already validated them once
1663 2012-08-21 22:27:20 <amiller> i know my backup is valid, i just want to start mining again
1664 2012-08-21 22:27:22 <amiller> what do i need
1665 2012-08-21 22:27:23 <graingert> amiller: you need to validate them each time
1666 2012-08-21 22:27:33 <graingert> if you delete any
1667 2012-08-21 22:28:01 <amiller> that's time consuming isn't it
1668 2012-08-21 22:28:07 <amiller> with a UTXO-set that's unnecessary
1669 2012-08-21 22:28:39 <graingert> !google UTXO
1670 2012-08-21 22:28:40 <BCBot2> graingert: Error: "google" is not a valid command.
1671 2012-08-21 22:28:40 <gribble> ZhameLa'cu Bente'utxo | Facebook: <http://www.facebook.com/people/ZhameLacu-Benteutxo/100002337598502>; ãã¬ã³TVï¼æ§ï¼ on USTREAM: è¶
å®æ´¾ä»æå¾ã«ããã¤ã³ã¿ã¼ãããå¯ºé¢ ...: <http://www.ustream.tv/channel/higantv>; Storing UTXOs in a Balanced Merkle Tree (zero-trust nodes with O(1 ...: <https://bitcointalk.org/index.php?topic=101734.0>
1672 2012-08-21 22:28:51 <graingert> gmaxwell: +kb BCBot2
1673 2012-08-21 22:28:55 copumpkin has quit (Quit: Computer has gone to sleep.)
1674 2012-08-21 22:29:09 <graingert> amiller: yeah but nothing does that
1675 2012-08-21 22:29:50 <gmaxwell> graingert: er, that might be the logging bot. IIRC.
1676 2012-08-21 22:30:01 <graingert> hmm
1677 2012-08-21 22:30:12 <gmaxwell> I could quiet it though.
1678 2012-08-21 22:30:40 <gmaxwell> !bloop
1679 2012-08-21 22:30:41 <gribble> Error: "bloop" is not a valid command.
1680 2012-08-21 22:31:15 <graingert> gmaxwell: +q BCBot2
1681 2012-08-21 22:31:20 darksk1ez has quit (Ping timeout: 260 seconds)
1682 2012-08-21 22:31:31 <gmaxwell> graingert: I did. and it worked.
1683 2012-08-21 22:31:41 <graingert> !google UTXO
1684 2012-08-21 22:31:41 <gribble> ZhameLa'cu Bente'utxo | Facebook: <http://www.facebook.com/people/ZhameLacu-Benteutxo/100002337598502>; ãã¬ã³TVï¼æ§ï¼ on USTREAM: è¶
å®æ´¾ä»æå¾ã«ããã¤ã³ã¿ã¼ãããå¯ºé¢ ...: <http://www.ustream.tv/channel/higantv>; Storing UTXOs in a Balanced Merkle Tree (zero-trust nodes with O(1 ...: <https://bitcointalk.org/index.php?topic=101734.0>
1685 2012-08-21 22:31:43 <graingert> ah
1686 2012-08-21 22:33:54 asa has quit (Read error: Connection reset by peer)
1687 2012-08-21 22:35:01 Nesetalis has joined
1688 2012-08-21 22:36:01 Zarutian has quit (Quit: Zarutian)
1689 2012-08-21 22:36:27 rdponticelli has joined
1690 2012-08-21 22:36:32 asa has joined
1691 2012-08-21 22:37:26 <BlueMatt> sipa: why break -connect loop after 100?
1692 2012-08-21 22:37:42 <BlueMatt> what if you are connecting to a local node which goes down for maintenance?
1693 2012-08-21 22:38:59 Bachfischer has quit (Quit: ZNC - http://znc.in)
1694 2012-08-21 22:39:25 dbe has quit (Remote host closed the connection)
1695 2012-08-21 22:42:19 <sipa> BlueMatt: there is an outer loop around it, this is just breaking from the inner loop
1696 2012-08-21 22:42:29 <BlueMatt> ah, ok
1697 2012-08-21 22:42:44 <sipa> the outer loop will sleep a while, release a lock, recompute some thing, and come back to the inner loop
1698 2012-08-21 22:43:33 darksk1ez has joined
1699 2012-08-21 22:44:12 nico1ai has joined
1700 2012-08-21 22:44:46 <gmaxwell> BlueMatt: I asked the same thing.
1701 2012-08-21 22:46:04 dbe has joined
1702 2012-08-21 22:46:11 <sipa> gmaxwell: https://bitcointalk.org/index.php?topic=102349.0
1703 2012-08-21 22:47:01 Neskia has joined
1704 2012-08-21 22:47:25 <BlueMatt> in hindsight, it does seem like something no way sipa would break
1705 2012-08-21 22:48:06 CodesInChaos has quit (Ping timeout: 248 seconds)
1706 2012-08-21 22:48:35 Neskia has quit (Read error: Connection reset by peer)
1707 2012-08-21 22:48:36 Nesetalis has quit (Read error: Connection reset by peer)
1708 2012-08-21 22:48:37 <gmaxwell> BlueMatt: meh, all that means is he didn't break it intentionally. ;)
1709 2012-08-21 22:48:52 LuaKT has quit ()
1710 2012-08-21 22:49:13 <gmaxwell> Code should always be reviewed with an adversarial eye; because god knows the compiler is surely out to kill you.
1711 2012-08-21 22:49:16 Nesetalis has joined
1712 2012-08-21 22:49:48 <Eliel> :D
1713 2012-08-21 22:49:55 <amiller> how hard would it be for me to make ultraprune export a UTXO snapshot from an arbitrary point in time?
1714 2012-08-21 22:49:59 <amiller> i'd just have to simulate a reorg wouldn't i
1715 2012-08-21 22:50:16 <amiller> does it create a second bdb? i think you just said it does reorgs in memory
1716 2012-08-21 22:50:37 Diablo-D3 has quit (Remote host closed the connection)
1717 2012-08-21 22:50:49 Matt_von_Mises has joined
1718 2012-08-21 22:50:54 <sipa> amiller: changes are accumulated in memory, and then committed to the database atomically
1719 2012-08-21 22:51:05 Bachfischer has joined
1720 2012-08-21 22:51:18 Turingi has quit (Read error: Connection reset by peer)
1721 2012-08-21 22:51:32 <sipa> and making it dump its UTXO set isn't hard; i have done so a few times for debugging purposes
1722 2012-08-21 22:51:39 <amiller> bitcoind -dumputxo <blockhash> <newdatabaseenvironment> something like that
1723 2012-08-21 22:51:58 <sipa> why a database?
1724 2012-08-21 22:52:18 <sipa> i think i still have the code, sec
1725 2012-08-21 22:52:19 <amiller> so i can compare it for equivalence to other utxo sets
1726 2012-08-21 22:53:14 <amiller> it would let you easily spot check my implementations
1727 2012-08-21 22:53:21 denisx has quit (Quit: denisx)
1728 2012-08-21 22:53:25 <amiller> i could produce one big list of hashes for all the utxos, and you could issue random challenges
1729 2012-08-21 22:53:35 <sipa> amiller: in my ultraprune_extras branch, there is a commit which adds a 'dumpcoinset' RPC
1730 2012-08-21 22:54:05 <sipa> it creates a file coins-<BLOCKHASH>.txt with a somewhat human-readable representation of the coinset
1731 2012-08-21 22:54:18 Diablo-D3 has joined
1732 2012-08-21 22:54:35 <graingert> are UTXO included in the BC yet?
1733 2012-08-21 22:54:50 <gmaxwell> graingert: thats still a fair ways off.
1734 2012-08-21 22:54:52 <amiller> no, and they won't be for a long time
1735 2012-08-21 22:55:42 <sipa> amiller: i have a similar patch for the current database code, which creates the same file for a given block hash, with the current txindex + block data
1736 2012-08-21 22:55:58 <sipa> i used that to compare ultraprune with the current validation engine
1737 2012-08-21 22:56:30 <sipa> not usable outside of a tmpfs datadir, though :)
1738 2012-08-21 22:57:22 copumpkin has joined
1739 2012-08-21 22:57:33 <graingert> amiller: gmaxwell: presumably the could be included but not validated
1740 2012-08-21 22:57:49 <amiller> it's not worth cluttering the chain with non-validated things
1741 2012-08-21 22:58:04 <sipa> amiller: a merged-mined hash doesn't take extra space
1742 2012-08-21 22:58:28 <amiller> hm
1743 2012-08-21 22:58:31 t7 has quit (Remote host closed the connection)
1744 2012-08-21 22:58:42 <graingert> so might as well put it in the reference miner
1745 2012-08-21 22:58:48 <sipa> graingert: first there must be an agreed-upon algorithm to calculate a merkle root hash of the UTXO set
1746 2012-08-21 22:59:07 <graingert> sipa: has that not been chosen :(
1747 2012-08-21 22:59:08 <amiller> merkle root hash - for a given block*
1748 2012-08-21 22:59:12 Matt_von_Mises has quit (Quit: Leaving.)
1749 2012-08-21 22:59:18 <sipa> both implementing it and agreeing upon an implementation will be not be trivial
1750 2012-08-21 22:59:19 <graingert> amiller: that's been chosen
1751 2012-08-21 22:59:39 <graingert> sipa: you could include all of them
1752 2012-08-21 22:59:55 <sipa> sure, you could also use all altcoins
1753 2012-08-21 22:59:59 <graingert> nah
1754 2012-08-21 23:00:05 <sipa> also, nah then :)
1755 2012-08-21 23:00:07 <graingert> :(
1756 2012-08-21 23:00:11 <amiller> that makes tons of sense, you can just merge mine the merkle roots directly
1757 2012-08-21 23:00:59 tsche has quit (Ping timeout: 240 seconds)
1758 2012-08-21 23:03:24 <graingert> hehe, you could use a bunch of formats and use a format specifier! :D
1759 2012-08-21 23:03:56 <gmaxwell> included but not validated is bascially useless.
1760 2012-08-21 23:04:09 <graingert> it's basically a "vote"
1761 2012-08-21 23:04:13 <amiller> it will become increasingly easy to check though
1762 2012-08-21 23:04:21 <amiller> there's a dterministic mapping from blocks to merkle roots in my scheme
1763 2012-08-21 23:04:26 <amiller> regardless of whether or not the merkle root is present
1764 2012-08-21 23:07:02 <graingert> yes, a deterministic mapping would make them easier to validate
1765 2012-08-21 23:08:38 <gmaxwell> amiller: from all blocks.
1766 2012-08-21 23:08:46 <amiller> 06fcf352f291a6f7242590266c0d80ca6514b779f8b9c4803887c0bf415b028c <- that's the utxo-root associated with block 0000000099c744455f58e6c6e98b671e1bf7f37346bfd4cf5d0274ad8ee660cb, according to the well defined format i put in the post (or else i made a mistake!)
1767 2012-08-21 23:09:10 <amiller> that's block 10,000
1768 2012-08-21 23:09:25 genjix has left ()
1769 2012-08-21 23:09:38 <graingert> yes, it doesn't have many 0s
1770 2012-08-21 23:09:47 <amiller> it's not supposed to have any zeros
1771 2012-08-21 23:09:56 <gmaxwell> amiller: graingert meant the block hash
1772 2012-08-21 23:09:58 <amiller> it's not an altchain, it's a merkle root
1773 2012-08-21 23:10:00 <amiller> oh
1774 2012-08-21 23:11:01 <amiller> altchains wouldn't have any zeros there anyway so nvm, that was another misunderstanding of mine
1775 2012-08-21 23:11:28 <sipa> depends whether they are merged-mined or not
1776 2012-08-21 23:11:56 <amiller> if it were merge mined, the "hash associated with block 0000000xxxxx" would be the header hash of the alt chain, not a proofofwork
1777 2012-08-21 23:12:11 <amiller> anyway
1778 2012-08-21 23:14:18 <amiller> i should be able to at least generate the same coins-*****.dat from an ultraprune dump that far back
1779 2012-08-21 23:16:12 <sipa> the format of the values is very ultraprune-specific (it's the serialized coins per txid)
1780 2012-08-21 23:16:37 <sipa> though it shouldn't be hard to change it to just a list of (amount,scriptout) pairs or something
1781 2012-08-21 23:19:25 sirk390 has quit (Quit: Leaving.)
1782 2012-08-21 23:20:50 DashhSleeps has joined
1783 2012-08-21 23:22:33 JudgeTheDude has quit (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
1784 2012-08-21 23:25:25 [\\\] has joined
1785 2012-08-21 23:30:30 DashhSleeps is now known as in
1786 2012-08-21 23:32:03 Marf has quit (Ping timeout: 250 seconds)
1787 2012-08-21 23:34:53 sebicas has quit (Quit: sebicas)
1788 2012-08-21 23:34:56 copumpkin is now known as TomWilliams
1789 2012-08-21 23:35:41 davout has joined
1790 2012-08-21 23:35:41 davout has quit (Changing host)
1791 2012-08-21 23:35:41 davout has joined
1792 2012-08-21 23:35:43 TomWilliams is now known as copumpkin
1793 2012-08-21 23:39:55 davout has quit (Ping timeout: 245 seconds)
1794 2012-08-21 23:40:30 Anduck has quit (Ping timeout: 252 seconds)
1795 2012-08-21 23:43:01 da2ce7_d is now known as da2ce7
1796 2012-08-21 23:43:21 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
1797 2012-08-21 23:51:37 p0s has joined