1 2011-10-04 00:02:04 peper has joined
2 2011-10-04 00:03:17 tcoppi has joined
3 2011-10-04 00:03:19 tcoppi has quit (Remote host closed the connection)
4 2011-10-04 00:04:03 ephcon has quit (Ping timeout: 248 seconds)
5 2011-10-04 00:05:06 nhodges has joined
6 2011-10-04 00:07:08 SomeoneWeirdAFK is now known as SomeoneWeird
7 2011-10-04 00:08:47 zhoutong has quit (Read error: Connection reset by peer)
8 2011-10-04 00:11:48 zhoutong has joined
9 2011-10-04 00:12:17 Ycros has joined
10 2011-10-04 00:14:50 theorb has joined
11 2011-10-04 00:14:53 <shadders> luke-jr: no psj can't use SIGUSR1 because the java api for receiving signals gives no way check on which pid sent the signal. because it's potentially dealing with multiple daemons it need to which one it came from. Also the daemons may be on different servers. Caesium helped me work around this problem by building a mini-daemon that listens for the signals, works out which bitcoind it came from and sends a poke to psj b
12 2011-10-04 00:14:53 <shadders> y a network socet.
13 2011-10-04 00:14:57 <shadders> https://bitbucket.org/shadders/bitcoin-poolserverj/src/623edd7e7b68/poolserverj-main/etc/psj_sigmon
14 2011-10-04 00:15:16 theorbtwo has quit (Ping timeout: 248 seconds)
15 2011-10-04 00:15:30 theorb is now known as theorbtwo
16 2011-10-04 00:16:18 <shadders> I think it's a better solution all around if something like this was built into bitcoind as a patch as it benefits pushpool as well by making native longpolling possible between two different machines...
17 2011-10-04 00:17:00 wolfspraul has quit (Ping timeout: 260 seconds)
18 2011-10-04 00:17:12 <shadders> Artforz was planning to integrate into a bitcoin patch but I'm not sure where he's got with it...
19 2011-10-04 00:19:22 wolfspraul has joined
20 2011-10-04 00:20:44 jimpsson1 has joined
21 2011-10-04 00:20:51 bitcoinbulletin has quit (Remote host closed the connection)
22 2011-10-04 00:22:47 mmoya has quit (Read error: Operation timed out)
23 2011-10-04 00:23:54 Ycros has quit (Quit: No Ping reply in 180 seconds.)
24 2011-10-04 00:25:29 zhoutong has quit (Read error: Connection reset by peer)
25 2011-10-04 00:25:57 MimeNarrator has quit (Read error: Connection reset by peer)
26 2011-10-04 00:26:06 zhoutong has joined
27 2011-10-04 00:26:12 Tuxavant has quit (Write error: Broken pipe)
28 2011-10-04 00:26:24 Tuxavant has joined
29 2011-10-04 00:27:19 c00w has joined
30 2011-10-04 00:28:17 coderrr has joined
31 2011-10-04 00:28:49 Tuxavant_ has joined
32 2011-10-04 00:29:45 tcoppi has joined
33 2011-10-04 00:29:53 MimeNarrator has joined
34 2011-10-04 00:29:57 tcoppi has quit (Remote host closed the connection)
35 2011-10-04 00:30:39 Tuxavant has quit (Ping timeout: 244 seconds)
36 2011-10-04 00:31:03 bitcoinbulletin has joined
37 2011-10-04 00:33:09 Aexoden has joined
38 2011-10-04 00:34:44 tcoppi has joined
39 2011-10-04 00:39:03 Tuxavant_ has quit (Quit: Disconnecting from stoned server.)
40 2011-10-04 00:39:54 vorlov has joined
41 2011-10-04 00:40:11 localhost has quit (Remote host closed the connection)
42 2011-10-04 00:41:25 Tuxavant has joined
43 2011-10-04 00:41:35 Graet has quit (Read error: Connection reset by peer)
44 2011-10-04 00:42:05 Ycros has joined
45 2011-10-04 00:43:51 Graet has joined
46 2011-10-04 00:44:10 localhost has joined
47 2011-10-04 00:44:12 rdponticelli_ has joined
48 2011-10-04 00:44:24 AAA_awright_ is now known as AAA_awright
49 2011-10-04 00:44:36 rdponticelli has quit (Ping timeout: 248 seconds)
50 2011-10-04 00:47:38 OpenOcean has joined
51 2011-10-04 00:49:02 zhoutong has quit (Read error: Connection reset by peer)
52 2011-10-04 00:49:54 zhoutong has joined
53 2011-10-04 00:50:55 <CIA-101> bitcoin: Luke Dashjr my_free_txn * r3cd01e5714e5 bitcoind-personal/src/main.cpp: Accept any transaction (fee-free or even non-standard) from myself
54 2011-10-04 00:50:57 <CIA-101> bitcoin: Luke Dashjr my_free_txn * r5f28a9b2d639 bitcoind-personal/src/main.cpp: Count credits to me against fee minimums
55 2011-10-04 00:55:25 copumpkin has joined
56 2011-10-04 00:55:58 luke-jr has quit (otg!~luke-jr@2001:470:5:265:222:4dff:fe50:4c49|Ping timeout: 244 seconds)
57 2011-10-04 00:56:48 luke-jr has quit (Excess Flood)
58 2011-10-04 00:57:06 luke-jr has joined
59 2011-10-04 00:57:21 Aexoden has quit (Ping timeout: 240 seconds)
60 2011-10-04 00:57:21 jrmithdobbs has quit (Ping timeout: 240 seconds)
61 2011-10-04 00:57:37 luke-jr has joined
62 2011-10-04 00:57:40 jrmithdobbs has joined
63 2011-10-04 00:57:45 Ycros has quit (Ping timeout: 240 seconds)
64 2011-10-04 00:58:25 Ycros has joined
65 2011-10-04 01:01:10 zhoutong has quit (Read error: Connection reset by peer)
66 2011-10-04 01:04:26 zhoutong has joined
67 2011-10-04 01:06:07 drewn has quit (Ping timeout: 245 seconds)
68 2011-10-04 01:07:03 drewn has joined
69 2011-10-04 01:11:06 zhoutong has quit (Read error: Connection reset by peer)
70 2011-10-04 01:12:03 zhoutong has joined
71 2011-10-04 01:13:19 zhoutong has quit (Read error: Connection reset by peer)
72 2011-10-04 01:13:32 OpenOcean has quit (Ping timeout: 244 seconds)
73 2011-10-04 01:13:47 jrmithdobbs has quit (Read error: Operation timed out)
74 2011-10-04 01:13:50 sneak has quit (Read error: Operation timed out)
75 2011-10-04 01:14:14 zhoutong has joined
76 2011-10-04 01:14:41 sneak has joined
77 2011-10-04 01:14:41 sneak has quit (Changing host)
78 2011-10-04 01:14:41 sneak has joined
79 2011-10-04 01:15:28 luke-jr_ has joined
80 2011-10-04 01:15:32 luke-jr has quit (Read error: Connection reset by peer)
81 2011-10-04 01:15:36 OpenOcean has joined
82 2011-10-04 01:15:36 tcoppi has quit (Ping timeout: 244 seconds)
83 2011-10-04 01:15:41 jrmithdobbs has joined
84 2011-10-04 01:16:12 Aexoden has joined
85 2011-10-04 01:17:37 <CIA-101> bitcoin: Luke Dashjr eligius_sendfee * r8eb0fc831032 bitcoind-personal/src/net.cpp: Add relay.eligius.st to DNS seed list
86 2011-10-04 01:17:39 tcoppi has joined
87 2011-10-04 01:17:58 tcoppi has quit (Remote host closed the connection)
88 2011-10-04 01:20:57 Aexoden has quit (Ping timeout: 240 seconds)
89 2011-10-04 01:22:15 copumpkin has quit (Ping timeout: 255 seconds)
90 2011-10-04 01:22:38 tcoppi has joined
91 2011-10-04 01:22:41 copumpkin has joined
92 2011-10-04 01:22:59 minimoose has joined
93 2011-10-04 01:24:14 Aexoden has joined
94 2011-10-04 01:24:15 HarryS has joined
95 2011-10-04 01:24:15 64MAAKOCF has joined
96 2011-10-04 01:24:33 Cusipzzz has joined
97 2011-10-04 01:24:34 copumpkin has quit (Changing host)
98 2011-10-04 01:24:34 copumpkin has joined
99 2011-10-04 01:25:05 num1 has quit (Read error: Connection reset by peer)
100 2011-10-04 01:26:12 laetus has joined
101 2011-10-04 01:26:22 HarryS has left ()
102 2011-10-04 01:26:40 minimoose has quit (Client Quit)
103 2011-10-04 01:27:05 vorlov has quit (Quit: vorlov)
104 2011-10-04 01:28:23 BTCTrader_ has joined
105 2011-10-04 01:28:48 BTCTrader_ is now known as Guest32521
106 2011-10-04 01:29:18 Bwild has quit (Ping timeout: 276 seconds)
107 2011-10-04 01:30:03 brunner has joined
108 2011-10-04 01:30:24 Guest32521 has quit (Client Quit)
109 2011-10-04 01:32:33 c00w has quit (Ping timeout: 240 seconds)
110 2011-10-04 01:34:29 DontMindMe has quit (Quit: Nettalk6 - www.ntalk.de)
111 2011-10-04 01:37:34 Bwild has joined
112 2011-10-04 01:40:20 rdponticelli_ has quit (Read error: Connection reset by peer)
113 2011-10-04 01:40:33 rdponticelli has joined
114 2011-10-04 01:41:32 <CIA-101> bitcoin: Luke Dashjr accept_nonstdtxn * re8870911d241 bitcoind-personal/src/ (init.cpp main.cpp): -acceptnonstdtxn option to skip "non-standard transaction" checks
115 2011-10-04 01:41:33 <CIA-101> bitcoin: Luke Dashjr free_relay * r8f77e375fe83 bitcoind-personal/src/main.h: Free Relay: Relay transactions regardless of fees (with -freerelay option)
116 2011-10-04 01:43:24 zhoutong has quit (Read error: Connection reset by peer)
117 2011-10-04 01:44:03 zhoutong has joined
118 2011-10-04 01:46:39 Moonies has quit (Quit: quack)
119 2011-10-04 01:47:40 PeterLambert has joined
120 2011-10-04 01:48:56 PeterLambert has left ()
121 2011-10-04 01:49:35 marf_away has quit (Ping timeout: 258 seconds)
122 2011-10-04 01:51:40 Folklore has joined
123 2011-10-04 01:53:14 t3a has quit (Remote host closed the connection)
124 2011-10-04 01:53:42 t3a has joined
125 2011-10-04 01:54:38 Joric has quit ()
126 2011-10-04 01:55:28 copumpkin has quit (Quit: Computer has gone to sleep.)
127 2011-10-04 01:59:55 copumpkin has joined
128 2011-10-04 02:00:18 MimeNarrator has quit (Read error: Connection reset by peer)
129 2011-10-04 02:01:28 tower has quit (Ping timeout: 258 seconds)
130 2011-10-04 02:02:09 random_cat has quit (Quit: WeeChat 0.3.5)
131 2011-10-04 02:05:36 tower has joined
132 2011-10-04 02:06:06 LobsterMan has joined
133 2011-10-04 02:06:13 MimeNarrator has joined
134 2011-10-04 02:06:26 LobsterMan has quit (Remote host closed the connection)
135 2011-10-04 02:09:47 LobsterMan has joined
136 2011-10-04 02:09:47 LobsterMan has quit (Changing host)
137 2011-10-04 02:09:47 LobsterMan has joined
138 2011-10-04 02:11:28 LobsterMan has left ()
139 2011-10-04 02:12:02 BTCTrader_ has joined
140 2011-10-04 02:12:27 BTCTrader_ is now known as Guest80386
141 2011-10-04 02:12:36 rdponticelli has quit (Ping timeout: 248 seconds)
142 2011-10-04 02:13:13 <t3a> !seen toffoo
143 2011-10-04 02:13:16 <spaola> toffoo (~tof@241-245-16-190.fibertel.com.ar) was last seen quitting from #bitcoin-police 1 day, 16 hours, 31 minutes ago stating ().
144 2011-10-04 02:17:08 TheSeven has quit (Disconnected by services)
145 2011-10-04 02:17:22 [7] has joined
146 2011-10-04 02:17:42 earthmeLon has joined
147 2011-10-04 02:17:42 earthmeLon has quit (Changing host)
148 2011-10-04 02:17:42 earthmeLon has joined
149 2011-10-04 02:19:04 shadders has quit (Ping timeout: 256 seconds)
150 2011-10-04 02:19:41 luke-jr_ is now known as luke-jr
151 2011-10-04 02:20:37 earthmeLon is now known as meLon
152 2011-10-04 02:22:16 meLon has quit (Client Quit)
153 2011-10-04 02:22:28 wolfspraul has quit (Quit: leaving)
154 2011-10-04 02:22:37 wolfspraul has joined
155 2011-10-04 02:23:43 paul0 has quit (Quit: paul0)
156 2011-10-04 02:24:51 amiller has quit (Remote host closed the connection)
157 2011-10-04 02:25:56 rdponticelli has joined
158 2011-10-04 02:30:40 crazy_imp has quit (Ping timeout: 244 seconds)
159 2011-10-04 02:31:27 vorlov has joined
160 2011-10-04 02:32:27 shadders has joined
161 2011-10-04 02:32:31 <Diablo-D3> https://www.npr.org/blogs/money/2011/10/03/141011155/did-a-reporter-just-solve-the-bitcoin-mystery
162 2011-10-04 02:32:35 <Diablo-D3> lol
163 2011-10-04 02:32:36 <Diablo-D3> fail
164 2011-10-04 02:32:43 <Diablo-D3> npr should stick to reporting the news
165 2011-10-04 02:32:43 crazy_imp has joined
166 2011-10-04 02:33:15 amiller has joined
167 2011-10-04 02:35:51 zhoutong has quit (Read error: Connection reset by peer)
168 2011-10-04 02:36:07 zhoutong has joined
169 2011-10-04 02:36:40 random_cat has joined
170 2011-10-04 02:36:57 Cusipzzz has quit (Quit: KVIrc 4.1.1 Equilibrium http://www.kvirc.net/)
171 2011-10-04 02:37:43 magn3ts has joined
172 2011-10-04 02:42:07 zhoutong has quit (Read error: Connection reset by peer)
173 2011-10-04 02:43:03 zhoutong has joined
174 2011-10-04 02:50:28 zhoutong has quit (Read error: Connection reset by peer)
175 2011-10-04 02:51:05 zhoutong has joined
176 2011-10-04 02:51:16 <CIA-101> bitcoin: David Joel Schwartz hub_mode * rbf333ad04e4f bitcoind-personal/src/ (init.cpp net.cpp): Update hub mode from diff3 0.5 to diff4 0.992
177 2011-10-04 02:53:04 zhoutong has quit (Read error: Connection reset by peer)
178 2011-10-04 02:54:26 zhoutong has joined
179 2011-10-04 02:57:02 sacarlson has joined
180 2011-10-04 03:08:07 zhoutong has quit (Read error: Connection reset by peer)
181 2011-10-04 03:08:39 zhoutong has joined
182 2011-10-04 03:10:51 zhoutong has quit (Read error: Connection reset by peer)
183 2011-10-04 03:11:25 zhoutong has joined
184 2011-10-04 03:17:52 zhoutong has quit (Read error: Connection reset by peer)
185 2011-10-04 03:18:56 zhoutong has joined
186 2011-10-04 03:19:58 <CIA-101> DiabloMiner: Patrick McFarland master * r183ab14 / src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java : Try to decrease rejects below 0.25% - http://git.io/l7KPVA
187 2011-10-04 03:20:10 noagendamarket has joined
188 2011-10-04 03:25:51 zhoutong has quit (Read error: Connection reset by peer)
189 2011-10-04 03:26:39 zhoutong has joined
190 2011-10-04 03:31:31 <CIA-101> DiabloMiner: Patrick McFarland master * r7681b89 / src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java : Cut down on async getwork debug spam - http://git.io/0HlMaw
191 2011-10-04 03:32:00 magn3ts has quit (Ping timeout: 255 seconds)
192 2011-10-04 03:33:49 <CIA-101> poolserverj: shadders * 48b1483a78aa r154 /poolserverj-main/src/main/java/com/shadworld/poolserver/ (4 files in 2 dirs): a few bugfixes for refactorying. All seems to pass now. Wil merge at this point and rebranch for the actual merged mining implementation as the extensive refactoring will make continuing the main branch difficult.
193 2011-10-04 03:33:50 <CIA-101> poolserverj: shadders * 5f533bb3eafb r155 /poolserverj-main/src/main/java/com/shadworld/poolserver/ (33 files in 11 dirs):
194 2011-10-04 03:33:50 <CIA-101> poolserverj: Merge with 48b1483a78aa9bcf961758753f7689dd8c57f48b
195 2011-10-04 03:33:50 <CIA-101> poolserverj: Completed prerequisite refactoring needed for merged mining implementation. Merging to main branch.
196 2011-10-04 03:34:59 zhoutong has quit (Read error: Connection reset by peer)
197 2011-10-04 03:36:04 zhoutong has joined
198 2011-10-04 03:38:09 Runnigan has quit ()
199 2011-10-04 03:39:56 zhoutong has quit (Read error: Connection reset by peer)
200 2011-10-04 03:40:48 zhoutong has joined
201 2011-10-04 03:40:54 copumpkin has quit (Quit: Computer has gone to sleep.)
202 2011-10-04 03:42:34 zhoutong has quit (Read error: Connection reset by peer)
203 2011-10-04 03:42:48 <luke-jr> so who's the n00b who registered luke-jr at GitHub under their own email? -.-
204 2011-10-04 03:43:28 zhoutong has joined
205 2011-10-04 03:43:29 <shadders> lol
206 2011-10-04 03:44:27 <shadders> they're probably going to post a patch to insert blasphemy in the block chain
207 2011-10-04 03:46:44 Diablo-D3 has quit (Quit: do coders dream of sheep()?)
208 2011-10-04 03:47:19 magn3ts has joined
209 2011-10-04 03:49:18 Diablo-D3 has joined
210 2011-10-04 03:52:50 zhoutong has quit (Read error: Connection reset by peer)
211 2011-10-04 03:53:39 zhoutong has joined
212 2011-10-04 03:57:15 asherkin has quit (Ping timeout: 258 seconds)
213 2011-10-04 03:59:01 zhoutong has quit (Read error: Connection reset by peer)
214 2011-10-04 04:00:10 zhoutong has joined
215 2011-10-04 04:01:18 <CIA-101> bitcoin: Luke Dashjr bugfix_CreateThread_ThreadSocketHandler_errReporting * r65ba3e2f5024 bitcoind-personal/src/net.cpp: Bugfix: report error creating ThreadSocketHandler thread just like the rest
216 2011-10-04 04:01:19 <CIA-101> bitcoin: David Joel Schwartz optimize_cache_rpcauth * r86a1e25ae3d3 bitcoind-personal/src/ (init.cpp rpc.cpp util.cpp util.h): Stash the RPC user and password in a global string so we don't have to fetch them from the map on every RPC request.
217 2011-10-04 04:01:20 <CIA-101> bitcoin: Luke Dashjr optimize_conn_adjtime * ra4e6ae101a02 bitcoind-personal/src/net.cpp: Only GetAdjustedTime once for the retry loop
218 2011-10-04 04:04:35 zhoutong has quit (Read error: Connection reset by peer)
219 2011-10-04 04:05:04 <CIA-101> DiabloMiner: Patrick McFarland master * rec9e664 / src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java : Lets try that fix again - http://git.io/chWkAQ
220 2011-10-04 04:05:28 zhoutong has joined
221 2011-10-04 04:07:05 zhoutong has quit (Read error: Connection reset by peer)
222 2011-10-04 04:07:39 zhoutong has joined
223 2011-10-04 04:12:06 gjs278 has quit (Read error: Connection reset by peer)
224 2011-10-04 04:12:09 <CIA-101> bitcoin: David Joel Schwartz optimize_DecodeBase64 * rdca9244fb45b bitcoind-personal/src/ (rpc.cpp util.cpp util.h): Optimized DecodeBase64
225 2011-10-04 04:12:09 <CIA-101> bitcoin: David Joel Schwartz optimize_ToHex * rf2d32ac03a26 bitcoind-personal/src/ (rpc.cpp util.cpp util.h): Optimized binary-to-hex converter (ToHex)
226 2011-10-04 04:19:48 Moonies has joined
227 2011-10-04 04:20:36 Diablo-D3 has quit (Ping timeout: 255 seconds)
228 2011-10-04 04:21:18 <CIA-101> bitcoin: David Joel Schwartz optimize_remove_CheckWork_delay * r514b18722aa2 bitcoind-personal/src/main.cpp: Remove 2 second sleep from CheckWork
229 2011-10-04 04:23:58 mrb_ has joined
230 2011-10-04 04:26:09 zhoutong has quit (Read error: Connection reset by peer)
231 2011-10-04 04:26:30 zhoutong has joined
232 2011-10-04 04:32:07 zhoutong has quit (Read error: Connection reset by peer)
233 2011-10-04 04:32:45 zhoutong has joined
234 2011-10-04 04:33:25 MobiusL has quit (Ping timeout: 248 seconds)
235 2011-10-04 04:36:11 zhoutong has quit (Read error: Connection reset by peer)
236 2011-10-04 04:36:57 zhoutong has joined
237 2011-10-04 04:38:14 zhoutong has quit (Read error: Connection reset by peer)
238 2011-10-04 04:39:35 zhoutong has joined
239 2011-10-04 04:41:09 WakiMiko_ has joined
240 2011-10-04 04:44:05 zhoutong has quit (Read error: Connection reset by peer)
241 2011-10-04 04:44:08 WakiMiko has quit (Ping timeout: 256 seconds)
242 2011-10-04 04:44:37 NickelBot has quit (Ping timeout: 248 seconds)
243 2011-10-04 04:44:37 zhoutong has joined
244 2011-10-04 04:45:00 paul0 has joined
245 2011-10-04 04:45:16 knotwork has quit (Ping timeout: 256 seconds)
246 2011-10-04 04:46:20 zhoutong has quit (Read error: Connection reset by peer)
247 2011-10-04 04:47:29 zhoutong has joined
248 2011-10-04 04:48:54 MobiusL has joined
249 2011-10-04 04:49:04 OpenOcean is now known as Mad7Scientist
250 2011-10-04 04:51:17 <CIA-101> bitcoin: David Joel Schwartz optimize_FastGetWork * r459f93ce7c70 bitcoind-personal/src/rpc.cpp: Detect typical 'getwork' calls and accelerate them. Bypass the JSON request parser, and the JSON reply builder.
251 2011-10-04 04:51:19 vorlov has quit (Quit: vorlov)
252 2011-10-04 04:53:12 eoss has quit (Quit: Leaving)
253 2011-10-04 04:54:19 zibbo has quit (Ping timeout: 244 seconds)
254 2011-10-04 04:55:55 inlikeflynn has joined
255 2011-10-04 05:01:15 <CIA-101> bitcoin: David Joel Schwartz optimize_http_status * r8407215df0c7 bitcoind-personal/src/rpc.cpp: Use C's const char* for status strings rather than C++'s std::string, which is slower
256 2011-10-04 05:01:16 <CIA-101> bitcoin: Luke Dashjr rpcclient_conn_close * re3f001963acf bitcoind-personal/src/rpc.cpp: Send "Connection: close" HTTP header with JSON-RPC requests (client)
257 2011-10-04 05:03:20 zhoutong has quit (Read error: Connection reset by peer)
258 2011-10-04 05:04:03 zhoutong has joined
259 2011-10-04 05:06:24 zhoutong has quit (Read error: Connection reset by peer)
260 2011-10-04 05:07:17 Cablesaurus has quit (Quit: Life without danger is a waste of oxygen)
261 2011-10-04 05:07:32 zhoutong has joined
262 2011-10-04 05:09:49 Cablesaurus has joined
263 2011-10-04 05:09:49 Cablesaurus has quit (Changing host)
264 2011-10-04 05:09:49 Cablesaurus has joined
265 2011-10-04 05:09:49 zhoutong has quit (Read error: Connection reset by peer)
266 2011-10-04 05:10:44 zhoutong has joined
267 2011-10-04 05:11:20 <CIA-101> bitcoin: Luke Dashjr rpc_keepalive * r7bb1cdcd29d0 bitcoind-personal/src/rpc.cpp: Merge branch 'OLD_rpc_keepalive_20111004' into rpc_keepalive
268 2011-10-04 05:13:11 zhoutong has quit (Read error: Connection reset by peer)
269 2011-10-04 05:13:44 zhoutong has joined
270 2011-10-04 05:13:59 Mad7Scientist is now known as _TERRORIST_
271 2011-10-04 05:14:31 Guest80386 has quit (Ping timeout: 260 seconds)
272 2011-10-04 05:15:33 zhoutong has quit (Read error: Connection reset by peer)
273 2011-10-04 05:16:39 zhoutong has joined
274 2011-10-04 05:16:58 lianj has quit (Ping timeout: 240 seconds)
275 2011-10-04 05:20:16 _TERRORIST_ is now known as Mad7Scientist
276 2011-10-04 05:21:33 dub has quit (Ping timeout: 245 seconds)
277 2011-10-04 05:26:37 Workbench has quit (Read error: Connection reset by peer)
278 2011-10-04 05:26:38 <luke-jr> think I'm done for tonight⦠25 new branches :P
279 2011-10-04 05:26:55 <shadders> you must be bored...
280 2011-10-04 05:27:10 dub has joined
281 2011-10-04 05:27:29 AStove has joined
282 2011-10-04 05:27:35 AStove has quit (Client Quit)
283 2011-10-04 05:27:57 Stove has joined
284 2011-10-04 05:28:26 <shadders> at least you split them... I sent TD a 7000 line diff for bitcoinj the other day. He's going to have fun merging
285 2011-10-04 05:28:45 <shadders> or he may tell me to get stuffed :)
286 2011-10-04 05:29:24 <luke-jr> shadders: half of the work was splitting up JoelKatz's diff4 patch
287 2011-10-04 05:29:48 <luke-jr> the painful thing will be when I have to merge them back XD
288 2011-10-04 05:29:53 <shadders> lot's of little 1diffs
289 2011-10-04 05:30:00 paul0 has quit (Quit: paul0)
290 2011-10-04 05:30:13 <luke-jr> eg, FastGetWork and ToHex
291 2011-10-04 05:30:23 <luke-jr> those were closely tied together
292 2011-10-04 05:30:30 <luke-jr> merging will be more painful than splitting :|
293 2011-10-04 05:34:51 <shadders> never really had to deal with this whole merge, branch, merge thing before. It certainly adds a new dimension of irritation
294 2011-10-04 05:38:37 <CIA-101> poolserverj: shadders * b8ebd4138ade r156 /: Starting 'merged-mining-3-for-real-this-time' branch
295 2011-10-04 05:38:38 <CIA-101> poolserverj: shadders * f8f8a500f150 r157 / (23 files in 9 dirs):
296 2011-10-04 05:38:38 <CIA-101> poolserverj: Abstract share validation and add some Aux entity classes.
297 2011-10-04 05:38:38 <CIA-101> poolserverj: Moved mm entities to core project so that AuxInfo can be encapsulated in Work
298 2011-10-04 05:41:12 <luke-jr> shadders: well, it'd be much less of an issue if JoelKatz did it the right way from the start :/
299 2011-10-04 05:41:22 cenuij has quit (Remote host closed the connection)
300 2011-10-04 05:42:55 cenuij has joined
301 2011-10-04 05:42:55 cenuij has quit (Changing host)
302 2011-10-04 05:42:55 cenuij has joined
303 2011-10-04 05:44:16 <luke-jr> http://activepolitic.com:82/Outside_News/10608.html
304 2011-10-04 05:46:39 cenuij has quit (Remote host closed the connection)
305 2011-10-04 05:46:43 E-sense has quit (Remote host closed the connection)
306 2011-10-04 05:47:06 t3a has quit (Read error: Connection reset by peer)
307 2011-10-04 05:47:25 t3a has joined
308 2011-10-04 05:52:09 zhoutong has quit (Read error: Connection reset by peer)
309 2011-10-04 05:53:11 zhoutong has joined
310 2011-10-04 05:53:15 nutcase has quit (Quit: Oh noes the internets broke!)
311 2011-10-04 05:53:22 cenuij has joined
312 2011-10-04 05:53:22 cenuij has quit (Changing host)
313 2011-10-04 05:53:22 cenuij has joined
314 2011-10-04 06:00:32 terahash has joined
315 2011-10-04 06:01:30 zapnap has quit (Remote host closed the connection)
316 2011-10-04 06:02:21 abragin has joined
317 2011-10-04 06:03:29 lianj has joined
318 2011-10-04 06:03:30 lianj has quit (Changing host)
319 2011-10-04 06:03:30 lianj has joined
320 2011-10-04 06:04:18 nutcase has joined
321 2011-10-04 06:04:19 nutcase has quit (Excess Flood)
322 2011-10-04 06:04:50 nutcase has joined
323 2011-10-04 06:07:10 Aexoden has quit (Ping timeout: 244 seconds)
324 2011-10-04 06:07:26 Aexoden has joined
325 2011-10-04 06:08:44 ferrouswheel has quit (Ping timeout: 252 seconds)
326 2011-10-04 06:09:09 ferrouswheel has joined
327 2011-10-04 06:12:31 terahash has left ()
328 2011-10-04 06:15:11 zhoutong has quit (Read error: Connection reset by peer)
329 2011-10-04 06:15:31 zhoutong has joined
330 2011-10-04 06:21:12 cenuij has quit (Remote host closed the connection)
331 2011-10-04 06:27:42 Tuxavant has quit (Quit: Disconnecting from stoned server.)
332 2011-10-04 06:29:42 Tuxavant has joined
333 2011-10-04 06:29:45 coderrr has quit (Ping timeout: 255 seconds)
334 2011-10-04 06:29:51 Sorcy has joined
335 2011-10-04 06:30:34 Ycros has quit (Ping timeout: 240 seconds)
336 2011-10-04 06:30:35 Optimo has joined
337 2011-10-04 06:30:52 coderrr has joined
338 2011-10-04 06:36:23 MimeNarrator has quit ()
339 2011-10-04 06:39:32 zhoutong has quit (Read error: Connection reset by peer)
340 2011-10-04 06:41:01 zhoutong has joined
341 2011-10-04 06:42:33 zhoutong has quit (Read error: Connection reset by peer)
342 2011-10-04 06:43:14 zhoutong has joined
343 2011-10-04 06:45:12 Optimo has quit (Quit: bai)
344 2011-10-04 06:45:28 Optimo has joined
345 2011-10-04 06:49:09 zhoutong has quit (Read error: Connection reset by peer)
346 2011-10-04 06:50:09 zhoutong has joined
347 2011-10-04 06:53:43 zhoutong has quit (Read error: Connection reset by peer)
348 2011-10-04 06:54:35 zhoutong has joined
349 2011-10-04 06:57:12 iocor has joined
350 2011-10-04 07:01:22 wolfspraul has quit (Ping timeout: 240 seconds)
351 2011-10-04 07:02:30 wolfspraul has joined
352 2011-10-04 07:04:34 danbri has joined
353 2011-10-04 07:07:57 Folklore has quit (Remote host closed the connection)
354 2011-10-04 07:12:31 zhoutong has quit (Read error: Connection reset by peer)
355 2011-10-04 07:12:53 zhoutong has joined
356 2011-10-04 07:14:55 zhoutong has quit (Read error: Connection reset by peer)
357 2011-10-04 07:15:40 zhoutong has joined
358 2011-10-04 07:20:21 zhoutong has quit (Read error: Connection reset by peer)
359 2011-10-04 07:20:52 zhoutong has joined
360 2011-10-04 07:21:37 gjs278 has joined
361 2011-10-04 07:26:40 Stove has quit ()
362 2011-10-04 07:35:41 dub has quit (Ping timeout: 260 seconds)
363 2011-10-04 07:38:37 zhoutong has quit (Read error: Connection reset by peer)
364 2011-10-04 07:38:42 erus` has joined
365 2011-10-04 07:38:48 larsivi has joined
366 2011-10-04 07:39:02 zhoutong has joined
367 2011-10-04 07:41:11 zhoutong has quit (Read error: Connection reset by peer)
368 2011-10-04 07:42:15 zhoutong has joined
369 2011-10-04 07:44:27 dub has joined
370 2011-10-04 07:45:56 nr9 has joined
371 2011-10-04 07:50:57 Lopuz has joined
372 2011-10-04 07:51:25 iocor has quit (Quit: Computer has gone to sleep.)
373 2011-10-04 07:53:57 devrandom has quit (Ping timeout: 248 seconds)
374 2011-10-04 07:55:37 zhoutong has quit (Read error: Connection reset by peer)
375 2011-10-04 07:56:36 devrandom has joined
376 2011-10-04 07:56:40 zhoutong has joined
377 2011-10-04 07:56:55 Disposition has quit (Quit: Leaving.)
378 2011-10-04 07:58:29 zhoutong has quit (Read error: Connection reset by peer)
379 2011-10-04 07:59:38 Disposition has joined
380 2011-10-04 07:59:41 zhoutong has joined
381 2011-10-04 07:59:42 MimeNarrator has joined
382 2011-10-04 08:02:31 amtal has quit (Ping timeout: 260 seconds)
383 2011-10-04 08:02:41 mmoya has joined
384 2011-10-04 08:03:19 iocor has joined
385 2011-10-04 08:03:22 dvide has quit ()
386 2011-10-04 08:04:37 pickett_ has quit (Ping timeout: 248 seconds)
387 2011-10-04 08:05:20 pickett_ has joined
388 2011-10-04 08:06:31 zhoutong has quit (Read error: Connection reset by peer)
389 2011-10-04 08:07:18 random_cat has quit (Ping timeout: 248 seconds)
390 2011-10-04 08:07:29 zhoutong has joined
391 2011-10-04 08:08:08 erle- has joined
392 2011-10-04 08:10:18 MichaelBurge has quit (Read error: Connection reset by peer)
393 2011-10-04 08:10:57 MichaelBurge has joined
394 2011-10-04 08:12:43 <cuqa> bitcoinpool claims that there might be a problem with block generation due to an overloaded wallet
395 2011-10-04 08:12:52 <cuqa> what u think about that?
396 2011-10-04 08:13:27 <cuqa> 22 million shares w/out block solve
397 2011-10-04 08:16:40 Disposition has quit (Read error: Connection reset by peer)
398 2011-10-04 08:17:44 random_cat has joined
399 2011-10-04 08:20:22 laetus has quit (Remote host closed the connection)
400 2011-10-04 08:21:36 cenuij has joined
401 2011-10-04 08:25:46 Disposition has joined
402 2011-10-04 08:25:58 erle- has quit (Ping timeout: 248 seconds)
403 2011-10-04 08:30:02 wasabi1 has quit (Read error: Connection reset by peer)
404 2011-10-04 08:32:47 sipa1024 has joined
405 2011-10-04 08:32:56 sipa1024 is now known as sipa
406 2011-10-04 08:33:08 sipa has quit (Changing host)
407 2011-10-04 08:33:08 sipa has joined
408 2011-10-04 08:34:40 amtal has joined
409 2011-10-04 08:36:16 erle- has joined
410 2011-10-04 08:36:16 zhoutong has quit (Read error: Connection reset by peer)
411 2011-10-04 08:36:39 CaptDDL has joined
412 2011-10-04 08:37:21 zhoutong has joined
413 2011-10-04 08:39:17 CaptainDDL has quit (Ping timeout: 260 seconds)
414 2011-10-04 08:40:57 zhoutong has quit (Read error: Connection reset by peer)
415 2011-10-04 08:40:58 abragin has quit (Read error: Connection reset by peer)
416 2011-10-04 08:41:49 zhoutong has joined
417 2011-10-04 08:41:57 abragin has joined
418 2011-10-04 08:41:57 abragin has quit (Changing host)
419 2011-10-04 08:41:57 abragin has joined
420 2011-10-04 08:43:08 zhoutong has quit (Read error: Connection reset by peer)
421 2011-10-04 08:44:06 d1g1t4l has joined
422 2011-10-04 08:44:06 zhoutong has joined
423 2011-10-04 08:44:19 d1g1t4l has quit (Remote host closed the connection)
424 2011-10-04 08:45:03 erus`_ has joined
425 2011-10-04 08:45:11 marf_away has joined
426 2011-10-04 08:45:17 CaptDDL has quit (Ping timeout: 244 seconds)
427 2011-10-04 08:45:45 CaptainDDL has joined
428 2011-10-04 08:45:53 CaptainDDL has quit (Changing host)
429 2011-10-04 08:45:53 CaptainDDL has joined
430 2011-10-04 08:46:46 erus` has quit (Ping timeout: 248 seconds)
431 2011-10-04 08:46:55 erus`_ is now known as erus`
432 2011-10-04 08:49:58 CaptDDL has joined
433 2011-10-04 08:51:02 CaptainDDL has quit (Ping timeout: 248 seconds)
434 2011-10-04 08:55:27 CaptDDL has quit (Ping timeout: 255 seconds)
435 2011-10-04 08:56:16 CaptainDDL has joined
436 2011-10-04 08:59:49 Sorcy is now known as Ycros
437 2011-10-04 09:01:25 CaptainDDL has quit (Ping timeout: 256 seconds)
438 2011-10-04 09:01:28 CaptDDL has joined
439 2011-10-04 09:07:19 TD[gone] is now known as TD
440 2011-10-04 09:07:34 amtal has quit (Ping timeout: 276 seconds)
441 2011-10-04 09:08:37 zhoutong has quit (Read error: Connection reset by peer)
442 2011-10-04 09:09:45 zhoutong has joined
443 2011-10-04 09:11:59 zhoutong has quit (Read error: Connection reset by peer)
444 2011-10-04 09:12:39 lianj has quit (Ping timeout: 252 seconds)
445 2011-10-04 09:12:49 amtal has joined
446 2011-10-04 09:12:57 zhoutong has joined
447 2011-10-04 09:14:30 CaptDDL has quit (Ping timeout: 248 seconds)
448 2011-10-04 09:16:39 CaptainDDL has joined
449 2011-10-04 09:21:17 CaptainDDL has quit (Ping timeout: 260 seconds)
450 2011-10-04 09:22:28 CaptainDDL has joined
451 2011-10-04 09:22:42 lianj has joined
452 2011-10-04 09:22:43 lianj has quit (Changing host)
453 2011-10-04 09:22:43 lianj has joined
454 2011-10-04 09:25:47 zhoutong has quit (Read error: Connection reset by peer)
455 2011-10-04 09:26:55 zhoutong has joined
456 2011-10-04 09:30:20 zhoutong has quit (Read error: Connection reset by peer)
457 2011-10-04 09:31:08 zhoutong has joined
458 2011-10-04 09:33:00 zhoutong has quit (Read error: Connection reset by peer)
459 2011-10-04 09:34:20 zhoutong has joined
460 2011-10-04 09:35:49 t3a has quit (Read error: Connection reset by peer)
461 2011-10-04 09:36:00 t3a has joined
462 2011-10-04 09:37:19 t3a has quit (Read error: Connection reset by peer)
463 2011-10-04 09:37:32 t3a has joined
464 2011-10-04 09:37:44 erle- has quit (Quit: CETERVMÂAVTEMÂCENSEOÂFDPÂESSEÂDELENDVM)
465 2011-10-04 09:39:49 zhoutong has quit (Read error: Connection reset by peer)
466 2011-10-04 09:40:56 zhoutong has joined
467 2011-10-04 09:43:05 zhoutong has quit (Read error: Connection reset by peer)
468 2011-10-04 09:43:50 Lopuz has quit (Ping timeout: 248 seconds)
469 2011-10-04 09:44:08 zhoutong has joined
470 2011-10-04 09:48:23 zhoutong has quit (Read error: Connection reset by peer)
471 2011-10-04 09:49:02 zhoutong has joined
472 2011-10-04 09:51:05 zhoutong has quit (Read error: Connection reset by peer)
473 2011-10-04 09:51:52 zhoutong has joined
474 2011-10-04 09:53:42 cosurgi has quit (Ping timeout: 260 seconds)
475 2011-10-04 09:55:04 cosurgi has joined
476 2011-10-04 09:56:12 zhoutong has quit (Read error: Connection reset by peer)
477 2011-10-04 09:57:15 zhoutong has joined
478 2011-10-04 09:58:03 CaptDDL has joined
479 2011-10-04 09:58:17 CaptainDDL has quit (Ping timeout: 276 seconds)
480 2011-10-04 09:59:23 zhoutong has quit (Read error: Connection reset by peer)
481 2011-10-04 10:00:31 zhoutong has joined
482 2011-10-04 10:01:39 zhoutong has quit (Read error: Connection reset by peer)
483 2011-10-04 10:02:46 zhoutong has joined
484 2011-10-04 10:02:49 CaptDDL has quit (Ping timeout: 245 seconds)
485 2011-10-04 10:03:05 altamic has joined
486 2011-10-04 10:03:17 altamic has quit (Client Quit)
487 2011-10-04 10:03:31 CaptainDDL has joined
488 2011-10-04 10:06:42 zhoutong has quit (Read error: Connection reset by peer)
489 2011-10-04 10:07:06 zhoutong has joined
490 2011-10-04 10:08:18 zhoutong has quit (Read error: Connection reset by peer)
491 2011-10-04 10:08:38 TheAncientGoat has joined
492 2011-10-04 10:09:17 zhoutong has joined
493 2011-10-04 10:13:47 zhoutong has quit (Read error: Connection reset by peer)
494 2011-10-04 10:14:45 zhoutong has joined
495 2011-10-04 10:16:35 zhoutong has quit (Read error: Connection reset by peer)
496 2011-10-04 10:17:02 zhoutong has joined
497 2011-10-04 10:18:55 zhoutong has quit (Read error: Connection reset by peer)
498 2011-10-04 10:19:13 zhoutong has joined
499 2011-10-04 10:22:29 CaptainDDL has quit (Ping timeout: 252 seconds)
500 2011-10-04 10:22:30 zhoutong has quit (Read error: Connection reset by peer)
501 2011-10-04 10:23:31 zhoutong has joined
502 2011-10-04 10:25:11 CaptainDDL has joined
503 2011-10-04 10:28:11 zhoutong has quit (Read error: Connection reset by peer)
504 2011-10-04 10:28:43 Cokein has joined
505 2011-10-04 10:28:50 zhoutong has joined
506 2011-10-04 10:30:52 zhoutong has quit (Read error: Connection reset by peer)
507 2011-10-04 10:31:14 zhoutong has joined
508 2011-10-04 10:31:23 Cokein has quit (2!~kvirc@host114-91-static.34-79-b.business.telecomitalia.it|Ping timeout: 240 seconds)
509 2011-10-04 10:33:09 zhoutong has quit (Read error: Connection reset by peer)
510 2011-10-04 10:34:36 zhoutong has joined
511 2011-10-04 10:36:30 zhoutong has quit (Read error: Connection reset by peer)
512 2011-10-04 10:36:49 zhoutong has joined
513 2011-10-04 10:40:30 iocor has quit (Quit: Computer has gone to sleep.)
514 2011-10-04 10:47:36 zhoutong has quit (Read error: Connection reset by peer)
515 2011-10-04 10:48:23 zhoutong has joined
516 2011-10-04 10:48:24 CaptDDL has joined
517 2011-10-04 10:48:25 cenuij has quit (Read error: Connection reset by peer)
518 2011-10-04 10:48:31 CaptainDDL has quit (Ping timeout: 260 seconds)
519 2011-10-04 10:48:58 larsivi has quit (Ping timeout: 255 seconds)
520 2011-10-04 10:50:15 zhoutong has quit (Read error: Connection reset by peer)
521 2011-10-04 10:51:34 zhoutong has joined
522 2011-10-04 10:51:54 iocor has joined
523 2011-10-04 10:53:46 zhoutong has quit (Read error: Connection reset by peer)
524 2011-10-04 10:54:43 zhoutong has joined
525 2011-10-04 10:56:10 larsivi has joined
526 2011-10-04 11:00:26 Beremat has joined
527 2011-10-04 11:02:20 zhoutong has quit (Read error: Connection reset by peer)
528 2011-10-04 11:03:21 zhoutong has joined
529 2011-10-04 11:09:21 zhoutong has quit (Read error: Connection reset by peer)
530 2011-10-04 11:09:56 zhoutong has joined
531 2011-10-04 11:13:55 RazielZ has joined
532 2011-10-04 11:18:53 zhoutong has quit (Read error: Connection reset by peer)
533 2011-10-04 11:19:26 zhoutong has joined
534 2011-10-04 11:23:26 zhoutong has quit (Read error: Connection reset by peer)
535 2011-10-04 11:24:18 zhoutong has joined
536 2011-10-04 11:24:47 CaptDDL has quit (Ping timeout: 256 seconds)
537 2011-10-04 11:25:32 CaptainDDL has joined
538 2011-10-04 11:28:39 Beremat has quit (Read error: Connection reset by peer)
539 2011-10-04 11:29:55 zhoutong has quit (Read error: Connection reset by peer)
540 2011-10-04 11:30:56 zhoutong has joined
541 2011-10-04 11:32:56 iocor has quit (Quit: Computer has gone to sleep.)
542 2011-10-04 11:32:56 zhoutong has quit (Read error: Connection reset by peer)
543 2011-10-04 11:33:53 zhoutong has joined
544 2011-10-04 11:34:46 CaptainDDL has quit (Ping timeout: 248 seconds)
545 2011-10-04 11:36:01 zhoutong has quit (Read error: Connection reset by peer)
546 2011-10-04 11:37:31 zhoutong has joined
547 2011-10-04 11:38:49 CaptainDDL has joined
548 2011-10-04 11:41:58 zhoutong has quit (Read error: Connection reset by peer)
549 2011-10-04 11:42:35 zhoutong has joined
550 2011-10-04 11:44:36 CaptDDL has joined
551 2011-10-04 11:46:35 CaptainDDL has quit (Ping timeout: 240 seconds)
552 2011-10-04 11:50:59 zhoutong has quit (Read error: Connection reset by peer)
553 2011-10-04 11:51:40 CaptDDL has quit (Ping timeout: 258 seconds)
554 2011-10-04 11:52:01 zhoutong has joined
555 2011-10-04 11:53:07 zhoutong has quit (Read error: Connection reset by peer)
556 2011-10-04 11:54:14 zhoutong has joined
557 2011-10-04 11:54:43 asherkin has joined
558 2011-10-04 11:58:08 Guest89633 has joined
559 2011-10-04 12:00:00 iocor has joined
560 2011-10-04 12:02:14 louigi has joined
561 2011-10-04 12:02:26 <louigi> luke-jr, ping
562 2011-10-04 12:06:05 Guest89633 has quit (Remote host closed the connection)
563 2011-10-04 12:08:18 zhoutong has quit (Read error: Connection reset by peer)
564 2011-10-04 12:08:58 zhoutong has joined
565 2011-10-04 12:10:12 zhoutong has quit (Read error: Connection reset by peer)
566 2011-10-04 12:11:13 zhoutong has joined
567 2011-10-04 12:18:46 iocor has quit (Quit: Computer has gone to sleep.)
568 2011-10-04 12:23:06 huk has quit ()
569 2011-10-04 12:24:58 louigi has quit (Quit: Leaving)
570 2011-10-04 12:33:28 zhoutong has quit (Read error: Connection reset by peer)
571 2011-10-04 12:34:36 zhoutong has joined
572 2011-10-04 12:35:48 sneak has quit (Ping timeout: 240 seconds)
573 2011-10-04 12:36:41 sneak has joined
574 2011-10-04 12:36:42 sneak has quit (Changing host)
575 2011-10-04 12:36:42 sneak has joined
576 2011-10-04 12:39:10 drewn has quit (Quit: Leaving)
577 2011-10-04 12:45:22 FellowTraveler has joined
578 2011-10-04 12:45:27 <FellowTraveler> Hi all.
579 2011-10-04 12:47:02 MobiusL has quit (Quit: Leaving)
580 2011-10-04 12:50:04 caedes has joined
581 2011-10-04 12:50:04 caedes has quit (Changing host)
582 2011-10-04 12:50:04 caedes has joined
583 2011-10-04 12:52:19 CaptainDDL has joined
584 2011-10-04 12:53:37 <diki> hello fellow traveler
585 2011-10-04 12:53:44 <diki> how was your journey today?
586 2011-10-04 12:54:15 <FellowTraveler> My journey was, I got a new version of OT and Moneychanger posted today, which are running pretty smooth now. Lots of bugs fixed.
587 2011-10-04 12:54:21 <FellowTraveler> Markets are pretty solid now.
588 2011-10-04 12:54:40 <FellowTraveler> I will also have basket currencies built into the GUI within the next day or two, so expect another Moneychanger release then.
589 2011-10-04 12:55:08 <FellowTraveler> Binaries are also posted. https://github.com/FellowTraveler/Open-Transactions/wiki
590 2011-10-04 12:56:19 MobiusL has joined
591 2011-10-04 12:56:19 MobiusL has quit (Changing host)
592 2011-10-04 12:56:19 MobiusL has joined
593 2011-10-04 13:00:03 zhoutong has quit (Read error: Connection reset by peer)
594 2011-10-04 13:00:42 zhoutong has joined
595 2011-10-04 13:02:46 zhoutong has quit (Read error: Connection reset by peer)
596 2011-10-04 13:03:16 zhoutong has joined
597 2011-10-04 13:03:44 CaptainDDL has quit (Ping timeout: 258 seconds)
598 2011-10-04 13:04:32 CaptainDDL has joined
599 2011-10-04 13:05:20 caedes has quit (Ping timeout: 245 seconds)
600 2011-10-04 13:06:04 caedes has joined
601 2011-10-04 13:10:52 caedes has quit (Read error: Operation timed out)
602 2011-10-04 13:14:32 flok has quit (Quit: ZNC - http://znc.sourceforge.net)
603 2011-10-04 13:14:32 zhoutong has quit (Read error: Connection reset by peer)
604 2011-10-04 13:14:58 erle- has joined
605 2011-10-04 13:15:26 zhoutong has joined
606 2011-10-04 13:15:48 wolfspraul has quit (Ping timeout: 260 seconds)
607 2011-10-04 13:16:13 caedes has joined
608 2011-10-04 13:16:24 wolfspraul has joined
609 2011-10-04 13:19:56 p0s has joined
610 2011-10-04 13:29:01 Baksch has joined
611 2011-10-04 13:29:31 Baksch has quit (Client Quit)
612 2011-10-04 13:30:14 noagendamarket has quit (Quit: Leaving)
613 2011-10-04 13:32:50 Gekz has quit (Read error: Operation timed out)
614 2011-10-04 13:32:51 zhoutong has quit (Read error: Connection reset by peer)
615 2011-10-04 13:33:23 zhoutong has joined
616 2011-10-04 13:35:53 Gekz has joined
617 2011-10-04 13:35:55 Gekz has quit (Changing host)
618 2011-10-04 13:35:55 Gekz has joined
619 2011-10-04 13:38:18 wasabi1 has joined
620 2011-10-04 13:39:16 Daniel0108 has quit (Remote host closed the connection)
621 2011-10-04 13:42:24 copumpkin has joined
622 2011-10-04 13:42:42 localhost has quit (Remote host closed the connection)
623 2011-10-04 13:43:21 iocor has joined
624 2011-10-04 13:44:41 zhoutong has quit (Read error: Connection reset by peer)
625 2011-10-04 13:45:51 zhoutong has joined
626 2011-10-04 13:49:34 Daniel0108 has joined
627 2011-10-04 13:49:34 zhoutong has quit (Read error: Connection reset by peer)
628 2011-10-04 13:50:57 zhoutong has joined
629 2011-10-04 13:55:17 zhoutong has quit (Read error: Connection reset by peer)
630 2011-10-04 13:55:43 zhoutong has joined
631 2011-10-04 13:57:31 localhost has joined
632 2011-10-04 13:57:44 <batouzo> hello FellowTraveler :)
633 2011-10-04 13:58:28 Burgundy has joined
634 2011-10-04 13:59:20 <FellowTraveler> hiya.
635 2011-10-04 14:00:14 shLONG has joined
636 2011-10-04 14:04:24 mmoya has quit (Read error: Operation timed out)
637 2011-10-04 14:06:47 MimeNarrator has quit (Remote host closed the connection)
638 2011-10-04 14:09:38 Stellar has quit (Quit: Signed)
639 2011-10-04 14:09:58 MimeNarrator has joined
640 2011-10-04 14:11:06 AStove has joined
641 2011-10-04 14:18:50 MobiusL has quit (Quit: Leaving)
642 2011-10-04 14:18:50 zhoutong has quit (Read error: Connection reset by peer)
643 2011-10-04 14:19:11 MobiusL has joined
644 2011-10-04 14:19:27 jimpsson1 has left ("o/")
645 2011-10-04 14:20:06 zhoutong has joined
646 2011-10-04 14:20:10 batouzo has quit (Ping timeout: 260 seconds)
647 2011-10-04 14:24:06 Sedra- has quit (Remote host closed the connection)
648 2011-10-04 14:24:28 Diablo-D3 has joined
649 2011-10-04 14:25:33 Sedra has joined
650 2011-10-04 14:27:10 <da2ce7> FellowTraveler, ups on your new release!
651 2011-10-04 14:27:36 <FellowTraveler> thank you da2ce7. How goes with the development?
652 2011-10-04 14:27:52 <da2ce7> ooh, I'm not really that sure... :O
653 2011-10-04 14:28:15 <da2ce7> I'm visiting the team in a couple of weeks... maybe a good hands-on demo will help.
654 2011-10-04 14:30:35 <FellowTraveler> I can't wait to see that thing get released.
655 2011-10-04 14:32:09 <da2ce7> :)
656 2011-10-04 14:32:24 larsivi has quit (Ping timeout: 260 seconds)
657 2011-10-04 14:35:03 <edcba> a
658 2011-10-04 14:37:33 batouzo has joined
659 2011-10-04 14:38:51 realazthat has joined
660 2011-10-04 14:39:48 RazielZ has quit (Ping timeout: 240 seconds)
661 2011-10-04 14:40:32 <da2ce7> edcba, what you working on?
662 2011-10-04 14:40:33 MimeNarrator has quit (Remote host closed the connection)
663 2011-10-04 14:40:45 <edcba> on my job :)
664 2011-10-04 14:41:03 <da2ce7> :P
665 2011-10-04 14:41:08 <edcba> quite a long time i didn't look at bitcoin
666 2011-10-04 14:41:12 <edcba> ;;bc,mtgox
667 2011-10-04 14:41:12 <gribble> {"ticker":{"high":5.02675,"low":4.92499,"avg":4.971406783,"vwap":4.979249866,"vol":16591,"last":4.97338,"buy":4.97338,"sell":4.97441}}
668 2011-10-04 14:41:16 <da2ce7> no big bitcoin project.
669 2011-10-04 14:41:20 <edcba> nope
670 2011-10-04 14:41:28 copumpkin has quit (Quit: Computer has gone to sleep.)
671 2011-10-04 14:41:39 <edcba> bitcoin is very stable now lol
672 2011-10-04 14:42:08 <da2ce7> yeah... untill it gets unstable again.
673 2011-10-04 14:44:21 rhl has joined
674 2011-10-04 14:45:01 <Diablo-D3> http://i872.photobucket.com/albums/ab289/lorthar/legolas-elrond-gay.jpg
675 2011-10-04 14:45:06 <Diablo-D3> why the fuck does that image even exist
676 2011-10-04 14:45:08 <rhl> Hi -- I am going to attempt to package bitcoin for fedora, can one of you developers send me info on how you, yourself build bitcoin? me@ryanlewis.net
677 2011-10-04 14:45:20 <rhl> it seems the source doesn't come with a buildsys
678 2011-10-04 14:46:22 <da2ce7> Diablo-D3, hot image, have any more???!!!
679 2011-10-04 14:46:49 <Diablo-D3> =|
680 2011-10-04 14:46:56 <Diablo-D3> rhl: did you try rtfm?
681 2011-10-04 14:47:22 <rhl> Diablo-D3, I grepped the source from bitcoin for the word 'make' and found zilch...
682 2011-10-04 14:47:26 <rhl> so, yes?
683 2011-10-04 14:47:33 <da2ce7> lol
684 2011-10-04 14:47:51 <rhl> does the github repo have something I don't see in the source you download
685 2011-10-04 14:47:54 <edcba> how to build bitcoin lol
686 2011-10-04 14:48:03 <edcba> that won't be easy :p
687 2011-10-04 14:48:09 <Diablo-D3> rhl: it uses qmake now iirc
688 2011-10-04 14:48:54 <rhl> Diablo-D3. I see...
689 2011-10-04 14:48:56 <CIA-101> bitcoin: Gavin Andresen master * r887b9d4 / doc/release-process.txt :
690 2011-10-04 14:48:56 <CIA-101> bitcoin: Merge pull request #547 from TheBlueMatt/build-updates
691 2011-10-04 14:48:56 <CIA-101> bitcoin: Update release-process to point to gitian.sigs repo. - http://git.io/-h2WIg
692 2011-10-04 14:49:09 <rhl> I just pulled the gitrepo, and I found a makefile..
693 2011-10-04 14:49:14 <rhl> yay...
694 2011-10-04 14:49:24 RazielZ has joined
695 2011-10-04 14:49:39 <Diablo-D3> and yeah
696 2011-10-04 14:49:40 knotwork has joined
697 2011-10-04 14:49:40 knotwork has quit (Changing host)
698 2011-10-04 14:49:40 knotwork has joined
699 2011-10-04 14:49:43 <Diablo-D3> theres a makefile in src
700 2011-10-04 14:49:46 <Diablo-D3> noobs
701 2011-10-04 14:50:11 <rhl> strange.. maybe my download was borked or something
702 2011-10-04 14:51:04 <Diablo-D3> rhl: I dunno man
703 2011-10-04 14:51:12 <Diablo-D3> Im looking in the .tar.gz release of the linux binary
704 2011-10-04 14:51:15 <Diablo-D3> its in src
705 2011-10-04 14:51:23 <rhl> Diablo-D3, do you run ubuntu?
706 2011-10-04 14:51:51 <CIA-101> bitcoin: Gavin Andresen master * r5c5d310 / (3 files in 2 dirs):
707 2011-10-04 14:51:51 <CIA-101> bitcoin: Merge pull request #549 from enmaku/master
708 2011-10-04 14:51:51 <CIA-101> bitcoin: Python scripts demonstrating using RPC to keep passphrases out of shell history/etc. - http://git.io/PEowVw
709 2011-10-04 14:52:30 <Diablo-D3> rhl: no, debian
710 2011-10-04 14:52:34 <Diablo-D3> ubuntu is a horrid pile of shit
711 2011-10-04 14:52:56 paul0 has joined
712 2011-10-04 14:53:08 NickelBot has joined
713 2011-10-04 14:55:24 zhoutong has quit (Read error: Connection reset by peer)
714 2011-10-04 14:56:04 zhoutong has joined
715 2011-10-04 14:56:47 <sipa> the makefile is for bitcoind
716 2011-10-04 14:56:56 <sipa> only bitcoin-qt is built through qmake for now
717 2011-10-04 14:57:11 iocor has quit (Quit: Computer has gone to sleep.)
718 2011-10-04 14:57:24 MimeNarrator has joined
719 2011-10-04 14:57:41 <wumpus> we really need to switch to a mature build system such cmake or autoconf some day...
720 2011-10-04 14:57:57 <sipa> yes
721 2011-10-04 14:58:03 <sipa> definitely
722 2011-10-04 14:58:34 <Diablo-D3> well, autoconf + buildsys
723 2011-10-04 14:58:38 <Diablo-D3> superior to autoconf + automake
724 2011-10-04 14:58:57 <wumpus> please no discussion on what to choose :p either one would be fine
725 2011-10-04 14:59:14 <Diablo-D3> automake is insane
726 2011-10-04 14:59:16 <wumpus> someone just needs to do it
727 2011-10-04 14:59:23 <Diablo-D3> buildsys is so much better
728 2011-10-04 14:59:52 <wumpus> autoconf is also insane, but it works better than what we have now that's all that matters :-)
729 2011-10-04 15:00:06 <Diablo-D3> autoconf is actually pretty sane if you use it right
730 2011-10-04 15:00:13 shDong has joined
731 2011-10-04 15:00:18 <Diablo-D3> most autoconf insanity is because of people using automake
732 2011-10-04 15:00:25 <Diablo-D3> or because they just dont understand autoconf
733 2011-10-04 15:00:44 <rhl> looks like bitcoin requires patented elliptic curve stuff
734 2011-10-04 15:00:54 <Diablo-D3> rhl: software patents are fictional.
735 2011-10-04 15:01:03 <rhl> well, fedora doesn't package them apparently
736 2011-10-04 15:01:05 <Diablo-D3> please do not bring them up here, this isn't #fud
737 2011-10-04 15:01:08 <wumpus> yes Diablo-D3, someone that understands it should do it
738 2011-10-04 15:01:14 <wumpus> feel free to do it and submit a pull request
739 2011-10-04 15:01:24 <wumpus> Diablo-D3: +1
740 2011-10-04 15:01:25 <Diablo-D3> wumpus: I already have a todo list thats too long
741 2011-10-04 15:01:46 <Diablo-D3> seriously, someone invent a cloning machine and make a few dozen mes
742 2011-10-04 15:01:50 <rhl> I could prolly help with this and use CMake.. CMake is really simple to setup
743 2011-10-04 15:01:59 <sipa> rhl: indeed, you'll need a local installation of openssl on redhat-based systems
744 2011-10-04 15:02:00 <Diablo-D3> cmake requires cmake installed
745 2011-10-04 15:02:02 <wumpus> Diablo-D3: I thought the same some days ago.. if only I was scalable :-)
746 2011-10-04 15:02:12 shLONG has quit (Ping timeout: 240 seconds)
747 2011-10-04 15:02:26 <Diablo-D3> autoconf and make only require a functional (or not so functional in some cases) sh, and make.
748 2011-10-04 15:02:28 <rhl> sipa, darn.. looks like we can't get bitcoin packaged for fedora then
749 2011-10-04 15:02:43 <Diablo-D3> rhl: the bitcoin binaries work on fedora anyhow
750 2011-10-04 15:02:43 <luke-jr> autoconf/automake is fine
751 2011-10-04 15:02:47 <luke-jr> no need for non-standard crap
752 2011-10-04 15:02:50 <wumpus> autoconf needs autoconf installed, and all kinds of m4 crap
753 2011-10-04 15:02:57 <Diablo-D3> wumpus: no
754 2011-10-04 15:03:07 <k9quaint> I just put all my code in one file and have the output be a.out, saves a lot of effort :P
755 2011-10-04 15:03:10 <Diablo-D3> wumpus: to use an already made ./connfigure, it requires only sh
756 2011-10-04 15:03:24 <Diablo-D3> wumpus: to build one as a developer it requires autoconf
757 2011-10-04 15:03:24 <wumpus> Diablo-D3: which means you need to check in generated files
758 2011-10-04 15:03:30 <Diablo-D3> check in? no
759 2011-10-04 15:03:40 <sipa> check in, no; package, yes
760 2011-10-04 15:03:45 <Diablo-D3> yes
761 2011-10-04 15:03:55 <rhl> you know, when you are installing software in a distro, if you need cmake, you can just list it as a dependency, and it installs..
762 2011-10-04 15:04:07 <Diablo-D3> rhl: yeah, but not all people use linux
763 2011-10-04 15:04:17 <luke-jr> Diablo-D3: everyone compilign should
764 2011-10-04 15:04:18 <k9quaint> rhl: DONT MENTION THAT BLACK MAGIC IN HERE!
765 2011-10-04 15:04:26 <rhl> jeez....
766 2011-10-04 15:04:32 <wumpus> the coo lthing about cmake is that it can also generate other types of build files
767 2011-10-04 15:04:34 <wumpus> such as msvc
768 2011-10-04 15:04:49 <luke-jr> the cool thing about cmake is that it can't crosscompile sanely
769 2011-10-04 15:04:49 <rhl> whatever guys...
770 2011-10-04 15:04:51 <Diablo-D3> I have evaluated basically every build system ever
771 2011-10-04 15:04:58 <luke-jr> or anything else autoconf/automake does right
772 2011-10-04 15:05:14 <Diablo-D3> autoconf + automake is the second "best", no matter how much of a horror it is for noobs
773 2011-10-04 15:05:21 <Diablo-D3> autoconf + buildsys is vastly superior
774 2011-10-04 15:05:30 * luke-jr has never even HEARD of buildsys
775 2011-10-04 15:05:32 <Diablo-D3> buildsys ships inside your app as a makefile you import.
776 2011-10-04 15:05:32 <wumpus> anyway, I won't go into discussion about this, I simply don't care as long as it works
777 2011-10-04 15:05:41 <diki> so is this game rage gonna be good?
778 2011-10-04 15:05:42 <Diablo-D3> luke-jr: you may not have, but you've most likely used programs that use it
779 2011-10-04 15:05:50 <diki> there are a few i want to play
780 2011-10-04 15:05:53 <diki> deus ex and this rage
781 2011-10-04 15:05:55 <Diablo-D3> for example, freenode's ircd uses buildsys.
782 2011-10-04 15:05:56 <diki> see the big giant
783 2011-10-04 15:05:58 <Diablo-D3> as does audacious
784 2011-10-04 15:06:47 <Diablo-D3> anyhow, afk
785 2011-10-04 15:07:08 copumpkin has joined
786 2011-10-04 15:07:35 <wumpus> k9quaint: no, just no :p bitcoin already has too much code in some files
787 2011-10-04 15:07:59 glitch-mod has quit (Read error: Connection reset by peer)
788 2011-10-04 15:08:22 <k9quaint> wumpus: I take monolithic development to new extremes, I call it bungiecoding :P
789 2011-10-04 15:08:24 <wumpus> and all the include files are a cross-including ball of mud, I agree it wouldn't make much of a difference to cat the .cpp files together too :-)
790 2011-10-04 15:08:41 <k9quaint> I also don't use any newlines
791 2011-10-04 15:08:53 <wumpus> hehe
792 2011-10-04 15:09:05 <wumpus> newlines are just for humans anyway, who needs th
793 2011-10-04 15:10:36 MC1984 has quit (Read error: Connection reset by peer)
794 2011-10-04 15:10:55 MC1984 has joined
795 2011-10-04 15:15:08 huk has joined
796 2011-10-04 15:16:44 Lopuz has joined
797 2011-10-04 15:17:44 paul0 has quit (Quit: paul0)
798 2011-10-04 15:22:53 vorlov has joined
799 2011-10-04 15:23:12 p0s has quit (Remote host closed the connection)
800 2011-10-04 15:25:04 Lopuz has quit (Read error: Connection reset by peer)
801 2011-10-04 15:31:36 KArmitt has joined
802 2011-10-04 15:34:31 zhoutong has quit (Read error: Connection reset by peer)
803 2011-10-04 15:34:51 zhoutong has joined
804 2011-10-04 15:36:00 zapnap has joined
805 2011-10-04 15:36:52 <gavinandresen> sipa: ping
806 2011-10-04 15:37:31 <gavinandresen> TD: you busy?
807 2011-10-04 15:37:40 <TD> gavinandresen: hey
808 2011-10-04 15:37:49 <TD> gavinandresen: nope
809 2011-10-04 15:38:10 <gavinandresen> TD: hey, can I pick your brain about some low-level CScript stuff? I'm wondering what Satoshi was thinking with OP_CODESEPARATOR...
810 2011-10-04 15:38:16 <TD> yes
811 2011-10-04 15:38:17 marf_away has quit (Quit: Nettalk6 - www.ntalk.de)
812 2011-10-04 15:38:28 <TD> that's a good question
813 2011-10-04 15:38:42 <TD> it's clearly intended for some kind of contract construction
814 2011-10-04 15:38:53 <TD> the question is ... what? i thought i had a use for it at one point, then realized i had it wrong
815 2011-10-04 15:39:07 <TD> apparently he tested it too judging by the code that eliminates duplicates when concatenated together
816 2011-10-04 15:39:17 <gavinandresen> I'm also looking really deeply for the first time at how transactions are signed...
817 2011-10-04 15:39:36 <TD> the thing that puzzles me about the concatenation related code is that it doesn't make a whole lot of sense to me
818 2011-10-04 15:39:55 <gavinandresen> yeah, doesn't make sense to me either.
819 2011-10-04 15:40:00 <TD> i can't see a case where you'd want a CODESEPARATOR in a scriptSig
820 2011-10-04 15:40:19 <TD> indeed having anything other than raw data in a scriptSig seems kind of pointless
821 2011-10-04 15:40:27 <TD> it has no inputs so any instructions at all are superfluous
822 2011-10-04 15:40:43 <gavinandresen> CHECKSIG blanks out its signatures... I'm trying to figure out what two CHECKSIGS in a transaction are actually signing. Does the second end up signing the first's signature?
823 2011-10-04 15:40:55 <gavinandresen> ... that can't be right....
824 2011-10-04 15:41:15 <TD> no, what CHECKSIG signs is controlled by the SIGHASH flags
825 2011-10-04 15:41:21 <TD> the input being signed is always cleared
826 2011-10-04 15:41:35 <TD> actually all input scripts are cleared, otherwise it'd be impossible to construct a txn
827 2011-10-04 15:41:36 <gavinandresen> I thought the OTHER inputs were cleared
828 2011-10-04 15:41:44 <TD> yes, the connected output is put in the input slot
829 2011-10-04 15:42:06 <TD> sorry, that was confusing of me
830 2011-10-04 15:42:37 <gavinandresen> I'm staring at the SignatureHash code right now...
831 2011-10-04 15:43:18 <TD> in a standard transaction when CHECKSIG is run, the script being evaluated is the output. so that's what is in scriptCode
832 2011-10-04 15:43:19 <gavinandresen> ... hang on, I'll stare at the bitcoinj signature code for a bit (haven't looked at how you coded it)
833 2011-10-04 15:43:34 <TD> let me give you a link to it
834 2011-10-04 15:43:55 <TD> http://code.google.com/p/bitcoinj/source/browse/trunk/src/com/google/bitcoin/core/Transaction.java#372
835 2011-10-04 15:44:00 <TD> that's the code that actually signs a transaction
836 2011-10-04 15:44:09 <TD> there is no code that verifies signatures, because it's not a full implementation
837 2011-10-04 15:44:10 <sipa> gavinandresen: pong
838 2011-10-04 15:44:22 <TD> inclusion in a buried block is considered ipso-facto proof the signature would have verified
839 2011-10-04 15:44:49 <TD> SignatureHash isn't as complicated as it looks though
840 2011-10-04 15:45:02 <gavinandresen> hey sipa, trying to better understand signing transactions, OP_CODESEPARATOR, all because I'm thinking hard about OP_EVAL...
841 2011-10-04 15:45:12 <TD> what would OP_EVAL do ?
842 2011-10-04 15:45:36 <gavinandresen> Evaluate the item on the top of the stack as a serialized Script
843 2011-10-04 15:45:50 <gavinandresen> (sounds scary at first, doesn't it?)
844 2011-10-04 15:45:59 <TD> well, i'm not sure what the use case would be
845 2011-10-04 15:46:05 <sipa> TD: https://bitcointalk.org/index.php?topic=46538.0
846 2011-10-04 15:47:34 <TD> i don't get it
847 2011-10-04 15:47:47 <TD> this looks like the kind of proposal i've been seeing from people who aren't actually implementing any contracts protocols
848 2011-10-04 15:47:56 <TD> "Addresses for arbitraritly complex transactions are fixed forever."
849 2011-10-04 15:48:04 <TD> i've yet to see an arbitrarily complex transaction that does not require some OOB protocol
850 2011-10-04 15:48:08 <TD> "Addresses need only be same length as the current ones, forever."
851 2011-10-04 15:48:10 <TD> that is not an advantage
852 2011-10-04 15:48:15 <gavinandresen> I want it for secure wallets.
853 2011-10-04 15:48:20 <TD> "Transactions sending to multisignature addresses in this scheme are the same length as normal. This addresses theymos' concern that senders shouldn't be burdened with extra fees from longer scriptPubKeys."
854 2011-10-04 15:48:23 <gavinandresen> I don't care about contracts
855 2011-10-04 15:48:26 <TD> senders should not be attaching fees at all
856 2011-10-04 15:48:51 <sipa> TD: on a somewhat related note, have you seen https://gist.github.com/1237788 ?
857 2011-10-04 15:48:56 <TD> well, i'm not convinced the script side of two-factor wallets should be developed independently of the rest of the system
858 2011-10-04 15:49:11 <TD> eg if i was doing all the work for two-factor wallets i'd probably try and rule out threshold signatures first
859 2011-10-04 15:49:52 <sipa> gavinandresen: i always somehow assumed that OP_CODESEPARATOR had some use in more advanced scripts, but never really thought about how and why
860 2011-10-04 15:51:04 Lopuz has joined
861 2011-10-04 15:51:09 <gavinandresen> TD: threshold encryption is spiffy, but I'm not seeing anybody submitting patches implementing it. I KNOW multi-factor wallets can be implemented pretty easily with two-signature addresses
862 2011-10-04 15:51:16 <TD> sipa: well, i'd like to see an http[s] protocol for challenging a server to sign a nonce with a key. it's useful for showing human-readable names in a GUI
863 2011-10-04 15:51:30 <TD> sipa: i'm not sure about trying to map out anything more complicated than that right now
864 2011-10-04 15:51:40 <TD> gavinandresen: who is going to implement the second factor? i assume it's intended to be a mobile app?
865 2011-10-04 15:52:22 <sipa> TD: signmessage was recently merged, which should make signing of messages easier
866 2011-10-04 15:52:22 <TD> like i said, i'm not sure it's worth developing one part without the other.
867 2011-10-04 15:52:36 <TD> sipa: ah cool. didn't see that. i was in the states for a week so i am behind on what's been merged.
868 2011-10-04 15:52:36 <gavinandresen> TD: my use case is a Wallet Protection Service Agency that automatically signs transactions below N BTC per day, and sends you a confirmation text if a transction is above that.
869 2011-10-04 15:52:44 <gavinandresen> (web-based service)
870 2011-10-04 15:53:12 <gavinandresen> TD: I want to develop the low-level support soon so the new transaction type gets relayed/mined.
871 2011-10-04 15:53:14 <TD> that's single factor from bitcoins perspective, right? the WPSA owns the keys
872 2011-10-04 15:53:36 <gavinandresen> TD: no, keys would be split between your bitcoin and the wallet service's
873 2011-10-04 15:53:58 <sipa> we're talking about a 2-out-of-2 scheme here, right?
874 2011-10-04 15:54:03 <gavinandresen> sipa: yes
875 2011-10-04 15:54:29 <TD> ok. i see. i was thinking more in terms of user-provided second factors. seems more decentralized that way.
876 2011-10-04 15:55:08 <gavinandresen> Competing Wallet Protection Services is nice and decentralized....
877 2011-10-04 15:55:38 <TD> well, we have competing banks as well :-)
878 2011-10-04 15:55:49 <TD> in practice such a service will charge fees, for instance.
879 2011-10-04 15:56:00 <TD> it might be the way to go
880 2011-10-04 15:56:01 <gavinandresen> So: OP_EVAL is a generalization of the standard CHECKSIG transaction we have today that moves the public key from the scriptPubKey to the scriptSig.
881 2011-10-04 15:56:27 wpl has quit (Ping timeout: 276 seconds)
882 2011-10-04 15:56:56 <sipa> but the actual script (which will be provided in scriptSig) cannot be secret
883 2011-10-04 15:57:05 <gavinandresen> TD: web-based Wallet Protection Service or hardware-gadget-based key-signing dongle... a 2-of-2 standard transaction type should make either easy to implement
884 2011-10-04 15:57:09 <TD> i have to say, off the cuff i don't like the idea of adding very powerful opcodes unless somebody can find a use case that requires one. avoiding fees isn't a use case IMHO because you can always ask a user to submit a zero-fee transaction to a regular key out of band, then you can create another tx that spends the first attaching a fee of whatever you like
885 2011-10-04 15:57:11 <sipa> so the only advantage is short address notation
886 2011-10-04 15:57:37 <topace> how does encrypting the wallet work when running bitcoind from the command line? is there an API to turn on the encryption, enter the passphrase, etc?
887 2011-10-04 15:57:43 <gavinandresen> Here's the use case: I want my bitcoins to always be secure, even if my PC is root-kitted. So: how do I tell you to send me some?
888 2011-10-04 15:57:44 <TD> and that's how fees should work in future. it doesn't really make sense that customers attach fees, the merchant is in a better place to do that.
889 2011-10-04 15:57:46 <sipa> topace: yes
890 2011-10-04 15:57:53 wpl has joined
891 2011-10-04 15:58:14 <topace> sipa: cool thx, and on any "sendtoaddress" also requires the passphrase then too ?
892 2011-10-04 15:58:18 <TD> can you do that without a TXT/SKINIT style environment? if you're sending mail or IMs from your compromised computer anything you say can be rewritten
893 2011-10-04 15:58:41 <sipa> topace: there is a notion of a "locked" wallet (encrypted, and password not known)
894 2011-10-04 15:58:52 <sipa> topace: there is an RPC to unlock the wallet for a limited (user-provided) time
895 2011-10-04 15:59:00 <TD> to make spending coins work you need to solve the identity problem first
896 2011-10-04 15:59:01 <sipa> and sendtoaddress fails if the wallet is locked
897 2011-10-04 15:59:12 <topace> ahh i see, perfect
898 2011-10-04 15:59:23 ByteCoin has joined
899 2011-10-04 15:59:24 <TD> sending a text message containing only an address and amount is vulnerable to just having your coins stolen when you spend them
900 2011-10-04 15:59:29 <sipa> topace: there's a README that explains it more thoroughly
901 2011-10-04 15:59:40 <TD> it's better than nothing, but if you ever make a large transaction you're vulnerable
902 2011-10-04 15:59:40 <topace> oh, i didnt see that, is it in the tarball ?
903 2011-10-04 15:59:44 <gavinandresen> TD: good point, I didn't think of the root-kit intercepting addresses in my communications with you
904 2011-10-04 16:00:19 <TD> solving identity solves the payments problem to some extent. your second factor can say "Pay amazon.com 12 BTC?"
905 2011-10-04 16:00:38 <TD> and if the virus on your machine rewrites the address it won't show up with the right name on your device
906 2011-10-04 16:00:56 <TD> if the device is compromised, when it signs the message to confirm user acceptance, the PC won't accept it because it did not match what was requested
907 2011-10-04 16:01:15 <TD> for receiving coins, i think you need some kind of social network integration. somebody needs to be able to visit a resource that is definitively owned by you and be able to get a key
908 2011-10-04 16:01:31 <sipa> TD: how do you see the message-signing http protocol, by the way?
909 2011-10-04 16:01:49 <TD> bitcoin:1abcd12443adsf?path=amazon.com
910 2011-10-04 16:02:11 <gavinandresen> TD: the Wallet Protection Service could offer the ability to verify payment addresses are protected by them
911 2011-10-04 16:02:16 <TD> https://www.amazon.com/_bitcoin/sign?pubkeyhash=1abcd12443adsf&nonce=1234
912 2011-10-04 16:02:39 <TD> sipa: now you can render amazon.com instead of 1abcd12443 (which could be anything)
913 2011-10-04 16:02:44 <TD> sipa: better UI and more useful second factors
914 2011-10-04 16:03:24 shDong has quit (Ping timeout: 260 seconds)
915 2011-10-04 16:03:26 <sipa> and where does the UI get the 'bitcoin:1abcd12443adsf?path=amazon.com' string?
916 2011-10-04 16:03:28 <TD> gavinandresen: yes that works too. they can also generate the keys for you with the deterministic wallet scheme so you never have to "reload". for today just pre-generating a ton of keys and uploading them works.
917 2011-10-04 16:03:31 <sipa> that is entered by the user?
918 2011-10-04 16:03:32 <TD> sipa: web page, email, etc
919 2011-10-04 16:03:45 <TD> sipa: no. the user just clicks a button provided by amazon. "Pay with Bitcoin" for instance
920 2011-10-04 16:04:05 shLONG has joined
921 2011-10-04 16:04:08 <TD> it'd have &value and so on as well of course
922 2011-10-04 16:04:23 <TD> probably the amount should be included in the signature
923 2011-10-04 16:04:38 SomeoneWeird is now known as SomeoneWeirdzzzz
924 2011-10-04 16:04:45 <sipa> ok, and that URL is sent to the bitcoin application
925 2011-10-04 16:04:52 <TD> yes
926 2011-10-04 16:04:56 <sipa> which does an http query to the given URL
927 2011-10-04 16:05:12 erus` has quit (Remote host closed the connection)
928 2011-10-04 16:05:12 <sipa> and gets a signature "yeah, indeed, we control the corresponding private key"
929 2011-10-04 16:05:13 <TD> if it's SSL and the target has an EV cert you can also display the human-friendly name
930 2011-10-04 16:05:28 <sipa> ah, ok, you really on SSL's PKI
931 2011-10-04 16:05:31 <gavinandresen> So: the use case for OP_EVAL is to keep the ?pubkeyhash= from growing very long if the transaction is complicated. And to move the fees associated with funding complicated transactions from the customer to the merchant.
932 2011-10-04 16:05:33 <sipa> *rely
933 2011-10-04 16:06:04 <TD> i think it's better to solve that with other methods. complicated transactions usually require some protocol more complicated than "open a magic uri" anyway
934 2011-10-04 16:06:16 <gavinandresen> TD: what other methods?
935 2011-10-04 16:06:17 <TD> and merchants can always chain transactions to attach whatever fee they like
936 2011-10-04 16:07:28 <gavinandresen> TD: but chaining trasactions means more fees, more transactions over the network, ...
937 2011-10-04 16:07:32 <ByteCoin> TD: I disagree. It would be useful to have a short address that allows donations for example to be sent so as to require "(a and b) or c" keys to redeem.
938 2011-10-04 16:07:37 <gavinandresen> ... more opportunity for a trojan to intercept...
939 2011-10-04 16:07:45 <TD> no
940 2011-10-04 16:07:53 <TD> customer just submits a transaction as per normal, but directly
941 2011-10-04 16:07:56 <TD> via HTTP or some other direct protocol
942 2011-10-04 16:08:08 <TD> merchant takes that fee-less transaction, creates another that spends it with whatever fee they want
943 2011-10-04 16:08:11 <TD> broadcasts both simultaneously
944 2011-10-04 16:08:18 <ByteCoin> TD: Why make things require a live internet connection all of a sudden?
945 2011-10-04 16:08:33 <sipa> how are you going to submit the transaction without a live internet connection?
946 2011-10-04 16:09:12 <ByteCoin> If bitcoin had been engineered from the start with the proviso that both parties can communicate directly, it could have been a LOT simpler!
947 2011-10-04 16:09:27 <ByteCoin> Requiring a live connection is a large retrograde step
948 2011-10-04 16:09:29 <gavinandresen> If you send a donation to me, I don't have to be running anything to receive it.
949 2011-10-04 16:10:05 <gavinandresen> (if it is a bitcoin address. If it is a https://gavinandresen.com/ address then I have to be running a server on gavinandresen.com)
950 2011-10-04 16:10:40 <ByteCoin> My favourite use case for this is donations to wikileaks where they publish the address in a newspaper and any permanent internet presence gets shut down by the feds.
951 2011-10-04 16:10:46 <TD> really nobody should be re-using addresses, not even for the donation case.
952 2011-10-04 16:10:58 <TD> people will do it without understanding the privacy implications
953 2011-10-04 16:11:01 batouzo has quit (Quit: Leaving)
954 2011-10-04 16:11:07 <gavinandresen> mmmm. people shouldn't do a lot of stuff...
955 2011-10-04 16:11:08 Xunie has joined
956 2011-10-04 16:11:19 <sipa> if you really really only want anonimous donations, a static address (short or long) is indeed the way to go
957 2011-10-04 16:11:25 <luke-jr> TD: privacy isn't important; addresses should be reusable in 99% of cases
958 2011-10-04 16:11:26 <ByteCoin> I have a proposal that makes sending to a fixed address anonymous.
959 2011-10-04 16:11:48 <luke-jr> TD: it's a flaw that people need new addresses for each payment
960 2011-10-04 16:11:51 <ByteCoin> If anonymity was important then it should have got more attention.
961 2011-10-04 16:12:05 <TD> well, it's a "flaw" that's pretty fundamental to bitcoins design.
962 2011-10-04 16:12:12 <gavinandresen> I am way more concerned about security than anonymity.
963 2011-10-04 16:12:18 <ByteCoin> Indeed, the profusion of new addresses is a flaw, and unecessary.
964 2011-10-04 16:12:20 <TD> it's not about anonymity
965 2011-10-04 16:12:21 <sipa> it's a flaw that people use static txout templates as only initiator for a transaction
966 2011-10-04 16:12:24 <TD> anonymity != privacy
967 2011-10-04 16:12:29 <TD> though they are two sides of the same coin sometimes
968 2011-10-04 16:12:36 <gavinandresen> Ok, I am way more concerned about security than privacy.
969 2011-10-04 16:12:41 <TD> i am not anonymous but i do not wish people to know my bank balance
970 2011-10-04 16:13:09 <gavinandresen> ... so generate a new, secure bitcoin address for every web visitor to your "send me bitcoins" donations page....
971 2011-10-04 16:13:20 <sipa> so you have a web server?
972 2011-10-04 16:13:27 <gavinandresen> I just want to enable secure bitcoin addresses
973 2011-10-04 16:13:52 <sipa> yes, i believe secure bitcoin addresses are useful
974 2011-10-04 16:13:55 <sipa> but they will be overused
975 2011-10-04 16:14:09 <TD> if you have a web server, you can run a program that accepts transactions directly from clients.
976 2011-10-04 16:14:15 <gavinandresen> I think people will stop using them when there is a better alternative.
977 2011-10-04 16:14:26 * sipa points to his proposal
978 2011-10-04 16:14:57 <ByteCoin> TD: I don't see why people should have to run a webserver to get functionality that's achievable by other means
979 2011-10-04 16:15:02 <TD> hmm, fees don't affect tx priority do they?
980 2011-10-04 16:15:16 <TD> ByteCoin: because these other means are getting absurdly over-complex. i mean, new opcodes? that's a chain-splitting change right there
981 2011-10-04 16:15:29 <TD> ByteCoin: i think we have to give up on the idea of magic URLs for anything beyond the simplest cases
982 2011-10-04 16:15:30 <gavinandresen> TD: they don't right now, but they probably should.
983 2011-10-04 16:15:45 <TD> even for the most trivial use case of "I want to pay X BTC to merchant Y" you need a multi-step protocol for any kind of reasonable user experience
984 2011-10-04 16:15:46 shLONG has quit ()
985 2011-10-04 16:15:56 <ByteCoin> TD: Introducing the new secure transaction types is a chain split anyway.
986 2011-10-04 16:16:01 <TD> no it's not
987 2011-10-04 16:16:04 <TD> old clients know how to run new scripts
988 2011-10-04 16:16:07 <TD> that's the whole point of script
989 2011-10-04 16:16:24 <TD> multi-step is a requirement anyway - people don't want to see addresses in their transaction list. people also don't want to label addresses themselves.
990 2011-10-04 16:16:25 shLONG has joined
991 2011-10-04 16:16:37 <TD> people are lazy. they want as easy as credit cards or paypal. click, pay, look at history and see something useful
992 2011-10-04 16:16:48 <TD> so you need to automatically associate a domain or friendly company name with an address
993 2011-10-04 16:17:22 Titeuf_87 has joined
994 2011-10-04 16:17:25 <TD> easiest way to do that in the absence of deep browser integration is challenge the merchant to sign a nonce with the recipient key. that way you can also get a reasonable confirmation message on your second factor
995 2011-10-04 16:17:30 <gavinandresen> Agreed. But that is orthogonal to whether or not OP_EVAL is a good idea, in my opinion
996 2011-10-04 16:18:02 <sipa> OP_EVAL is good for one thing: short static addresses that can be use for safe donations (and maybe a few other things)
997 2011-10-04 16:18:08 cenuij has joined
998 2011-10-04 16:18:09 cenuij has quit (Changing host)
999 2011-10-04 16:18:09 cenuij has joined
1000 2011-10-04 16:18:32 <sipa> however, if OP_EVAL is the only way for initiating a complex transaction, it will be used for all those cases
1001 2011-10-04 16:18:58 Blitzboom has quit (Read error: Connection reset by peer)
1002 2011-10-04 16:19:01 <sipa> where you're better of using at least some form of negotiation
1003 2011-10-04 16:19:07 <TD> like i said, i think it's never a good idea to use a short static address for donations. people would be taken by surprise by the privacy leaks. you see it today because the alternatives are hard. the fix is to make the alternatives easy.
1004 2011-10-04 16:19:22 Blitzboom has joined
1005 2011-10-04 16:19:22 Blitzboom has quit (Changing host)
1006 2011-10-04 16:19:22 Blitzboom has joined
1007 2011-10-04 16:19:28 <TD> charities don't typically reveal their donator lists without at least confirming it's OK with the donators
1008 2011-10-04 16:19:57 Blitzboom_ has joined
1009 2011-10-04 16:19:58 <Optimo> anyone here have any luck ever getting a reply from adsense/admob for their account? seems they are leaving their affiliates high and dry
1010 2011-10-04 16:20:02 <TD> if bitcoin helpfully "unmasked" donators to <whatever>, it'll be the system that gets blamed. especially if there are a bunch of features that encourage this, eg, a "create a secure address" menu item
1011 2011-10-04 16:20:05 <gavinandresen> TD: you're not moved by the transaction fee argument?
1012 2011-10-04 16:20:18 Blitzboom_ has quit (Read error: Connection reset by peer)
1013 2011-10-04 16:20:19 Blitzboom has quit (Read error: Connection reset by peer)
1014 2011-10-04 16:20:34 <TD> in future i see most transactions not being broadcast at all
1015 2011-10-04 16:20:42 <ByteCoin> TD: You're very keen on anonymity. Why not advocate the use of a technique where you can use a constant address but stop people working out which incoming transactions are yours.
1016 2011-10-04 16:20:44 <TD> you only need to broadcast a transaction when you don't trust the payer, so you need the networks support
1017 2011-10-04 16:20:58 <TD> for many types of payment that trust exists and can be used to optimize by just handing around serialized transactions and trusting the sender to not double spend
1018 2011-10-04 16:21:03 <gavinandresen> ??? I negotiate with Amazon.com... and what happens?
1019 2011-10-04 16:21:07 <TD> eg, if i send you coins gavin, you can probably trust that i won't double spend
1020 2011-10-04 16:21:34 <TD> ByteCoin: no, again, don't mix up anonymity with privacy. people want privacy, always. anonymity (ie nobody can figure out who you are if you do bad stuff) is a different thing.
1021 2011-10-04 16:21:42 paul0 has joined
1022 2011-10-04 16:21:53 <gavinandresen> TD: I trust you, but I don't trust that you won't have to restore your wallet from a backup and accidently double-spend....
1023 2011-10-04 16:22:03 <TD> gavinandresen: amazon probably doesn't trust you, so they broadcast the fee tx you provided along with another one that spends it and includes a fee. miners observe they can collect the fee by recursively including the dependents
1024 2011-10-04 16:22:05 <gavinandresen> (shit happens)
1025 2011-10-04 16:22:13 <TD> gavinandresen: that fee can be adjusted according to their risk model
1026 2011-10-04 16:22:23 Blitzboom has joined
1027 2011-10-04 16:22:23 Blitzboom has quit (Changing host)
1028 2011-10-04 16:22:23 Blitzboom has joined
1029 2011-10-04 16:22:38 <TD> gavinandresen: wallet backups shouldn't be usable until you've fully rescanned the chain from the backup point
1030 2011-10-04 16:22:51 <TD> gavinandresen: good software won't allow you to accidentally double-spend, ever. if it does that's a bad bug (users will think bitcoin is broken)
1031 2011-10-04 16:22:54 <TD> i know it can happen today
1032 2011-10-04 16:23:03 MobiusL has quit (Remote host closed the connection)
1033 2011-10-04 16:23:22 <TD> if my family is just circulating money between ourselves though, we probably don't need to ever broadcast the transactions. they become digital IOUs
1034 2011-10-04 16:23:34 <TD> when i eventually want to spend that money on amazon, i might send them 5 or 6 different transactions
1035 2011-10-04 16:23:45 <gavinandresen> TD: if the IOUs aren't in the chain then a rescan won't find them
1036 2011-10-04 16:23:48 <TD> inclusion of a tx is so cheap, miners will include all 6 free transactions in order to get the 7th fee-paying one
1037 2011-10-04 16:24:11 <TD> yeah, that's true. wallet backups have to be well managed i guess
1038 2011-10-04 16:24:13 MobiusL has joined
1039 2011-10-04 16:24:13 MobiusL has quit (Changing host)
1040 2011-10-04 16:24:13 MobiusL has joined
1041 2011-10-04 16:24:15 <TD> like a backup after every spend
1042 2011-10-04 16:24:33 <TD> i guess they'll be automatic in future
1043 2011-10-04 16:24:45 <TD> there was an android client that did that automatically (bad idea without encryption but the user experience was nice)
1044 2011-10-04 16:25:29 ByteCoin has left ()
1045 2011-10-04 16:25:31 <TD> today this scheme wouldn't work btw because fees don't affect block inclusion at all beyond making them eligible, as far as i can tell, and fees aren't calculated recursively.
1046 2011-10-04 16:25:49 <TD> that'd not be a chain-splitting change though. miners that upgraded would have a competitive advantage over those who didn't
1047 2011-10-04 16:25:51 <TD> so it should catch on
1048 2011-10-04 16:26:00 <Diablo-D3> "... that women who have sex with more than 20 guys are much less likely to get married."
1049 2011-10-04 16:26:04 <TD> the result is that buyers never have to include security fees, which is what you'd expect.
1050 2011-10-04 16:26:16 <Diablo-D3> <anon> If a woman is having sex with 20 guys, how the hell could she get her wedding dress on?!
1051 2011-10-04 16:26:59 <gavinandresen> TD: so I'm trying to map out how to get secure wallets SOON. You're proposing developing a protocol for negotiating a transaction starting from something that is transparent and user-friendly.... to me, that sounds like it is going to take quite a while to get right.
1052 2011-10-04 16:27:33 <gavinandresen> ... and a while to get people to switch from "email me your address and I'll send you coins" to "here's the URL to pay to"
1053 2011-10-04 16:28:03 <jrmithdobbs> never time to do it right
1054 2011-10-04 16:28:07 <jrmithdobbs> always time to do it twice
1055 2011-10-04 16:28:25 <TD> wallet security is ever-evolving. secure payments in the face of malware is an unsolved problem. even banks with large R&D departments and expensive two-factor gadgets have not fully solved it. i think we need to be realistic here - a few months difference won't have much impact on this, especially as all solutions proposed require the development of either mobile software or third party services
1056 2011-10-04 16:28:44 <gavinandresen> As I said, I see the OP_EVAL and wallet-secured bitcoin addresses as orthogonal to much-more-user-friendly payment process
1057 2011-10-04 16:29:08 <jrmithdobbs> gavinandresen: if you really want something soon maybe you could help sipa rebase import/export so people can realistically use offline wallets until a proper solution can be implemented?
1058 2011-10-04 16:29:16 <TD> i think you always have to start from the user experience
1059 2011-10-04 16:29:22 <TD> and work backwards to the implementation
1060 2011-10-04 16:29:34 <sipa> jrmithdobbs: import/export will be finished very soon
1061 2011-10-04 16:29:44 <jrmithdobbs> sipa: cool
1062 2011-10-04 16:29:45 <TD> what does the secure wallet functionality look like, to the user? i'd personally want to be able to configure my wallet to say, i always want at least 20 BTC freely available to spend without confirmations
1063 2011-10-04 16:29:50 <TD> more than that, should need confirmation
1064 2011-10-04 16:30:05 <TD> now if i'm a tiny merchant and somebody wants to buy something costing 100 BTC, sending them a secure address doesn't work
1065 2011-10-04 16:30:14 <TD> i'd end up with 100 BTC locked up and not 20 BTC free standing
1066 2011-10-04 16:30:46 <gavinandresen> TD: I sign up with Acme Bitcoin Wallet Security, LTD. I tell them I want a transaction limit of 20 BTC.
1067 2011-10-04 16:31:01 erle- has quit (Quit: CETERVMÂAVTEMÂCENSEOÂFDPÂESSEÂDELENDVM)
1068 2011-10-04 16:31:08 <gavinandresen> TD: (hand-wave) I tell Bitcoin I'm using Acme Bitcoin Wallet Security LTD as my secondary key provider.
1069 2011-10-04 16:31:50 <gavinandresen> Now whenever Bitcoin generates keys, it generates two-factor keys, and all my bitcoin addresses begin with byte \02 instead of
1070 2011-10-04 16:31:52 <gavinandresen> \00
1071 2011-10-04 16:31:56 sacarlson has quit (Ping timeout: 256 seconds)
1072 2011-10-04 16:32:14 <sipa> and how does Acme know what transactions are to you?
1073 2011-10-04 16:32:46 <TD> it doesn't have to, i guess
1074 2011-10-04 16:32:51 <gavinandresen> Acme doesn't care. Bitcoin asks Acme to sign transactions when payments are made from my wallet
1075 2011-10-04 16:32:59 <TD> you'd pass it an incomplete TX and it'd sign it after verifying with your second factor
1076 2011-10-04 16:33:35 <gavinandresen> ... Acme always signs transactions under threshold, if they're over that then it ... calls me or sends me a text message or.....
1077 2011-10-04 16:34:22 <gavinandresen> That doesn't solve the "who do you think you are paying" problem, but it does solve the "my wallet was stolen and my passphrase compromised" problem
1078 2011-10-04 16:34:31 DontMindMe has joined
1079 2011-10-04 16:34:34 mithridates has joined
1080 2011-10-04 16:34:54 <TD> the alternative is you give payers a normal, single key address. once the payment is received your wallet automatically splits it for you.
1081 2011-10-04 16:34:57 <sipa> ok, so you need a develop a protocol for "sign me this partial tx, please"
1082 2011-10-04 16:35:02 <TD> i mean, makes it a 2-factor coin
1083 2011-10-04 16:35:29 <gavinandresen> TD: I don't like doubling the number of transactions on the network, but yes, that would work too.
1084 2011-10-04 16:36:08 <gavinandresen> Actually, I take it back-- if your wallet was stolen and your passphrase compromised then the thief can intercept the coins sent to you.
1085 2011-10-04 16:36:26 <mithridates> I was just reading about git, have you considered adding a network based git app to your program to take care of changes and give the chance to recover your system?
1086 2011-10-04 16:36:33 <gavinandresen> (it'll be a double-spend race)
1087 2011-10-04 16:36:59 <mithridates> I don't know if it's possible or not, do you think it's possible?
1088 2011-10-04 16:38:50 cenuij has quit (Remote host closed the connection)
1089 2011-10-04 16:38:54 c00w has joined
1090 2011-10-04 16:39:22 cenuij has joined
1091 2011-10-04 16:40:29 <gavinandresen> TD: again, I'm pushing for new 'standard' transactions now to lay the groundwork for any and all of the above in the next few months.
1092 2011-10-04 16:40:46 <gavinandresen> ... but that means we need to figure out what the transactions should look like.
1093 2011-10-04 16:42:25 <TD> gavinandresen: if they are broadcast, yes :-)
1094 2011-10-04 16:42:30 <TD> yeah
1095 2011-10-04 16:42:38 <TD> i know. this is a useful discussion. thanks for starting it
1096 2011-10-04 16:42:47 <TD> i have a feeling i'm on the verge of understanding CODESEPARATOR by the way
1097 2011-10-04 16:42:55 <TD> need to play about with it a bit and try designing a protocol that uses it
1098 2011-10-04 16:42:56 Zarutian has joined
1099 2011-10-04 16:43:03 <TD> but i vaguely feel i see where satoshi was going with it
1100 2011-10-04 16:43:20 <gavinandresen> TD: cool!
1101 2011-10-04 16:44:19 <TD> ok, let's consider the person to person case when the attacker can attack once (ie, steal a wallet) but does not have an ongoing compromise of the host. we wish to arrange everything over email
1102 2011-10-04 16:44:21 gjs278 has quit (Remote host closed the connection)
1103 2011-10-04 16:44:44 <TD> i was mentioning to Simon Barber the other day, maybe the URL scheme is going to run out of steam faster than we think. a new file type is not any harder for most platforms to handle, but it's more flexible
1104 2011-10-04 16:45:13 <TD> like i want a payment, so i select "Request payment" and fill out the details (bitcoin picks a key for me). it generates a file that i drag/drop onto an email
1105 2011-10-04 16:45:29 <TD> this works for web mail these days too, in any modern browser (you can drag/drop attachments onto emails you are composing)
1106 2011-10-04 16:45:49 <sipa> anything like the payment descriptor format i suggested?
1107 2011-10-04 16:45:52 <TD> the other side opens the attachment, clicks confirm to pay, and is asked to drag a .bitcoin file back to the email (perhaps the original .bitcoin file stated it was expecting a file back)
1108 2011-10-04 16:45:56 <TD> that contains a serialized tx
1109 2011-10-04 16:46:16 <TD> well kind of. i don't think representing binary data with text is great, i suggested to simon using a serialized protocol buffer.
1110 2011-10-04 16:46:17 osmosis_ has quit (Quit: Leaving)
1111 2011-10-04 16:46:24 <TD> that way you can just serialize a CTransaction and stuff it into the file
1112 2011-10-04 16:46:27 sacarlson has joined
1113 2011-10-04 16:46:33 <sipa> the actual format can differ, of course
1114 2011-10-04 16:46:36 <TD> sure
1115 2011-10-04 16:46:36 osmosis has joined
1116 2011-10-04 16:47:01 <TD> the .bitcoin file, once registered by an app, can be generic - it can contain instructions of arbitrary complexity and doesn't have to be done entirely with key=value pairs. also note that some older browsers have very brutal URL length restrictions
1117 2011-10-04 16:47:09 <TD> whereas a file can be of any size
1118 2011-10-04 16:47:17 gjs278 has joined
1119 2011-10-04 16:47:26 <TD> so it can also trigger more complex negotiations, like including a list of acceptable dispute mediators the merchant has, things like that.
1120 2011-10-04 16:48:20 <TD> from the users perspective, it's just files, and i think we can assume most users have figured out files at a basic level by now (drag/drop helps). most of the time it'd still be URL triggered I guess, as downloading a .bitcoin file just to open your client for amazon purchases is a bit ugly (leaves the files lying around, maybe). but the URL could just point to a .bitcoin file that the app itself downloads.
1121 2011-10-04 16:48:45 <TD> so yeah, kind of a payment descriptor indeed
1122 2011-10-04 16:48:52 mosimo has joined
1123 2011-10-04 16:49:07 <TD> though probably not based on providing arbitrary scripts you have to pattern match. that's kind of awkward :)
1124 2011-10-04 16:49:34 <sipa> the requester of the payment determines what kind of txout script is used
1125 2011-10-04 16:49:35 laetus has joined
1126 2011-10-04 16:49:47 <sipa> he doesn't need to support anything but the script he requested himself
1127 2011-10-04 16:49:49 ThomasV has joined
1128 2011-10-04 16:50:36 <TD> yeah, but the payers app needs to understand what exactly is happening, so it has to pattern match on the txout script. it'd be better to just identify different kinds of thing with a string
1129 2011-10-04 16:50:46 <TD> like "org.bitcoin.payment.basic"
1130 2011-10-04 16:50:53 <sipa> why does it need to know what the txout script does?
1131 2011-10-04 16:50:55 <TD> or "org.bitcoin.payment.mediated"
1132 2011-10-04 16:51:00 <sipa> ah, right
1133 2011-10-04 16:51:02 <TD> how does it explain to the user what it's about to do otherwise?
1134 2011-10-04 16:51:17 <gavinandresen> ... which gets back to OP_EVAL. The payment requester can just ask to be paid to hash(script)
1135 2011-10-04 16:51:34 <sipa> in which case the payer has absolutely no idea what he's doing
1136 2011-10-04 16:51:57 <TD> yeah. if the user doesn't have to care at all (eg, two-key output) fine. if it's anything more complicated (mediated tx) it won't work.
1137 2011-10-04 16:52:07 <gavinandresen> The payer could still connect to some verification URL to solve the identity problem
1138 2011-10-04 16:52:21 <TD> i guess you could have both
1139 2011-10-04 16:52:27 Turingi has joined
1140 2011-10-04 16:54:46 <gavinandresen> I think I'm lost again. What problem(s) are being solved?
1141 2011-10-04 16:54:57 Kolky has joined
1142 2011-10-04 16:55:17 <gavinandresen> attacker can attack once (steal a wallet) but your machine isn't compromised?
1143 2011-10-04 16:56:17 <gavinandresen> ... but you're getting a payment request via an insecure, there-might-be-a-mitm channel like email?
1144 2011-10-04 16:58:29 <TD> sipa: http://pastebin.com/3eW1etTC
1145 2011-10-04 16:58:32 <TD> sipa: something like that
1146 2011-10-04 16:59:03 <TD> gavinandresen: for the musing i just posted, yes, your wallet was stolen (once) and you don't know it. but the malware is either gone or not smart enough to be doing ongoing interception/rewriting of traffic.
1147 2011-10-04 16:59:27 <TD> gavinandresen: if you have a virus that you assume is arbitrarily powerful, any instructions you send can be rewritten. that's super hard and i don't know of any banks in the world that try to solve that one today
1148 2011-10-04 16:59:33 <jrmithdobbs> that's a pretty contrived scenario
1149 2011-10-04 16:59:50 <TD> even the ones that have bank specific two-factor authentication hardly protect you against a virus that knows how to spot IBAN/SWIFT codes in web pages or email
1150 2011-10-04 16:59:57 <TD> jrmithdobbs: it's the exact scenario seen so far
1151 2011-10-04 17:00:07 <TD> jrmithdobbs: viruses that just look for wallet.dat files and upload them to some dropbox
1152 2011-10-04 17:00:19 <jrmithdobbs> ya but they do it every time they start up
1153 2011-10-04 17:00:24 <jrmithdobbs> not once and delete themselves
1154 2011-10-04 17:00:25 shDong has joined
1155 2011-10-04 17:00:25 <gavinandresen> We should be able to do better than banks
1156 2011-10-04 17:00:35 <TD> jrmithdobbs: sure, but at some point an AV scanner could delete them for you
1157 2011-10-04 17:00:41 <TD> (or another virus, lol)
1158 2011-10-04 17:00:45 <jrmithdobbs> the "machine not still compromised" part is what I was calling contrived, sorry that wasn't clear
1159 2011-10-04 17:00:54 <TD> machines do get cleaned up
1160 2011-10-04 17:01:11 <jrmithdobbs> no, people just think they cleaned them up, in my experience
1161 2011-10-04 17:01:13 <jrmithdobbs> ;p
1162 2011-10-04 17:01:13 <TD> gavinandresen: agreed. but these threat models are complicated
1163 2011-10-04 17:01:32 <TD> the .bitcoin file format solves other issues too though
1164 2011-10-04 17:01:34 <TD> not just security
1165 2011-10-04 17:01:46 <TD> i think it's worth taking the time to think through as much as possible in advance
1166 2011-10-04 17:01:49 <gavinandresen> TD: agreed. Which is why I want to try to solve a little tiny piece of the puzzle before trying to solve the whole thing
1167 2011-10-04 17:02:23 <gavinandresen> TD: ... and it seems to me multisignature transactions will be a very useful tool for whatever the final solution is
1168 2011-10-04 17:02:37 <TD> yes definitely
1169 2011-10-04 17:03:14 <sipa> if you're going to enable OP_DROP as a way for initiating complex transactions, there should be a way for doing them directly at the same time, imho
1170 2011-10-04 17:03:15 <jrmithdobbs> I think you're all slightly dillusional if you think normal users are actually going to use the multi-sig stuff to secure their transactions (which, to my understanding, is the target audience you're trying to protect with these changes)
1171 2011-10-04 17:03:20 shLONG has quit (Ping timeout: 248 seconds)
1172 2011-10-04 17:03:38 <TD> jrmithdobbs: i think the UX can be made sufficiently nice.
1173 2011-10-04 17:03:40 <sipa> jrmithdobbs: all depends on how hard it is for the ordinary user
1174 2011-10-04 17:04:07 <jrmithdobbs> TD: still requires multiple bitcoin instances on multiple independent machines or it's no better than two factor auth on the wallet crypto
1175 2011-10-04 17:04:14 <TD> jrmithdobbs: if you have an android phone the setup process can be relatively easy. a few clicks, a few taps, done.
1176 2011-10-04 17:04:25 <jrmithdobbs> and *that* is the hard part, convincing poperly they need to run two machines to send one transaction? Don't see it flying.
1177 2011-10-04 17:04:33 <gavinandresen> The UI could be as easy as: Enter URL for wallet protection service:
1178 2011-10-04 17:04:34 <TD> it's also worth considering the N-factor case (business partners who want to secure a larger pool of coins)
1179 2011-10-04 17:04:50 <jrmithdobbs> does anyone have adoption numbers for OTP/sms auth adoption with paypal/banks etc?
1180 2011-10-04 17:05:00 <jrmithdobbs> for non-business accounts?
1181 2011-10-04 17:05:05 <TD> i have the stats for google. they are confidential unfortunately.
1182 2011-10-04 17:05:29 <TD> the comparison is flawed though because enabling OTP for your gmail account is quite different to using it for payments
1183 2011-10-04 17:05:33 <jrmithdobbs> they're fairly low, though, are they not? (understand if you can't comment)
1184 2011-10-04 17:05:39 <TD> fwiw my bank (UBS) requires OTP for both login and wires
1185 2011-10-04 17:06:06 <jrmithdobbs> but ya, it's not a good comparisson
1186 2011-10-04 17:06:11 <TD> my UK bank does the same thing
1187 2011-10-04 17:06:18 <TD> outside the USA 2-factor auth is very common
1188 2011-10-04 17:06:29 <jrmithdobbs> inside it's almost unheardo f
1189 2011-10-04 17:06:29 <TD> i guess because it's an extension of chip/pin, which was deployed throughout europe
1190 2011-10-04 17:06:37 <jrmithdobbs> ya
1191 2011-10-04 17:06:45 <sipa> what is OTP exactly?
1192 2011-10-04 17:06:48 <TD> yes. the system the banks use is called CAP. it's an extension of the EMV system
1193 2011-10-04 17:06:51 <TD> OTP = one time password
1194 2011-10-04 17:06:54 <jrmithdobbs> one time password
1195 2011-10-04 17:07:02 <sipa> yes, i know the abbreviation
1196 2011-10-04 17:07:06 <TD> actually for bank wires they require signing the destination account number
1197 2011-10-04 17:07:08 <sipa> but what does it mean for the customer?
1198 2011-10-04 17:07:08 <TD> OTP is just for login
1199 2011-10-04 17:07:16 <TD> for UBS it works like this
1200 2011-10-04 17:07:23 <TD> when you sign in to your ebanking, they give you a 6 digit code
1201 2011-10-04 17:07:32 <TD> you power on a calculator device, enter your cards PIN
1202 2011-10-04 17:07:34 <TD> then the 6 digit code
1203 2011-10-04 17:07:37 <jrmithdobbs> sipa: eg, BOA has two options, one is a fob, the other is a sms option where it sends the code via sms on login attempt
1204 2011-10-04 17:07:40 <TD> it signs the code and you type in the response
1205 2011-10-04 17:07:45 <sipa> oh, that
1206 2011-10-04 17:07:50 <sipa> yes we have that here as well
1207 2011-10-04 17:08:02 <sipa> i'd have called it challenge/response
1208 2011-10-04 17:08:07 <jrmithdobbs> it's not CR though
1209 2011-10-04 17:08:10 <jrmithdobbs> there's no C
1210 2011-10-04 17:08:10 <TD> to wire money you type in some digits of the destination account number
1211 2011-10-04 17:08:22 <TD> right. competent implementations are. UBS is competent in retail banking
1212 2011-10-04 17:08:25 <TD> (investment banking is another matter)
1213 2011-10-04 17:08:42 <TD> btw all card payments are 2-factor here as well, of course
1214 2011-10-04 17:08:44 <sipa> the 6 digit code is a challenge, no?
1215 2011-10-04 17:08:57 <TD> to pay you enter your card, enter your pin, see the payment details, confirm
1216 2011-10-04 17:09:02 <jrmithdobbs> oh, the UBS on is C/R ya
1217 2011-10-04 17:09:18 <jrmithdobbs> the BOA one is not C/R it's more traditional sync'ed seeds for otp
1218 2011-10-04 17:09:24 <jrmithdobbs> whichi s gay
1219 2011-10-04 17:09:28 <jrmithdobbs> but all they offer
1220 2011-10-04 17:09:49 <TD> american banks have it "harder" because they never deployed the EMV infrastructure that the whole thing relies on
1221 2011-10-04 17:09:57 <TD> do US credit cards even have chips at all?
1222 2011-10-04 17:10:03 <jrmithdobbs> very few
1223 2011-10-04 17:10:06 <jrmithdobbs> VERY
1224 2011-10-04 17:10:12 <sipa> what?
1225 2011-10-04 17:10:31 <jrmithdobbs> and even fewer payment processors can even use the things
1226 2011-10-04 17:10:45 <jrmithdobbs> because the regulation to try and require it (back in the 90s iirc?) got killed
1227 2011-10-04 17:10:52 <sipa> in belgium you can't pay with chipless cards anymore
1228 2011-10-04 17:10:53 <jrmithdobbs> so noone ever built it out
1229 2011-10-04 17:10:59 <TD> yes
1230 2011-10-04 17:11:13 <TD> USA is extremely backwards with respect to banking security
1231 2011-10-04 17:11:13 <jrmithdobbs> and now the shit's been broken so rallying for them to require it would just be stupid
1232 2011-10-04 17:11:21 <TD> read krebsonsecurity.com for a never ending stream of horror stories
1233 2011-10-04 17:11:30 <jrmithdobbs> it's fucking horrendously scarey
1234 2011-10-04 17:11:34 <TD> some banks are trying to claim in court that secret question or browser fingerprinting is an adequate substitute
1235 2011-10-04 17:11:40 <TD> it should be very easy for bitcoin to beat the banks in the USA
1236 2011-10-04 17:11:42 <jrmithdobbs> I'm waiting for some little shit like lulzsec to come along and wake them up
1237 2011-10-04 17:11:44 <TD> harder in europe, but still possible
1238 2011-10-04 17:11:48 <jrmithdobbs> because it's seriously going to take something of that nature
1239 2011-10-04 17:11:58 <TD> afaik EMV is not exactly broken ?
1240 2011-10-04 17:12:03 <TD> it was breached and repaired a few times, iirc
1241 2011-10-04 17:12:13 <jrmithdobbs> it's broken enough that it shouldn't advocated for new deployment imho
1242 2011-10-04 17:12:21 <TD> what are you thinking of, precisely?
1243 2011-10-04 17:12:46 <jrmithdobbs> weren't there keys for processing that were leaked or something like that?
1244 2011-10-04 17:13:04 <jrmithdobbs> i'm honestly not that familiar with c/p since amerikkkan
1245 2011-10-04 17:13:07 casascius has quit (Ping timeout: 252 seconds)
1246 2011-10-04 17:13:12 <TD> no, i don't think there were any EMV keys leaks
1247 2011-10-04 17:13:20 <TD> there were a few interesting protocol attacks, but they can be detected by the banks backend systems
1248 2011-10-04 17:13:47 <TD> a few of the terminal devices turned out to be hopelessly insecure. at one point someone discovered they were being shipped with skimmers direct from the chinese factory
1249 2011-10-04 17:14:01 <TD> the skimmers weren't able to break EMV but they could steal the magstripe data for cloning and use in countries where EMV wasn't deployed
1250 2011-10-04 17:14:03 <TD> (like the usa)
1251 2011-10-04 17:14:12 mithridates has quit (Ping timeout: 252 seconds)
1252 2011-10-04 17:14:34 <TD> at any rate, it works well enough i doubt any new system will get deployed.
1253 2011-10-04 17:14:41 noagendamarket has joined
1254 2011-10-04 17:15:37 <jrmithdobbs> TD: think this is the paper i was thinking of
1255 2011-10-04 17:15:42 <jrmithdobbs> https://docs.google.com/viewer?url=http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf
1256 2011-10-04 17:15:52 <jrmithdobbs> but i've not got time to read it atm to confirm ;p
1257 2011-10-04 17:16:45 <TD> i read it some time ago
1258 2011-10-04 17:16:52 <TD> ross anderson likes melodrama
1259 2011-10-04 17:16:54 <jrmithdobbs> think it's a bunch of MITM stuff for c/p specifically not the magstripe thing you're talking about
1260 2011-10-04 17:16:58 <TD> the paper itself points out several solutions
1261 2011-10-04 17:17:13 shDong has quit ()
1262 2011-10-04 17:17:16 <TD> it's not permanently broken. his points about bad process and too much spec secrecy are well made though
1263 2011-10-04 17:17:33 shLONG has joined
1264 2011-10-04 17:17:37 <TD> EMV is so complicated it makes bitcoin look like hello world
1265 2011-10-04 17:17:47 <TD> i think bitcoins security argument can be well developed, given time
1266 2011-10-04 17:17:54 <jrmithdobbs> i think we need something similar with updated (larger key) crypto and an open standard before trying to advocate for it in the states
1267 2011-10-04 17:18:42 <jrmithdobbs> but then, the banks are the second largest (iirc) lobby in the country so anything that makes them actually do something useful will never get passed anyways
1268 2011-10-04 17:19:04 <TD> ok, time to go home. thanks for the useful discussion.
1269 2011-10-04 17:19:16 <sipa> cya
1270 2011-10-04 17:19:31 TD is now known as TD[gone]
1271 2011-10-04 17:19:58 <gavinandresen> sipa: can you enlighten me on recovering public keys from signatures?
1272 2011-10-04 17:20:24 <gavinandresen> sipa: ... to recover securely, I need to know a hash of the public key?
1273 2011-10-04 17:20:48 <gavinandresen> (and 2 bits so I know which of 4 possible keys it is)?
1274 2011-10-04 17:21:19 <sipa> signature + message hash + 2 bits
1275 2011-10-04 17:21:40 <gavinandresen> message hash or public key hash?
1276 2011-10-04 17:21:45 <sipa> message hash
1277 2011-10-04 17:21:58 <sipa> although in 99.999..% of the cases 1 bit suffices, and that can obviously easily be brute-forced
1278 2011-10-04 17:22:38 <gavinandresen> Did you see my message on the forums about having CHECKSIG inside OP_EVAL do key recovery?
1279 2011-10-04 17:22:56 dvide has joined
1280 2011-10-04 17:23:03 <sipa> yes - it has the advantage of enabling better signature schemes
1281 2011-10-04 17:23:17 <sipa> but i don't like the fact that it will require OP_EVAL to use the new feature
1282 2011-10-04 17:23:25 <gavinandresen> I'm really liking OP_EVAL, even though it is way-wicked-scary at first glance
1283 2011-10-04 17:24:00 <sipa> i like it because of its possibilities, but one shouldn't see it as "all future transactions will eventually be OP_EVAL-based"
1284 2011-10-04 17:24:07 <sipa> that has serious downsides as well
1285 2011-10-04 17:24:14 <gavinandresen> how so?
1286 2011-10-04 17:24:43 <sipa> more data in the chain, more things the client needs to remember, less transparent
1287 2011-10-04 17:24:54 <sipa> (less transparant can be an advantage as well, obviously)
1288 2011-10-04 17:25:10 <gavinandresen> If complicated scripts are common, then it will work out to be LESS data in the chain, actually
1289 2011-10-04 17:25:17 <sipa> how so?
1290 2011-10-04 17:25:46 <gavinandresen> If you have a complicated "something OR something else" then OP_EVAL lets you put just one of the something's scripts in the chain
1291 2011-10-04 17:25:52 <gavinandresen> (when it is spent)
1292 2011-10-04 17:26:50 <luke-jr> just wondering, but will OP_EVAL work with non-sig based stuff?
1293 2011-10-04 17:26:58 <sipa> hmmm; you mean a "(scripthash XXXX) or (scripthash YYYY)"-like script?
1294 2011-10-04 17:27:03 <luke-jr> ie, if you put a couple of booleans on the stack, can you do &&/|| with them?
1295 2011-10-04 17:27:17 <sipa> yes
1296 2011-10-04 17:27:23 <gavinandresen> luke-jr: wouldn't be standard transactions, but yeah....
1297 2011-10-04 17:27:48 <luke-jr> would be nice to get some way to check block height in there too
1298 2011-10-04 17:28:07 <luke-jr> so one could say after block X, an additional key becomes valid
1299 2011-10-04 17:28:25 <sipa> gavinandresen: i didn't think of that, but yes, it seems possible that it does decrease chain size
1300 2011-10-04 17:28:36 <gmaxwell> But then people write txn like height<x or doom. and then the txn is lost in reorgs.
1301 2011-10-04 17:28:46 <gavinandresen> sipa: Yup. Imagine a new standard scrpt... define H= as DUP HASH160 <hash> EQUAL
1302 2011-10-04 17:29:16 <gavinandresen> ... and do H= H= OR VERIFY to make sure one of the scripts is valid. then just EVAL to evaluate it.
1303 2011-10-04 17:30:01 <gavinandresen> Assuming both scripts are big, long, hairy, lots-of-public-keys-or-something then that is less data in the chain
1304 2011-10-04 17:30:21 <luke-jr> gmaxwell: reorgs shouldn't be large
1305 2011-10-04 17:30:36 <luke-jr> gmaxwell: perhaps require such a rule to be fuzzy. ie, +/- 6 blocks
1306 2011-10-04 17:31:01 <luke-jr> so a transaction has 6 blocks to get included again if it got into an invalid block
1307 2011-10-04 17:31:02 <sipa> gavinandresen: still, in the more complex contract cases there may be more than one person who can start a transaction based on a certain output
1308 2011-10-04 17:31:38 <gmaxwell> sipa: alsoâ Consider that the most expensive space in the long term is the online space needed for not yet confirmed txn. OP_EVAL puts most of the disk usage in the inputs, which could be archived because you don't need them once you've validated them.
1309 2011-10-04 17:31:42 <sipa> gavinandresen: in those cases, you'll need to show these people the actual script being signed, so they know you are including them
1310 2011-10-04 17:31:48 <gavinandresen> does using EVAL change that? EVAL is just shorthand for "some complicated script"
1311 2011-10-04 17:32:07 <gavinandresen> ... and if you need to show them, you show then the hash and the script, and they can verify....
1312 2011-10-04 17:32:26 * luke-jr once again reminds that &&/|| key scripts could be replaced with a split-up private key :p
1313 2011-10-04 17:32:29 <gmaxwell> sipa: you'd need another 'address type' for those contracts, yesâ but at least it doesn't have to go in the chain.
1314 2011-10-04 17:32:59 <sipa> if the tx script is just "A or B", people who are B can immediately see they can spend it
1315 2011-10-04 17:33:23 <sipa> but that's probably not an important problem, if negotiations for txouts become commonplace anyway
1316 2011-10-04 17:34:00 <sipa> but i must admit it has more advantages than what i believed
1317 2011-10-04 17:34:09 <gavinandresen> I'm not sure what a standard wallet should do with an A or B transaction if the wallet only knows about either A or B... dangerous to include it in your balance because it can be spent out from under you at any time
1318 2011-10-04 17:34:18 <sipa> agree
1319 2011-10-04 17:34:43 <luke-jr> gavinandresen: that's true even with the simplest transaction
1320 2011-10-04 17:34:51 <luke-jr> you never know who has the key besides you ;)
1321 2011-10-04 17:35:02 <sipa> if you generated it yourself, you do know
1322 2011-10-04 17:35:10 <sipa> otherwise you are correct
1323 2011-10-04 17:35:10 <gavinandresen> luke-jr: there is a deep assumption that your private keys are yours.
1324 2011-10-04 17:35:32 <gavinandresen> ... relaxed a little bit with sipa's patches to detect when they've been spent-out-from-under-you....
1325 2011-10-04 17:35:51 <gmaxwell> AorB is pretty explicitly saying one is not on the same host at leastâ otherwise why bother?
1326 2011-10-04 17:36:06 <sipa> mental note: rewrite rejectedtx pull request
1327 2011-10-04 17:36:47 <gavinandresen> The A or B case I care about is where A is a 'working' key in my day-to-day-use wallet and B is a deterministic emergency-I-lost-my-wallet key where only the public key is in the day-to-day wallet
1328 2011-10-04 17:36:56 <gavinandresen> ... but in that case the client would know about both A and B
1329 2011-10-04 17:37:48 <gavinandresen> sipa: what's up with key import/export and the rejectedtx pulls? I'm a little nervous about pulling one without the other....
1330 2011-10-04 17:37:58 <sipa> rejectedtx is horribly outdated
1331 2011-10-04 17:38:56 <luke-jr> gavinandresen: how about those 25 branches I sent to the ML? :P
1332 2011-10-04 17:39:00 <gavinandresen> How big is the risk of pulling import/export keys without rejectedtx?
1333 2011-10-04 17:39:10 * luke-jr doesn't see why there'd be any risk
1334 2011-10-04 17:39:32 <gmaxwell> Import.. sigh.. I noticed a thread on the forum "Hey, how do I generate 1000 addresses?" and a bunch of people jumped on to point them to a webpage that makes import wallet keys... It wasn't until several posts down did someone suggest for `seq 1000`; do bitcoind getnewaddress ;done ...
1335 2011-10-04 17:39:55 <luke-jr> gmaxwell: for i in {1..1000}; do ⦠done
1336 2011-10-04 17:39:58 <luke-jr> :p
1337 2011-10-04 17:40:00 <sipa> the problem case is: spending a coin with a client that hasn't heard it is already spent
1338 2011-10-04 17:40:15 <gavinandresen> ... which gets easier if you've been moving private keys around
1339 2011-10-04 17:40:21 <sipa> that can happen because it doesn't have the full block chain, because it is offline, or just because it's too fast
1340 2011-10-04 17:40:41 <luke-jr> i c
1341 2011-10-04 17:40:53 <luke-jr> why not flag exported keys as "shared" or something
1342 2011-10-04 17:41:05 <midnightmagic> er.. would just like to say thanks for having these discussions in here rather than somewhere else.
1343 2011-10-04 17:41:11 <gmaxwell> Because of the maturity rules coin selection will often pick the same inputs between multiple clients _even_ if the txn values differ, if you don't have that many inputs available.
1344 2011-10-04 17:41:16 <luke-jr> midnightmagic: O.o?
1345 2011-10-04 17:41:47 <sipa> luke-jr: that's certainly a possibility
1346 2011-10-04 17:41:52 <sipa> and it's useful, i think
1347 2011-10-04 17:41:58 <luke-jr> imported, too
1348 2011-10-04 17:41:59 <sipa> but it doesn't solve the problem
1349 2011-10-04 17:42:07 <gavinandresen> I think sipa has the right fix-- reject transactions as orphaned if they don't confirm after a long time (that's what rejectetx does, right?)
1350 2011-10-04 17:42:25 * luke-jr would think it rejects ones that are detected as conflicts
1351 2011-10-04 17:42:27 <gmaxwell> luke-jr: ironically, avoiding spending from them isn't the case you want for newly imported keys oftenâ e.g. If bob gives you a bitcoin gift card you want to spend that sucker as soon as possible.
1352 2011-10-04 17:42:34 <gavinandresen> ... so you can shoot yourself in the foot, but it will eventually heal
1353 2011-10-04 17:42:46 <sipa> gmaxwell: no, it marks wallet transactions inactive if they conflict with a transaction in the block chain
1354 2011-10-04 17:42:49 <midnightmagic> luke-jr: it means i don't have to look far to find reasoning/rationale. i think that is an enormous problem in most open-source projects: the reasoning behind changes is usually lost, which sometimes erects insurmountable barriers to future changes.
1355 2011-10-04 17:42:52 <sipa> eh, gavinandresen
1356 2011-10-04 17:42:57 <luke-jr> gmaxwell: true. perhaps import needs some options ;0
1357 2011-10-04 17:43:15 <gmaxwell> sipa: yea, I was about to respond to gavinandresen and say that would be better.
1358 2011-10-04 17:43:16 <luke-jr> ie, "import as a shared key", "import and automatically resend anything on this address to a private key", etc
1359 2011-10-04 17:43:40 <sipa> or even "import without private key"
1360 2011-10-04 17:43:46 tower has quit (Ping timeout: 258 seconds)
1361 2011-10-04 17:43:50 <sipa> so it just tracks, but is unable to spend
1362 2011-10-04 17:44:02 <luke-jr> sipa: well, that'd be importing a public key then, no?
1363 2011-10-04 17:44:05 <sipa> yes
1364 2011-10-04 17:44:12 <sipa> or even just an address
1365 2011-10-04 17:44:26 <cuqa> bitcoin pool claims they had an issue because the wallet would have been too big aka too much transactions and therefore they were not able to solve another block
1366 2011-10-04 17:44:46 <cuqa> what do you think about that? they now have ~22.5 million shares round
1367 2011-10-04 17:44:49 <luke-jr> cuqa: sounds like bs from a pool known to associate with thiefs
1368 2011-10-04 17:45:11 <sipa> gavinandresen: but afterwards there was a discussion
1369 2011-10-04 17:45:15 <luke-jr> cuqa: sounds like they're stealing the blocks :P
1370 2011-10-04 17:45:21 <sipa> gavinandresen: which resulted in the idea of negative confirmations
1371 2011-10-04 17:45:24 <cuqa> yea for me too
1372 2011-10-04 17:45:41 <luke-jr> sipa: interesting
1373 2011-10-04 17:45:48 <cuqa> strange behaviour, also that they paid the prior block with 10 million shares from own pocket
1374 2011-10-04 17:45:57 <luke-jr> cuqa: why?
1375 2011-10-04 17:46:01 <gmaxwell> sipa: how many blocks impossible is your txn? very neat.
1376 2011-10-04 17:46:03 <cuqa> i mean either they are the biggest economic failures on this planet
1377 2011-10-04 17:46:11 <cuqa> or they rip ppl off
1378 2011-10-04 17:46:12 <luke-jr> cuqa: join #Eligius ;)
1379 2011-10-04 17:46:16 ThomasV has quit (Ping timeout: 244 seconds)
1380 2011-10-04 17:46:19 <luke-jr> cuqa: we don't ripoff
1381 2011-10-04 17:46:35 <sipa> gmaxwell: so a transaction in the wallet which depends on a transaction with N confirmations, itself has -N confirmations
1382 2011-10-04 17:46:57 <sipa> and -1 confirmation should be enough to mark a transaction inactive
1383 2011-10-04 17:47:03 <luke-jr> sipa: you mean is blocked by�
1384 2011-10-04 17:47:05 vorlov has quit (Quit: vorlov)
1385 2011-10-04 17:47:14 <sipa> luke-jr: ehr, yes, of course
1386 2011-10-04 17:47:35 Workbench has joined
1387 2011-10-04 17:47:41 <sipa> depends on a txout which is consumed by another N-confirmed tx, means -N confirmations
1388 2011-10-04 17:48:14 <luke-jr> I think expiration is a good idea too
1389 2011-10-04 17:48:25 <sipa> plus i believe there was the idea of a waiting time
1390 2011-10-04 17:48:38 <sipa> and if that becomes too large, mark the transaction inactive as well
1391 2011-10-04 17:48:42 <luke-jr> provided clients have a way to "refresh" the transaction
1392 2011-10-04 17:49:21 <luke-jr> maybe we'll see clients that send without a fee, then resend with a slightly higher fee, etc ;)
1393 2011-10-04 17:49:22 tower has joined
1394 2011-10-04 17:50:32 <sipa> that's quite dangerous
1395 2011-10-04 17:50:47 <sipa> actually, as long as they share a common input, it isn't
1396 2011-10-04 17:51:04 <wumpus> and as long as you handle time correctly
1397 2011-10-04 17:51:25 <sipa> and as long as peers don't refuse to forward it because of conflictingness(?_
1398 2011-10-04 17:51:42 <luke-jr> sipa: that's why we need some kind of expiration
1399 2011-10-04 17:51:48 <wumpus> otherwise the sending client can think that the tranaction timed out, but it didn't, so it sends it again with a higher fee and gets included twice (?)
1400 2011-10-04 17:52:09 <luke-jr> wumpus: the resend would have to be a "double spend"
1401 2011-10-04 17:52:13 <wumpus> maybe base expiration on block# instead of time, at least eeryone agrees on that
1402 2011-10-04 17:52:20 <sipa> well if the second attempts consumes the same input, there can never be more than one in the block chain
1403 2011-10-04 17:53:12 <wumpus> (or, no even that isn't safe with orphaned chains etc)
1404 2011-10-04 17:54:17 <wumpus> yes regarding it as a double spend would work
1405 2011-10-04 17:54:30 <gmaxwell> I liked the proposed feature of conflict notifications... then it would be safer to forward new conflicting txn.
1406 2011-10-04 17:55:11 <gmaxwell> E.g. you hear a conflict, you forward a conflict notice.. and then you wait until the next block and if the chain hasn't mooted the issue you then also forward the conflict.
1407 2011-10-04 17:55:22 <luke-jr> how about not checking the sigs on relayed txns?
1408 2011-10-04 17:55:45 <luke-jr> let miners sort out doublespends
1409 2011-10-04 17:56:07 <luke-jr> err
1410 2011-10-04 17:56:10 <luke-jr> not checking the inputs
1411 2011-10-04 17:56:20 <gmaxwell> luke-jr: miners sort out still increases the risk of seeing 0,1 confirmed txn that won't survive.
1412 2011-10-04 17:56:58 <luke-jr> gmaxwell: how about only checking inputs against the blockchain?
1413 2011-10-04 17:57:06 <luke-jr> ie, forward double spends against 0-confirmed txns
1414 2011-10-04 17:57:11 <Diablo-D3> gmaxwell: heh guess what, I think I magically have zero rejects now
1415 2011-10-04 17:58:13 <luke-jr> I have that too
1416 2011-10-04 17:58:20 <luke-jr> for a few minutes after I start poclbm
1417 2011-10-04 17:58:21 <luke-jr> <.<
1418 2011-10-04 17:58:24 <Diablo-D3> lol
1419 2011-10-04 17:58:24 <gmaxwell> luke-jr: You can get a 1txn confirmed that won't survive if two miners make different choices and both mine blocks and one orphans another.
1420 2011-10-04 17:58:28 <Diablo-D3> well 839 shares thus far
1421 2011-10-04 17:58:31 <Diablo-D3> and no reject
1422 2011-10-04 17:58:45 <luke-jr> gmaxwell: that's possible already
1423 2011-10-04 17:59:05 <luke-jr> gmaxwell: it's LESS likely if we relay 0-confirmation double spends, since miners will probably pick the same one
1424 2011-10-04 17:59:52 MimeNarrator has quit ()
1425 2011-10-04 18:00:09 <gmaxwell> It's possible but its unlikely because only one txn usually gets further than one hop from the origin.
1426 2011-10-04 18:01:08 <luke-jr> I wasn't aware someone tried it ;)
1427 2011-10-04 18:01:22 <Diablo-D3> everyone has tried everything by now imo
1428 2011-10-04 18:02:01 <gmaxwell> Diablo-D3: I suspect some pools are cheating in the PR game by not rejecting shares that they really ought to reject.
1429 2011-10-04 18:02:04 <luke-jr> anyhow, a real double spender is likely to try to connect directly to pools
1430 2011-10-04 18:02:17 <gmaxwell> Diablo-D3: As a result you get low reject rates but the pools ROR is just crappy.
1431 2011-10-04 18:02:24 <Diablo-D3> gmaxwell: well I think pools should stop rejecting dupes
1432 2011-10-04 18:02:30 <Diablo-D3> just silently accept them and drop them
1433 2011-10-04 18:02:43 <gmaxwell> luke-jr: who cares about attackers if software features makes accidental double spends easyish.
1434 2011-10-04 18:03:14 iocor has joined
1435 2011-10-04 18:03:18 <gmaxwell> Diablo-D3: then people won't fix buggy client software and the pool will suffer overall.
1436 2011-10-04 18:03:18 <Diablo-D3> gmaxwell: but yeah, I dont think btcguild plays the PR game
1437 2011-10-04 18:03:26 <Diablo-D3> gmaxwell: no, its not buggy clients
1438 2011-10-04 18:03:28 <luke-jr> gmaxwell: I wasn't talking about key import/export anymore :P
1439 2011-10-04 18:03:32 <Diablo-D3> if the share send never completes, the client retries
1440 2011-10-04 18:03:38 <gmaxwell> I haven't done the math but I think my reject rates there are impossibly low.
1441 2011-10-04 18:03:43 <luke-jr> Diablo-D3: it CAN BE buggy clients
1442 2011-10-04 18:03:52 <Diablo-D3> the client cant know if the server got it if the connection drops during the response phase
1443 2011-10-04 18:04:03 <Diablo-D3> its a long standing unsolvable problem in transactional states over error prone networks
1444 2011-10-04 18:04:50 <luke-jr> Diablo-D3: perhaps you should suggest a new mining extension; a unique id for each submission
1445 2011-10-04 18:05:05 <luke-jr> and duplicates get their old result looked up and returned if the unique id matches
1446 2011-10-04 18:05:11 c00w has quit (Read error: Operation timed out)
1447 2011-10-04 18:05:14 <Diablo-D3> no, btcguild did have x-reject-reason for awhile
1448 2011-10-04 18:05:15 <luke-jr> might not be worth the effort to implement pool-side tho
1449 2011-10-04 18:05:30 <Diablo-D3> I was going to add "if == "duplicate", ignore reject", but I cant try it now
1450 2011-10-04 18:05:45 <luke-jr> Diablo-D3: try btcguild PPS
1451 2011-10-04 18:05:49 <luke-jr> Diablo-D3: or Eligius ;)
1452 2011-10-04 18:06:07 <luke-jr> but anyhow, that solution doesn't really fix it
1453 2011-10-04 18:06:08 <Diablo-D3> meh, eligius still hasnt fixed the UA bug
1454 2011-10-04 18:06:15 <Diablo-D3> pretty much why everyone left eligius
1455 2011-10-04 18:06:23 <Diablo-D3> that, and your religious whoring
1456 2011-10-04 18:06:24 <gmaxwell> UA bug?
1457 2011-10-04 18:06:27 <luke-jr> cuz even if the dupe is a retry, you don't know if the real result is accepted or stale
1458 2011-10-04 18:06:37 <Diablo-D3> gmaxwell: he detects UAs to specifically attack people
1459 2011-10-04 18:06:40 <luke-jr> Diablo-D3: liar
1460 2011-10-04 18:06:50 <Diablo-D3> luke-jr: am I? then remove the UA detection for DM
1461 2011-10-04 18:06:51 <luke-jr> gmaxwell: DiabloMiner has a bug, so I turned off rollntime for it
1462 2011-10-04 18:07:01 <luke-jr> Diablo-D3: if I do that, people complain DM gives them a lot of stales
1463 2011-10-04 18:07:07 <luke-jr> or rather, unknown-work
1464 2011-10-04 18:07:13 <Diablo-D3> DM has no bug, I have tried repeatedly to reproduce it on other pools, and I cant
1465 2011-10-04 18:07:21 <Diablo-D3> and I cant reliably reproduce it on yours either
1466 2011-10-04 18:07:22 <luke-jr> Diablo-D3: other pools don't support the same features Eligius does
1467 2011-10-04 18:07:28 <Diablo-D3> so whatever the problem is, its on your end
1468 2011-10-04 18:07:38 <luke-jr> Diablo-D3: change your UA and you'll presumably reproduce it
1469 2011-10-04 18:07:44 <Diablo-D3> I did change it you moron
1470 2011-10-04 18:07:50 <Diablo-D3> what use would be testing if I didnt change it
1471 2011-10-04 18:07:51 <gavinandresen> sipa: gonna grab lunch, but here's my current thinking on standard transaction types: https://gist.github.com/1262291
1472 2011-10-04 18:08:08 <gavinandresen> (in very abbreviated form)
1473 2011-10-04 18:08:45 <luke-jr> Diablo-D3: if you want me to remove the UA check, I will one more time until DM users complain, ok?
1474 2011-10-04 18:09:12 <luke-jr> (too bad pushpool doesn't have infra to compare before/after invalids)
1475 2011-10-04 18:09:33 <sipa> gavinandresen: why put the message hash in the script?
1476 2011-10-04 18:09:46 larsivi has joined
1477 2011-10-04 18:09:46 <sipa> oh wait
1478 2011-10-04 18:10:01 <Diablo-D3> luke-jr: what were they even complaining about? I had sub-1% rejects before you added the fix
1479 2011-10-04 18:10:12 <Diablo-D3> your UA check drove rejects UP for me
1480 2011-10-04 18:10:36 <gavinandresen> sipa: afk for a bit, no guarantees that I got the key recovery proposal right....
1481 2011-10-04 18:10:38 <luke-jr> Diablo-D3: I saw their DiabloMiner submitting shares against work from over 2 minutes old
1482 2011-10-04 18:10:39 flok has joined
1483 2011-10-04 18:10:53 <Diablo-D3> luke-jr: yes, but your definition of "over" is questionable.
1484 2011-10-04 18:11:02 <Diablo-D3> if its one second over, its not over
1485 2011-10-04 18:11:04 <sipa> gavinandresen: the message hash is calculated already, as part of the signature verification step
1486 2011-10-04 18:11:05 <luke-jr> yes it is
1487 2011-10-04 18:11:07 <Diablo-D3> thats network lag
1488 2011-10-04 18:11:16 <luke-jr> which the miner is supposed to account for
1489 2011-10-04 18:11:23 <Diablo-D3> not really.
1490 2011-10-04 18:11:26 <sipa> gavinandresen: so it's really just signature + 2 bits you need to put in the script
1491 2011-10-04 18:11:26 <luke-jr> yes really.
1492 2011-10-04 18:11:38 <Diablo-D3> that just makes miners more complex
1493 2011-10-04 18:11:43 <sipa> gavinandresen: on every place where there is currently a signature
1494 2011-10-04 18:12:03 <luke-jr> Diablo-D3: something has to account for it, and the pool isn't able to
1495 2011-10-04 18:12:12 <Diablo-D3> the pool can just freely reject it
1496 2011-10-04 18:12:14 <luke-jr> the miner can actually measure the time it takes
1497 2011-10-04 18:12:26 <sipa> gavinandresen: and you'll have some OP with the meaning "produce the pubkey on the stack, that is valid for a given signature"
1498 2011-10-04 18:12:39 <luke-jr> or a "cheap" miner could just hard-code some expected latency
1499 2011-10-04 18:12:42 <Diablo-D3> and with my new campaign to drive rejects down even farther (now that I can because I use btcguild), you're probably never going to see it
1500 2011-10-04 18:12:56 <luke-jr> Diablo-D3: oh?
1501 2011-10-04 18:13:07 <Diablo-D3> yeah, I async bail a second early.
1502 2011-10-04 18:13:14 paul0 has quit (Quit: paul0)
1503 2011-10-04 18:13:28 <luke-jr> nfc what that menas
1504 2011-10-04 18:13:29 cjdelisle has quit (Quit: leaving)
1505 2011-10-04 18:13:29 <luke-jr> means*
1506 2011-10-04 18:13:41 <Diablo-D3> well, you know I already have async get/sendwork, right?
1507 2011-10-04 18:14:37 <Diablo-D3> it sends the executor thread for getwork a second early to avoid a potential block condition if the work queue is empty
1508 2011-10-04 18:14:54 <luke-jr> ok
1509 2011-10-04 18:15:17 <Diablo-D3> it used to block if the work queue was empty (I wasnt exploiting my existing code well enough)
1510 2011-10-04 18:15:26 <luke-jr> my custom poclbm starts getting new work 2 * maxLatencySeen early
1511 2011-10-04 18:15:53 <Diablo-D3> well, this can cover a second of latency
1512 2011-10-04 18:15:57 <luke-jr> Diablo-D3: so how can I distinguish this newer version from the older one that has the issue?
1513 2011-10-04 18:16:15 <Diablo-D3> DM to server, server beating bitcoind with a whip, and server to DM
1514 2011-10-04 18:16:19 <Diablo-D3> it shouldnt take more than a second
1515 2011-10-04 18:16:23 <Diablo-D3> if it does, the server needs fixed
1516 2011-10-04 18:16:28 <luke-jr> it takes about 0.34 seconds on Eligius usually
1517 2011-10-04 18:16:33 <Diablo-D3> or you need to quit mining over sat-pohone
1518 2011-10-04 18:16:37 <Diablo-D3> yeah exactly
1519 2011-10-04 18:16:37 <luke-jr> lol
1520 2011-10-04 18:16:40 <Diablo-D3> so a second is good enough
1521 2011-10-04 18:16:56 <Diablo-D3> most of the time theres already a fresh work waiting
1522 2011-10-04 18:17:28 <Diablo-D3> and for most miners, its hopping out due to either LP or nonce saturation anyhow
1523 2011-10-04 18:17:28 <luke-jr> see, this is why sending a version in User-Agent is handy
1524 2011-10-04 18:17:37 <Diablo-D3> yeah, but DM has no versions
1525 2011-10-04 18:17:38 <luke-jr> I don't have any way to tell whether the miners are usign the older one or newer one, do I?
1526 2011-10-04 18:17:46 <luke-jr> how about git ids?
1527 2011-10-04 18:17:53 <Diablo-D3> git ids do not progress sequentially.
1528 2011-10-04 18:17:57 <luke-jr> true
1529 2011-10-04 18:18:00 Graet has quit (Ping timeout: 248 seconds)
1530 2011-10-04 18:18:02 <luke-jr> git commit date?
1531 2011-10-04 18:18:18 <Diablo-D3> not useful because you could only recognize my dates
1532 2011-10-04 18:18:24 <luke-jr> ?
1533 2011-10-04 18:18:25 <Diablo-D3> and everyone has their own custom fork of DM
1534 2011-10-04 18:18:37 <luke-jr> srsly? people fork DM?
1535 2011-10-04 18:18:41 <sipa> gavinandresen: for your last example, the scriptSig would be: "<sig+bits A> <sig+bits B> <OP_RECPUBKEY <pubkey> OP_EQUALNUM OP_VERIFY OP_RECPUBKEY <pubkey> OP_EQUALNUM OP_VERIFY>>"
1536 2011-10-04 18:18:46 <Diablo-D3> yeah, I know a lot of power users who have custom code
1537 2011-10-04 18:19:05 <luke-jr> git commit date where author = Patrick? :/
1538 2011-10-04 18:19:24 <Diablo-D3> well, the rule is, I dont release DM, so just make sure your copy is always up to date or suffer the consiquences
1539 2011-10-04 18:19:28 <luke-jr> meh, if people complain I'll just tell em to upgrade DM
1540 2011-10-04 18:19:31 <sipa> gavinandresen: or, "<sig+bits A> <sig+bits B> <OP_RECPUBKEY OP_HASH160 <address> OP_EQUALNUM OP_VERIFY ...>"
1541 2011-10-04 18:19:39 <Diablo-D3> luke-jr: exactly, thats what I do
1542 2011-10-04 18:19:48 <Diablo-D3> if theres a legitimate bug, then file it on github
1543 2011-10-04 18:20:25 <gavinandresen> sipa: ... with a CHECKMULTISIG? Or does recovering the pubkey imply signature verification too?
1544 2011-10-04 18:20:27 <luke-jr> Diablo-D3: please test latest DM and confirm no invalids?
1545 2011-10-04 18:20:28 Graet_ has joined
1546 2011-10-04 18:20:33 <luke-jr> Diablo-D3: on Eligius
1547 2011-10-04 18:20:40 <Diablo-D3> Im in the middle of a test now on btcguild
1548 2011-10-04 18:20:49 <sipa> gavinandresen: if the recovered key matches the pubkey you expect, the signature is valid
1549 2011-10-04 18:21:00 <sipa> there is no separate validness check
1550 2011-10-04 18:22:32 <gavinandresen> sipa: I'll remove that Proposal from my gist, and let somebody (cough) who actually knows about recovering public keys write it up
1551 2011-10-04 18:23:11 gp5st has joined
1552 2011-10-04 18:23:25 <gavinandresen> sipa: is there a OP_RECPUBKEY proposal already I don't know about?
1553 2011-10-04 18:23:44 <Diablo-D3> luke-jr: I do 10k share tests because thats the minimum statistically valid imo
1554 2011-10-04 18:23:46 <sipa> gavinandresen: there was, in the the origin forum thread were i announced key recovery :)
1555 2011-10-04 18:24:10 <Diablo-D3> luke-jr: Im 956 shares in, and its 0 rejects... I usually see at least 1 by now
1556 2011-10-04 18:24:33 <sipa> gavinandresen: but if we're going to use an OP_NOP for OP_EVAL, i'd prefer to use another OP_NOP for OP_RECPUBKEY as well, instead of changing semantics inside and outside of OP_EVAL
1557 2011-10-04 18:24:46 <luke-jr> http://bitcoinscene.org/threads/22-DiabloMiner-testing-needed?p=93
1558 2011-10-04 18:25:01 <sipa> otherwise you can equally well say that the language inside OP_EVAL is "Bitcoin script 2.0", with other improvements as well
1559 2011-10-04 18:25:07 <luke-jr> sipa: there's only 10 OP_NOPs; probably best to be conservative with them
1560 2011-10-04 18:25:23 <gavinandresen> sipa: fine with me. But you won't get automatic backwards-compatibility unless the RECPUBKEY is inside an EVAL
1561 2011-10-04 18:25:29 <gmaxwell> Eval provides a nice way to hide some changes without burning up more NOPs.
1562 2011-10-04 18:25:32 <Diablo-D3> jesus how many forums do we have now?
1563 2011-10-04 18:25:57 <sipa> gavinandresen, gmaxwell: agree, but that means we should use it to the maximum extent possible
1564 2011-10-04 18:25:59 <gmaxwell> But yea, I don't like the idea of tossing everything in all at once either.
1565 2011-10-04 18:26:08 MimeNarrator has joined
1566 2011-10-04 18:26:28 p0s has joined
1567 2011-10-04 18:26:31 <cuqa> why do you even need another forum
1568 2011-10-04 18:26:49 <luke-jr> Diablo-D3: 2 I think
1569 2011-10-04 18:26:59 <sipa> i don't like nifty new features only becoming available inside OP_EVAL, actually
1570 2011-10-04 18:27:09 <luke-jr> cuqa: BitcoinTalk is a cesspool, and BitcoinScene gives projects subforums
1571 2011-10-04 18:27:26 <Diablo-D3> do projects WANT subforums?
1572 2011-10-04 18:27:34 <luke-jr> Diablo-D3: it makes sense for pools at least
1573 2011-10-04 18:27:39 <luke-jr> rather than 500-page threads
1574 2011-10-04 18:27:40 <Diablo-D3> I mean, I'm mod of the mining cesspool
1575 2011-10-04 18:27:45 <luke-jr> with a million topics
1576 2011-10-04 18:27:56 <gavinandresen> sipa: the alternative is waiting until we can organize and schedule a block chain split
1577 2011-10-04 18:28:09 <cuqa> is it ur board luke?
1578 2011-10-04 18:28:11 <Diablo-D3> and remember, the only reason its a cesspool is because theymos wont let me ban people
1579 2011-10-04 18:28:21 <luke-jr> cuqa: I mod only the Eligius subforum
1580 2011-10-04 18:28:32 <luke-jr> Diablo-D3: not saying it's your fault
1581 2011-10-04 18:28:40 <cuqa> who is the owner
1582 2011-10-04 18:28:57 <Diablo-D3> but I want to ban people so much ;_;
1583 2011-10-04 18:29:15 <luke-jr> gavinandresen: what would you think of organizing a fork with a weekly-reset testnet (only) that tests changes scheduled for a block chain split?
1584 2011-10-04 18:29:19 <luke-jr> cuqa: I think Kevin
1585 2011-10-04 18:29:32 <sipa> gavinandresen: i think we can come up with a "better" script language than the current one, if backward compatibility is not required
1586 2011-10-04 18:30:07 <luke-jr> gavinandresen: not you doing it necessarily, just the concept of it
1587 2011-10-04 18:30:11 <gavinandresen> sipa: okey doke. OP_EVAL2 could be used to interpret that better script language.....
1588 2011-10-04 18:30:15 <gavinandresen> (or maybe OP_EVAL3)
1589 2011-10-04 18:30:24 <sipa> good point
1590 2011-10-04 18:31:30 <gavinandresen> luke-jr: testing schemes for upgrading on testnet is a good idea
1591 2011-10-04 18:31:47 <luke-jr> ah, I see someone also suggested it on the forum
1592 2011-10-04 18:32:27 <gavinandresen> luke-jr: speaking of upgrading, would asking miners to put a version number in their coinbase be the same as asking them to put a set of flags for what they support?
1593 2011-10-04 18:32:50 <gavinandresen> ... and in general, what are miners putting in their coinbases? I haven't been keeping track...
1594 2011-10-04 18:33:15 <gmaxwell> Version numbers are bad... they're meaningless. Anyone doing large scale mining is carrying patches.
1595 2011-10-04 18:33:39 <Diablo-D3> yeah and
1596 2011-10-04 18:33:44 <Diablo-D3> people should be using the newest version anyhow
1597 2011-10-04 18:34:14 <gavinandresen> gmaxwell: okey doke. I don't care if it is a set of flags... how should they be represented in the coinbase?
1598 2011-10-04 18:34:26 TD[gone] is now known as TD
1599 2011-10-04 18:34:37 <gmaxwell> Flags also kind of suck because some idiot will double purpose a bit and it'll lose its meaning.
1600 2011-10-04 18:34:41 TD has left ()
1601 2011-10-04 18:34:45 <Diablo-D3> heh
1602 2011-10-04 18:34:46 TD has joined
1603 2011-10-04 18:34:46 TD has left ()
1604 2011-10-04 18:34:55 <Diablo-D3> gmaxwell: textual flags?
1605 2011-10-04 18:35:01 <gavinandresen> gmaxwell: okey doke, I don't care if it is magic fairy dust..............
1606 2011-10-04 18:35:15 <gavinandresen> .... but I do want something soon
1607 2011-10-04 18:35:16 <luke-jr> gavinandresen: support-flags are better, because there's no reason to assume a linear progression of features
1608 2011-10-04 18:35:53 <midnightmagic> hey gavin has vince not forwarded any patches for auxiliary mining yet?
1609 2011-10-04 18:36:01 <luke-jr> gavinandresen: if you mean to enable upgrades, I think the flags should disappear for reuse after it's enabled ;)
1610 2011-10-04 18:36:08 pickett_ has quit (Ping timeout: 248 seconds)
1611 2011-10-04 18:36:14 <luke-jr> midnightmagic: I sent one yesterday
1612 2011-10-04 18:36:22 <luke-jr> midnightmagic: part of my coinbaser branch
1613 2011-10-04 18:36:41 <gavinandresen> luke-jr: I'm trying to get a concrete proposal
1614 2011-10-04 18:36:43 <midnightmagic> luke-jr: does that roll in vince's getaux* rpc calls?
1615 2011-10-04 18:37:27 <gavinandresen> who is vince? getmemorypool was pulled: https://github.com/bitcoin/bitcoin/pull/476
1616 2011-10-04 18:37:29 <luke-jr> midnightmagic: no
1617 2011-10-04 18:38:33 <gmaxwell> gavinandresen: yea, what luke-jr says. If you make the deployment rule for OP_EVAL "O_EVAL gains its new meaning on the first block after height X where >50% of the last 1008 blocks have indicated support" then the indicator can be reused after that point.
1618 2011-10-04 18:39:03 <midnightmagic> luke-jr: Ah, sorry, I'm talking about the merged-mining patches that bitcoind needs to support in order to enable it. there's only 33 blocks to go before it's enabled, and it seems troublesome that it requires an external patch to function properly in light of people talking so much about repurposing coinbase.
1619 2011-10-04 18:39:03 <gavinandresen> gmaxwell: yes. So what, exactly, is in the coinbase to say that?
1620 2011-10-04 18:39:07 <luke-jr> reuse also means the indicator can be obvious; ie, "OP_EVAL" as 8 bytes in the coinbase
1621 2011-10-04 18:39:41 <luke-jr> midnightmagic: the trouble is that there is no documentation and vince's implementation puts the bitcoin mining at jeopardy
1622 2011-10-04 18:39:48 <gavinandresen> luke-jr: ... and the indicator would be.... a byte at the beginning of the coinbase?
1623 2011-10-04 18:39:56 <midnightmagic> esp. so since the patch conflicts directly with a patch that gavin recently pulled as part of a fix of yours.
1624 2011-10-04 18:39:58 <luke-jr> midnightmagic: coinbaser adds "setauxwork" RPC call to handle it more sane
1625 2011-10-04 18:40:08 <luke-jr> gavinandresen: 8 bytes: <length>"OP_EVAL"
1626 2011-10-04 18:40:24 <midnightmagic> luke-jr: it only does so because it hasn't been conceptually merged with your bugfix.
1627 2011-10-04 18:40:39 <luke-jr> midnightmagic: no, because it requires a proxy in front of bitcoind
1628 2011-10-04 18:40:48 <luke-jr> an additional point of failure
1629 2011-10-04 18:40:59 <midnightmagic> ah is that what you're talking about
1630 2011-10-04 18:41:08 <luke-jr> midnightmagic: my implementation puts it on the side
1631 2011-10-04 18:41:16 <luke-jr> midnightmagic: so if it fails, bitcoin mining goes on
1632 2011-10-04 18:41:19 <gavinandresen> luke-jr: thanks. At the very beginning of the coinbase or could it appear anywhere?
1633 2011-10-04 18:41:24 <midnightmagic> any pool can incorporate the merged-mining logic, it's not difficult, vince did it in a script even.
1634 2011-10-04 18:41:31 <luke-jr> gavinandresen: anywhere
1635 2011-10-04 18:41:51 <luke-jr> midnightmagic: it's risky
1636 2011-10-04 18:41:52 <midnightmagic> luke-jr: isn't that what failover is for?
1637 2011-10-04 18:41:57 <luke-jr> midnightmagic: â¦
1638 2011-10-04 18:42:05 <luke-jr> failover takes miners to a different pool
1639 2011-10-04 18:42:13 pickett has joined
1640 2011-10-04 18:42:22 <midnightmagic> all of my miners failover either to a local instance of bitcoin, or a pool.
1641 2011-10-04 18:42:39 <luke-jr> gavinandresen: it would be cleaner to merge coinbaser *before* adding this btw ;)
1642 2011-10-04 18:42:55 <gavinandresen> first come first served.
1643 2011-10-04 18:43:00 <luke-jr> midnightmagic: as a pool operator, I don't want miners to failover; I want my pool to stay up
1644 2011-10-04 18:43:13 <luke-jr> gavinandresen: coinbaser is ready yesterday :p
1645 2011-10-04 18:43:22 <luke-jr> part of those PULL reqs I sent
1646 2011-10-04 18:43:34 jandd_ has quit (Quit: leaving)
1647 2011-10-04 18:43:51 <luke-jr> gavinandresen: and has infrastructure that could be helpful in adding these flags
1648 2011-10-04 18:43:57 <gavinandresen> luke-jr: ever read the book "Getting Things Done" ? One of the principles is to have ONE inbox....
1649 2011-10-04 18:44:03 <midnightmagic> luke-jr: have you released your pool software somewhere?
1650 2011-10-04 18:44:11 <gavinandresen> ... and for pulls, github is that one inbox
1651 2011-10-04 18:44:12 <luke-jr> midnightmagic: what pool software?
1652 2011-10-04 18:44:26 coblee has quit (Quit: coblee)
1653 2011-10-04 18:44:27 <midnightmagic> luke-jr: eligius. whatever daemon you have running.
1654 2011-10-04 18:44:28 <gavinandresen> (yes, I know, github is evil and they're just waiting to sue my pants off)
1655 2011-10-04 18:44:30 <luke-jr> gavinandresen: well, GitHub has issues
1656 2011-10-04 18:44:31 jandd has joined
1657 2011-10-04 18:44:41 coblee has joined
1658 2011-10-04 18:44:42 <luke-jr> gavinandresen: I'm not going to tell a lie to appease you.
1659 2011-10-04 18:44:51 <luke-jr> midnightmagic: pushpool and bitcoind
1660 2011-10-04 18:45:05 <midnightmagic> luke-jr: stock? you have no private mods?
1661 2011-10-04 18:45:10 <Diablo-D3> [02:33:08] <gavinandresen> luke-jr: ever read the book "Getting Things Done" ? One of the principles is to have ONE inbox....
1662 2011-10-04 18:45:10 <luke-jr> midnightmagic: most of my changes to pushpool are merged in mainline
1663 2011-10-04 18:45:13 <Diablo-D3> gavinandresen: hah, dude
1664 2011-10-04 18:45:16 <Diablo-D3> the real thing to GTD
1665 2011-10-04 18:45:17 <gavinandresen> luke-jr: I did look through your pulls, but none of them strike me as high priority.
1666 2011-10-04 18:45:18 <luke-jr> midnightmagic: my bitcoind changes are on Gitorious
1667 2011-10-04 18:45:19 <Diablo-D3> have NO inbox.
1668 2011-10-04 18:45:58 <luke-jr> gavinandresen: well, merging coinbaser gets you the infrastructure to add the coinbase flags, plus avoids making me rebase it when you reinvent parts ;p
1669 2011-10-04 18:46:16 <midnightmagic> luke-jr: way to submarine my trap bro. :-) i suddenly agree with you. keeping the pool up is extremely important. I think pushpool itself can incorporate the merged-mining logic and spare us all the proxy POF..
1670 2011-10-04 18:46:30 <luke-jr> gavinandresen: IMO, OP_EVAL isn't high priority, but if you want it, coinbaser can help
1671 2011-10-04 18:47:06 <luke-jr> midnightmagic: if Eligius weren't so much at a loss already, I'd be seriously considering rewriting pushpool :P
1672 2011-10-04 18:47:13 <luke-jr> or at least significant parts of it
1673 2011-10-04 18:47:17 <gavinandresen> luke-jr: I'll look at it again. And OP_EVAL is only high priority because getting an IsStandard multisig transaction type is high priority
1674 2011-10-04 18:47:46 <sipa> why do they need to be related?
1675 2011-10-04 18:47:54 <midnightmagic> luke-jr: that java pool software looks promising. do you have any comments about it?
1676 2011-10-04 18:47:55 marf_away has joined
1677 2011-10-04 18:48:02 <luke-jr> gavinandresen: basically, the code for aux works (for merged mining) can also be used with arbitrary data like coinbase flags
1678 2011-10-04 18:48:12 <luke-jr> midnightmagic: it's not pushpool compatible like they claim :/
1679 2011-10-04 18:48:35 <midnightmagic> doh
1680 2011-10-04 18:48:58 <luke-jr> midnightmagic: specifically, it forces all usernames to lowercase (so no base58/addresses), and insists on a password
1681 2011-10-04 18:49:07 <gavinandresen> sipa: because if we want to do (a and b) OR c transactions then I think the transaction types will be different with/without OP_EVAL
1682 2011-10-04 18:49:09 <midnightmagic> double-doh
1683 2011-10-04 18:49:12 <luke-jr> it also seems to insist on numeric user ids
1684 2011-10-04 18:49:48 <luke-jr> I also have my doubts as to how well it'd resist DDoS
1685 2011-10-04 18:50:15 <luke-jr> if I were doing it, I'd use a single RAW socket and skip the TCP stack ;)
1686 2011-10-04 18:50:57 <luke-jr> btw, if the person who registered "luke-jr" on GitHub is here, please tell me the password <.<
1687 2011-10-04 18:51:38 <Diablo-D3> >raw sockets
1688 2011-10-04 18:51:40 <Diablo-D3> >not root on linux
1689 2011-10-04 18:51:42 <Diablo-D3> que?
1690 2011-10-04 18:52:01 disq has quit (Ping timeout: 245 seconds)
1691 2011-10-04 18:52:26 <luke-jr> Diablo-D3: yay for capabilities
1692 2011-10-04 18:52:47 flok has quit (Quit: ZNC - http://znc.sourceforge.net)
1693 2011-10-04 18:53:08 <Diablo-D3> newfangled shit, get off my lawn
1694 2011-10-04 18:53:47 TD has joined
1695 2011-10-04 18:53:58 <TD> lol at the michael clear speculation. poor guy.
1696 2011-10-04 18:54:00 inlikeflynn has quit (Ping timeout: 255 seconds)
1697 2011-10-04 18:54:12 <luke-jr> yeah, we all know Satoshi is Gavin's wife
1698 2011-10-04 18:54:21 <gavinandresen> shhhh
1699 2011-10-04 18:54:31 <luke-jr> oops, did I say that in public?
1700 2011-10-04 18:54:43 <luke-jr> >..
1701 2011-10-04 18:56:46 flok has joined
1702 2011-10-04 19:01:00 pumpkin has joined
1703 2011-10-04 19:01:08 <sipa> gavinandresen: https://gist.github.com/1262449
1704 2011-10-04 19:01:11 da2ce7 has quit (Remote host closed the connection)
1705 2011-10-04 19:01:39 disq has joined
1706 2011-10-04 19:02:14 ephcon has joined
1707 2011-10-04 19:03:20 da2ce7 has joined
1708 2011-10-04 19:04:31 copumpkin has quit (Ping timeout: 245 seconds)
1709 2011-10-04 19:06:15 t3a has quit (Ping timeout: 255 seconds)
1710 2011-10-04 19:10:07 <gavinandresen> sipa: you're not worrying at all about backwards compatiblity? You're assuming a hard block chain split? (I assume, since switching alt/normal stack would break every exsiting transaction....)
1711 2011-10-04 19:10:41 <sipa> gavinandresen: no, i assume OP_EVAL
1712 2011-10-04 19:11:10 <gavinandresen> Got it,so new operations only valid inside OP_EVAL'ed scripts?
1713 2011-10-04 19:11:12 <sipa> ah, the first example assumes a hard block chain split
1714 2011-10-04 19:11:24 pumpkin is now known as copumpkin
1715 2011-10-04 19:11:31 <sipa> the second and third are embedding it in OP_EVAL
1716 2011-10-04 19:11:34 RazielZ has quit (Quit: Leaving)
1717 2011-10-04 19:12:06 <sipa> just having OP_SWITCH would make any complex boolean script already a lot simpler
1718 2011-10-04 19:12:35 cenuij has quit (Remote host closed the connection)
1719 2011-10-04 19:13:10 <sipa> i'm pondering about an OP_TXHASH, that returns the tx hash used as message for the signing algorithm, so you could implement your own hashing schemes
1720 2011-10-04 19:13:29 cenuij has joined
1721 2011-10-04 19:13:29 cenuij has quit (Changing host)
1722 2011-10-04 19:13:29 cenuij has joined
1723 2011-10-04 19:14:30 <gavinandresen> Having CScript::Solver do partial-matching of snippets of opcodes to dig out addresses that are relevant to you makes me nervous....
1724 2011-10-04 19:14:56 <gavinandresen> ... seems like a very likely place for a DoS attack involving some oddly-formed Script
1725 2011-10-04 19:16:36 <gavinandresen> That's why I've been steering towards "Here are N 'standard' transaction forms that are reasonably straightforward to dig addresess out of"
1726 2011-10-04 19:16:47 <gavinandresen> (where N is 4 or 5)
1727 2011-10-04 19:17:14 <TD> you could just scan the script as raw bytes. but i doubt it's a problem.
1728 2011-10-04 19:17:50 <TD> it'd be better to have some kind of robust update system than try and solve every DoS in advance.
1729 2011-10-04 19:17:50 B0g4r7_ has joined
1730 2011-10-04 19:18:27 shLONG has quit ()
1731 2011-10-04 19:18:46 sraue has joined
1732 2011-10-04 19:19:20 64MAAKOCF has quit (Ping timeout: 248 seconds)
1733 2011-10-04 19:19:31 <gavinandresen> TD: is there another distributed security-sensitive open-source software project that has a robust update system we could copy?
1734 2011-10-04 19:19:48 <TD> chrome? ;)
1735 2011-10-04 19:19:52 disq has quit (Ping timeout: 248 seconds)
1736 2011-10-04 19:19:59 <TD> that wouldn't work for servers of course.
1737 2011-10-04 19:20:04 Raccoon` has joined
1738 2011-10-04 19:20:21 <TD> i think it'd be necessary to roll a custom one for servers. and recommend users avoid their distributions package management, as linux distros would certainly try and patch it out
1739 2011-10-04 19:20:48 <TD> server security < desktop security these days, unfortunately. i guess you could start by emailing root when there is an update available.
1740 2011-10-04 19:21:23 <da2ce7> you could just provide the binararies in a GIT tree. and annouce a new root.
1741 2011-10-04 19:21:24 <luke-jr> TD: yay for bad security practices?
1742 2011-10-04 19:22:12 <da2ce7> git provides a secure one command line update process.
1743 2011-10-04 19:22:16 Raccoon has quit (Ping timeout: 252 seconds)
1744 2011-10-04 19:22:16 Raccoon` is now known as Raccoon
1745 2011-10-04 19:22:43 paul0 has joined
1746 2011-10-04 19:22:43 <luke-jr> people should only use their distro's packages
1747 2011-10-04 19:23:40 disq has joined
1748 2011-10-04 19:24:30 <helo> s/people/luke-jr/
1749 2011-10-04 19:24:42 <luke-jr> no, people in general
1750 2011-10-04 19:24:43 <luke-jr> end users
1751 2011-10-04 19:33:38 <TD> distributors have a very poor track record of keeping software up to date. they also have a track record of making "fixes" that break things in subtle ways
1752 2011-10-04 19:33:44 <TD> with something like openssl, that is merely a disaster
1753 2011-10-04 19:33:54 <TD> with something like bitcoin it could potentially cripple or nuke the entire system
1754 2011-10-04 19:34:44 <TD> packagers are not domain experts and should not be misled into thinking they are. encouraging users to rely on upstream is the way to go. i've had to deal with distro-specific changes in a previous job and it was a bloody pain
1755 2011-10-04 19:36:34 <sipa> gavinandresen: updated: https://gist.github.com/1262449
1756 2011-10-04 19:38:37 lyspooner has joined
1757 2011-10-04 19:40:07 <gavinandresen> sipa: probabaly better to just use OP_0 OP_0 OP_0 in the ScriptSig to make old clients happy (not use OP_NZERO)
1758 2011-10-04 19:40:19 <gavinandresen> (it's not like you're saving many bytes....)
1759 2011-10-04 19:40:39 <sipa> oh, yes, definitely
1760 2011-10-04 19:40:47 <sipa> at least in case 2
1761 2011-10-04 19:40:53 <gavinandresen> yes
1762 2011-10-04 19:41:17 yasmina has joined
1763 2011-10-04 19:42:13 markus_wanner has joined
1764 2011-10-04 19:42:19 DaQatz has quit (Read error: Connection reset by peer)
1765 2011-10-04 19:43:20 ephcon has quit (Ping timeout: 248 seconds)
1766 2011-10-04 19:43:23 DaQatz has joined
1767 2011-10-04 19:43:24 <gavinandresen> sipa: you're missing a 1 OP_LARGER in the last example....
1768 2011-10-04 19:44:00 <sipa> thanks; fixed
1769 2011-10-04 19:44:00 <yasmina> hello
1770 2011-10-04 19:44:22 <yasmina> I want sequence diagram for block exchange!!
1771 2011-10-04 19:44:53 <gavinandresen> yasmina: so fire up your favorite diagramming tool and make them....
1772 2011-10-04 19:45:21 <yasmina> ok I want the sequence :)
1773 2011-10-04 19:45:27 <forrestv> yasmina, inv, getdata, block
1774 2011-10-04 19:45:45 Zarutian has quit (Ping timeout: 256 seconds)
1775 2011-10-04 19:45:57 <sipa> inv -> getdata -> block block block block inv
1776 2011-10-04 19:46:15 <sipa> the last inv causing a new getdata for more blocks
1777 2011-10-04 19:47:06 <yasmina> which hashes to include in inv?
1778 2011-10-04 19:47:26 <sipa> inv is just an advertizement of known things
1779 2011-10-04 19:47:42 <yasmina> onothe questio what kind of data I have in block index?
1780 2011-10-04 19:48:19 <sipa> yasmina: read https://bitcointalk.org/index.php?topic=41729.0
1781 2011-10-04 19:50:23 <yasmina> I read them
1782 2011-10-04 19:50:23 zhoutong has quit (Read error: Connection reset by peer)
1783 2011-10-04 19:51:41 zhoutong has joined
1784 2011-10-04 19:52:29 <gavinandresen> sipa: OP_CHECKPUBKEY is so somebody could do their own hash checking?
1785 2011-10-04 19:52:30 <yasmina> I was think : getblocks-> recv inv response is get data response block
1786 2011-10-04 19:53:27 <sipa> gavinandresen: OP_CHECKPUBKEY is a shorthand for what is currently a spend-to-pubkey, OP_CHECKHASH is a shorthand for what is currently a spend-to-address
1787 2011-10-04 19:54:07 <sipa> but the actual lower-level primitives are exposed as well, so you could use them for spend-to-shared-secret, or spend-while-checking-message-signature
1788 2011-10-04 19:54:25 <sipa> i suppose i need to add examples for those
1789 2011-10-04 19:55:08 <gavinandresen> I'm not sure OP_CHECKPUBKEY is useful enough to create a shorthand... seems like spend-to-address will be vastly more common, since it is fewer bytes (and so lower fees)
1790 2011-10-04 19:55:34 <gavinandresen> (and the long-hand version is only 3 bytes longer)
1791 2011-10-04 19:55:57 <sipa> agree, i'll remove it
1792 2011-10-04 19:56:05 c00w has joined
1793 2011-10-04 20:01:41 <yasmina> :((
1794 2011-10-04 20:04:00 Katapult has quit (Remote host closed the connection)
1795 2011-10-04 20:04:12 ephcon has joined
1796 2011-10-04 20:05:45 <gavinandresen> sipa: I think I like it. Now how to convince TD it is worth doing even if we don't have secure updating and super-easy click-to-pay and and and... all sorts of stuff yet
1797 2011-10-04 20:06:58 <TD> heh
1798 2011-10-04 20:07:08 <TD> well new opcodes mean a chain split - not an easy thing to do if people aren't updating
1799 2011-10-04 20:07:18 <gmaxwell> No they don't.
1800 2011-10-04 20:07:33 <gavinandresen> new opcodes are not a chain split if they are only valid inside OP_EVAL, and OP_EVAL == OP_NOP to old clients
1801 2011-10-04 20:07:39 <gmaxwell> Not if they don't result in old nodes failing to validate.
1802 2011-10-04 20:08:22 <TD> if you have a script that older clients see as a NOP but newer clients see as conditional, isn't that a problem?
1803 2011-10-04 20:08:27 Moonies has quit (Quit: quack)
1804 2011-10-04 20:08:37 yasmina has quit (Quit: Page closed)
1805 2011-10-04 20:08:51 <gavinandresen> TD: no, it doesn't have to be, assuming we can get more than 50% of hashing power to update
1806 2011-10-04 20:08:55 <sipa> TD: if at least 50% of miners have upgraded, no script that is invalid in the new rules will make it into the block chain
1807 2011-10-04 20:08:56 <gmaxwell> Also, all the current opcodes that are disabled and would cause a chain split... might it be wise turn them into NOPs inside eval?
1808 2011-10-04 20:08:58 DaQatz has quit (Read error: Connection reset by peer)
1809 2011-10-04 20:09:20 gp5st has left ()
1810 2011-10-04 20:09:45 <gavinandresen> gmaxwell: probably, yes
1811 2011-10-04 20:09:50 <sipa> also, most of my criticism towards OP_EVAL is void, if you realize you can just put "<script> OP_EVAL" as scriptPubKey
1812 2011-10-04 20:10:05 DaQatz has joined
1813 2011-10-04 20:10:49 <gavinandresen> ... old clients would interpret that as "anybody can spend"... but yeah....
1814 2011-10-04 20:11:10 <sipa> yes, there is a problem with old clients that accept 0-confirmations...
1815 2011-10-04 20:11:11 <gmaxwell> (I'd really like to get those opcodes reenabled, but I can't personally commit time to writing tests for them. :-/)
1816 2011-10-04 20:11:42 <gavinandresen> gmaxwell: any opcodes in particular?
1817 2011-10-04 20:11:47 <sipa> gmaxwell, TD: not sure if you've seen the link; https://gist.github.com/1262449
1818 2011-10-04 20:12:25 <gmaxwell> sipa: Perhaps we should do some negoiation on connect and if you don't claim to support the new rules the node should not forward you any txn complying with them.
1819 2011-10-04 20:13:00 <gmaxwell> But since no widely used software does something fun like "I'll add all anyone can spend txn to my wallet because I can spend them" it's probably not that big a deal.
1820 2011-10-04 20:13:08 <gavinandresen> sipa: Old client wallet code will ignore the new transactions, so shouldn't be an issue
1821 2011-10-04 20:13:25 <sipa> good point
1822 2011-10-04 20:13:33 <TD> sipa: no ecdsa at all ?
1823 2011-10-04 20:13:48 <sipa> TD: sure; OP_RECOVER does ECDSA key recovery
1824 2011-10-04 20:13:56 <TD> where is the key used?
1825 2011-10-04 20:14:04 <sipa> and <sig+bits A> is an ECDSA signature + bits necessary for recovery
1826 2011-10-04 20:15:02 <TD> i meant, where is the signature checked?
1827 2011-10-04 20:15:03 <gmaxwell> sipa: you can omit the bits and just brute force them. (Though personally I like including them because it makes it faster and increases security)
1828 2011-10-04 20:15:19 <sipa> TD: not; key recovery implies a valid signature
1829 2011-10-04 20:15:20 <gavinandresen> keep the bits...
1830 2011-10-04 20:15:47 TheAncientGoat has quit (Ping timeout: 245 seconds)
1831 2011-10-04 20:15:57 <TD> it's interesting but i think this invalidates several important analyses of bitcoins security for little discernable benefit
1832 2011-10-04 20:16:03 <TD> the current script language works ok
1833 2011-10-04 20:16:25 <sipa> if you're paranoid, you can always implement an additional signature verification after recovery
1834 2011-10-04 20:17:05 <gavinandresen> sipa: but we're talking what are the standard, out-of-the-box transactions, which is what everybody will use
1835 2011-10-04 20:17:53 <sipa> the typical spend-to-address scriptPubKey would be "<<hashA> OP_CHECKHASH> OP_EVAL" :)
1836 2011-10-04 20:18:18 <sipa> and corresponding scriptSig: <sig+bits A>
1837 2011-10-04 20:18:43 vorlov has joined
1838 2011-10-04 20:19:22 <gavinandresen> Advantage is less bandwidth and disk space... is key recovery more or less expensive than a signature check? And how much?
1839 2011-10-04 20:19:26 <sipa> so 24 + 66 bytes, instead of 25 + 139 bytes
1840 2011-10-04 20:19:48 <sipa> i believe it is like 1.5x a signature check
1841 2011-10-04 20:19:58 <gmaxwell> Thats really nice.
1842 2011-10-04 20:20:07 <gavinandresen> That's a reason NOT to do it, then...
1843 2011-10-04 20:20:44 <gavinandresen> ... transaction validation will be CPU bound, I would guess, not network/disk bound.
1844 2011-10-04 20:20:52 <gmaxwell> It's a reason, yes. But I don't think it's a super compelling one. We're still a very very long way away from the sig computation binding the normal runtime... it's just an issue for initial bringup.
1845 2011-10-04 20:21:00 <sipa> i'm not convinced about that, actually
1846 2011-10-04 20:21:11 <sipa> i think both are possible future bounds
1847 2011-10-04 20:21:43 <luke-jr> does it prevent people from using sig space for spam?
1848 2011-10-04 20:21:45 <TD> disk space can be optimized a lot with no breaking changes
1849 2011-10-04 20:22:03 <gmaxwell> also, it's not terribly hard to fpga accelerate ecc (well, I haven't considered the key recovery)
1850 2011-10-04 20:22:29 <gmaxwell> But really, sipa how many key recoveries can you do per second?
1851 2011-10-04 20:22:41 <sipa> i posted benchmarks a long time ago on the forum
1852 2011-10-04 20:23:16 <sipa> oh, it's better
1853 2011-10-04 20:23:37 <sipa> 650us for a verification, 685us for a recovery
1854 2011-10-04 20:23:52 <TD> how do you identify transactions sent to yourself this way?
1855 2011-10-04 20:23:57 <gmaxwell> From a gate count perspective the field multiplies are cheaper than e.g. sha256. It's just that they aren't especially fast on current cpus.
1856 2011-10-04 20:24:18 <sipa> TD: double pattern-match, i guess
1857 2011-10-04 20:24:19 <gmaxwell> TD: you know the address that would be used, same as now effectively.
1858 2011-10-04 20:24:54 <gmaxwell> sipa: so 5.4% slower, thats ~noise.
1859 2011-10-04 20:24:56 ephcon has quit (Ping timeout: 248 seconds)
1860 2011-10-04 20:24:57 datagutt has quit (Quit: Computer has gone to sleep.)
1861 2011-10-04 20:24:59 <sipa> first match on <script> OP_EVAL, then match script on <hashA> OP_CHECKSIG
1862 2011-10-04 20:25:19 <TD> oh, i see
1863 2011-10-04 20:25:30 <TD> no i meant in the pure case. but <hashA> is a pubkey hash
1864 2011-10-04 20:25:40 <sipa> yes
1865 2011-10-04 20:26:16 <TD> i think there are cases where you want to check a signature, rather than checking the public key
1866 2011-10-04 20:26:31 <TD> i'd be generally very careful about redesigning script until every feature in it is fully explained
1867 2011-10-04 20:26:44 <TD> otherwise it's likely to block features satoshi considered but failed to document
1868 2011-10-04 20:26:52 amtal has quit (Ping timeout: 276 seconds)
1869 2011-10-04 20:27:14 <gavinandresen> ... that's why I was trying to figure out what CODESEPARATOR is for....
1870 2011-10-04 20:27:39 <TD> exactly. i think it's for allowing conditions to be placed upon spending transactions.
1871 2011-10-04 20:28:07 <gavinandresen> The real question would be whether something like OP_EVAL should act like it is surrounded by CODESEPARATORs
1872 2011-10-04 20:28:27 <sipa> btw: the current proposal isn't compatible with different signature types (the SIGHASH_... thing), but it's not that hard to change
1873 2011-10-04 20:28:27 <TD> sipa: btw i still don't really get it. OP_RECOVER checks the signature, right?
1874 2011-10-04 20:29:01 <sipa> TD: OP_RECOVER does the same thing as OP_CHECKSIG does now, but instead of taking a pubkey from the stack, it puts the pubkey that would have been valid on the stack
1875 2011-10-04 20:29:25 <TD> so it does key recovery, then checks the signature with the recovered key[s] against the tx hash
1876 2011-10-04 20:29:36 <sipa> you could say that
1877 2011-10-04 20:29:48 inlikeflynn has joined
1878 2011-10-04 20:29:55 <sipa> but the recovery algorithm implies a valid signature
1879 2011-10-04 20:30:01 <TD> valid signature over what?
1880 2011-10-04 20:30:18 <TD> you give the recovery algorithm the input message as part of recovering the key?
1881 2011-10-04 20:30:27 <sipa> key recovery does: (message, signature) -> key
1882 2011-10-04 20:30:33 <TD> ok
1883 2011-10-04 20:30:37 <sipa> key verification does: (message, signature, key) -> bool
1884 2011-10-04 20:30:39 <TD> best to define that at the top.
1885 2011-10-04 20:30:49 <TD> as key recovery is a very obscure operation.
1886 2011-10-04 20:31:12 Andrew__ has quit (Ping timeout: 245 seconds)
1887 2011-10-04 20:31:15 <TD> technically you get back 4 keys?
1888 2011-10-04 20:31:18 Doktor99 has quit (Ping timeout: 258 seconds)
1889 2011-10-04 20:31:20 DaQatz has quit (Ping timeout: 248 seconds)
1890 2011-10-04 20:31:25 <sipa> yes, but the signature is extended with 2 bits
1891 2011-10-04 20:31:31 <sipa> which select the one you want
1892 2011-10-04 20:31:38 <sipa> and the recovery only returns the chosen one
1893 2011-10-04 20:31:57 DaQatz has joined
1894 2011-10-04 20:32:05 noagendamarket has quit (Ping timeout: 252 seconds)
1895 2011-10-04 20:33:32 baz_ has joined
1896 2011-10-04 20:34:10 BurtyB has quit (Read error: No route to host)
1897 2011-10-04 20:34:25 BurtyB has joined
1898 2011-10-04 20:35:14 LightRider has quit (Ping timeout: 252 seconds)
1899 2011-10-04 20:36:35 AStove has quit ()
1900 2011-10-04 20:36:57 vorlov has quit (Quit: vorlov)
1901 2011-10-04 20:39:40 <luke-jr> https://github.com/bitcoin/bitcoin/pull/550
1902 2011-10-04 20:42:08 <luke-jr> https://github.com/bitcoin/bitcoin/pull/551
1903 2011-10-04 20:45:06 marf_away has quit (Ping timeout: 258 seconds)
1904 2011-10-04 20:46:37 c00w has quit (Ping timeout: 240 seconds)
1905 2011-10-04 20:48:18 <TD> are there instructions for building the qt version on macos anywhere?
1906 2011-10-04 20:48:34 <gavinandresen> TD: doc/readme-qt.rst I think
1907 2011-10-04 20:48:43 <luke-jr> TD: qmake bitcoin-qt.pro && make ?
1908 2011-10-04 20:49:19 <TD> it appears qmake creates an xcode project on macos
1909 2011-10-04 20:49:27 <TD> however xcode doesn't seem that easy to use.
1910 2011-10-04 20:49:32 <TD> i'll have a read
1911 2011-10-04 20:49:39 <gavinandresen> really? qmake make a Makefile on my mac
1912 2011-10-04 20:49:58 <TD> hmm
1913 2011-10-04 20:50:11 <luke-jr> gavinandresen: is crypto++ being removed for sure? ie, should I skip making a pullreq for qmake_system_crypto++?
1914 2011-10-04 20:50:11 <TD> ok, i see, the mac instructions suggest you use macports instead of installing boost et al directly
1915 2011-10-04 20:50:12 * b4epoche like xcode
1916 2011-10-04 20:50:13 * TD does so
1917 2011-10-04 20:51:04 <gavinandresen> luke-jr: crypto++ is almost certainly being removed.
1918 2011-10-04 20:51:26 <luke-jr> k
1919 2011-10-04 20:52:46 shadders has quit (Ping timeout: 258 seconds)
1920 2011-10-04 20:52:56 <sipa> TD: you probably understand the use cases for SIGHASH_* best
1921 2011-10-04 20:53:04 <TD> what about them?
1922 2011-10-04 20:53:18 <sipa> would you keep them inside the signature for the default case or not?
1923 2011-10-04 20:54:06 <sipa> as in: allow the signer to specify it, or by default let the payer specify it
1924 2011-10-04 20:54:25 <TD> the flags are a property of the signature. they tell you what was signed.
1925 2011-10-04 20:54:32 <TD> so clearly the signer has to specify it
1926 2011-10-04 20:54:57 * TD still isn't convinced this proposal is a good idea
1927 2011-10-04 20:55:18 <sipa> right; but would it be useful to give the payer specify (by default): the hash must be of type SIGHASH_ALL
1928 2011-10-04 20:55:40 <sipa> ").correctGrammar();
1929 2011-10-04 20:56:30 Daniel0108 has quit (Ping timeout: 252 seconds)
1930 2011-10-04 20:56:33 <TD> i'm not sure. i can't think of a use for that. it seems unnecessarily restrictive. why would you limit the recipients options like that ?
1931 2011-10-04 20:57:26 <sipa> the use is that it saves a byte, and up to now all signatures ever have been SIGHASH_ALL (iirc), so it's definitely a useful default
1932 2011-10-04 20:57:34 random_cat has quit (Remote host closed the connection)
1933 2011-10-04 20:57:35 log0s has quit (Remote host closed the connection)
1934 2011-10-04 20:58:32 Zarutian has joined
1935 2011-10-04 20:58:45 <gavinandresen> TD: somewhat-less-radical proposals here: https://gist.github.com/1262291
1936 2011-10-04 20:59:13 <TD> sipa: if you can find a way to encode the flags such that the default case takes no space, sure, but that's not the same thing as allowing the payer to specify what SIGHASH flags the recipient is allowed to use on their own signatures.
1937 2011-10-04 20:59:19 log0s has joined
1938 2011-10-04 21:00:02 <sipa> ok, i won't do that
1939 2011-10-04 21:01:18 <TD> gavinandresen: is line 40 supposed to read <hash2> ?
1940 2011-10-04 21:01:28 <gavinandresen> TD yes
1941 2011-10-04 21:01:57 snimpy has joined
1942 2011-10-04 21:02:54 snimpy has quit (Client Quit)
1943 2011-10-04 21:02:55 <TD> need to think about this more
1944 2011-10-04 21:03:06 <TD> the rationale is to allow CHECKMULTISIG without blowing the sigop count?
1945 2011-10-04 21:03:14 <gavinandresen> TD: yes
1946 2011-10-04 21:03:19 <TD> ok
1947 2011-10-04 21:04:31 Doktor99_ has joined
1948 2011-10-04 21:04:31 Doktor99 has joined
1949 2011-10-04 21:06:19 shadders has joined
1950 2011-10-04 21:06:57 elkingrey has joined
1951 2011-10-04 21:09:49 amtal has joined
1952 2011-10-04 21:10:13 snimpy has joined
1953 2011-10-04 21:11:43 zhoutong has quit (Read error: Connection reset by peer)
1954 2011-10-04 21:12:31 Doktor99 has quit (Quit: Leaving)
1955 2011-10-04 21:12:36 zhoutong has joined
1956 2011-10-04 21:12:37 marf_away has joined
1957 2011-10-04 21:13:32 <snimpy> ;;bc,blocks
1958 2011-10-04 21:13:33 <gribble> 148072
1959 2011-10-04 21:14:03 snimpy has quit (Quit: snimpy)
1960 2011-10-04 21:16:17 snimpy has joined
1961 2011-10-04 21:16:36 <snimpy> ;;bc,deepbit
1962 2011-10-04 21:16:37 <gribble> 4512629000
1963 2011-10-04 21:17:16 <snimpy> ;;bc,slushspool
1964 2011-10-04 21:17:16 <gribble> Error: "bc,slushspool" is not a valid command.
1965 2011-10-04 21:17:38 <snimpy> ;;bc,slushpool
1966 2011-10-04 21:17:39 <gribble> 1197522000
1967 2011-10-04 21:19:17 <cuqa> ;;bc,btcserv
1968 2011-10-04 21:19:17 <gribble> Error: "bc,btcserv" is not a valid command.
1969 2011-10-04 21:19:37 <snimpy> Hi
1970 2011-10-04 21:20:18 <cuqa> Hi
1971 2011-10-04 21:21:43 <snimpy> ;;bc,fx
1972 2011-10-04 21:21:46 <gribble> 1 XAU = 0.00 USD | 1 US dollar = 0.7553 euros | 1 US dollar = 1.0650 Canadian dollars | 1 US dollar = 0.6503 British pounds sterling | 1 US dollar = 1.0632 Australian dollars | 1 US dollar = 76.8600 Japanese yen | 1 US dollar = 7.7854 Hong Kong dollars | 1 BTC = 4.9393 USD
1973 2011-10-04 21:22:43 <snimpy> My first use of gribble, its exciting
1974 2011-10-04 21:23:53 <nameless> !~root@weowntheinter.net|;;ticker
1975 2011-10-04 21:23:54 <gribble> Best bid: 4.935, Best ask: 4.9383, Bid-ask spread: 0.0033, Last trade: 4.93831, 24 hour volume: 12471, 24 hour low: 4.9201, 24 hour high: 5.02675
1976 2011-10-04 21:24:34 snimpy has quit (Quit: snimpy)
1977 2011-10-04 21:24:44 <sipa> again updated, now with correct support for sighash types
1978 2011-10-04 21:27:13 <TD> the more i look at CODESEPARATOR the more inscrutable it becomes
1979 2011-10-04 21:27:23 <TD> there's an "obvious" construction using it that on closer inspection cannot ever work
1980 2011-10-04 21:28:20 <TD> in fact i wonder if this is another one of satoshis mistakes
1981 2011-10-04 21:28:32 <TD> or something that was under development but is incomplete
1982 2011-10-04 21:28:51 copumpkin has quit (Quit: Computer has gone to sleep.)
1983 2011-10-04 21:30:08 <TD> there's no point putting a separator into a scriptSig, or indeed anything that is not raw data, because the contents are never covered by any signature at all.
1984 2011-10-04 21:31:02 <TD> i thought for a while you could put a <sig> <pubkey> CHECKSIG into a scriptPubKey as a way of enforcing various properties of the spending tx, but that doesn't work either because the act of inserting the signature breaks the signed txin connection. i'm not sure what the CHECKSIG code for deleting a signature is for actually
1985 2011-10-04 21:31:13 <TD> it's never needed in the regular case
1986 2011-10-04 21:31:37 <TD> if there was a way of txins referring to transactions by simplified hash, i could see it being useful then. hmmm.
1987 2011-10-04 21:31:56 <gavinandresen> TD: good, I'm glad it's not just me who can't figure out what the heck he intended...
1988 2011-10-04 21:32:52 c00w has joined
1989 2011-10-04 21:35:21 Beremat has joined
1990 2011-10-04 21:35:24 gavinandresen has quit (Quit: gavinandresen)
1991 2011-10-04 21:37:06 tower is now known as again
1992 2011-10-04 21:39:06 random_cat has joined
1993 2011-10-04 21:39:42 lyspooner has quit (Quit: ChatZilla 0.9.87 [Firefox 3.6.23/20110920075126])
1994 2011-10-04 21:43:41 eoss has joined
1995 2011-10-04 21:44:17 eoss has quit (Remote host closed the connection)
1996 2011-10-04 21:46:51 <elkingrey> anybody know what the deal with operation fabulous is? I created a publish site days ago and haven't gotten approved. Looked up BioMike on the forums and he hasn't posted anything in over a month.
1997 2011-10-04 21:47:32 drewn has joined
1998 2011-10-04 21:48:39 E-sense has joined
1999 2011-10-04 21:48:52 t3a has joined
2000 2011-10-04 21:48:59 <TD> qt gui is snazzy
2001 2011-10-04 21:50:34 erle- has joined
2002 2011-10-04 21:51:09 shLONG has joined
2003 2011-10-04 21:53:00 inlikeflynn has quit (Read error: Connection reset by peer)
2004 2011-10-04 21:53:12 inlikeflynn has joined
2005 2011-10-04 21:53:50 c00w has quit (Ping timeout: 240 seconds)
2006 2011-10-04 21:55:38 again is now known as tower
2007 2011-10-04 21:55:56 yeah has joined
2008 2011-10-04 21:57:29 <yeah> Bitcoin design allow user set password for key? Only be able to spend btc of a specific key filling a password?
2009 2011-10-04 21:58:02 <yeah> I don't mean encrypt all wallet
2010 2011-10-04 21:58:33 <sipa> that's exactly what wallet encryption does
2011 2011-10-04 21:59:01 <sipa> only it's the same password for all keys
2012 2011-10-04 21:59:41 <luke-jr> yeah: the design is fine with it, but no client actually supports that
2013 2011-10-04 22:00:03 <yeah> But I mean: I export a private key with a password to a friend. He will only be able to spend the btc of this key filling the password I set
2014 2011-10-04 22:00:30 <sipa> use GPG or whatever encryption tool for that
2015 2011-10-04 22:00:33 <luke-jr> ^
2016 2011-10-04 22:01:12 <sipa> (read: no, as bitcoin currently doesn't even support exporting the private key, it certainly doesn't support exporting it in encrypted form)
2017 2011-10-04 22:01:15 <yeah> But he could change the password and I couldn't spend the btc with the previous password
2018 2011-10-04 22:01:25 <sipa> huh
2019 2011-10-04 22:01:34 <luke-jr> sipa: vanitygen only supports "exporting" :p
2020 2011-10-04 22:01:40 <sipa> you still have the key in your wallet, and that doesn't change
2021 2011-10-04 22:02:21 mmoya has joined
2022 2011-10-04 22:02:31 <luke-jr> yeah: he can send it to a new address
2023 2011-10-04 22:02:53 <yeah> Hum, so not possible
2024 2011-10-04 22:03:23 <sipa> i'm not sure what you want
2025 2011-10-04 22:03:37 <luke-jr> yeah: I think if you found a way to do that, you'd revolutionize cryptography.
2026 2011-10-04 22:03:46 <sipa> you want to be able a password in such a way that whoever else has that key, his password is changed as well?>
2027 2011-10-04 22:03:49 <luke-jr> sipa: he wants quantum-based crypto I think
2028 2011-10-04 22:03:56 <yeah> hehe, I'm newbie. Just discovering bitcoin
2029 2011-10-04 22:04:07 <sipa> welcome :)
2030 2011-10-04 22:04:08 <yeah> doing newbie questions
2031 2011-10-04 22:04:16 <yeah> and a bad english
2032 2011-10-04 22:04:49 <luke-jr> yeah: the block chain is all bits for now, no qubits
2033 2011-10-04 22:05:07 <yeah> I did this question: http://bitcoin.stackexchange.com/questions/1360/will-it-be-possible-to-export-a-key-and-only-allow-it-to-be-imported-once
2034 2011-10-04 22:05:29 <yeah> now I understand
2035 2011-10-04 22:06:00 Sedra has quit (Remote host closed the connection)
2036 2011-10-04 22:06:45 rerety has joined
2037 2011-10-04 22:06:48 <rerety> ok
2038 2011-10-04 22:07:11 <sipa> yeah: the best way to deal with that is to immediately issue a transaction to move the included funds away from the imported key
2039 2011-10-04 22:07:16 <rerety> smoebody here ?
2040 2011-10-04 22:07:32 rerety has quit (Client Quit)
2041 2011-10-04 22:07:39 <luke-jr> "redeem", not import
2042 2011-10-04 22:07:47 <yeah> sipa: yes, but when i did the question I was thinking in ways to not pay fee
2043 2011-10-04 22:07:58 <luke-jr> sipa: I think your import patch needs a "redeem" version that automatically transfers funds :P
2044 2011-10-04 22:08:26 <sipa> luke-jr: yes, that was the reason i started working on CWallet even :)
2045 2011-10-04 22:08:31 <gmaxwell> luke-jr: I'd suggested a general mechenism where you can mark a key as tainted and bitcoin will try to keep funds off of it. But it's a ugly double spend risk.
2046 2011-10-04 22:08:40 <luke-jr> XD
2047 2011-10-04 22:08:45 <sipa> luke-jr: so you could do an import into a memory-only separate wallet, and then move it to your real one
2048 2011-10-04 22:08:47 Sedra has joined
2049 2011-10-04 22:09:03 <gmaxwell> e.g. if your wallet is compromised you send all your funds to new addresses, then you mark all old addresses as tainted.
2050 2011-10-04 22:09:17 kish is now known as butrs
2051 2011-10-04 22:09:52 <yeah> Not laughing at me right?
2052 2011-10-04 22:09:59 <yeah> hehe
2053 2011-10-04 22:11:05 <gmaxwell> sipa: I dunno about memory only.. better to just keep the privkey around in case funds show up.
2054 2011-10-04 22:11:32 <sipa> ok, load in memory-only wallet, move, merge :)
2055 2011-10-04 22:11:35 Sedra has quit (Remote host closed the connection)
2056 2011-10-04 22:11:44 <sipa> well, if you have tainted keys, that's overkill
2057 2011-10-04 22:15:10 Pinion has joined
2058 2011-10-04 22:16:05 Sedra has joined
2059 2011-10-04 22:20:40 c00w has joined
2060 2011-10-04 22:20:42 paul0 has quit (Quit: paul0)
2061 2011-10-04 22:22:01 elkingrey has quit (Quit: Leaving)
2062 2011-10-04 22:22:20 tyn has joined
2063 2011-10-04 22:22:57 Tamo has joined
2064 2011-10-04 22:26:09 Titeuf_87 has quit (Quit: Ex-Chat)
2065 2011-10-04 22:28:30 erle- has quit (Quit: CETERVMÂAVTEMÂCENSEOÂFDPÂESSEÂDELENDVM)
2066 2011-10-04 22:30:14 Pinion has quit (Quit: Has quit)
2067 2011-10-04 22:30:17 slush has quit (Ping timeout: 248 seconds)
2068 2011-10-04 22:34:13 cenuij has quit (Remote host closed the connection)
2069 2011-10-04 22:37:52 abragin has quit (Ping timeout: 245 seconds)
2070 2011-10-04 22:38:24 yeah has quit (Quit: Page closed)
2071 2011-10-04 22:39:55 zomtec has joined
2072 2011-10-04 22:47:25 zhoutong has quit (Read error: Connection reset by peer)
2073 2011-10-04 22:48:01 DontMindMe has quit (Quit: Nettalk6 - www.ntalk.de)
2074 2011-10-04 22:48:20 zhoutong has joined
2075 2011-10-04 22:49:48 zhoutong has quit (Read error: Connection reset by peer)
2076 2011-10-04 22:50:34 zhoutong has joined
2077 2011-10-04 22:51:48 zhoutong has quit (Read error: Connection reset by peer)
2078 2011-10-04 22:52:09 Doktor99_ has quit (Ping timeout: 248 seconds)
2079 2011-10-04 22:52:38 Turingi has quit (Read error: Connection reset by peer)
2080 2011-10-04 22:52:53 zhoutong has joined
2081 2011-10-04 23:04:12 mosimo has quit (Read error: Connection reset by peer)
2082 2011-10-04 23:05:27 zhoutong has quit (Read error: Connection reset by peer)
2083 2011-10-04 23:06:07 shLONG has quit (Ping timeout: 252 seconds)
2084 2011-10-04 23:06:21 zhoutong has joined
2085 2011-10-04 23:06:40 Blitzboom has quit (Ping timeout: 252 seconds)
2086 2011-10-04 23:07:14 <mizerydearia> feedback desired for #bitcoin-tickers. Join the channel and check it out. (STILL IN DEVELOPMENT)
2087 2011-10-04 23:12:27 zhoutong has quit (Read error: Connection reset by peer)
2088 2011-10-04 23:13:19 c00w has quit (Ping timeout: 255 seconds)
2089 2011-10-04 23:13:53 zhoutong has joined
2090 2011-10-04 23:15:48 tyn has quit (Read error: Connection reset by peer)
2091 2011-10-04 23:15:49 zhoutong has quit (Read error: Connection reset by peer)
2092 2011-10-04 23:16:00 cronopio has joined
2093 2011-10-04 23:16:10 zhoutong has joined
2094 2011-10-04 23:18:52 BlueMatt-mobile has joined
2095 2011-10-04 23:19:35 copumpkin has joined
2096 2011-10-04 23:20:55 Kolky has quit (Quit: Bye bye!)
2097 2011-10-04 23:21:05 BlueMatt-mobile has quit (Client Quit)
2098 2011-10-04 23:22:15 surikator has joined
2099 2011-10-04 23:24:08 Blitzboom has joined
2100 2011-10-04 23:24:09 Blitzboom has quit (Changing host)
2101 2011-10-04 23:24:09 Blitzboom has joined
2102 2011-10-04 23:25:49 <CIA-101> poolserverj: shadders * 0b01d86ff5f0 r158 /poolserverj-main/src/main/java/com/shadworld/poolserver/db/worker/AnyWorkerFetchEngine.java: AnyWorkerDBFetchEngine
2103 2011-10-04 23:28:33 shLONG has joined
2104 2011-10-04 23:28:43 shLONG has quit (Remote host closed the connection)
2105 2011-10-04 23:31:27 tyn has joined
2106 2011-10-04 23:31:54 ThomasV has joined
2107 2011-10-04 23:33:57 TD is now known as TD[gone]
2108 2011-10-04 23:36:04 sacarlson has quit (Read error: Connection reset by peer)
2109 2011-10-04 23:39:47 c00w has joined
2110 2011-10-04 23:40:12 tcoppi has quit (Remote host closed the connection)
2111 2011-10-04 23:42:07 cjdelisle has joined
2112 2011-10-04 23:43:37 surikator has quit (Quit: Scientific discovery is just maximal compression of strings. Nothing more, nothing less.)
2113 2011-10-04 23:44:38 c00w has quit (Ping timeout: 240 seconds)
2114 2011-10-04 23:48:09 rdponticelli has quit (Ping timeout: 248 seconds)
2115 2011-10-04 23:51:30 rdponticelli has joined
2116 2011-10-04 23:52:15 b4epoche_ has joined
2117 2011-10-04 23:54:17 sacarlson has joined
2118 2011-10-04 23:54:17 zhoutong has quit (Read error: Connection reset by peer)
2119 2011-10-04 23:55:06 zhoutong has joined
2120 2011-10-04 23:55:26 ThomasV has quit (Ping timeout: 240 seconds)
2121 2011-10-04 23:56:31 BlueMatt has joined
2122 2011-10-04 23:56:53 <BlueMatt> did luke-jr just agree to pay github's legal fees?
2123 2011-10-04 23:57:08 <luke-jr> BlueMatt: no, someone else made the account
2124 2011-10-04 23:57:20 <BlueMatt> he
2125 2011-10-04 23:57:26 sneak has quit (Ping timeout: 260 seconds)
2126 2011-10-04 23:57:49 <luke-jr> I'm convinced it's a practical non-issue and wouldn't hold up in court if they tried to abuse it, so the only thing left was getting past the sign up screen without lying
2127 2011-10-04 23:58:11 <luke-jr> I'm still pushing to get crap off GitHub tho ;)
2128 2011-10-04 23:59:57 upb has joined