1 2015-11-12T00:00:07 *** evoskuil has joined #bitcoin-dev
2 2015-11-12T00:01:47 *** roxtrongo has joined #bitcoin-dev
3 2015-11-12T00:01:57 *** [1]evoskuil has joined #bitcoin-dev
4 2015-11-12T00:04:26 *** evoskuil has quit IRC
5 2015-11-12T00:04:26 *** [1]evoskuil is now known as evoskuil
6 2015-11-12T00:06:12 *** bkukowski has joined #bitcoin-dev
7 2015-11-12T00:07:13 *** bkukowski has left #bitcoin-dev
8 2015-11-12T00:12:18 *** skyraider has quit IRC
9 2015-11-12T00:14:56 *** Lightsword has quit IRC
10 2015-11-12T00:15:57 *** denisx has quit IRC
11 2015-11-12T00:18:18 *** LeMiner has joined #bitcoin-dev
12 2015-11-12T00:21:22 *** bkukowski has joined #bitcoin-dev
13 2015-11-12T00:21:32 <bkukowski> is artforz still around?
14 2015-11-12T00:21:45 <bkukowski> I haven't been here in a while
15 2015-11-12T00:22:30 *** bedeho has joined #bitcoin-dev
16 2015-11-12T00:25:00 *** cfromknecht has quit IRC
17 2015-11-12T00:25:05 *** agricocb has quit IRC
18 2015-11-12T00:25:26 *** cfromknecht has joined #bitcoin-dev
19 2015-11-12T00:26:00 *** Lightsword has joined #bitcoin-dev
20 2015-11-12T00:30:12 *** cfromknecht has quit IRC
21 2015-11-12T00:30:14 *** wallet42 has joined #bitcoin-dev
22 2015-11-12T00:30:41 *** bedeho has quit IRC
23 2015-11-12T00:30:52 *** owlhooter has joined #bitcoin-dev
24 2015-11-12T00:33:52 *** t7 has quit IRC
25 2015-11-12T00:34:19 *** DougieBot5000 has joined #bitcoin-dev
26 2015-11-12T00:34:25 *** roxtrongo has quit IRC
27 2015-11-12T00:38:20 *** agricocb has joined #bitcoin-dev
28 2015-11-12T00:39:40 *** rodkeys has quit IRC
29 2015-11-12T00:42:57 *** bedeho has joined #bitcoin-dev
30 2015-11-12T00:46:05 *** cfromknecht has joined #bitcoin-dev
31 2015-11-12T00:53:20 *** rnvk has joined #bitcoin-dev
32 2015-11-12T01:14:16 *** justanotherusr is now known as justanotheruser
33 2015-11-12T01:14:17 *** bkukowski has quit IRC
34 2015-11-12T01:20:01 *** Newyorkadam has joined #bitcoin-dev
35 2015-11-12T01:26:38 *** gribble has quit IRC
36 2015-11-12T01:28:50 *** won9 has quit IRC
37 2015-11-12T01:32:16 *** zooko has joined #bitcoin-dev
38 2015-11-12T01:32:47 *** dave4925 has quit IRC
39 2015-11-12T01:33:36 *** roconnor has joined #bitcoin-dev
40 2015-11-12T01:35:07 *** kgk has quit IRC
41 2015-11-12T01:42:03 *** one_zero has joined #bitcoin-dev
42 2015-11-12T01:42:51 *** zooko has quit IRC
43 2015-11-12T01:43:45 *** gribble has joined #bitcoin-dev
44 2015-11-12T01:43:45 *** ChanServ sets mode: +o gribble
45 2015-11-12T01:44:25 *** Ylbam has quit IRC
46 2015-11-12T01:44:38 *** altgribble` is now known as altgribble
47 2015-11-12T01:46:43 *** SkillfulHacking has joined #bitcoin-dev
48 2015-11-12T01:52:08 *** hybridsole has joined #bitcoin-dev
49 2015-11-12T01:54:43 *** moa has quit IRC
50 2015-11-12T01:57:42 *** Newyorkadam has quit IRC
51 2015-11-12T01:59:51 *** cfromknecht has quit IRC
52 2015-11-12T02:00:06 *** evoskuil has quit IRC
53 2015-11-12T02:00:12 *** cfromknecht has joined #bitcoin-dev
54 2015-11-12T02:00:39 *** evoskuil has joined #bitcoin-dev
55 2015-11-12T02:00:46 *** trippysalmon has joined #bitcoin-dev
56 2015-11-12T02:02:35 *** wallet42 has quit IRC
57 2015-11-12T02:02:42 *** wallet42 has joined #bitcoin-dev
58 2015-11-12T02:07:03 *** wallet42 has quit IRC
59 2015-11-12T02:11:03 *** neilf has quit IRC
60 2015-11-12T02:11:23 *** mrkent has joined #bitcoin-dev
61 2015-11-12T02:12:26 *** nwilcox has quit IRC
62 2015-11-12T02:13:08 *** cfromknecht has quit IRC
63 2015-11-12T02:13:36 *** cfromkne_ has joined #bitcoin-dev
64 2015-11-12T02:18:50 *** cfromkne_ has quit IRC
65 2015-11-12T02:19:13 *** Burrito has quit IRC
66 2015-11-12T02:21:34 *** rusty has joined #bitcoin-dev
67 2015-11-12T02:23:35 *** Newyorkadam has joined #bitcoin-dev
68 2015-11-12T02:24:02 *** Starduster has quit IRC
69 2015-11-12T02:25:31 *** c-cex-yuriy has quit IRC
70 2015-11-12T02:25:41 *** trippysalmon has quit IRC
71 2015-11-12T02:30:46 *** evoskuil has quit IRC
72 2015-11-12T02:31:09 *** giel__ has quit IRC
73 2015-11-12T02:31:51 *** evoskuil has joined #bitcoin-dev
74 2015-11-12T02:32:11 *** Yoghur114 has quit IRC
75 2015-11-12T02:36:50 *** brson has quit IRC
76 2015-11-12T02:37:07 *** GITNE has quit IRC
77 2015-11-12T02:40:55 <stiell> Are bare multisig outputs still considered standard? Has e.g. 1-of-2 or 2-of-3 been considered for stealth-address transactions, where one of the keys is "fake" and used for deriving the shared secret?
78 2015-11-12T02:43:00 <gmaxwell> that would only make it less efficient and not really solve any of the problems with it. (still trivially distinguishable, still high overhead, still not efficiently scanable, still has privacy problems in the sender wallet)
79 2015-11-12T02:44:52 *** Newyorkadam has quit IRC
80 2015-11-12T02:45:52 *** Newyorkadam has joined #bitcoin-dev
81 2015-11-12T02:49:49 *** jgarzik has joined #bitcoin-dev
82 2015-11-12T02:54:55 *** Newyorkadam has quit IRC
83 2015-11-12T03:04:43 *** ValicekB has quit IRC
84 2015-11-12T03:08:07 *** ValicekB has joined #bitcoin-dev
85 2015-11-12T03:09:15 <rusty> Hmm, does bitcoind prune UTXOs which touch a wallet address, or are they preserved so you can always extract history?
86 2015-11-12T03:09:35 *** mrkent has quit IRC
87 2015-11-12T03:21:11 *** jgarzik has quit IRC
88 2015-11-12T03:23:15 *** jgarzik has joined #bitcoin-dev
89 2015-11-12T03:31:22 *** kgk has joined #bitcoin-dev
90 2015-11-12T03:33:37 *** dcousens has quit IRC
91 2015-11-12T03:33:40 *** CheckDavid has quit IRC
92 2015-11-12T03:36:55 *** kgk has quit IRC
93 2015-11-12T03:37:47 *** frank1e has joined #bitcoin-dev
94 2015-11-12T03:42:15 *** matsjj has joined #bitcoin-dev
95 2015-11-12T03:46:24 *** matsjj has quit IRC
96 2015-11-12T03:46:42 *** mrkent has joined #bitcoin-dev
97 2015-11-12T03:48:41 *** dave4925 has joined #bitcoin-dev
98 2015-11-12T03:50:08 *** fanquake has quit IRC
99 2015-11-12T03:50:25 *** moa has joined #bitcoin-dev
100 2015-11-12T03:58:05 *** Subo1977 has joined #bitcoin-dev
101 2015-11-12T03:58:27 *** ploopkazoo has quit IRC
102 2015-11-12T03:59:10 *** brson has joined #bitcoin-dev
103 2015-11-12T04:01:35 *** Delta_ has quit IRC
104 2015-11-12T04:06:31 *** ploopkazoo has joined #bitcoin-dev
105 2015-11-12T04:10:21 *** Giszmo has quit IRC
106 2015-11-12T04:15:23 *** kermit has quit IRC
107 2015-11-12T04:16:59 *** stapler117 has joined #bitcoin-dev
108 2015-11-12T04:18:41 *** kermit has joined #bitcoin-dev
109 2015-11-12T04:19:02 *** CodeShark has joined #bitcoin-dev
110 2015-11-12T04:19:02 *** brson has quit IRC
111 2015-11-12T04:19:25 *** Arnavion has quit IRC
112 2015-11-12T04:19:30 *** [1]AndyOfiesh has joined #bitcoin-dev
113 2015-11-12T04:19:30 *** ItSANgo has quit IRC
114 2015-11-12T04:19:31 *** kermit has quit IRC
115 2015-11-12T04:19:41 *** [1]evoskuil has joined #bitcoin-dev
116 2015-11-12T04:19:43 *** Arnavion has joined #bitcoin-dev
117 2015-11-12T04:20:44 *** neilf has joined #bitcoin-dev
118 2015-11-12T04:21:19 *** Jokergod has joined #bitcoin-dev
119 2015-11-12T04:21:26 *** AndyOfiesh has quit IRC
120 2015-11-12T04:21:26 *** [1]AndyOfiesh is now known as AndyOfiesh
121 2015-11-12T04:21:46 *** evoskuil has quit IRC
122 2015-11-12T04:21:46 *** [1]evoskuil is now known as evoskuil
123 2015-11-12T04:22:01 *** TheSeven has quit IRC
124 2015-11-12T04:22:13 *** [7] has joined #bitcoin-dev
125 2015-11-12T04:24:14 <gmaxwell> rusty: the wallet itself keeps its own history.
126 2015-11-12T04:24:53 <rusty> gmaxwell: right... seems like I should be polling on listsinceblock, *except* that doesn't show unconfirmed txs.
127 2015-11-12T04:25:56 *** kermit has joined #bitcoin-dev
128 2015-11-12T04:25:59 *** neilf has quit IRC
129 2015-11-12T04:27:51 *** codice_ has quit IRC
130 2015-11-12T04:29:47 *** codice has joined #bitcoin-dev
131 2015-11-12T04:31:30 *** gribble has quit IRC
132 2015-11-12T04:32:12 *** kgk has joined #bitcoin-dev
133 2015-11-12T04:33:12 *** frank1e has quit IRC
134 2015-11-12T04:36:33 *** kgk has quit IRC
135 2015-11-12T04:36:35 <phantomcircuit> rusty, poll on listtransactions and just have it return lots of them :)
136 2015-11-12T04:37:49 <rusty> phantomcircuit: it was never clear to me that listtransactions was in order independent of reorgs.
137 2015-11-12T04:38:27 <rusty> phantomcircuit: thus, I figure the only way to use it is with a count of bignum, and weed out yourself.
138 2015-11-12T04:39:44 <rusty> Since I really want "tell me about any tx which touches this output", it's a bit awkward.
139 2015-11-12T04:40:32 *** robbak has joined #bitcoin-dev
140 2015-11-12T04:40:48 <CodeShark> rusty: what are you trying to do?
141 2015-11-12T04:40:58 <rusty> CodeShark: hi!
142 2015-11-12T04:41:01 <CodeShark> hello :)
143 2015-11-12T04:41:51 <rusty> CodeShark: lightning needs to know various things. When a tx reaches a certain depth (and later, if that changes due to reorg). Whenever any tx spending a certain output appears.
144 2015-11-12T04:42:32 <CodeShark> ah, yes...the need for this actually prompted much of my own projects - I've got a skeleton for a notification system that allows you to subscribe to such events
145 2015-11-12T04:42:54 <rusty> Yeah, I'm hoping to abstract it away, just want something "working" for the prototype.
146 2015-11-12T04:43:05 <CodeShark> trying to do this with the bitcoin core wallet RPC is, how shall we say...painful ;)
147 2015-11-12T04:44:01 *** wallet42 has joined #bitcoin-dev
148 2015-11-12T04:45:15 <CodeShark> it's fairly simple to do it live (just filtering tx and block relays, only need state for depth)
149 2015-11-12T04:45:39 <CodeShark> but you'll probably need a queue in case you disconnect, etc...
150 2015-11-12T04:47:10 <phantomcircuit> rusty, oh.... yeah that's not fun :P
151 2015-11-12T04:48:27 <CodeShark> I guess you can poll the RPC for the sake of prototyping
152 2015-11-12T04:48:27 *** gribble has joined #bitcoin-dev
153 2015-11-12T04:48:34 *** ChanServ sets mode: +o gribble
154 2015-11-12T04:49:19 <rusty> CodeShark: yep, that's the plan..
155 2015-11-12T04:52:52 *** aulait has joined #bitcoin-dev
156 2015-11-12T04:52:54 <CodeShark> I've got a system that does this for a particular m-of-n account structure, but I'm currently working on extending it to a broader set of cases
157 2015-11-12T04:53:30 <CodeShark> we probably want to allow for more general script templates
158 2015-11-12T04:54:23 <CodeShark> although if everything is p2sh, we can just use the redeemscript hash for all filtering
159 2015-11-12T04:56:04 *** jtimon has quit IRC
160 2015-11-12T04:56:43 <CodeShark> rusty, you can always load a filter with the txouts you're interested in and sync blocks from a given height
161 2015-11-12T04:56:57 <CodeShark> https://github.com/ciphrex/mSIGNA/blob/master/deps/CoinQ/examples/peer/src/main.cpp
162 2015-11-12T04:59:38 *** adam3us has quit IRC
163 2015-11-12T05:04:56 *** splix has joined #bitcoin-dev
164 2015-11-12T05:06:27 *** aulait has quit IRC
165 2015-11-12T05:07:02 *** aulait has joined #bitcoin-dev
166 2015-11-12T05:08:14 *** sparetire_ has quit IRC
167 2015-11-12T05:11:30 *** cfromknecht has joined #bitcoin-dev
168 2015-11-12T05:13:03 *** matsjj has joined #bitcoin-dev
169 2015-11-12T05:13:48 *** Lightsword has quit IRC
170 2015-11-12T05:17:36 *** matsjj has quit IRC
171 2015-11-12T05:18:09 *** NLNico has joined #bitcoin-dev
172 2015-11-12T05:22:21 *** SkillfulHacking has quit IRC
173 2015-11-12T05:22:41 *** Lightsword has joined #bitcoin-dev
174 2015-11-12T05:22:47 *** so has joined #bitcoin-dev
175 2015-11-12T05:27:33 <Jokergod> Hi, how are all ?
176 2015-11-12T05:28:04 *** Jokergod has quit IRC
177 2015-11-12T05:29:18 *** wallet42 has quit IRC
178 2015-11-12T05:30:59 *** ploopkazoo has quit IRC
179 2015-11-12T05:31:06 *** wallet42 has joined #bitcoin-dev
180 2015-11-12T05:33:47 *** kgk has joined #bitcoin-dev
181 2015-11-12T05:34:03 *** lnostdal_ has joined #bitcoin-dev
182 2015-11-12T05:36:53 *** shesek has joined #bitcoin-dev
183 2015-11-12T05:37:31 *** lnostdal has quit IRC
184 2015-11-12T05:39:35 *** won9 has joined #bitcoin-dev
185 2015-11-12T05:42:12 *** roxtrong_ has joined #bitcoin-dev
186 2015-11-12T05:45:00 *** adam3us has joined #bitcoin-dev
187 2015-11-12T05:49:07 *** d_t has joined #bitcoin-dev
188 2015-11-12T05:52:59 *** kgk has quit IRC
189 2015-11-12T05:57:44 *** splix_ has joined #bitcoin-dev
190 2015-11-12T05:58:21 *** splix has quit IRC
191 2015-11-12T06:02:03 *** adam3us has quit IRC
192 2015-11-12T06:03:26 *** AndyOfiesh has quit IRC
193 2015-11-12T06:08:02 *** CodeShark_ has joined #bitcoin-dev
194 2015-11-12T06:08:27 *** CodeShark_ has quit IRC
195 2015-11-12T06:08:49 *** CodeShark has quit IRC
196 2015-11-12T06:09:01 *** CodeShark_ has joined #bitcoin-dev
197 2015-11-12T06:09:11 *** CodeShark_ has quit IRC
198 2015-11-12T06:09:26 *** CodeShark has joined #bitcoin-dev
199 2015-11-12T06:12:53 *** sharperguy has joined #bitcoin-dev
200 2015-11-12T06:12:56 *** AndyOfiesh has joined #bitcoin-dev
201 2015-11-12T06:14:55 *** p15 has joined #bitcoin-dev
202 2015-11-12T06:16:45 *** roxtrong_ has quit IRC
203 2015-11-12T06:18:00 *** roxtrongo has joined #bitcoin-dev
204 2015-11-12T06:18:15 *** nivah has joined #bitcoin-dev
205 2015-11-12T06:19:39 *** adam3us has joined #bitcoin-dev
206 2015-11-12T06:29:27 *** wallet42 has quit IRC
207 2015-11-12T06:31:12 *** wallet42 has joined #bitcoin-dev
208 2015-11-12T06:33:47 *** neozaru has joined #bitcoin-dev
209 2015-11-12T06:35:21 *** adam3us has quit IRC
210 2015-11-12T06:40:37 *** wallet42 has quit IRC
211 2015-11-12T06:40:52 *** rusty has quit IRC
212 2015-11-12T06:43:12 *** ribasushi has quit IRC
213 2015-11-12T06:46:47 *** cyphase_ is now known as cyphase
214 2015-11-12T06:48:44 *** roxtrongo has quit IRC
215 2015-11-12T06:51:05 *** won9 has quit IRC
216 2015-11-12T06:51:28 *** whaack_ has joined #bitcoin-dev
217 2015-11-12T06:53:09 *** ribasushi has joined #bitcoin-dev
218 2015-11-12T06:54:01 *** Ylbam has joined #bitcoin-dev
219 2015-11-12T06:55:24 *** prosodyvVerreabC is now known as prosodyCagain
220 2015-11-12T06:55:31 *** roxtrongo has joined #bitcoin-dev
221 2015-11-12T07:02:22 *** Palsson_ has quit IRC
222 2015-11-12T07:05:07 *** twixisowned has joined #bitcoin-dev
223 2015-11-12T07:06:21 *** trixbutt has joined #bitcoin-dev
224 2015-11-12T07:07:18 *** trixbutt has quit IRC
225 2015-11-12T07:08:44 *** trixisowned has quit IRC
226 2015-11-12T07:08:48 *** whaack_ has quit IRC
227 2015-11-12T07:08:58 *** whaack has joined #bitcoin-dev
228 2015-11-12T07:09:40 *** twixisowned has quit IRC
229 2015-11-12T07:13:23 *** whaack has left #bitcoin-dev
230 2015-11-12T07:14:10 *** joepie91_ has quit IRC
231 2015-11-12T07:14:36 *** Apocalyptic has quit IRC
232 2015-11-12T07:15:56 *** rodkeys has joined #bitcoin-dev
233 2015-11-12T07:16:20 *** blueness_ has quit IRC
234 2015-11-12T07:16:20 *** segy has quit IRC
235 2015-11-12T07:16:46 *** horlicks_ has quit IRC
236 2015-11-12T07:17:02 *** bd_ has quit IRC
237 2015-11-12T07:17:07 *** Apocalyptic has joined #bitcoin-dev
238 2015-11-12T07:17:21 *** horlicks_ has joined #bitcoin-dev
239 2015-11-12T07:17:31 *** blueness_ has joined #bitcoin-dev
240 2015-11-12T07:19:17 *** segy has joined #bitcoin-dev
241 2015-11-12T07:20:33 *** Palsson_ has joined #bitcoin-dev
242 2015-11-12T07:21:56 *** roxtrongo has quit IRC
243 2015-11-12T07:22:13 *** roxtrongo has joined #bitcoin-dev
244 2015-11-12T07:22:41 *** twixisowned has joined #bitcoin-dev
245 2015-11-12T07:22:53 *** trixisowned has joined #bitcoin-dev
246 2015-11-12T07:23:33 *** joepie91_ has joined #bitcoin-dev
247 2015-11-12T07:24:26 *** bd_ has joined #bitcoin-dev
248 2015-11-12T07:25:19 *** ploopkazoo has joined #bitcoin-dev
249 2015-11-12T07:29:43 *** metalcamp has joined #bitcoin-dev
250 2015-11-12T07:29:48 *** Starduster has joined #bitcoin-dev
251 2015-11-12T07:31:26 *** neozaru has quit IRC
252 2015-11-12T07:35:55 *** sinetek has joined #bitcoin-dev
253 2015-11-12T07:36:48 *** damethos has joined #bitcoin-dev
254 2015-11-12T07:43:00 *** roxtrongo has quit IRC
255 2015-11-12T07:50:23 *** roxtrongo has joined #bitcoin-dev
256 2015-11-12T07:51:36 *** IAmNotDorian has joined #bitcoin-dev
257 2015-11-12T07:56:12 *** nivah has quit IRC
258 2015-11-12T07:56:15 *** noamh has joined #bitcoin-dev
259 2015-11-12T07:57:50 *** sharperguy has quit IRC
260 2015-11-12T08:03:19 *** sinetek has quit IRC
261 2015-11-12T08:04:11 *** sinetek has joined #bitcoin-dev
262 2015-11-12T08:05:03 *** nivah has joined #bitcoin-dev
263 2015-11-12T08:11:45 *** roxtrongo has quit IRC
264 2015-11-12T08:14:51 *** pepesza_ has joined #bitcoin-dev
265 2015-11-12T08:15:48 *** DougieBot5000 has quit IRC
266 2015-11-12T08:23:58 *** hey_joe has joined #bitcoin-dev
267 2015-11-12T08:24:57 *** twixisowned has quit IRC
268 2015-11-12T08:24:58 *** trixisowned has quit IRC
269 2015-11-12T08:26:04 *** NLNico has quit IRC
270 2015-11-12T08:26:09 *** trixisowned has joined #bitcoin-dev
271 2015-11-12T08:30:52 *** hey_joe has quit IRC
272 2015-11-12T08:36:39 *** gribble has quit IRC
273 2015-11-12T08:45:01 *** JackH has joined #bitcoin-dev
274 2015-11-12T08:48:30 *** BashCo has quit IRC
275 2015-11-12T08:51:08 <jtoomim> is anyone else having trouble mining on testnet3?
276 2015-11-12T08:51:17 *** kgk has joined #bitcoin-dev
277 2015-11-12T08:51:52 *** gribble has joined #bitcoin-dev
278 2015-11-12T08:51:53 *** ChanServ sets mode: +o gribble
279 2015-11-12T08:51:57 <jtoomim> it appears to me that there might be a bug in PoW somewhere with massive reorgs, or something like that
280 2015-11-12T08:52:21 <jtoomim> i haven't been able to mine since around the time the v4 chain overtook the v3 chain in PoW
281 2015-11-12T08:53:01 <jtoomim> CPU mining fails silently, and ASIC mining via p2pool returns this:
282 2015-11-12T08:53:06 <jtoomim> 2015-11-12 07:29:07.848005 ERROR: CheckProofOfWork(): hash doesn't match nBits
283 2015-11-12T08:53:06 <jtoomim> 2015-11-12 07:29:07.848061 ERROR: CheckBlockHeader(): proof of work failed
284 2015-11-12T08:53:06 <jtoomim> 2015-11-12 07:29:07.848113 ERROR: ProcessNewBlock: CheckBlock FAILED
285 2015-11-12T08:54:43 <jtoomim> ASIC mining via ckpool fails silently as well
286 2015-11-12T08:56:03 *** kgk has quit IRC
287 2015-11-12T08:56:36 *** Grouver has joined #bitcoin-dev
288 2015-11-12T08:58:20 *** frank1e has joined #bitcoin-dev
289 2015-11-12T08:58:43 *** matsjj has joined #bitcoin-dev
290 2015-11-12T08:58:45 *** mjerr has joined #bitcoin-dev
291 2015-11-12T09:00:04 *** tarantillo_ has quit IRC
292 2015-11-12T09:00:23 *** tarantillo_ has joined #bitcoin-dev
293 2015-11-12T09:00:57 <gmaxwell> jtoomim: bitcoin core seems to be running fine.
294 2015-11-12T09:01:20 <jtoomim> which version of core?
295 2015-11-12T09:01:34 <jtoomim> i tried 0.9.2, since it was on one of my machines, and i had the same issue
296 2015-11-12T09:02:00 <jtoomim> it might be a corrupted blockchain
297 2015-11-12T09:02:38 <jtoomim> but it's a strange issue
298 2015-11-12T09:02:46 <gmaxwell> 0.9.2 is very old and not fully compatible with the enforced on testnet by more recent software.
299 2015-11-12T09:03:04 <jtoomim> my nodes are all following the v4 chain
300 2015-11-12T09:03:11 <jtoomim> one is at 603158 right now
301 2015-11-12T09:03:47 <jtoomim> i've also got a 11.1 node which i think had exclusive control over a blockchain copy, though it wasn't running continuously
302 2015-11-12T09:03:51 <jtoomim> and it seems to be having the same issue
303 2015-11-12T09:04:14 <jtoomim> 0.11.1, sorry
304 2015-11-12T09:04:23 <jtoomim> gmaxwell, which version are you using?
305 2015-11-12T09:04:55 *** StormDev has joined #bitcoin-dev
306 2015-11-12T09:05:20 <gmaxwell> 0.11.2 and master.
307 2015-11-12T09:06:06 <jtoomim> is 11.2 v4?
308 2015-11-12T09:06:10 *** molly has quit IRC
309 2015-11-12T09:07:00 <jtoomim> yes, it is
310 2015-11-12T09:07:06 *** ThomasV has joined #bitcoin-dev
311 2015-11-12T09:07:21 <gmaxwell> block version numbers are not directly coupled to software versions... v4 and greater signals CLTV enforcement. 0.11.2, 0.10.4, and git master are CLTV supporting versions of bitcoin core.
312 2015-11-12T09:07:50 <jtoomim> i suspect that BIP65 may be implicated in this
313 2015-11-12T09:08:14 <jtoomim> as i mentioned before, the issue appeared around the time that the v4 fork overtook the v3 and BIP101 forks
314 2015-11-12T09:08:34 <gmaxwell> dubious.
315 2015-11-12T09:08:44 <jtoomim> i hope i'm hallucinating
316 2015-11-12T09:09:00 <gmaxwell> You're not even running software that has BIP65 (or BIP66 for that matter.)
317 2015-11-12T09:09:01 <jtoomim> it would be nice if someone else were to test a v3 version
318 2015-11-12T09:09:10 <jtoomim> i'm running 0.11.1
319 2015-11-12T09:09:15 <jtoomim> as well as 0.9.2
320 2015-11-12T09:09:23 <jtoomim> as well as XT 0.11B and C and D
321 2015-11-12T09:09:34 <jtoomim> D = master, sorry
322 2015-11-12T09:09:45 *** BashCo has joined #bitcoin-dev
323 2015-11-12T09:09:55 <jtoomim> the only block version i'm not running is a BIP65 one
324 2015-11-12T09:09:56 <gmaxwell> You're failing to understand my point. Your issue is local; and cannot be caused by software you do not have.
325 2015-11-12T09:10:19 <jtoomim> that's valid
326 2015-11-12T09:10:29 <gmaxwell> Your own node is rejecting the work you are giving it because it believes it does not pass the difficulty check (for whatever reason)
327 2015-11-12T09:10:31 <jtoomim> there may be a bug that was triggered by the reorg
328 2015-11-12T09:10:48 *** matsjj_ has joined #bitcoin-dev
329 2015-11-12T09:11:11 <jtoomim> i'll try rebuilding the chain to see if that helps
330 2015-11-12T09:11:12 *** frank1e has quit IRC
331 2015-11-12T09:11:20 *** GAit has joined #bitcoin-dev
332 2015-11-12T09:11:41 *** rusty has joined #bitcoin-dev
333 2015-11-12T09:12:02 *** pepesza_ has quit IRC
334 2015-11-12T09:12:39 *** matsjj has quit IRC
335 2015-11-12T09:13:12 <jtoomim> i'll probably fall asleep before the rebuild is done
336 2015-11-12T09:13:24 <jtoomim> s/rebuild/reindex/g
337 2015-11-12T09:13:46 *** melvster has quit IRC
338 2015-11-12T09:14:42 *** CoinMuncher has joined #bitcoin-dev
339 2015-11-12T09:14:54 <jtoomim> anyway, i just thought i should let you guys know, since Core at least two Core versions were also affected in my testing
340 2015-11-12T09:15:37 *** ThomasV has quit IRC
341 2015-11-12T09:16:03 *** rusty has quit IRC
342 2015-11-12T09:24:20 <drazisil> does anyone happen to have json examples of stratum chatter between a miner and p2pool?
343 2015-11-12T09:24:28 *** won9 has joined #bitcoin-dev
344 2015-11-12T09:26:58 *** melvster has joined #bitcoin-dev
345 2015-11-12T09:31:59 *** missmogg has quit IRC
346 2015-11-12T09:32:18 *** romonster has quit IRC
347 2015-11-12T09:32:23 *** IAmNotDorian has quit IRC
348 2015-11-12T09:32:23 *** lewellyn has quit IRC
349 2015-11-12T09:32:49 <jtoomim> use tcpdump
350 2015-11-12T09:34:40 *** one_zero has quit IRC
351 2015-11-12T09:36:15 <drazisil> jtoomim: thank you
352 2015-11-12T09:38:19 *** lewellyn has joined #bitcoin-dev
353 2015-11-12T09:38:22 *** romonster has joined #bitcoin-dev
354 2015-11-12T09:38:30 *** missmogg has joined #bitcoin-dev
355 2015-11-12T09:38:53 *** AaronvanW has joined #bitcoin-dev
356 2015-11-12T09:43:46 *** roxtrongo has joined #bitcoin-dev
357 2015-11-12T09:47:52 *** pepesza_ has joined #bitcoin-dev
358 2015-11-12T09:49:55 *** kadoban has quit IRC
359 2015-11-12T09:52:48 *** kgk has joined #bitcoin-dev
360 2015-11-12T09:57:10 *** kgk has quit IRC
361 2015-11-12T09:58:37 *** damethos has quit IRC
362 2015-11-12T10:00:49 *** graingert has joined #bitcoin-dev
363 2015-11-12T10:03:29 <phantomcircuit> jtoomim, there's no bug there
364 2015-11-12T10:04:23 *** roconnor has quit IRC
365 2015-11-12T10:10:24 *** IAmNotDorian has joined #bitcoin-dev
366 2015-11-12T10:14:44 *** melvster has quit IRC
367 2015-11-12T10:16:24 *** CoinMuncher1 has joined #bitcoin-dev
368 2015-11-12T10:17:35 *** CoinMuncher has quit IRC
369 2015-11-12T10:19:29 *** CoinMuncher has joined #bitcoin-dev
370 2015-11-12T10:20:46 *** CoinMuncher1 has quit IRC
371 2015-11-12T10:22:58 *** rubensayshi has joined #bitcoin-dev
372 2015-11-12T10:27:19 *** melvster has joined #bitcoin-dev
373 2015-11-12T10:34:41 *** d_t has quit IRC
374 2015-11-12T10:36:24 *** roxtrongo has quit IRC
375 2015-11-12T10:37:30 *** bedeho has quit IRC
376 2015-11-12T10:47:45 *** oleganza has joined #bitcoin-dev
377 2015-11-12T10:49:09 *** graingert_ has joined #bitcoin-dev
378 2015-11-12T10:49:17 *** damethos has joined #bitcoin-dev
379 2015-11-12T10:49:56 <oleganza> Hi there! I'd like to understand some security aspect of OP_CHECKSIG. It needs to place subscript (i.e. output script in absence of OP_CODESEPARATOR) in the txinput to compute the SignatureHash. My question is: what purpose does it have? If it was leaving all sigscripts empty, *including* the input currently being signed/verified, wouldn't it all work the same way?
380 2015-11-12T10:52:15 <gmaxwell> yes, because the txin commits to the scriptpubkey, although its a politeness for hardware wallets, in that they can know they are signing for the scriptpubkey they think they're signing for without having to send them the whole input transaction. Sadly, it doesn't include the amount, which is also critical to check.
381 2015-11-12T10:52:17 <oleganza> There could be a use case in 2009 when CODESEPARATOR was actually used, but today it seems to be a useless behaviour left for compatibility reasons.
382 2015-11-12T10:52:48 <oleganza> gmaxwell: aha, that's a fair point
383 2015-11-12T10:52:53 <gmaxwell> With OP_CODESEPARATOR's apparent original intent it would have been more useful.
384 2015-11-12T10:52:57 <oleganza> but without amount it seems rather useless
385 2015-11-12T10:53:24 *** Palsson_ has quit IRC
386 2015-11-12T10:53:35 *** graingert has quit IRC
387 2015-11-12T10:53:57 <oleganza> So if hardware wallet needs parent tx anyway to check the amount, then this subscript inclusion is otherwise useless?
388 2015-11-12T10:54:08 *** roxtrongo has joined #bitcoin-dev
389 2015-11-12T10:54:13 *** cfromknecht has quit IRC
390 2015-11-12T10:54:18 <oleganza> I mean today, in 2015 when we don't need codeseparator
391 2015-11-12T10:54:20 *** cfromknecht has joined #bitcoin-dev
392 2015-11-12T10:54:22 *** kgk has joined #bitcoin-dev
393 2015-11-12T10:55:30 <oleganza> gmaxwell: thanks for your comment
394 2015-11-12T10:55:33 <rubensayshi> there are quite a few people actually doing that without knowledge of the parent tx
395 2015-11-12T10:55:51 <rubensayshi> because of a limited amount of trust in w/e is providing the unsigned TX
396 2015-11-12T10:56:24 <gmaxwell> rubensayshi: there are _lots_ of people using "HSM"s that sign anything presented to them with no checking at all.
397 2015-11-12T10:56:43 <oleganza> which defeats the whole purpose of having HSM in the first place
398 2015-11-12T10:56:44 <gmaxwell> such moves provide virtually no security, but sound good when you rattle them off to customers. :-/
399 2015-11-12T10:56:53 <rubensayshi> hehe
400 2015-11-12T10:58:40 *** shinzaemon has joined #bitcoin-dev
401 2015-11-12T10:58:52 *** kgk has quit IRC
402 2015-11-12T10:59:34 *** paveljanik has joined #bitcoin-dev
403 2015-11-12T11:02:47 <wumpus> well they need to compromise you persistently instead of just and and nab the key. I can see how that's - somewhat- helpful for, say, certificate authorities, because there is an audit trail of every use. But not for bitcoin, no, where you can sign away everything with one transaction.
404 2015-11-12T11:03:33 *** cfromknecht has quit IRC
405 2015-11-12T11:04:20 *** moa has quit IRC
406 2015-11-12T11:04:40 <gmaxwell> in bitcoin at least you cannot sign for future transactions paid to that key, unless you keep the compromise going.
407 2015-11-12T11:04:48 <gmaxwell> but thats about the only advantage.
408 2015-11-12T11:05:32 <gmaxwell> HSM vendors are _remarkably_ resistant to having any support for customer provided business logic (and also claim that no one wants it).
409 2015-11-12T11:05:59 *** AaronvanW has quit IRC
410 2015-11-12T11:11:41 *** AaronvanW has joined #bitcoin-dev
411 2015-11-12T11:11:41 *** AaronvanW has quit IRC
412 2015-11-12T11:11:41 *** AaronvanW has joined #bitcoin-dev
413 2015-11-12T11:22:16 *** oleganza has quit IRC
414 2015-11-12T11:30:11 *** ThomasV has joined #bitcoin-dev
415 2015-11-12T11:32:51 *** rodkeys has quit IRC
416 2015-11-12T11:37:50 *** Palsson_ has joined #bitcoin-dev
417 2015-11-12T11:49:18 *** agricocb has quit IRC
418 2015-11-12T11:50:00 <wumpus> well let's say that, escaping the limits of human psychology and possibly physics, you made some piece of hw+sw finally safe, and, would you let pesky user software on it? :-)
419 2015-11-12T11:51:05 <gmaxwell> true, users seem to be the root of all problems. kill all the users!
420 2015-11-12T11:51:12 <wumpus> yeah!
421 2015-11-12T11:51:55 <gmaxwell> you'd think they'd still have some competative advantage by building in some super sandbox (I don't even care if its pretty slow) but it seems most people don't ask for this and are perfectly happy with the black box that signs anything. :)
422 2015-11-12T11:55:21 *** kgk has joined #bitcoin-dev
423 2015-11-12T11:56:23 <wumpus> sure, I agree, at some point it's just "a computer with carefully controlled interface, tamper protection, and extensive logging", and I'm sure there is a market for that
424 2015-11-12T11:59:57 *** kgk has quit IRC
425 2015-11-12T12:05:46 *** jtimon has joined #bitcoin-dev
426 2015-11-12T12:12:52 *** GAit has quit IRC
427 2015-11-12T12:14:14 *** Hasimir has quit IRC
428 2015-11-12T12:14:22 *** Khayman has joined #bitcoin-dev
429 2015-11-12T12:14:28 *** TheAdversary has quit IRC
430 2015-11-12T12:14:41 *** TheAdversary has joined #bitcoin-dev
431 2015-11-12T12:15:46 *** Khayman is now known as Hasimir
432 2015-11-12T12:20:19 *** GAit has joined #bitcoin-dev
433 2015-11-12T12:21:23 *** mjerr has quit IRC
434 2015-11-12T12:25:34 *** cryptapus_ has joined #bitcoin-dev
435 2015-11-12T12:25:34 *** cryptapus_ has joined #bitcoin-dev
436 2015-11-12T12:27:27 *** mrkent has quit IRC
437 2015-11-12T12:30:35 <jonasschnelli> Oh. I missed the hardware wallet discussion.
438 2015-11-12T12:31:29 *** melvster has quit IRC
439 2015-11-12T12:31:33 *** metalcamp has quit IRC
440 2015-11-12T12:32:16 <jonasschnelli> <oleganza> [11:53:57] So if hardware wallet needs parent tx anyway to check the amount, [...]? Right. Without the inputs you can't verify the fees of the transaction your are going to sign.
441 2015-11-12T12:33:55 <jonasschnelli> and i agree with wumpus: hw-wallet not automatically increase the users security. But the have the potential to sign data in a very secure way, if done right.
442 2015-11-12T12:34:17 <jonasschnelli> We all know that keeping private keys on a standard computer is by default a bad idea.
443 2015-11-12T12:35:23 <jonasschnelli> As wumpus mentioned, hardware wallets are tiny computers that are trying to reduce I/O to a minimum
444 2015-11-12T12:37:46 *** nivah has quit IRC
445 2015-11-12T12:41:20 *** Palsson_ has quit IRC
446 2015-11-12T12:42:35 *** metalcamp has joined #bitcoin-dev
447 2015-11-12T12:44:48 *** melvster has joined #bitcoin-dev
448 2015-11-12T12:45:43 <wumpus> "We all know that keeping private keys on a standard computer is by default a bad idea" yep. too much malware that just nabs wallet.dat (as well as does keylogging). Anything that makes attacks harder and more expensive is good. gmaxwell's point was that HSMs that just dumbly sign everything withoout user confirmation or checking are not very useful for bitcoin.
449 2015-11-12T12:46:07 <jonasschnelli> Right. This is the hard part.
450 2015-11-12T12:47:16 <jonasschnelli> The software i'm working on, will allow to 2FA-lock the hardware wallet. Transactions can only be signed by entering a second factor, retrievable over a smartphone by verifing the data to sign.
451 2015-11-12T12:47:52 <jonasschnelli> The hardware wallet and the smartphone need to be paired once over a ECDH pattern.
452 2015-11-12T12:49:13 <jonasschnelli> An attacker would require to MITM your PC, forge a transaction, break your ECDH/AES256 or additionally root access your smartphone.
453 2015-11-12T12:49:34 <jonasschnelli> All possible but much harder than hacking/stealing something like "wallet.dat".
454 2015-11-12T12:51:12 *** Hasimir has quit IRC
455 2015-11-12T12:52:23 *** TheAdversary has quit IRC
456 2015-11-12T12:52:34 *** markus-k has joined #bitcoin-dev
457 2015-11-12T12:52:53 *** oleganza has joined #bitcoin-dev
458 2015-11-12T12:53:32 *** metalcamp has quit IRC
459 2015-11-12T12:54:38 <wumpus> right - most automated attacks will hit either your PC or your smartphone, not both. Targeted attacks might, but it's at least a higher bar.
460 2015-11-12T12:56:35 *** Hasimir has joined #bitcoin-dev
461 2015-11-12T12:57:09 <jonasschnelli> Right, and you can always increase security by adding another multisig participant (another hardware wallet [maybe from another vendor], or another smartphone, etc.).
462 2015-11-12T12:57:24 <jonasschnelli> Just make sure you still know which smartphone participates in which wallet...
463 2015-11-12T12:57:45 <jonasschnelli> and the risk of missing or losing a backup gets higher...
464 2015-11-12T12:57:58 *** TheAdversary has joined #bitcoin-dev
465 2015-11-12T12:58:16 <wumpus> that's the other risk that has to be balanced, risk of loss
466 2015-11-12T12:59:56 *** go1111111 has quit IRC
467 2015-11-12T13:01:36 *** GAit has quit IRC
468 2015-11-12T13:02:09 *** won9 has quit IRC
469 2015-11-12T13:02:11 *** go1111111 has joined #bitcoin-dev
470 2015-11-12T13:07:35 *** Palsson_ has joined #bitcoin-dev
471 2015-11-12T13:09:51 *** fkhan has quit IRC
472 2015-11-12T13:10:08 *** p15x has joined #bitcoin-dev
473 2015-11-12T13:10:16 *** GAit has joined #bitcoin-dev
474 2015-11-12T13:12:29 *** StormDev has quit IRC
475 2015-11-12T13:12:55 *** StormDev has joined #bitcoin-dev
476 2015-11-12T13:17:19 *** mjerr has joined #bitcoin-dev
477 2015-11-12T13:20:21 *** GITNE has joined #bitcoin-dev
478 2015-11-12T13:24:44 *** fkhan has joined #bitcoin-dev
479 2015-11-12T13:25:15 *** ThomasKeller has quit IRC
480 2015-11-12T13:27:05 *** ThomasKeller has joined #bitcoin-dev
481 2015-11-12T13:27:36 *** h3xc0d3r has joined #bitcoin-dev
482 2015-11-12T13:30:47 *** metalcamp has joined #bitcoin-dev
483 2015-11-12T13:41:25 *** hashtag has quit IRC
484 2015-11-12T13:45:40 *** jgarzik has quit IRC
485 2015-11-12T13:49:38 *** fkhan has quit IRC
486 2015-11-12T13:51:43 *** molly has joined #bitcoin-dev
487 2015-11-12T13:53:11 *** gielbier has joined #bitcoin-dev
488 2015-11-12T13:53:27 *** gielbier has quit IRC
489 2015-11-12T13:53:28 *** gielbier has joined #bitcoin-dev
490 2015-11-12T13:55:40 *** Exxpre has joined #bitcoin-dev
491 2015-11-12T13:57:30 *** kgk has joined #bitcoin-dev
492 2015-11-12T13:58:33 *** roxtrongo has quit IRC
493 2015-11-12T14:01:09 *** jtimon has quit IRC
494 2015-11-12T14:02:03 *** kgk has quit IRC
495 2015-11-12T14:07:38 <Exxpre> hello guys, i am working on developing a wallet.
496 2015-11-12T14:07:57 <Exxpre> looking for help on storing users wallet structure
497 2015-11-12T14:08:11 <jonasschnelli> Exxpre: sure. what db/format are you using right now?
498 2015-11-12T14:08:28 <jonasschnelli> what language your are working with?
499 2015-11-12T14:08:57 *** BashCo has quit IRC
500 2015-11-12T14:13:53 *** tantalum has joined #bitcoin-dev
501 2015-11-12T14:16:27 *** agricocb has joined #bitcoin-dev
502 2015-11-12T14:23:02 *** DatBeeDoe has joined #bitcoin-dev
503 2015-11-12T14:23:24 *** DatBeeDoe has quit IRC
504 2015-11-12T14:23:58 *** jgarzik has joined #bitcoin-dev
505 2015-11-12T14:23:58 *** jgarzik has quit IRC
506 2015-11-12T14:23:58 *** jgarzik has joined #bitcoin-dev
507 2015-11-12T14:24:49 *** Guyver2 has joined #bitcoin-dev
508 2015-11-12T14:27:02 *** mikmcf has joined #bitcoin-dev
509 2015-11-12T14:27:17 *** Grouver has quit IRC
510 2015-11-12T14:28:59 *** ThomasV has quit IRC
511 2015-11-12T14:30:36 *** noamh has quit IRC
512 2015-11-12T14:30:39 *** fkhan has joined #bitcoin-dev
513 2015-11-12T14:31:07 *** Palsson_ has quit IRC
514 2015-11-12T14:31:43 *** noamh has joined #bitcoin-dev
515 2015-11-12T14:32:23 *** Guyver2 has quit IRC
516 2015-11-12T14:33:24 *** Guyver2 has joined #bitcoin-dev
517 2015-11-12T14:34:04 *** Palsson_ has joined #bitcoin-dev
518 2015-11-12T14:34:29 *** zviratko has joined #bitcoin-dev
519 2015-11-12T14:39:30 *** agricocb has quit IRC
520 2015-11-12T14:43:23 *** Exxpre has quit IRC
521 2015-11-12T14:49:29 *** agricocb has joined #bitcoin-dev
522 2015-11-12T14:55:54 *** noamh has quit IRC
523 2015-11-12T14:57:54 *** noamh has joined #bitcoin-dev
524 2015-11-12T14:58:04 *** timothy has joined #bitcoin-dev
525 2015-11-12T14:59:03 *** kgk has joined #bitcoin-dev
526 2015-11-12T15:03:29 *** ItSANgo has joined #bitcoin-dev
527 2015-11-12T15:03:30 *** kgk has quit IRC
528 2015-11-12T15:11:23 *** Ahmed90 has joined #bitcoin-dev
529 2015-11-12T15:19:42 *** btc_panhandler has joined #bitcoin-dev
530 2015-11-12T15:20:00 *** Lightsword has quit IRC
531 2015-11-12T15:23:51 *** ParadoxSpiral has joined #bitcoin-dev
532 2015-11-12T15:26:24 *** ThomasV has joined #bitcoin-dev
533 2015-11-12T15:28:24 *** treehug88 has joined #bitcoin-dev
534 2015-11-12T15:31:10 *** markus-k has quit IRC
535 2015-11-12T15:33:50 *** adam3us has joined #bitcoin-dev
536 2015-11-12T15:34:21 *** roxtrongo has joined #bitcoin-dev
537 2015-11-12T15:36:47 *** akrmn has quit IRC
538 2015-11-12T15:37:33 *** damethos has quit IRC
539 2015-11-12T15:37:49 *** damethos has joined #bitcoin-dev
540 2015-11-12T15:38:17 *** pepesza has joined #bitcoin-dev
541 2015-11-12T15:38:34 *** sparetire_ has joined #bitcoin-dev
542 2015-11-12T15:39:14 *** Giszmo has joined #bitcoin-dev
543 2015-11-12T15:39:19 *** benrcole has joined #bitcoin-dev
544 2015-11-12T15:39:36 *** nwilcox has joined #bitcoin-dev
545 2015-11-12T15:41:10 *** pepesza_ has quit IRC
546 2015-11-12T15:42:55 *** ThomasV has quit IRC
547 2015-11-12T15:43:16 *** damethos has quit IRC
548 2015-11-12T15:43:53 *** noobfikt has quit IRC
549 2015-11-12T15:46:42 *** shinzaemon has quit IRC
550 2015-11-12T15:48:42 *** zooko has joined #bitcoin-dev
551 2015-11-12T15:49:52 *** jtimon has joined #bitcoin-dev
552 2015-11-12T15:50:12 *** noobfikt has joined #bitcoin-dev
553 2015-11-12T15:52:02 *** Palsson_ has quit IRC
554 2015-11-12T15:56:31 *** DougieBot5000 has joined #bitcoin-dev
555 2015-11-12T15:56:53 *** roxtrong_ has joined #bitcoin-dev
556 2015-11-12T16:01:06 *** roxtrongo has quit IRC
557 2015-11-12T16:03:35 *** adam3us has quit IRC
558 2015-11-12T16:03:38 *** sinetek has quit IRC
559 2015-11-12T16:05:07 *** sinetek has joined #bitcoin-dev
560 2015-11-12T16:05:28 *** noamh has quit IRC
561 2015-11-12T16:06:19 *** zooko has quit IRC
562 2015-11-12T16:06:42 *** sinetek has quit IRC
563 2015-11-12T16:09:30 *** sinetek has joined #bitcoin-dev
564 2015-11-12T16:11:10 *** scosant has quit IRC
565 2015-11-12T16:12:05 *** nwilcox has quit IRC
566 2015-11-12T16:15:07 *** rolandnsharp has quit IRC
567 2015-11-12T16:15:21 *** rolandnsharp has joined #bitcoin-dev
568 2015-11-12T16:16:02 *** _yoy_ has quit IRC
569 2015-11-12T16:16:47 *** _yoy_ has joined #bitcoin-dev
570 2015-11-12T16:17:47 *** damethos has joined #bitcoin-dev
571 2015-11-12T16:17:57 *** IAmNotDorian has quit IRC
572 2015-11-12T16:18:45 *** StormDev has quit IRC
573 2015-11-12T16:19:38 *** ThomasV has joined #bitcoin-dev
574 2015-11-12T16:23:50 *** ribasushi has quit IRC
575 2015-11-12T16:25:44 *** IngCr3at1on has joined #bitcoin-dev
576 2015-11-12T16:25:57 *** oleganza has quit IRC
577 2015-11-12T16:28:09 *** nwilcox has joined #bitcoin-dev
578 2015-11-12T16:28:24 *** pepesza has quit IRC
579 2015-11-12T16:29:57 *** damethos has quit IRC
580 2015-11-12T16:30:25 *** damethos has joined #bitcoin-dev
581 2015-11-12T16:32:02 *** wraithm has joined #bitcoin-dev
582 2015-11-12T16:32:45 *** zooko has joined #bitcoin-dev
583 2015-11-12T16:35:52 *** Lightsword has joined #bitcoin-dev
584 2015-11-12T16:36:27 <jtoomim> jonasschnelli gmaxwell probably user error then. thanks for checking.
585 2015-11-12T16:36:39 <jtoomim> oops phantomcircuit not jonash
586 2015-11-12T16:37:29 *** splix_ has quit IRC
587 2015-11-12T16:38:27 *** roxtrong_ has quit IRC
588 2015-11-12T16:38:29 *** ribasushi has joined #bitcoin-dev
589 2015-11-12T16:45:21 *** benrcole has quit IRC
590 2015-11-12T16:47:03 *** Abstrct has joined #bitcoin-dev
591 2015-11-12T16:48:17 *** rubensayshi has quit IRC
592 2015-11-12T16:48:51 *** Diablo-D3 has quit IRC
593 2015-11-12T16:51:20 <Abstrct> Hi folks, I'm looking to run an alpha test for a project I'm working on but I want to be able to give my testers some testnet coins. Is there somewhere (other than setting up miners) I can get something more substantial than whats available through a faucet?
594 2015-11-12T16:52:26 <sturles> Asking here is a good start. I think e.g. phantomcircuit has lots of testnetcoins.
595 2015-11-12T16:52:57 *** d_t has joined #bitcoin-dev
596 2015-11-12T16:53:42 *** Diablo-D3 has joined #bitcoin-dev
597 2015-11-12T16:54:27 *** meLon has quit IRC
598 2015-11-12T16:56:00 <Abstrct> Great! Nice to hear I'm on the right track.
599 2015-11-12T16:56:44 <phantomcircuit> Abstrct, how many you want??
600 2015-11-12T16:56:59 <phantomcircuit> no but seriously https://tpfaucet.appspot.com/
601 2015-11-12T16:57:02 <phantomcircuit> that one works
602 2015-11-12T16:57:26 *** mikmcf has quit IRC
603 2015-11-12T16:58:17 *** d_t has quit IRC
604 2015-11-12T16:58:18 <Abstrct> I would like to be able to give each tester at least 5, with between 5-10 people testing.
605 2015-11-12T16:58:58 <Abstrct> I have managed to grab some off of faucets but I also don't want to drain every faucet out there as that seems like a jerk move
606 2015-11-12T17:00:47 *** adam3us has joined #bitcoin-dev
607 2015-11-12T17:01:21 *** kgk has joined #bitcoin-dev
608 2015-11-12T17:01:51 <phantomcircuit> Abstrct, i regularly refill that faucet
609 2015-11-12T17:03:15 <Abstrct> Alright, well I will just hit it for a couple days then. Thanks for keeping it filled :)
610 2015-11-12T17:06:06 *** kgk has quit IRC
611 2015-11-12T17:06:55 <Abstrct> Thanks for the quick replies - have a good one
612 2015-11-12T17:07:13 *** Abstrct has left #bitcoin-dev
613 2015-11-12T17:08:27 *** alb12_ has quit IRC
614 2015-11-12T17:10:15 *** IrishGringo has joined #bitcoin-dev
615 2015-11-12T17:13:06 *** ThomasV has quit IRC
616 2015-11-12T17:13:37 *** splix has joined #bitcoin-dev
617 2015-11-12T17:13:54 *** venzen has quit IRC
618 2015-11-12T17:14:08 *** splix has quit IRC
619 2015-11-12T17:14:20 *** ishahnaz has joined #bitcoin-dev
620 2015-11-12T17:14:38 *** bedeho has joined #bitcoin-dev
621 2015-11-12T17:18:05 *** mikmcf has joined #bitcoin-dev
622 2015-11-12T17:18:35 *** adam3us has quit IRC
623 2015-11-12T17:18:45 *** mikmcf has quit IRC
624 2015-11-12T17:18:55 *** ThomasV has joined #bitcoin-dev
625 2015-11-12T17:23:45 *** adam3us has joined #bitcoin-dev
626 2015-11-12T17:26:27 *** GAit has quit IRC
627 2015-11-12T17:26:55 *** GAit has joined #bitcoin-dev
628 2015-11-12T17:27:17 *** kadoban has joined #bitcoin-dev
629 2015-11-12T17:36:13 *** nwilcox_ has joined #bitcoin-dev
630 2015-11-12T17:36:43 *** meLon has joined #bitcoin-dev
631 2015-11-12T17:37:52 *** meLon has quit IRC
632 2015-11-12T17:38:21 *** nwilcox has quit IRC
633 2015-11-12T17:38:24 *** meLon has joined #bitcoin-dev
634 2015-11-12T17:38:44 *** brson has joined #bitcoin-dev
635 2015-11-12T17:38:56 *** meLon has joined #bitcoin-dev
636 2015-11-12T17:41:57 *** ishahnaz has quit IRC
637 2015-11-12T17:42:23 *** ThomasV has quit IRC
638 2015-11-12T17:45:57 *** skyraider has joined #bitcoin-dev
639 2015-11-12T17:46:30 *** graingert_ has quit IRC
640 2015-11-12T17:52:32 *** adam3us has quit IRC
641 2015-11-12T17:53:46 *** sharperguy has joined #bitcoin-dev
642 2015-11-12T17:54:23 *** cfromknecht has joined #bitcoin-dev
643 2015-11-12T17:57:18 *** paulo_ has joined #bitcoin-dev
644 2015-11-12T17:57:38 *** adam3us has joined #bitcoin-dev
645 2015-11-12T18:01:38 *** benrcole has joined #bitcoin-dev
646 2015-11-12T18:02:00 *** Elglobo has quit IRC
647 2015-11-12T18:02:48 *** kgk has joined #bitcoin-dev
648 2015-11-12T18:03:14 *** Elglobo has joined #bitcoin-dev
649 2015-11-12T18:03:40 *** CheckDavid has joined #bitcoin-dev
650 2015-11-12T18:04:39 *** benrcole1 has joined #bitcoin-dev
651 2015-11-12T18:05:03 *** benrcole has quit IRC
652 2015-11-12T18:07:43 *** kgk has quit IRC
653 2015-11-12T18:07:43 *** nwilcox_ has quit IRC
654 2015-11-12T18:08:55 *** damethos has quit IRC
655 2015-11-12T18:12:43 *** neilf has joined #bitcoin-dev
656 2015-11-12T18:21:15 *** oleganza has joined #bitcoin-dev
657 2015-11-12T18:21:44 *** adam3us has quit IRC
658 2015-11-12T18:22:55 *** IrishGringo has quit IRC
659 2015-11-12T18:29:52 *** timothy has quit IRC
660 2015-11-12T18:35:46 *** mjerr has quit IRC
661 2015-11-12T18:36:22 *** nwilcox has joined #bitcoin-dev
662 2015-11-12T18:36:35 *** cyphase has quit IRC
663 2015-11-12T18:41:34 *** mrkent has joined #bitcoin-dev
664 2015-11-12T18:44:30 *** morcos has quit IRC
665 2015-11-12T18:45:41 *** morcos has joined #bitcoin-dev
666 2015-11-12T18:47:47 *** coin_trader has joined #bitcoin-dev
667 2015-11-12T18:49:53 *** ahmed__ is now known as ahmed_
668 2015-11-12T18:50:06 *** p15x has quit IRC
669 2015-11-12T18:50:29 *** wraithm has quit IRC
670 2015-11-12T18:50:29 *** p15 has quit IRC
671 2015-11-12T18:50:31 *** urup has joined #bitcoin-dev
672 2015-11-12T18:51:32 *** GAit has quit IRC
673 2015-11-12T18:53:39 *** GAit has joined #bitcoin-dev
674 2015-11-12T18:55:47 *** neilf has quit IRC
675 2015-11-12T18:56:02 *** damethos has joined #bitcoin-dev
676 2015-11-12T18:56:31 *** ratbanebo has joined #bitcoin-dev
677 2015-11-12T18:59:00 *** d_t has joined #bitcoin-dev
678 2015-11-12T18:59:04 *** d_t has quit IRC
679 2015-11-12T18:59:06 *** Beef has quit IRC
680 2015-11-12T18:59:41 *** d_t has joined #bitcoin-dev
681 2015-11-12T18:59:44 *** d_t has quit IRC
682 2015-11-12T19:00:20 *** d_t has joined #bitcoin-dev
683 2015-11-12T19:00:23 *** d_t has quit IRC
684 2015-11-12T19:00:30 <gmaxwell> Meeting?
685 2015-11-12T19:00:32 <petertodd> yup
686 2015-11-12T19:00:54 <jtimon> here
687 2015-11-12T19:00:58 *** d_t has joined #bitcoin-dev
688 2015-11-12T19:01:03 <jonasschnelli> Yes
689 2015-11-12T19:01:10 <morcos> Suggested topic: What to do about priority for 0.12? (besides cry)
690 2015-11-12T19:01:24 <wumpus> #meetingstart
691 2015-11-12T19:01:42 <wumpus> #startmeeting
692 2015-11-12T19:01:42 <lightningbot> Meeting started Thu Nov 12 19:01:42 2015 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
693 2015-11-12T19:01:42 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
694 2015-11-12T19:01:43 <BlueMatt> morcos: that
695 2015-11-12T19:01:52 *** Beef has joined #bitcoin-dev
696 2015-11-12T19:02:03 <wumpus> #topic What to do about priority for 0.12? (besides cry)
697 2015-11-12T19:02:13 *** ebfull has joined #bitcoin-dev
698 2015-11-12T19:02:35 <petertodd> morcos: ditch it for now IMO, and work on a more general mechanism to get arbitrary txs propagated (perhaps priority, perhaps hashcash, maybe both!)
699 2015-11-12T19:02:45 *** GreenIsMyPepper_ is now known as GreenIsMyPepper
700 2015-11-12T19:03:01 <BlueMatt> remove priority entirely
701 2015-11-12T19:03:01 *** sipa has joined #bitcoin-dev
702 2015-11-12T19:03:03 <phantomcircuit> wumpus, the wallet needs to be fixed... that is all
703 2015-11-12T19:03:07 <morcos> So as I commented on sdaftuars #6992, what I care most about is having 0.12 have a nice consistent state
704 2015-11-12T19:03:16 <BlueMatt> yes, remove all priority is consistent :)
705 2015-11-12T19:03:21 <morcos> semi-supporting priority in a broken manner is bad
706 2015-11-12T19:03:41 <jtimon> ack on removing enterely, it will be more disruptive the longer we wait
707 2015-11-12T19:03:45 <BlueMatt> we still have the fee adjustment RPC for miners that need to adjust fees, and we can (maybe) use that later to add our own default adjustments if people cry too much, though I'd rather not
708 2015-11-12T19:03:46 <sdaftuar> well i think pulling priority entirely without ever having warned is too abrupt
709 2015-11-12T19:03:52 <morcos> BlueMatt: I'm ok with that if its politically feasible, but seems like we should have communicated on the -dev list a long time ago and would maybe have gotten some pushback
710 2015-11-12T19:03:56 <jtimon> and we will remove it eventually
711 2015-11-12T19:03:59 <sipa> sdaftuar: agree
712 2015-11-12T19:04:18 <petertodd> morcos: not that many people use priority, particularly since even right now it's not very reliable and hard to calculate
713 2015-11-12T19:04:22 *** kgk has joined #bitcoin-dev
714 2015-11-12T19:04:23 *** urup has quit IRC
715 2015-11-12T19:04:27 <sdaftuar> i proposed a staggered approach in #6992 -- let's let people know we're deprecating, and then plan to pull it in the next release
716 2015-11-12T19:04:31 <BlueMatt> the only people who use priority are devs, pretty much
717 2015-11-12T19:04:36 <BlueMatt> I dont think we need much time to announce
718 2015-11-12T19:04:38 <sdaftuar> and in 0.12 we can default the blockprioritysize to 0
719 2015-11-12T19:05:05 <petertodd> sdaftuar: well, the upgrade path is itself a staggered approach - not everyone will got to v0.12.0 instantly, and you don't need 100% to propagate reasonably well
720 2015-11-12T19:05:08 <phantomcircuit> we've made the mistake in the past of failing to communicate well that something will not work long term
721 2015-11-12T19:05:13 <petertodd> phantomcircuit: +1
722 2015-11-12T19:05:13 <phantomcircuit> lets not make that mistake again
723 2015-11-12T19:05:27 <morcos> yes, but that starts with communicate
724 2015-11-12T19:05:37 <petertodd> sdaftuar: also, XT will likely keep priority, which gives people an option
725 2015-11-12T19:06:00 <phantomcircuit> morcos, "this is now deprecated" afaict no wallet outside of bitcoin core implements priority calculations
726 2015-11-12T19:06:05 <CodeShark> not really an option if you can't pick and choose granularly :)
727 2015-11-12T19:06:12 <jtimon> action item communicate it on the ml?
728 2015-11-12T19:06:24 <gavinandresen> Whatâs the plan to mitigate the âspend money on fees, crowd out everybody elseâs transactionsâ attack if priority goes away?
729 2015-11-12T19:06:46 <BlueMatt> gavinandresen: that is bitcoin
730 2015-11-12T19:06:48 <phantomcircuit> gavinandresen, there isn't a plan because that's a fundamental property of the system
731 2015-11-12T19:07:06 <phantomcircuit> if someone wants to blow wads of cash on trying to break things they can buy miners just as easily
732 2015-11-12T19:07:09 <petertodd> gavinandresen: those attacks are horribly expensive...
733 2015-11-12T19:07:39 <petertodd> phantomcircuit: exactly - as fees pay more of miners' incomes, those attacks become as expensive as just 51% attacking the network anyway
734 2015-11-12T19:07:42 <gavinandresen> petertodd: really? I thought the latest spam attack showed it was fairly chieap....
735 2015-11-12T19:07:56 <petertodd> gavinandresen: yes, but it was also ineffective at stopping normal users from sending txs
736 2015-11-12T19:07:58 <CodeShark> about all we can do is make it expensive - but economics dictates that sufficiently well-funded adversaries can attack the network
737 2015-11-12T19:08:05 <morcos> gavinandresen: tx fees to get mined quickly never went up that high
738 2015-11-12T19:08:09 <petertodd> gavinandresen: that's why we have fee estimation, replace-by-fee, CPFP etc.
739 2015-11-12T19:08:11 <gavinandresen> If the plan is âsmarter wallets that raise fees appropriatelyâ then great. That needs to be communicated.
740 2015-11-12T19:08:17 <petertodd> gavinandresen: we already have that
741 2015-11-12T19:08:21 <BlueMatt> gavinandresen: wallets already did that
742 2015-11-12T19:08:26 *** rodkeys has joined #bitcoin-dev
743 2015-11-12T19:08:31 <phantomcircuit> gavinandresen, that is the plan and has been communicated directly to all of the wallet devs for months
744 2015-11-12T19:08:32 <BlueMatt> that was +/- the only impact the spam attack had
745 2015-11-12T19:08:38 <BlueMatt> (well, that and the relay network :((( )
746 2015-11-12T19:08:46 *** kgk has quit IRC
747 2015-11-12T19:08:53 <phantomcircuit> indeed if you open up the google you will find many of them implemented dynamic fees without the last few months
748 2015-11-12T19:09:03 <sipa> well at least bitcoin core's wallet will need to support that too!
749 2015-11-12T19:09:22 <BlueMatt> we have the fee estimator stuff?
750 2015-11-12T19:09:23 <BlueMatt> its not bad
751 2015-11-12T19:09:28 <petertodd> sipa: AFAIK many of the wallet providers use bitcoin core's fee estimation
752 2015-11-12T19:09:37 <BlueMatt> in fact, many people "implemented dynaic fees" buy just using bitcoin core's
753 2015-11-12T19:10:03 <morcos> please review #6134 on that note!
754 2015-11-12T19:10:15 *** neilf has joined #bitcoin-dev
755 2015-11-12T19:10:16 <sipa> petertodd: hmm, that's good for a baseline, but i would expect that some mechanism to respend with higher fees is available
756 2015-11-12T19:10:19 <BlueMatt> anyway, back to the actual topic....
757 2015-11-12T19:10:30 <BlueMatt> I think removing priority in 0.12 is fine
758 2015-11-12T19:10:37 <morcos> ok, will someone volunteer to email -dev and let them know this is the plan then?
759 2015-11-12T19:10:39 <BlueMatt> if it is announced in the next weeks
760 2015-11-12T19:10:42 <BlueMatt> morcos: willdo
761 2015-11-12T19:10:53 <wumpus> #action please review #6134 (Improve usage of fee estimation code)
762 2015-11-12T19:10:58 <jtimon> sipa: that makes some form of RBF a priority
763 2015-11-12T19:11:07 <petertodd> sipa: mycelium for example has multiple levels of fees that you can easily select
764 2015-11-12T19:11:14 <BlueMatt> next topic: rbf for 0.12?
765 2015-11-12T19:11:22 <BlueMatt> (though i think the answer there may just be "YES")
766 2015-11-12T19:11:24 <morcos> then i think we could skip sdaftuar's 6992 and we could skip dynamic priority 6357
767 2015-11-12T19:11:27 <morcos> (hold on)
768 2015-11-12T19:11:32 <wumpus> RBF: https://github.com/bitcoin/bitcoin/pull/6871
769 2015-11-12T19:11:53 <morcos> but we'll be having another regression in the mining code, by making those who still want to mine by priority, only have access to starting priority
770 2015-11-12T19:12:00 <morcos> is that also an ok regression?
771 2015-11-12T19:12:11 <BlueMatt> morcos: we could rip out all priority stuff in 0.12?
772 2015-11-12T19:12:17 <morcos> we should also default block priority size to 0 and comment about further deprecation in the future
773 2015-11-12T19:12:27 <petertodd> morcos: well, a lot of miners have turned off priority anyway; I'd let them make that decision and give us some feedback
774 2015-11-12T19:12:46 <BlueMatt> morcos: we could backport default block priority size to 0....
775 2015-11-12T19:12:57 <BlueMatt> but i wouldnt think we should
776 2015-11-12T19:13:22 <sipa> ... i just wished we could replace priority with an adjusted fee metric...
777 2015-11-12T19:13:38 <gavinandresen> morcos: yes, I think that is an OK regression.
778 2015-11-12T19:13:45 <morcos> thanks gavinandresen
779 2015-11-12T19:13:52 <btcdrak> sipa: what would that look like?
780 2015-11-12T19:13:56 *** jtoomim_ has joined #bitcoin-dev
781 2015-11-12T19:14:04 <CodeShark> it ultimately is a balance between rational behavior and how lazy miners are in changing defaults :)
782 2015-11-12T19:14:23 <BlueMatt> sipa: meh, I'm not so sure
783 2015-11-12T19:14:33 <jtimon> morcos: why this deprecation needs to be in 2 steps?
784 2015-11-12T19:14:40 <morcos> if we've stopped fully supporting priority, it only makes sense to change the default blockpriority size to 0, doesn't need to be backported
785 2015-11-12T19:14:53 <BlueMatt> morcos: ack
786 2015-11-12T19:14:58 <sipa> BlueMatt: i said i wished; i'm not convinced it is possible in a useful way
787 2015-11-12T19:15:02 <morcos> jtimon: primarily bc it hasn't be discussed very much yet
788 2015-11-12T19:15:11 <BlueMatt> sipa: we could have something for relay that isnt the same as mining (years ago there was some discussion of "relay policy is what *you* want to be mined", miners can do the rational thing)
789 2015-11-12T19:15:20 <wumpus> jtimon: to give some advance warning before completely removing it
790 2015-11-12T19:15:22 <BlueMatt> sipa: ok, well then I agree
791 2015-11-12T19:15:40 <jtimon> morcos: I believe this has been a recurring discussion ever since we wanted to limit the mempool size
792 2015-11-12T19:15:44 <morcos> anyway, i think the new 2 step process avoids adding new complication now. presents a mostly consistent release, and allows us to rip all this stuff right out as soon as we branch off 0.12
793 2015-11-12T19:15:55 <sipa> jtimon: but it has only been a discussion among developers
794 2015-11-12T19:15:57 <wumpus> yes
795 2015-11-12T19:16:13 *** jg_taxi has joined #bitcoin-dev
796 2015-11-12T19:16:21 <petertodd> morcos: well, if we're not *ready* to rip that code away, I 100% agree we should just set the default to zero, but if we're ready to rip that code away, I see no reason to delay
797 2015-11-12T19:16:42 *** jtoomim has quit IRC
798 2015-11-12T19:16:46 <jtimon> ok, default to zero as a first step and remove in 0.13 ?
799 2015-11-12T19:16:58 <Luke-Jr> we should absolutely not remove priority..
800 2015-11-12T19:17:07 <CodeShark> ?
801 2015-11-12T19:17:17 <btcdrak> Luke-Jr: why?
802 2015-11-12T19:17:31 <Luke-Jr> it's the best metric Core's default policy supports right now..
803 2015-11-12T19:17:40 <BlueMatt> Luke-Jr: no, feerate is
804 2015-11-12T19:17:43 <gmaxwell> I thought sipa has a good way to rationalize it that should be exploired. It would eliminate the multiple objective optimization.
805 2015-11-12T19:17:44 <jg_taxi> Nearly universal consensus to remove - except for Luke :)
806 2015-11-12T19:17:58 <Luke-Jr> BlueMatt: feerate often isn't.
807 2015-11-12T19:18:00 <phantomcircuit> morcos, we should not be carrying code complex efficient dynamic priority calculation
808 2015-11-12T19:18:05 <morcos> gmaxwell: multiple objective optimization isn't that hard
809 2015-11-12T19:18:09 <BlueMatt> gmaxwell: yes, we should explore adjustments to feerate, but the priority code as it exists should be ripped out
810 2015-11-12T19:18:10 <jtimon> we should only have a cost function (currently txSize) and a reward function (currently fees)
811 2015-11-12T19:18:12 <morcos> phantomcircuit: right, we will skip adding that
812 2015-11-12T19:18:29 <phantomcircuit> i rewrote that sentence one time too few
813 2015-11-12T19:18:36 <gmaxwell> morcos: not fundimentally hard but unnecessary code and computional complexity.
814 2015-11-12T19:18:42 <petertodd> Luke-Jr: I think what we need is "multi-mempool" support, to make it easier to deal with multiple different metrics - e.g. a pool with polcies like Eligius certainly would want to have an easy time setting up a seperate priority-based mechanism
815 2015-11-12T19:18:44 <Luke-Jr> also shouldn't be changing defaults to try to influence miners, outside of emergencies.
816 2015-11-12T19:18:58 <jtimon> after we unify that it's much simpler to change the cost/reward functions
817 2015-11-12T19:19:04 <jg_taxi> Fee deltas can produce priority
818 2015-11-12T19:19:08 <petertodd> Luke-Jr: same reason I think we *should* have a non-feerate mechanism for tx propagation that doesn't interact with the feerate based mechanism
819 2015-11-12T19:19:14 <petertodd> jg_taxi: yup
820 2015-11-12T19:19:20 <gmaxwell> the thing sipa suggests eliminates all impact of priority except in the cost calculation.
821 2015-11-12T19:19:23 <BlueMatt> Luke-Jr: we're not chaning to try to influence miners, we're changing to keep shit from breaking when miners disable priority anyway
822 2015-11-12T19:19:24 <morcos> what i'm proposing is basically shipping 0.12 as is with respect to priority, with a couple of changes: mining code will use starting priority, default prioritysize=0, and wallet is smart enough to not place priority txs if mempool limiting is in effect
823 2015-11-12T19:19:31 <jg_taxi> Thus you can do priority without priority code
824 2015-11-12T19:19:49 <BlueMatt> morcos: which seems reasonable
825 2015-11-12T19:19:59 <morcos> so thats the fewest changes from now to a semi-consistent state. more ripping out can then be done in 0.13. if we're not going to rip it out, we should do more now to make it work better, but sounds like we are
826 2015-11-12T19:20:00 <jg_taxi> Ack 0
827 2015-11-12T19:20:12 *** paulo_ has quit IRC
828 2015-11-12T19:20:15 <BlueMatt> though I really want to rip out the code (its a big churn, though, so we can push back)
829 2015-11-12T19:20:15 <petertodd> morcos: I'd be inclined to make the wallet not use priority at all by default
830 2015-11-12T19:20:32 <Luke-Jr> morcos: the first should be optional, at least
831 2015-11-12T19:20:37 <sipa> jg_taxi, gmaxwell: my idea was to take the btcdaysdestroued of a transaction, divide that by the average utxo age, take a small fraction of that (1%) and add that as extra fee
832 2015-11-12T19:20:57 <Luke-Jr> BlueMatt: I don't know what you mean. Why would things break?
833 2015-11-12T19:20:59 <sipa> jg_taxi, gmaxwell: the problem is that that has no bound on how much fees can be lost by a miner
834 2015-11-12T19:21:06 <Luke-Jr> and why must default policy be changed to prevent it?
835 2015-11-12T19:21:12 <petertodd> morcos: main thing is I just don't want users to get their txs stuck, especially since full RBF and CPFP support isn't in the wallet yte
836 2015-11-12T19:21:28 <morcos> ok i agree with petertodd , lets default QT to no longer send free also. bitcoind already has that off
837 2015-11-12T19:21:31 <sipa> Luke-Jr: multiple sorting orders is a massive complication to maintain...
838 2015-11-12T19:21:38 <Luke-Jr> morcos: doesn't it already?
839 2015-11-12T19:21:47 <morcos> QT is default on
840 2015-11-12T19:21:55 <jtimon> Luke-Jr: maintaining that code while doing other changes to the mempool behaviour is costly
841 2015-11-12T19:22:02 <jg_taxi> Once opt in RBF is there wallet will have smarter policies in this area
842 2015-11-12T19:22:10 <Luke-Jr> sipa: better to maintain complicated code than to make flexible policy code more complicated to write
843 2015-11-12T19:22:11 <phantomcircuit> petertodd, how do you relay transactions that you're not keeping in the mempool though?
844 2015-11-12T19:22:21 <phantomcircuit> (especially if there's opt in RBF for them)
845 2015-11-12T19:22:23 <gmaxwell> sipa: you can simply cap the impact; thats a candidate for the only tunable for that approach.
846 2015-11-12T19:22:51 <petertodd> phantomcircuit: well, I'm thinking in the future we won't just have one mempool, or one way fo relaying - e.g. it'd be a trivial hack to do tx relaying by bitmessage :)
847 2015-11-12T19:23:01 <gmaxwell> From a code perspective what sipa suggests is largely orthorgonal with removing priority (actually, it wants priority removed); but from a communication perspective it's different.
848 2015-11-12T19:23:21 <sipa> gmaxwell: that does mean it should work first...
849 2015-11-12T19:23:39 <morcos> Luke-Jr: The problem is its impossible to meaningfully speed up CreateNewBlock unless you are A) dynamically calculating priority on the fly as in 6357 or B) changing to a static definition of priority.
850 2015-11-12T19:23:53 <Luke-Jr> if simpler mempool code, makes it harder to write mining policy code, then the simpler mempool policy code should be rejected.
851 2015-11-12T19:23:58 <BlueMatt> gmaxwell: I'm really not sold on doing an adjustment metric....I mean we could, as long as it has a limited impact and I'd be fine with that, but then what was the point?
852 2015-11-12T19:24:02 *** Yoghur114 has joined #bitcoin-dev
853 2015-11-12T19:24:04 <morcos> I really think we need the performance improvement in CNB, so we have to pick A or B. People don't like adding the complication of A, so B it is
854 2015-11-12T19:24:11 <BlueMatt> gmaxwell: mostly I think we should only do it for relay, not mining, but then there is actually no point
855 2015-11-12T19:24:13 <jg_taxi> It sounds like there needs to be a minor hook related to this anyway
856 2015-11-12T19:24:21 <gmaxwell> luke's argument as I understand it is that in recent months we'd generally seen dos attackers as more willing and able to pay just over market rate fees than joe user; even though many wallets have caught up with dynamic fee behavior. Part of this is due to the market rate fees being so low that most of the cost of adjustment is the lack of RBF (which doesn't bother attackers) rather than the fee its
857 2015-11-12T19:24:24 <jtimon> Luke-Jr: you don't have to remove priority in your branch
858 2015-11-12T19:24:27 <gmaxwell> elf. But all this may be a temporary effect.
859 2015-11-12T19:24:28 <Luke-Jr> morcos: or recalculate priorities each block
860 2015-11-12T19:24:41 <Luke-Jr> jtimon: the changes being proposed make that impossible
861 2015-11-12T19:24:48 <morcos> Luke-Jr: That requries accessing every input for every tx in the mempool
862 2015-11-12T19:24:58 <sipa> Luke-Jr: not impossible, just expensive
863 2015-11-12T19:25:02 <Luke-Jr> morcos: it doesn't need to.
864 2015-11-12T19:25:10 <morcos> that's option A
865 2015-11-12T19:25:20 <gmaxwell> BlueMatt: even a limited impact is likely useful for getting non-dos-attack transactions sorted higher.
866 2015-11-12T19:25:37 <BlueMatt> Luke-Jr: there is a fee-adjustment api for this, it can be tweaked into being your priority calculator
867 2015-11-12T19:25:45 <jtimon> Luke-Jr: as "impossible" as reverting a merged change in master, don't you mean hard to maintain? why should bitcoin core bear that cost instead?
868 2015-11-12T19:25:45 <BlueMatt> gmaxwell: sure, but do we get miners to use it as well?
869 2015-11-12T19:25:45 <petertodd> gmaxwell: the speed at which wallet authors have adopted dynamic fees makes me pretty optimistic that dos attackers won't be doing too much harm - the cost to pay over "market rate" is really, really high
870 2015-11-12T19:25:47 <Luke-Jr> BlueMatt: priority is not fee-adjustment.
871 2015-11-12T19:25:50 *** sharperguy has quit IRC
872 2015-11-12T19:26:12 <gavinandresen> +1 for using the adjust api if you want something weird. And I vote for simple and fast for createnewblock
873 2015-11-12T19:26:14 <phantomcircuit> this all fundamentally comes down to a simple question; do you believe that user real users will pay higher fees than non-users?
874 2015-11-12T19:26:33 <gmaxwell> phantomcircuit: that overly simplifies.
875 2015-11-12T19:26:37 <BlueMatt> phantomcircuit: meh, we cant do anything if they arent
876 2015-11-12T19:26:46 <petertodd> BlueMatt: agreed there
877 2015-11-12T19:26:51 <Luke-Jr> BlueMatt: they aren't in practice.
878 2015-11-12T19:26:54 <gmaxwell> Because it ignores prediction error costs which are high right now due to a lack of replacement.
879 2015-11-12T19:27:01 <sdaftuar> BlueMatt: i think mempool limiting needs to be updated to take into account fee-deltas
880 2015-11-12T19:27:03 <BlueMatt> Luke-Jr: then we're fucked, lets all go home
881 2015-11-12T19:27:04 <phantomcircuit> gmaxwell, yes... but we can fix that
882 2015-11-12T19:27:14 <phantomcircuit> speaking of which where are we with opt in rbf?
883 2015-11-12T19:27:15 <BlueMatt> sdaftuar: oh? I thought it did that?
884 2015-11-12T19:27:18 <morcos> The topic was what to do for 0.12. The nice thing about my suggested approach is its minimal changes for now, and allows us to keep arguing indefinitely about prioirty next release cycle, but with a slight nudge towards deprecation.
885 2015-11-12T19:27:26 <BlueMatt> sdaftuar: then, yes, it really does need to be updated if it doesnt
886 2015-11-12T19:27:35 <sdaftuar> (double checking)
887 2015-11-12T19:27:38 <BlueMatt> phantomcircuit: thats the next topic, be patient :)
888 2015-11-12T19:27:39 <petertodd> phantomcircuit: wumpus code reviewed ACKed it
889 2015-11-12T19:28:07 <BlueMatt> morcos: I thought your suggestion included disabling priority for wallet when you see a limited mempool?
890 2015-11-12T19:28:12 <jgarzik> I tested opt-in with a simple replacement. Need to re-review but overall ACK
891 2015-11-12T19:28:13 *** alb12 has joined #bitcoin-dev
892 2015-11-12T19:28:14 <BlueMatt> morcos: I would call that a pretty hard deprecation
893 2015-11-12T19:28:20 <btcdrak> Link for the RBF patch https://github.com/bitcoin/bitcoin/pull/6871
894 2015-11-12T19:28:22 <morcos> morcos: thats already in master!
895 2015-11-12T19:28:22 <BlueMatt> morcos: given mempool sizes
896 2015-11-12T19:28:25 <morcos> BlueMatt: i mena
897 2015-11-12T19:28:28 <Luke-Jr> morcos: so the current behaviour remains possible?
898 2015-11-12T19:28:32 <gmaxwell> morcos: I think what you're suggesting is okay for now. I am only commenting because I do not share BlueMatt/Petertodd/etc. view on the utility of priority like things.
899 2015-11-12T19:28:35 <BlueMatt> jgarzik: please wait for topic change
900 2015-11-12T19:28:50 <CodeShark> I don't think we'll ever finish this topic :p
901 2015-11-12T19:28:56 <jgarzik> BlueMatt, talk to phantomcircuit he started it :)
902 2015-11-12T19:29:00 <wumpus> time for topic change?
903 2015-11-12T19:29:02 *** GITNE has quit IRC
904 2015-11-12T19:29:04 <btcdrak> yes!
905 2015-11-12T19:29:07 <CodeShark> please!
906 2015-11-12T19:29:08 <phantomcircuit> ya
907 2015-11-12T19:29:08 <BlueMatt> can we ack the current proposal?
908 2015-11-12T19:29:09 <cfields> yes
909 2015-11-12T19:29:10 <BlueMatt> first
910 2015-11-12T19:29:10 *** GITNE has joined #bitcoin-dev
911 2015-11-12T19:29:12 <wumpus> #topic RBF opt-in
912 2015-11-12T19:29:17 <CodeShark> ACK
913 2015-11-12T19:29:17 <BlueMatt> morcos' proposal acks?
914 2015-11-12T19:29:20 <petertodd> ACK
915 2015-11-12T19:29:21 <jgarzik> ACK
916 2015-11-12T19:29:22 <btcdrak> ACK
917 2015-11-12T19:29:27 <wumpus> ACK
918 2015-11-12T19:29:27 <BlueMatt> ok, new topic :)
919 2015-11-12T19:29:27 <sipa> ACK
920 2015-11-12T19:29:29 <sdaftuar> sdaftuar was here
921 2015-11-12T19:29:30 <gmaxwell> ACK
922 2015-11-12T19:29:31 <CodeShark> hehe
923 2015-11-12T19:29:33 <morcos> Luke-Jr: you'd be able to approximate the current behavior. I f you started with a large mempool, you could still send prioirty txs, and if you were willing to forgo the slight diff in static vs actual priority
924 2015-11-12T19:29:33 *** sporkman has joined #bitcoin-dev
925 2015-11-12T19:29:36 <btcdrak> #link https://github.com/bitcoin/bitcoin/pull/6871
926 2015-11-12T19:29:36 <Luke-Jr> NACK if current policy is made impossible
927 2015-11-12T19:29:45 <jtimon> I got lost, what is the current proposal?
928 2015-11-12T19:29:50 <btcdrak> RBF
929 2015-11-12T19:29:55 <CodeShark> opt-in RBF
930 2015-11-12T19:30:05 <phantomcircuit> oh boy
931 2015-11-12T19:30:06 <wumpus> jtimon: set prioritysize to 0 for 0.12, rip out priority for 0.13
932 2015-11-12T19:30:14 *** ThomasV has joined #bitcoin-dev
933 2015-11-12T19:30:19 <BlueMatt> wumpus: and disable priority in wallet if mempool is limited
934 2015-11-12T19:30:22 <jtimon> ok, ack both
935 2015-11-12T19:30:29 <morcos> jtimon: shipping 0.12 as is with respect to priority, with a couple of changes: mining code will use starting priority, default prioritysize=0, and wallet is smart enough to not place priority txs if mempool limiting is in effect
936 2015-11-12T19:30:39 <petertodd> Luke-Jr: the above will make current policy still possible, and give time for something better to be implemented I think
937 2015-11-12T19:30:42 *** jg_taxi has quit IRC
938 2015-11-12T19:30:46 <jgarzik> nod
939 2015-11-12T19:30:54 <BlueMatt> ok, so *now* rbf
940 2015-11-12T19:30:56 <Luke-Jr> petertodd: not if mining code must use starting priority.
941 2015-11-12T19:30:59 <jgarzik> ### really RBF
942 2015-11-12T19:31:14 <petertodd> re: RBF, tools! https://github.com/petertodd/replace-by-fee-tools
943 2015-11-12T19:31:27 <petertodd> I wrote tx combining - "incremental sendmany" - yesterday
944 2015-11-12T19:31:27 <btcdrak> that's a good start
945 2015-11-12T19:31:28 <gmaxwell> Luke-Jr: we'll talk more later.
946 2015-11-12T19:31:30 <wumpus> nice petertodd
947 2015-11-12T19:31:38 <BlueMatt> how much is there to discuss aside from "yes, we want this, code has been heavily concept-ack'ed"?
948 2015-11-12T19:31:42 <morcos> Yay for RBF
949 2015-11-12T19:31:45 <jtimon> RBF: ACK
950 2015-11-12T19:31:54 <morcos> we go from cry to rejoice
951 2015-11-12T19:31:54 <jgarzik> opt-in RBF - ACK
952 2015-11-12T19:31:56 <petertodd> BlueMatt: and running in production at f2pool in the FFS variant
953 2015-11-12T19:31:57 <Luke-Jr> biggest problem for optin RBF is that you can't opt-in per-output
954 2015-11-12T19:31:59 <Luke-Jr> IMO
955 2015-11-12T19:32:00 <btcdrak> I guess action point is to review PR if you havemt
956 2015-11-12T19:32:23 <petertodd> Luke-Jr: yeah, that'd be cool, but very hard to implement, and prolematic re privacy :(
957 2015-11-12T19:32:24 <wumpus> #action review and merge #6871 (nSequence-based Full-RBF opt-in)
958 2015-11-12T19:32:27 <BlueMatt> petertodd: I think we all agree FSS is useless :(
959 2015-11-12T19:32:32 <petertodd> Luke-Jr: nSequence is the only "free to use" field we have :(
960 2015-11-12T19:32:36 <jgarzik> BlueMatt, ACK!
961 2015-11-12T19:32:48 <btcdrak> I would prefer we just went full-RBF. I know the landscape has changed a lot since all the tx flooding
962 2015-11-12T19:32:51 <jgarzik> petertodd, until the TX structure changes
963 2015-11-12T19:32:56 <petertodd> BlueMatt: yeah, and if that changes, we can implement FSS later as an add-on
964 2015-11-12T19:33:04 * jtimon should find time to turn concept ACK into utACK
965 2015-11-12T19:33:05 <jgarzik> well we also have TX version bits
966 2015-11-12T19:33:06 <petertodd> jgarzik: agreed!
967 2015-11-12T19:33:31 <Luke-Jr> jgarzik: this doesn't help per-ouptut I think
968 2015-11-12T19:33:32 <gmaxwell> Luke-Jr: any RBF use (further) breaks the safty of unconfirmed decendants... I don't know how much additional value per output flagging would accomplish even if it were reasonably possible (nowhere to encode it, alas).
969 2015-11-12T19:33:33 <petertodd> for now though, nSequence opt-in is the best we have
970 2015-11-12T19:33:38 <sdaftuar> as i mentioned last week i think an email to the list about how opt-in RBF works is important
971 2015-11-12T19:33:43 <jgarzik> it would be nice to mask out TX version bits ahead of time. Agree it doesn't help with per-{input,output} stuff.
972 2015-11-12T19:33:44 <petertodd> sdaftuar: will do
973 2015-11-12T19:33:55 <jtimon> suggested topic: version bits
974 2015-11-12T19:34:12 <morcos> Suggested Topic: wumpus was supposed to merge chain limits so we could email -dev list about that as well
975 2015-11-12T19:34:17 <Luke-Jr> petertodd: can this optin-RBF be disabled by nodes?
976 2015-11-12T19:34:20 <jgarzik> #action - everybody take opt-in RBF from concept ACK to [ut] ACK
977 2015-11-12T19:34:39 <petertodd> Luke-Jr: no, but if you want to add a command line switch for that by all means go for it
978 2015-11-12T19:34:41 <BlueMatt> morcos: yea, lets do that
979 2015-11-12T19:35:11 <Luke-Jr> petertodd: IMO nodes should be able to toggle between FSS-or-not, and never/optin/always
980 2015-11-12T19:35:15 <morcos> sorry jgarzik: s/wumpus/any one of the 5 high elders of Bitcoin/
981 2015-11-12T19:35:35 <phantomcircuit> petertodd, well... technically you can send the replacement optin flag outside of the transaction
982 2015-11-12T19:35:37 <Luke-Jr> (are any anti-RBF people going to block an option for nodes to enable always-full-RBF?)
983 2015-11-12T19:35:45 <petertodd> Luke-Jr: well, write that and pull-req! just a few more lines of code
984 2015-11-12T19:35:55 <phantomcircuit> it's not consensus enforced so it doesn't matter
985 2015-11-12T19:36:47 <wumpus> morcos: #6771 seems quite controversial looking at the comments
986 2015-11-12T19:37:02 <phantomcircuit> Luke-Jr, i predict yes, so please as a separate pull request
987 2015-11-12T19:37:27 <morcos> wumpus: yes we discussed that last week. its a strong majority in favor, but there is a very vocal minority who are opposed. its not clear how strongly opposed though.
988 2015-11-12T19:37:31 <jgarzik> ### change topic, people
989 2015-11-12T19:37:43 <jgarzik> #topic chain limits
990 2015-11-12T19:37:44 <btcdrak> wumpus: really? a couple of loud voices only it seems.
991 2015-11-12T19:37:44 <wumpus> ok ,next topic was versionbits by jtimon aaik
992 2015-11-12T19:37:46 <Luke-Jr> jgarzik: I'd particularly like an answer from you on that :P
993 2015-11-12T19:37:46 <wumpus> #topic versionbits
994 2015-11-12T19:37:57 <wumpus> jgarzik: please don't do that, I'm chairing
995 2015-11-12T19:38:16 <morcos> unfortunately we don't think there is much of an otpion, so last time we said we'd merge and email and if all hell breaks loose we could consider reverting, but we have to do what we think is the right choice. and leaving existing limits is dangerous
996 2015-11-12T19:38:17 <jgarzik> then keep it moving, chair :)
997 2015-11-12T19:38:35 <wumpus> jgarzik: it's kind of annoying if we both change topics
998 2015-11-12T19:38:39 <btcdrak> CodeShark: what is the status of versionbits?
999 2015-11-12T19:38:42 <CodeShark> for versionbits, some think the container stuff I did is a bit excessive
1000 2015-11-12T19:38:45 <btcdrak> wumpus: agree one chair.
1001 2015-11-12T19:38:52 <sipa> morcos: afaik all the opposing voices had use cases up to a few deep
1002 2015-11-12T19:38:55 <wumpus> jgarzik: you can chair next week, ok
1003 2015-11-12T19:38:56 <jtimon> there's two implementations, CodeShark's https://github.com/bitcoin/bitcoin/pull/6816 and rusty's (let me look for the link later)
1004 2015-11-12T19:38:57 <CodeShark> it has been proposed to stick everything into a single static table
1005 2015-11-12T19:39:06 <jgarzik> I'm tempted to write a TX version bits BIP, just to reserve bits for later, separate from block version bits
1006 2015-11-12T19:39:11 <gmaxwell> morcos: lets come back to after meeting.
1007 2015-11-12T19:39:40 <phantomcircuit> jgarzik, fyi there is at least a few transactions in the chain that have weird versions
1008 2015-11-12T19:39:41 <petertodd> I haven't looked in detail at either softfork version bits code myself, but I don't think it needs to be in v0.12.0 at all, so I'm thinking no rush
1009 2015-11-12T19:39:51 <jgarzik> phantomcircuit, hmmm interesting
1010 2015-11-12T19:39:58 <sipa> petertodd: it will need to be backportable anyway
1011 2015-11-12T19:40:14 <petertodd> phantomcircuit: not necessarily a bit deal - there's some blocks with weird versions too, and the soft-fork mechanism handles that fine
1012 2015-11-12T19:40:29 *** ThomasV has quit IRC
1013 2015-11-12T19:40:31 <gmaxwell> Versionbits bip needs a minor revisions, proposals need a starting time. It can be just a time for which signaling will begin, or also a time for when counting starts.
1014 2015-11-12T19:40:33 <btcdrak> petertodd: no sense in delaying this or dealing with refactoring that will come in 0.13
1015 2015-11-12T19:40:48 <CodeShark> I had proposed a starting time in a PR to the bip
1016 2015-11-12T19:40:54 <CodeShark> but some opposed it
1017 2015-11-12T19:40:58 <gmaxwell> Suggested topic: 0.11.2/0.10.4 release.
1018 2015-11-12T19:41:03 <jgarzik> in general we want to push versionbits soonish
1019 2015-11-12T19:41:05 <gmaxwell> CodeShark: we have more expirence now.
1020 2015-11-12T19:41:07 <sipa> CodeShark: there is very good reason now to have it
1021 2015-11-12T19:41:23 <phantomcircuit> petertodd, yes im aware, just saying it's something to keep in mind
1022 2015-11-12T19:41:23 <sipa> jgarzik: existing softforks need to complete forst anyway
1023 2015-11-12T19:41:30 <wumpus> gmaxwell: I don't understand why you want that as topic, they're already in rc?
1024 2015-11-12T19:41:31 <btcdrak> CodeShark: I very much pefer the table approach suggested by rusty.
1025 2015-11-12T19:41:32 <jgarzik> nod
1026 2015-11-12T19:41:45 <gmaxwell> http://bitcoin.sipa.be/ver-2k.png
1027 2015-11-12T19:41:51 *** btc_panhandler has quit IRC
1028 2015-11-12T19:41:56 <cfields> btcdrak: got a link?
1029 2015-11-12T19:41:59 <jtimon> to be clear I never opposed to a starting date
1030 2015-11-12T19:42:08 <gmaxwell> wumpus: just to find out if there is anything we need to target to cut the release that you or others are thinking of.
1031 2015-11-12T19:42:31 <gmaxwell> (I look at that graph twice a day and worry that it's going to uptick hard without a release out. :) )
1032 2015-11-12T19:42:37 <btcdrak> cfields: this was rusty's draft idea: https://github.com/bitcoin/bitcoin/compare/master...rustyrussell:bip-9-versionbits
1033 2015-11-12T19:43:06 <jtimon> btcdrak: thanks
1034 2015-11-12T19:43:06 <cfields> wumpus: want the qt/-fpie change backported to .11.2 ?
1035 2015-11-12T19:43:14 <petertodd> gmaxwell: yeah, very inclined to have a CLTV relese out; I'd only delay 0.11.2/0.10.4 for critical fixes
1036 2015-11-12T19:43:16 <jgarzik> cfields, later / different chan
1037 2015-11-12T19:43:16 <sipa> what is the topic?
1038 2015-11-12T19:43:21 <jgarzik> versionbits
1039 2015-11-12T19:43:24 <btcdrak> sipa: versionbits
1040 2015-11-12T19:43:28 <wumpus> cfields: too late for that IMO, as gmaxwell says we want them final ASAP
1041 2015-11-12T19:43:38 <jgarzik> let's move on - seems main decision is codeshark / rusty - not much actionable right now
1042 2015-11-12T19:43:44 <petertodd> jgarzik: agreed
1043 2015-11-12T19:43:47 <CodeShark> I had added a deploytime parameter as well, but I took it out: https://github.com/bitcoin/bips/pull/219
1044 2015-11-12T19:43:48 <cfields> jgarzik: eh? the question was what's .11.2 waiting for
1045 2015-11-12T19:43:51 <cfields> wumpus: ok
1046 2015-11-12T19:43:59 <jgarzik> cfields, the topic is versionbits
1047 2015-11-12T19:44:00 <jgarzik> cfields, not qt
1048 2015-11-12T19:44:01 <btcdrak> CodeShark: better add it back then
1049 2015-11-12T19:44:10 <CodeShark> will do
1050 2015-11-12T19:44:16 <wumpus> #topic chian limits
1051 2015-11-12T19:44:18 <gmaxwell> versionbits isn't actionable yet. starting time should be considered.
1052 2015-11-12T19:44:18 <jtimon> in fact I personally think both CodeShark's and rusty's are more complicated than they need to be
1053 2015-11-12T19:44:27 *** brson_ has joined #bitcoin-dev
1054 2015-11-12T19:44:33 <jgarzik> chain limits -- last meeting we decided to push & tell list about it
1055 2015-11-12T19:44:42 <gmaxwell> CodeShark: feel free to pull me into a conversation with rusty about starting time.
1056 2015-11-12T19:44:46 <jgarzik> definitionally impossible to satisfy all
1057 2015-11-12T19:44:54 <wumpus> I'm not comfortable with merging it with all the controversy
1058 2015-11-12T19:44:59 <jgarzik> I am
1059 2015-11-12T19:44:59 <petertodd> re: chian limits, I keep thinking that the # of users actually affected by them is reasonably small, and they tend to be people with engineering teams who should be able to at least do the easy hack of "create a buffer of txs waiting to go out"
1060 2015-11-12T19:45:07 <morcos> wumpus: are you comfortable with someone merging it?
1061 2015-11-12T19:45:09 <CodeShark> will do, gmaxwell
1062 2015-11-12T19:45:10 <btcdrak> gmaxwell: I thought we were all in that discussion
1063 2015-11-12T19:45:13 <jtimon> I opposed to having a per-bip threshold instead of per-chain
1064 2015-11-12T19:45:14 <BlueMatt> jgarzik: go do it
1065 2015-11-12T19:45:18 <jgarzik> OK
1066 2015-11-12T19:45:27 <gmaxwell> I am fine with jgarzik merging it. We can revert based on response if needed.
1067 2015-11-12T19:45:32 <CodeShark> yeah, actually I think I also added you to the convo, gmaxwell
1068 2015-11-12T19:45:35 <petertodd> gmaxwell: +1
1069 2015-11-12T19:45:37 <CodeShark> but this was a few weeks ago
1070 2015-11-12T19:45:39 <btcdrak> gmaxwell: +1
1071 2015-11-12T19:45:44 <sipa> petertodd: they don't even need them to be mined at once; they just nees to get them in the mempool at once so customers can see the transactions
1072 2015-11-12T19:45:45 <jgarzik> merge easy, revert easy
1073 2015-11-12T19:45:49 <jgarzik> get Internet feedback
1074 2015-11-12T19:45:50 <wumpus> blah
1075 2015-11-12T19:45:53 <gmaxwell> CodeShark: I might have been stupid then.
1076 2015-11-12T19:45:55 <petertodd> sipa: yes I know :(
1077 2015-11-12T19:46:06 <gmaxwell> wumpus: I think it will actually be okay but we need more information if not.
1078 2015-11-12T19:46:14 <jgarzik> nod
1079 2015-11-12T19:46:25 <petertodd> sipa: we should definitely communicate the RBF sendmany alternative to long chains ASAP
1080 2015-11-12T19:46:32 <sipa> petertodd: if people were justnusing payment protocol etc, and not using the p2p network as a communication channel, nobody would care
1081 2015-11-12T19:46:33 <morcos> ok after it's merged I will email the list
1082 2015-11-12T19:46:41 <jgarzik> ok
1083 2015-11-12T19:46:44 <petertodd> sipa: agreed
1084 2015-11-12T19:46:47 <gmaxwell> wumpus: the cases people raised were all for small chain counts; and large chains cannot be safely supported by the software (of course you can still author large chains, you just need to retransmit until nodes take them-- not unlike other limits... not even clear to me that people knew this)
1085 2015-11-12T19:47:04 *** brson has quit IRC
1086 2015-11-12T19:47:18 <sipa> gmaxwell: read my conversation with petertodd above
1087 2015-11-12T19:47:32 <gmaxwell> Long chains are still also highly malleability vulnerable.
1088 2015-11-12T19:47:33 <petertodd> re: "customer sees tx in wallet" - the user experience of long chains isn't great anyway, as they're not all that reliable due to propagation failures
1089 2015-11-12T19:47:39 <jgarzik> yup
1090 2015-11-12T19:47:44 <sipa> gmaxwell: retransmit doesn't work for them, it is not mining; it is about getting them instantly relayed
1091 2015-11-12T19:47:55 <wumpus> right
1092 2015-11-12T19:47:57 <gmaxwell> sipa: fair point though also petertodd's response.
1093 2015-11-12T19:48:16 <petertodd> gmaxwell: RBF sendmany won't show up in many users wallets yet :(
1094 2015-11-12T19:48:32 <jgarzik> get opt-in RBF into tree, and it will show up in wallets rapidly.
1095 2015-11-12T19:48:34 <morcos> I think this is the reason to announce this as far in advance as possible
1096 2015-11-12T19:48:38 <petertodd> jgarzik: agreed
1097 2015-11-12T19:48:40 <gmaxwell> petertodd: I think showing up in wallets isn't the actual metric, showing up in block explorers is.
1098 2015-11-12T19:48:53 <morcos> So that if they need to figure out another way to communicate the information they can
1099 2015-11-12T19:48:58 <btcdrak> jgarzik: +!
1100 2015-11-12T19:49:06 <morcos> also its a configurable limit!, we're just chanigng the default
1101 2015-11-12T19:49:09 <petertodd> gmaxwell: good point - although it'll take awhile for even that to be handled well rather than as scary doublespends
1102 2015-11-12T19:49:23 <jgarzik> morcos, agree but weak argument - most go with default
1103 2015-11-12T19:49:41 <wumpus> morcos: yes it's not a consensus change :)
1104 2015-11-12T19:49:42 <btcdrak> gmaxwell: we can contact popular explorers to make changes. Shouldnt be hard.
1105 2015-11-12T19:49:46 <sipa> indeed; defaults has anlot.of power unfortunately
1106 2015-11-12T19:49:53 <morcos> the default should be one that allows the node to operate securely and be safe from attack, if more risky parameters are needed for rarer use cases that should be something those users worry about
1107 2015-11-12T19:49:56 <gmaxwell> In any case I think collectively we dont think failing to limit here is technically viable. So what choice do we have? people can have their own opinions, but not your own reality. :)
1108 2015-11-12T19:50:10 *** alb12 has quit IRC
1109 2015-11-12T19:50:17 <morcos> gmaxwell: exactly
1110 2015-11-12T19:50:18 <jgarzik> ### 10min
1111 2015-11-12T19:50:20 <gmaxwell> if there are specific needs about very long chains we need to know so we can figure out how to handle them.
1112 2015-11-12T19:50:23 *** adam3us has joined #bitcoin-dev
1113 2015-11-12T19:50:26 <petertodd> gmaxwell: agreed - first priority is to keep the system working for the super majority who don't need long chains
1114 2015-11-12T19:50:34 *** amantonop has joined #bitcoin-dev
1115 2015-11-12T19:50:37 <jgarzik> gmaxwell, yep -- and merging is the best way to get user feedback on that, IMO
1116 2015-11-12T19:50:48 <wumpus> gmaxwell: that's true - the only thing under discussion is what the limits should be, not whetehr there should be any
1117 2015-11-12T19:50:52 <phantomcircuit> gmaxwell, nobody commenting in the pull request came up with an actual use case for very long chains, they merely asserted that they needed them
1118 2015-11-12T19:50:56 <jgarzik> can only spin wheels so long in the dev silo (info vacuum)
1119 2015-11-12T19:51:00 <btcdrak> what is the PR for chainlimits again?
1120 2015-11-12T19:51:04 <jgarzik> #6771
1121 2015-11-12T19:51:05 <phantomcircuit> which i am happy to ignore
1122 2015-11-12T19:51:21 <btcdrak> #link https://github.com/bitcoin/bitcoin/pull/6771
1123 2015-11-12T19:51:32 <jgarzik> new topic?
1124 2015-11-12T19:51:39 <jtimon> 25 25 wasn't final, right
1125 2015-11-12T19:51:57 <morcos> 25 / 101 and 25 / 101 are the final limits
1126 2015-11-12T19:52:35 <jtimon> same for both? I expected ancestors to be lower
1127 2015-11-12T19:53:04 <morcos> jtimon: most common use case is linear chain...
1128 2015-11-12T19:53:23 <sipa> new topic?
1129 2015-11-12T19:53:26 <wumpus> any other topics?
1130 2015-11-12T19:53:44 <petertodd> <crickets>
1131 2015-11-12T19:53:47 <jgarzik> did we cover jonas while I was in the taxi?
1132 2015-11-12T19:54:10 <sdaftuar> ?
1133 2015-11-12T19:54:10 <jtimon> ?
1134 2015-11-12T19:54:20 <CodeShark> not sure I want to know
1135 2015-11-12T19:54:20 <Luke-Jr> ?
1136 2015-11-12T19:54:23 <petertodd> â½
1137 2015-11-12T19:54:30 <Luke-Jr> â
1138 2015-11-12T19:54:42 <jgarzik> proposal for new GUI maintainer
1139 2015-11-12T19:54:42 <CodeShark> sounds kinky, though
1140 2015-11-12T19:54:52 <petertodd> CodeShark: GUI's are pretty kinky
1141 2015-11-12T19:55:10 <BlueMatt> petertodd: they're masochistic, if nothing else
1142 2015-11-12T19:55:13 <gmaxwell> jgarzik: I think it's kind of rude to bring that up in this meeting when wumpus probably hasn't talked to jonasschnelli about it! :)
1143 2015-11-12T19:55:28 <jgarzik> gmaxwell, he said he did, which is why I mentioned it
1144 2015-11-12T19:55:40 <wumpus> it's not time to talk about that yet
1145 2015-11-12T19:55:42 * bsm1175321 would separate the GUI into a different project...
1146 2015-11-12T19:55:42 <Luke-Jr> jonas also doesn't seem to be here for the meeting
1147 2015-11-12T19:55:44 <wumpus> yes, that very rude
1148 2015-11-12T19:55:48 <gmaxwell> ah. Okay.
1149 2015-11-12T19:55:54 *** moa has joined #bitcoin-dev
1150 2015-11-12T19:56:02 <wumpus> I asked if he was interested, not whether we should announce it yet
1151 2015-11-12T19:56:06 <BlueMatt> ok, end meeting?
1152 2015-11-12T19:56:24 <btcdrak> if we can remember the command this week :-)
1153 2015-11-12T19:56:30 <wumpus> #meetingend
1154 2015-11-12T19:56:39 <gmaxwell> #destroymeeting
1155 2015-11-12T19:56:42 <wumpus> #endmeeting
1156 2015-11-12T19:56:42 <lightningbot> Meeting ended Thu Nov 12 19:56:42 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
1157 2015-11-12T19:56:42 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-12-19.01.html
1158 2015-11-12T19:56:42 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-12-19.01.txt
1159 2015-11-12T19:56:42 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-12-19.01.log.html
1160 2015-11-12T19:56:43 <Luke-Jr> #endmeeting
1161 2015-11-12T19:56:43 * btcdrak *sniggers*
1162 2015-11-12T19:56:47 <BlueMatt> #magicmeetbotincantation
1163 2015-11-12T19:57:01 <petertodd> #DoWhatIMean
1164 2015-11-12T19:57:05 <btcdrak> every week lol
1165 2015-11-12T19:57:09 <jgarzik> sys_dwim()
1166 2015-11-12T19:57:19 *** sharperguy has joined #bitcoin-dev
1167 2015-11-12T19:57:47 <gmaxwell> Luke-Jr: on priority. the exact current behavior requires walking all inputs for all transactioin in the mempool on every CNB to update priorities. With large mempools this is an enormous amount of time, and we cannot continue doing this.
1168 2015-11-12T19:58:00 <sharperguy> Has anyone seen this error when building libbitcoin? "/usr/local/include/boost/test/tools/old/impl.hpp:92: undefined reference to `boost::test_tools::tt_detail::report_assertion..."
1169 2015-11-12T19:58:11 <morcos> gmaxwell: in core-dev
1170 2015-11-12T19:58:13 <jonasschnelli> sorry. was offline.
1171 2015-11-12T19:58:20 <btcdrak> sipa: thanks for the code-review today on #6312
1172 2015-11-12T19:59:06 *** adam3us has quit IRC
1173 2015-11-12T19:59:40 <phantomcircuit> sharperguy, #libbitcoin
1174 2015-11-12T19:59:40 *** t7 has joined #bitcoin-dev
1175 2015-11-12T20:00:10 <wumpus> cfields: we should the qt/-fPIC detection stuff, but after 0.11.2 and 0.10.4 final have been released
1176 2015-11-12T20:00:14 <wumpus> +backport
1177 2015-11-12T20:00:35 <cfields> ok
1178 2015-11-12T20:00:44 <btcdrak> gmaxwell: note MTP was not backported to 0.10.4.
1179 2015-11-12T20:01:01 *** LeMiner has quit IRC
1180 2015-11-12T20:01:26 <wumpus> cfields: (which we should do tomorrow anyway)
1181 2015-11-12T20:01:35 <cfields> yes
1182 2015-11-12T20:02:18 *** skyraider has quit IRC
1183 2015-11-12T20:02:18 <gmaxwell> btcdrak: I know. I doubt 0.10.4 will see much mining deployment.
1184 2015-11-12T20:02:20 <wumpus> or maybe even now. you're here now
1185 2015-11-12T20:02:44 <btcdrak> gmaxwell: it was my thought too. Well, my excuse for not doing the backport anyway.
1186 2015-11-12T20:02:51 <btcdrak> miners should be on 0.11 imo
1187 2015-11-12T20:03:32 *** wraithm has joined #bitcoin-dev
1188 2015-11-12T20:03:38 *** CheckDavid has quit IRC
1189 2015-11-12T20:03:52 *** GAit has quit IRC
1190 2015-11-12T20:04:43 <jonasschnelli> gmaxwell, jgarzik: wumpus did ask about a GUI maintainer and I'm ready to do it. I hope i can reduce wumpus workload by taking care of everything gui related.
1191 2015-11-12T20:04:55 * jonasschnelli is phone typing and partially online
1192 2015-11-12T20:05:13 <jgarzik> jonasschnelli, fyi just emailed an apology -- I thought it was OK to disclose given ACKs & your acceptance
1193 2015-11-12T20:05:23 <jgarzik> but my error
1194 2015-11-12T20:05:28 <wumpus> jonasschnelli: we just weren't supposed to announce it yet :-)
1195 2015-11-12T20:05:34 *** LeMiner has joined #bitcoin-dev
1196 2015-11-12T20:05:54 <jonasschnelli> Okay. I see. Sorry then for my response.
1197 2015-11-12T20:06:06 *** ThomasKeller has quit IRC
1198 2015-11-12T20:06:08 <wumpus> jonasschnelli: not your fault!
1199 2015-11-12T20:06:32 <wumpus> jonasschnelli: it's no problem anyway, welcome I suppose :D
1200 2015-11-12T20:06:32 <jgarzik> yep my bad
1201 2015-11-12T20:08:00 <sipa> jonasschnelli: indeed, welcome :)
1202 2015-11-12T20:08:19 *** LeMiner has quit IRC
1203 2015-11-12T20:08:23 <jonasschnelli> Super. Thanks guys. :)
1204 2015-11-12T20:08:45 <Taek> do most miners start mining on a block before validating it?
1205 2015-11-12T20:08:51 <Taek> (SPV miners aside)
1206 2015-11-12T20:08:54 *** pepesza has joined #bitcoin-dev
1207 2015-11-12T20:09:04 *** twixisowned has joined #bitcoin-dev
1208 2015-11-12T20:09:34 *** amantonop has quit IRC
1209 2015-11-12T20:09:47 <sipa> Taek: that would be by definition validationless mining (which is what SPV mining should be called) :)
1210 2015-11-12T20:10:04 <sipa> what is typically called SPV mining has no validation it, not even SPV
1211 2015-11-12T20:10:30 <btcdrak> Congratulations jonasschnelli
1212 2015-11-12T20:11:41 <Taek> sipa: at first pass, I think it would be sufficient to validate immediately, but start mining on the new block before validation completes. If the POW is valid, you assume that the cost of making the block is greater than the amount of work that can be wasted by sending around an invalid block if the miners will only be doing invalid mining for a few seconds
1213 2015-11-12T20:11:59 <Taek> the miners would also have to propagate the block before validating it again
1214 2015-11-12T20:12:05 *** trixisowned has quit IRC
1215 2015-11-12T20:12:22 <Taek> I don't have a good grasp on what practical mining looks like today
1216 2015-11-12T20:13:44 *** Dizzle has joined #bitcoin-dev
1217 2015-11-12T20:14:26 <gmaxwell> Taek: If I'm short, sorry. I'm tired of people repeating this. I think you need to actually go simulate it; because what you're suggesting really undermines SPV security, as they make a very strong assumption that miners have validated, and because of the exponential distribution fairly large runs of blocks with short times are quite common.
1218 2015-11-12T20:14:36 *** Ozymandus has joined #bitcoin-dev
1219 2015-11-12T20:15:06 <Taek> gmaxwell: understood. Would probably help to have a document similar to pos.pdf to catch people up
1220 2015-11-12T20:15:24 <gmaxwell> There is more or less no such thing as only a couple seconds in mining due to latencies and efficiency losses on work reset. Figure any work issued people are going to work on for at least 30 seconds.
1221 2015-11-12T20:16:23 <phantomcircuit> (although the latency problem can be fixed... but only in hardware)
1222 2015-11-12T20:16:52 <Ozymandus> Is today the chat on the state of Bitcoin?
1223 2015-11-12T20:17:00 <Ozymandus> Just getting my bearings and timetable correct.
1224 2015-11-12T20:17:49 <sipa> Ozymandus: you are 77 minutes late; 7PM iceland time
1225 2015-11-12T20:18:34 *** mjerr has joined #bitcoin-dev
1226 2015-11-12T20:19:20 *** d_t has quit IRC
1227 2015-11-12T20:19:21 <Ozymandus> Thanks sipa. I'll sort myself out for next week
1228 2015-11-12T20:21:59 *** adam3us has joined #bitcoin-dev
1229 2015-11-12T20:23:12 *** btc_panhandler has joined #bitcoin-dev
1230 2015-11-12T20:23:34 *** damethos has quit IRC
1231 2015-11-12T20:23:50 *** damethos has joined #bitcoin-dev
1232 2015-11-12T20:24:41 *** d_t has joined #bitcoin-dev
1233 2015-11-12T20:25:02 *** Ozymandus has quit IRC
1234 2015-11-12T20:26:04 *** skyraider has joined #bitcoin-dev
1235 2015-11-12T20:27:20 *** wraithm has quit IRC
1236 2015-11-12T20:31:05 *** h3xc0d3r has joined #bitcoin-dev
1237 2015-11-12T20:32:03 *** ThomasKeller has joined #bitcoin-dev
1238 2015-11-12T20:35:01 *** h3xc0d3r has quit IRC
1239 2015-11-12T20:35:26 *** nwilcox has quit IRC
1240 2015-11-12T20:35:29 *** eki5bvu7njh has joined #bitcoin-dev
1241 2015-11-12T20:41:47 *** kgk has joined #bitcoin-dev
1242 2015-11-12T20:47:46 *** Amnez777_ has joined #bitcoin-dev
1243 2015-11-12T20:49:43 <jtimon> Luke-Jr: do you have examples in which a separate block space is necessary for implementing a given mining polcy?
1244 2015-11-12T20:50:00 <Luke-Jr> jtimon: the current policy!
1245 2015-11-12T20:50:34 *** Amnez777 has quit IRC
1246 2015-11-12T20:51:11 *** kgk has quit IRC
1247 2015-11-12T20:51:18 <sipa> i do think the current policy is suboptimal though for what it is trying to achieve... if i could pay either fee F, or priority P... why would something with fee F/2 and priority P/2 not be acceptable?
1248 2015-11-12T20:51:23 <wizkid057> just scanning some of the above conversation, a proper mining implementation shouldn't care how long createblock takes as long as it does complete at some point
1249 2015-11-12T20:51:32 <jtimon> Luke-Jr: it could be equivalently implemented without a separated block space (maybe with performance costs if one is not careful)
1250 2015-11-12T20:52:28 <Luke-Jr> jtimon: not easily
1251 2015-11-12T20:52:51 <jtimon> Luke-Jr: I mean some case in which you believe a separated space is mundamentally necessary
1252 2015-11-12T20:52:58 <Luke-Jr> sipa: perhaps. but that's tangent to the matter
1253 2015-11-12T20:53:04 <sipa> Luke-Jr: i don't think so
1254 2015-11-12T20:53:06 <jtimon> Luke-Jr: agreed not necessarily easy
1255 2015-11-12T20:53:13 <Luke-Jr> jtimon: policy code should be easy
1256 2015-11-12T20:54:00 <jtimon> it cannot be easy for all posible cases, infinite possible policies is certainly too hard to maintain
1257 2015-11-12T20:54:19 <Lightsword> wizkid057, well the issue right now is that a large amount of mining pools do fully rely on CNB and GBT for generating stratum templates
1258 2015-11-12T20:54:48 <wizkid057> Lightsword: then they should fix that ;)
1259 2015-11-12T20:54:52 <Luke-Jr> jtimon: infinity being too hard, does not justify making non-infinity real-world policies harder
1260 2015-11-12T20:55:08 <jtimon> but you can have a common interface and that interface doesn't need to expose separated spaces
1261 2015-11-12T20:55:28 <Luke-Jr> jtimon: if it doesn't, you make typical policies significantly harder
1262 2015-11-12T20:56:05 <jtimon> Luke-Jr: ok, I'm asking about what part of those "typical policies" will be harder to maintain if priority is removed as it is
1263 2015-11-12T20:56:23 <sipa> i think it's only called a typical policy for historical reasons; it may well be possible to write a superior ones more easily
1264 2015-11-12T20:56:28 <wizkid057> Lightsword: I think a tweak to bitcoind's blocknotify that also provided the height and bits fields would be more than sufficient to get miners on the right track quickly (basically what I have Eligius doing now)
1265 2015-11-12T20:56:44 <Lightsword> wizkid057, I think itâs a fairly complex change for a lot of implementations, in any case the difference it makes when running bitcoind with minrelaytxfee=0.0001 and limitfreerelay=0 seems to be negligable
1266 2015-11-12T20:56:52 <jtimon> Luke-Jr: because I have only read about the default policy and I have only imagined what I would do as a miner
1267 2015-11-12T20:57:17 *** mrkent has quit IRC
1268 2015-11-12T20:57:36 <Luke-Jr> in any case, keeping the current policy is fairly cheap
1269 2015-11-12T20:57:38 <wizkid057> Lightsword: GBT is always going to be slower than just making a blank template, though
1270 2015-11-12T20:57:41 <jtimon> Luke-Jr: tangent ACK on s/standard policy/default policy/ clearer term
1271 2015-11-12T20:58:16 *** mstang83 has joined #bitcoin-dev
1272 2015-11-12T20:58:39 <Lightsword> wizkid057, the ckpool based pools which fully rely on GBT seem to be some of the fastest pools to send out stratum updates on block changes however so I think itâs probably something that would be best handled in bitcoind itself
1273 2015-11-12T20:58:39 <jtimon> Luke-Jr: of course, changing things while keeping the current policy is the problem
1274 2015-11-12T20:58:42 *** grieve has joined #bitcoin-dev
1275 2015-11-12T20:59:03 <Luke-Jr> jtimon: but it's not a problem
1276 2015-11-12T20:59:10 <jtimon> Luke-Jr: that should be the problem of those who want to maintain the current policy, not Bitcoin Core's for eternity
1277 2015-11-12T20:59:39 <Luke-Jr> jtimon: no, it shouldn't.
1278 2015-11-12T20:59:40 <wizkid057> Lightsword: maybe a GBT option on the request to not process/return transactions for the first request after a blocknotify would make some sense. would be a trivial patch for the pool software too to make that request initially
1279 2015-11-12T20:59:53 *** akrmn has joined #bitcoin-dev
1280 2015-11-12T20:59:57 <Luke-Jr> jtimon: Bitcoin Core should not be making policies harder to maintain.
1281 2015-11-12T21:00:17 <Luke-Jr> anyhow, as I understand it, 6898+6357 preserves the current policy just fine
1282 2015-11-12T21:00:25 *** TheAdversary has quit IRC
1283 2015-11-12T21:00:32 <wizkid057> Lightsword: also keep in mind that the ckpool based pools all have minimal load compared to say, Eligius
1284 2015-11-12T21:00:33 <jtimon> Luke-Jr: Bitcoin Core doesn't make any policy harder to maintain, all it can do is making some policies easier to maintain
1285 2015-11-12T21:00:46 *** Guyver2 has quit IRC
1286 2015-11-12T21:00:53 <Lightsword> wizkid057, either that or have a aggressively filtered secondary mempool to generate initial GBT from
1287 2015-11-12T21:00:56 *** Khayman has joined #bitcoin-dev
1288 2015-11-12T21:01:39 <wizkid057> Lightsword: seems overly complicated. probably less than a dozen lines of code to add a flag to GBT to skip transactions
1289 2015-11-12T21:01:48 *** Hasimir has quit IRC
1290 2015-11-12T21:02:07 <Luke-Jr> Lightsword: I propose adding an option to GBT requests "fast", which causes bitcoind to skip the mempool in CNB.
1291 2015-11-12T21:02:10 *** TheAdversary has joined #bitcoin-dev
1292 2015-11-12T21:02:20 <Luke-Jr> Lightsword: then you can call that for your first template of a new block
1293 2015-11-12T21:02:26 <wizkid057> Luke-Jr: I just said that :P
1294 2015-11-12T21:02:26 *** Khayman is now known as Hasimir
1295 2015-11-12T21:02:29 <Luke-Jr> eg, the longpoll request
1296 2015-11-12T21:02:39 <Lightsword> wizkid057, I donât really see any GBT latency issues though when the mempool is under 1MB
1297 2015-11-12T21:03:04 <jtimon> bitcoin core will stop making policies that are currently implemented using a separated block space instead of unified cost/reward metrics consciously easier to maintain (but they can still be maintained, it may remain easy forever)
1298 2015-11-12T21:03:19 <wizkid057> Lightsword: me either, but that's rare these days with sane limits
1299 2015-11-12T21:04:14 <wizkid057> Lightsword: Eligius's mempool is 62MB right now, lol
1300 2015-11-12T21:04:38 *** akrmn has quit IRC
1301 2015-11-12T21:04:48 <Lightsword> wizkid057, thatâs why I think the secondary pool just for CNB may be best if it gets refilled from a larger one, the main issue is not running out of RAM it is CNB having to operate on too large a mempool
1302 2015-11-12T21:05:16 <jtimon> I should not talk about mathematical proofs I'm not going to provide, but I strongly believe that the domains of all possible policies implementable with and without separated space are equivalent
1303 2015-11-12T21:05:32 <wizkid057> a bitcoind I have with completely default settings has a mempoolsize of 1018700445 bytes (1GB!)
1304 2015-11-12T21:05:49 <wizkid057> "size" : 75583,
1305 2015-11-12T21:05:53 <wizkid057> holy crap that's a lot of spam
1306 2015-11-12T21:06:00 *** nwilcox has joined #bitcoin-dev
1307 2015-11-12T21:06:30 <wizkid057> hmm... I should try a GBT on it
1308 2015-11-12T21:06:44 *** Amnez777_ has quit IRC
1309 2015-11-12T21:06:45 *** Amnez777_ has joined #bitcoin-dev
1310 2015-11-12T21:07:09 <Lightsword> wizkid057, one other option is just having multiple bitcoind instances and setting one with very agressive mempool filtering for fast block changes, while having a larger one for regular stratum updates
1311 2015-11-12T21:07:11 <jtimon> Luke-Jr: if you want help rebasing any concrete mining policy on top of a branch without priority, I'm interested
1312 2015-11-12T21:07:19 <wizkid057> hmm... going to rule that a non-issue: real 0m19.073s
1313 2015-11-12T21:07:37 <Lightsword> which ckpool currently doesnât supportâ¦.but may have that added
1314 2015-11-12T21:07:48 <wizkid057> 19 seconds to GBT on a crappy dual core machine with 8GB of ram and a 1GB mempool
1315 2015-11-12T21:08:16 <wizkid057> Lightsword: really, that's just seriously overcomplicating things
1316 2015-11-12T21:08:23 *** TheAdversary has quit IRC
1317 2015-11-12T21:08:36 <gmaxwell> 0.12 GBT will many times faster.
1318 2015-11-12T21:08:54 <Lightsword> I was seeing 10 seconds on a ~7MB mempool on a high end server
1319 2015-11-12T21:09:08 <wizkid057> if my crap box with bitcoind 0.11 and a 1GB mempool can return a GBT in 19 seconds... I see this as a non-issue
1320 2015-11-12T21:09:09 <gmaxwell> though part of the reason for this is ... more or less elimiating priority or at least incremental priority update.
1321 2015-11-12T21:09:33 *** Khayman has joined #bitcoin-dev
1322 2015-11-12T21:09:35 <gmaxwell> Lightsword: that sounds suspect even on 0.11. By "high end server" do you mean some questionable VPS? :)
1323 2015-11-12T21:09:44 <wizkid057> Lightsword: I think your definition of high end is questionable
1324 2015-11-12T21:10:06 <Lightsword> gmaxwell, AWS with 32GB ram quad core, with little other source of resource usage
1325 2015-11-12T21:10:08 *** TheAdversary has joined #bitcoin-dev
1326 2015-11-12T21:10:21 <gmaxwell> AWS is often completely IO starved.
1327 2015-11-12T21:10:30 <wizkid057> Lightsword: the machine I'm poking at now is an aws t1.small machine
1328 2015-11-12T21:10:33 <wangchun> wizkid057: getblocktemplate could get very slow with 1GB spams in mempool, how do you handle it?
1329 2015-11-12T21:10:47 *** Hasimir has quit IRC
1330 2015-11-12T21:10:52 <morcos> sipa: jtimon: sorry if i'm behind, but i agree with Luke-Jr, the current policy accomplishes a goal that is not equaly possible to accomplish with a combined metric. It just may not be currently worth the complication given that its not incentive compatible
1331 2015-11-12T21:10:52 <Lightsword> gmaxwell, disk IO?
1332 2015-11-12T21:10:58 *** Khayman is now known as Hasimir
1333 2015-11-12T21:11:09 <wizkid057> wangchun: I just dont care how long GBT takes. on blocknotify, I start mining immediately with no txns and as soon as GBT returns I update miners
1334 2015-11-12T21:11:23 <gmaxwell> I wish I could ban bitcoin core usage on AW; for all the spurrious complaints about performance tracable low disk throughput / high latency. :( (not serious but)
1335 2015-11-12T21:11:48 *** lewellyn has quit IRC
1336 2015-11-12T21:12:04 <wangchun> wizkid057: It is what they called "SPV mining". They will attack you for doing this.
1337 2015-11-12T21:12:10 *** lewellyn has joined #bitcoin-dev
1338 2015-11-12T21:12:20 *** GAit has joined #bitcoin-dev
1339 2015-11-12T21:12:22 <wizkid057> wangchun: no, it's not. I let bitcoind verify the block.
1340 2015-11-12T21:12:25 <Luke-Jr> morcos: the complication in this case isn't computationally expensive, so IMO it is worth it
1341 2015-11-12T21:12:33 <Lightsword> gmaxwell, with disabling free relay it seems fine though, if there is enough RAM CNB doesnât even need to touch the disk itself right?
1342 2015-11-12T21:12:43 <wangchun> wizkid057: and it generates 1-tx block, doesn't it? Everyone hate 1-tx block.
1343 2015-11-12T21:12:56 <Luke-Jr> wangchun: you absolutely should mine empty blocks on blocknotify. that is safe and not SPV mining
1344 2015-11-12T21:13:05 <Luke-Jr> it is only good for Bitcoin
1345 2015-11-12T21:13:10 <wizkid057> wangchun: sure, if the pool finds a block before GBT returns it's 1-tx. doesnt hurt anyone. much ado about nothing.
1346 2015-11-12T21:13:40 <wizkid057> adds security, ups confirmation count of in-chain txns, etc
1347 2015-11-12T21:13:52 <wangchun> Luke-Jr: But people do not like it. They will get to hate you. In the last four months, we've lost 2.5% due to suspected block withholdings.
1348 2015-11-12T21:13:55 <gmaxwell> Lightsword: you'd need a 6gb dbcache to really guarentee that, and then only after the cache is well primed.
1349 2015-11-12T21:13:58 <jtimon> morcos: I disagree, a combined metric could reproduce the current policy without a separated space (the easiest way to do so may be a performance disaster), but the point is we don't even want to
1350 2015-11-12T21:14:20 <morcos> jtimon: i really don't think so
1351 2015-11-12T21:14:24 *** c-cex-yuriy has joined #bitcoin-dev
1352 2015-11-12T21:14:27 <Luke-Jr> wangchun: they can hate me all they like. I make my decisions based on reason, not popularity.
1353 2015-11-12T21:14:48 <wizkid057> wangchun: I have a conspiracy theory on the whole block withholding thing, but I'll save that for another time
1354 2015-11-12T21:14:53 <Luke-Jr> jtimon: debating this is irrelevant and a waste of time better spent on code.
1355 2015-11-12T21:14:55 <gmaxwell> wangchun: ignorance can be corrected; though I doubt the withholding attacks are because of 1tx blocks.
1356 2015-11-12T21:14:59 <wangchun> Luke-Jr: You are right. I don't care whether they hate me. But I care about the attacks.
1357 2015-11-12T21:15:37 <jtimon> Luke-Jr: agreed, please just show me the branch that you think would suffer more if we entirely kill priority
1358 2015-11-12T21:15:44 <Luke-Jr> wangchun: a hardfork could conceivably make withholding attacks impossible. maybe we should do that if we have a hardfork.
1359 2015-11-12T21:15:45 *** ibo has joined #bitcoin-dev
1360 2015-11-12T21:15:46 <Lightsword> gmaxwell, that shouldnât be an issue, I run 32GB RAM, is there a way to force bitcoind to prime the cache on startup?
1361 2015-11-12T21:16:19 *** mrkent has joined #bitcoin-dev
1362 2015-11-12T21:17:08 <jtimon> Luke-Jr: If I'm not able to maintain the functionality of the policy, then at least will understand your point of view better
1363 2015-11-12T21:17:49 <gmaxwell> Lightsword: are you running with -dbcache=8192 or likewise?
1364 2015-11-12T21:18:03 <Lightsword> gmaxwell, no, Iâm default there
1365 2015-11-12T21:18:04 <wizkid057> Lightsword: on dedicated hardware (12 core machine with 32 GB ram, SSD RAID0) Eligius's GBT takes < 10 seconds consistently
1366 2015-11-12T21:18:11 <gmaxwell> Lightsword: oh dear.
1367 2015-11-12T21:18:25 <gmaxwell> Lightsword: well then your large amount of memory is completely uninteresting from a performance perspective.
1368 2015-11-12T21:19:08 <wizkid057> gmaxwell: I thought dbcache had a max of 4096?
1369 2015-11-12T21:19:11 <Lightsword> gmaxwell, does it default a lot lower?
1370 2015-11-12T21:19:28 <wizkid057> Lightsword: 100MB I think
1371 2015-11-12T21:19:48 *** akrmn has joined #bitcoin-dev
1372 2015-11-12T21:19:50 <gmaxwell> wizkid057: no, 16384 on 64bit.
1373 2015-11-12T21:20:21 <wizkid057> hmm
1374 2015-11-12T21:20:48 <wangchun> gmaxwell: It's either because of 1tx blocks, or the XT thing, as it all begins from late June/early July.
1375 2015-11-12T21:20:52 <Lightsword> linux has its own disk cache though as well right?
1376 2015-11-12T21:20:56 <gmaxwell> really 4096 is more than enough to get almost all of the hitrate.
1377 2015-11-12T21:21:08 <wizkid057> gmaxwell: that change between 0.10 and 0.11?
1378 2015-11-12T21:21:12 <Lightsword> Iâm assuming that should be making a difference since frequently accessed files get cached
1379 2015-11-12T21:21:31 <jgarzik> BlueMatt, Thanks for emailing bitcoin-dev RE priority!
1380 2015-11-12T21:21:33 <gmaxwell> Lightsword: the difference there is very small.
1381 2015-11-12T21:21:53 <BlueMatt> jgarzik: hey, sometimes I actually follow through when I say I'm gonna do something :p
1382 2015-11-12T21:21:58 <Lightsword> gmaxwell, so I should run with dbcache=8192 in my bitcoin.conf then? or should I try higher?
1383 2015-11-12T21:22:09 *** cryptapus_ has quit IRC
1384 2015-11-12T21:22:34 <jgarzik> BlueMatt, I am pro user communication, it gives me warm fuzzies ;p
1385 2015-11-12T21:22:44 <gmaxwell> Lightsword: 8192 is fine. It won't use more than about 6GB right now anyways. Thats enough to get the whole utxo set in ram.
1386 2015-11-12T21:23:01 <BlueMatt> jgarzik: yea, we need a better strategy there, actually....like, most "users" dont read bitcoin-dev, even that is an echo chamber :(
1387 2015-11-12T21:23:11 <BlueMatt> jgarzik: we need a bitcoin-users-announce list or something
1388 2015-11-12T21:23:24 <BlueMatt> (dont take that as a serious suggestion, I dont want more lists)
1389 2015-11-12T21:23:42 <gmaxwell> BlueMatt: someone who cares to can, however. The duty isn't to go out and bang on everyone's door, but to at least make it readily available.
1390 2015-11-12T21:23:42 <wizkid057> I read -dev when I have time... lots of activity though, so, hard to keep up sometimes
1391 2015-11-12T21:23:48 <jgarzik> BlueMatt, agree w/ sentiment - though I want to be a cheerleader for progress, steps in the right direction
1392 2015-11-12T21:23:58 <jgarzik> it has a wider audience than IRC
1393 2015-11-12T21:24:04 <gmaxwell> "The plans were on display"
1394 2015-11-12T21:24:13 <BlueMatt> wizkid057: you have to be good at reading the first mail and then ignoring that entire topic
1395 2015-11-12T21:24:19 <jgarzik> heh
1396 2015-11-12T21:24:36 <wizkid057> BlueMatt: lol
1397 2015-11-12T21:25:00 <morcos> wumpus: btw i emailed -dev on 10/5 with the proposed lower limits and received basically no response. one weak nack that said they hadn't yet seen a use case for more than 25. hope that makes you feel better about the amount of controversy
1398 2015-11-12T21:25:21 <wizkid057> âYes,â said Arthur, âyes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying âBeware of the Leopard.â
1399 2015-11-12T21:25:51 <gmaxwell> wizkid057: :)
1400 2015-11-12T21:25:55 <wumpus> morcos: yes it's a bit strange that some people say to care deeply about it but when you probe further it's not clear what it is about
1401 2015-11-12T21:26:23 <phantomcircuit> gmaxwell, gah 19 loc, you monsters!
1402 2015-11-12T21:26:23 *** GAit has quit IRC
1403 2015-11-12T21:26:42 *** GAit has joined #bitcoin-dev
1404 2015-11-12T21:27:07 *** neozaru has joined #bitcoin-dev
1405 2015-11-12T21:27:55 <Luke-Jr> wizkid057: -dev ML is getting easier to keep up with since it's moderated now
1406 2015-11-12T21:32:19 <wumpus> morcos: after reading the comments another time it does seem that most people initially against it their concerns were put mostly at rest
1407 2015-11-12T21:32:40 <wumpus> morcos: e.g. 25 is stilll enough, they just don't want it to become even lower
1408 2015-11-12T21:34:10 <wizkid057> Luke-Jr: oh... when did that happen?
1409 2015-11-12T21:34:24 <Luke-Jr> wizkid057: dunno, maybe a month ago or so
1410 2015-11-12T21:37:06 *** Burrito has joined #bitcoin-dev
1411 2015-11-12T21:39:29 *** shurnormal has joined #bitcoin-dev
1412 2015-11-12T21:45:38 *** damethos has quit IRC
1413 2015-11-12T21:49:37 *** mjerr has quit IRC
1414 2015-11-12T21:49:40 *** noamh has joined #bitcoin-dev
1415 2015-11-12T21:50:57 *** [7] has quit IRC
1416 2015-11-12T21:51:38 *** TheSeven has joined #bitcoin-dev
1417 2015-11-12T21:52:50 <sipa> morcos: yes, i agree that may be the case; i was talking hypothetically - the current policy is not optimal (for example, it could limit the amount of fees lost rather than set a fixed sze area)
1418 2015-11-12T21:53:03 *** Newyorkadam has joined #bitcoin-dev
1419 2015-11-12T21:53:39 *** Ahmed90 has quit IRC
1420 2015-11-12T21:54:46 *** ParadoxSpiral has quit IRC
1421 2015-11-12T21:54:49 <morcos> sipa: yes i mostly think its not worth trying to do anything different that's also not incentive compatible.
1422 2015-11-12T21:55:11 *** cfromknecht has quit IRC
1423 2015-11-12T21:55:19 *** cfromknecht has joined #bitcoin-dev
1424 2015-11-12T21:56:34 *** adam3us has quit IRC
1425 2015-11-12T21:57:27 *** treehug88 has quit IRC
1426 2015-11-12T21:57:58 <morcos> oh yeah, btw, not to beat a dead horse, but did you see sturles comment on 6992. sdaftuar saw the same thing, it does make your mempool more accurately reflect what will be in blocks. however that to me is a minor reason to support it if we think that effect will go away in time due to less priority space by miners.
1427 2015-11-12T21:57:58 *** jgarzik has quit IRC
1428 2015-11-12T21:58:46 *** Newyorkadam has quit IRC
1429 2015-11-12T21:58:58 <sipa> well if we keep priority space... it likely will all just keep working fine, maybe for years
1430 2015-11-12T21:59:06 *** brson_ has quit IRC
1431 2015-11-12T21:59:09 <sipa> ... for a small number of users with old coins
1432 2015-11-12T22:00:06 <sturles> Except for a very few, miners seem to keep priority space.
1433 2015-11-12T22:00:31 <sturles> A common misconception here, it seems, is that priority transactions don't pay fees. They do.
1434 2015-11-12T22:00:47 <sipa> they're not required to
1435 2015-11-12T22:01:11 <sturles> The may pay less fees than other transactions, but the total fees per KB from the priority space and the rest is not very different.
1436 2015-11-12T22:01:23 <sturles> sipa: No, they are not required to, but most do.
1437 2015-11-12T22:01:25 <sipa> i think priority transactions only really work because nearly nobody uses them
1438 2015-11-12T22:01:32 *** alb12 has joined #bitcoin-dev
1439 2015-11-12T22:01:50 *** sharperguy has quit IRC
1440 2015-11-12T22:01:55 <sipa> sturles: if the feerate is not very differentz removing the priority rule will not make a difference
1441 2015-11-12T22:02:00 <sturles> Bitcoin would have been completely devastated during some of the previous spam attacks if we hadn't had the priority space.
1442 2015-11-12T22:02:09 <sipa> i doubt that
1443 2015-11-12T22:02:27 <sipa> it's a small percentage of the block space
1444 2015-11-12T22:02:37 <sturles> Non-spam trickeled through the storm. Very few non-spam transactions were significantly delayed, even with much lower fees than the spam.
1445 2015-11-12T22:03:06 <sturles> You will be amazed to know how large part of the current blocks are wasted on spam.
1446 2015-11-12T22:03:21 <sipa> i am sure about that!
1447 2015-11-12T22:03:36 <wizkid057> sturles: I think a good chunk of the help during the spam attacks were a small number of pools doing some filtering...
1448 2015-11-12T22:03:40 <sturles> Most legitimate transactions can fit in a very small part of the blocks. The current priority space is large enough.
1449 2015-11-12T22:03:54 <sturles> wizkid057: True.
1450 2015-11-12T22:04:04 <sipa> sturles: so you're saying mining fee income should come from spam, that pays for legitimate transactions?
1451 2015-11-12T22:04:14 <sipa> what if we get mkre legitimate transactions?
1452 2015-11-12T22:04:28 <wizkid057> I got dozens of emails from people with "stuck" transactions thanking me for including their transactions in a block
1453 2015-11-12T22:04:30 <sturles> No, I never said that.
1454 2015-11-12T22:04:48 <sipa> then the priority space won't be big enough in the long term
1455 2015-11-12T22:04:56 <sipa> or the medium term
1456 2015-11-12T22:05:17 <sturles> sipa: I say the priority space pays about the same in fees as the rest, even if priority transactions aren't required to pay fees.
1457 2015-11-12T22:05:38 *** benrcole1 has left #bitcoin-dev
1458 2015-11-12T22:05:45 <sturles> It may be too small, yes. We should increase the default somewhat.
1459 2015-11-12T22:05:47 <sipa> sturles: if that is the case, removing it will make no difference
1460 2015-11-12T22:05:47 *** jtoomim_ is now known as jtoomim
1461 2015-11-12T22:06:14 <sturles> Yes, it does. About the same, not exactly the same.
1462 2015-11-12T22:06:36 *** mrkent has quit IRC
1463 2015-11-12T22:06:51 <sturles> See if you can find a difference in income between e.g. BitMinter's blocks (500kB priority space) and those with a lot smaller or no priority space.
1464 2015-11-12T22:06:55 <wizkid057> I think some mechanism that both auto adjusts fees based on current conditions, as well as a sane replace-by-fee type setup that allows people to bump their txn fees (possibly automatically up to a limit?) would be the way to go long term
1465 2015-11-12T22:07:06 <sipa> well i am still in favor of just using a combined metric that slightly increases the 'virtual fee' by a priority metric
1466 2015-11-12T22:07:14 <wizkid057> that way the spammers end up going broke and not causing much havoc, and legit folks have a way in
1467 2015-11-12T22:07:24 <sipa> people just fear it will either nkt work, or be gamable
1468 2015-11-12T22:08:04 <sturles> I think a combined metric may end up at least as complex as the current situation. People are going to adjust all kinds of knobs.
1469 2015-11-12T22:08:23 <sipa> sturles: i promise you it will be 100s of lines of code less
1470 2015-11-12T22:09:02 <sipa> no separate index, no separate fee estimator, no separate mempool space, no logic to selectively sort in CNB, ...
1471 2015-11-12T22:09:09 <wizkid057> definitely long term (and maybe even short term with the second subsidy halving coming next year) there is going to have to be some serious changes to how txn fees are handled, for sure
1472 2015-11-12T22:09:27 <morcos> sipa: there will be a conversion factor estimator
1473 2015-11-12T22:09:35 <sipa> morcos: sure
1474 2015-11-12T22:09:42 <sipa> that's 1 line
1475 2015-11-12T22:09:50 <sipa> ah
1476 2015-11-12T22:10:04 <sipa> hmm, if you think you need to go that far
1477 2015-11-12T22:10:29 <morcos> i just think a fixed conversion factor would be just as annoying as the fixed fees in the past were
1478 2015-11-12T22:11:21 <sipa> perhaps
1479 2015-11-12T22:11:22 <morcos> but you are right, way simpler. maybe its ok for it to be a manual knob that miners just adjust in time of spam attacks
1480 2015-11-12T22:11:29 <sturles> sipa: No matter what changes are made â please run a simulation high fee spam attack to see that normal transactions still get a chance to get through.
1481 2015-11-12T22:11:46 <morcos> sturles: there hasn't been a high fee spam attack yet
1482 2015-11-12T22:12:02 <morcos> its hard for their to be one, bc its by definition expensive
1483 2015-11-12T22:12:51 <wizkid057> spam *should* be prohibitively expensive. IMO, it is not currently
1484 2015-11-12T22:13:06 <dgenr8> morcos: +1, shame if we don't exploit this property to the fullest
1485 2015-11-12T22:13:08 <sturles> Yes, there was one using higher than the default fee. The default when no estimate is available, and for some SPV wallets.
1486 2015-11-12T22:14:37 *** CheckDavid has joined #bitcoin-dev
1487 2015-11-12T22:14:50 <wizkid057> last I checked I could fill an entire block for like $100 or so
1488 2015-11-12T22:14:53 <wizkid057> if I wanted
1489 2015-11-12T22:14:56 <dgenr8> sipa: does a priority tweak really help, if a wallet tx can still be dropped? seems like it's fish or cut bait
1490 2015-11-12T22:15:08 <wizkid057> that's definitely not prohibitively expensive for someone wanting to cause issues
1491 2015-11-12T22:15:28 <kanzure> re: fee estimation, see http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011685.html https://medium.com/@bramcohen/how-wallets-can-handle-transaction-fees-ff5d020d14fb
1492 2015-11-12T22:16:25 <Luke-Jr> sipa: the legitimate tx volume is like 300k/block on average. smaller, if we rule out microtransactions. so 27k default priority size is 9% of that
1493 2015-11-12T22:17:06 <sipa> morcos: part of the problem in using btcdays as metric is that there is a huge stash of it available in case it would actually become valuable
1494 2015-11-12T22:17:30 <Luke-Jr> sipa: it loses its value when transferred.. :P
1495 2015-11-12T22:17:52 <Luke-Jr> besides, nobody is adding value to it, just maintaining its current value
1496 2015-11-12T22:18:00 <Luke-Jr> which IMO has not been a problem
1497 2015-11-12T22:19:10 <wizkid057> I could see some system where btcdays lowered fees enough to be worthwhile being exploited by larger entities with a sufficient buffer to keep their sent coins older
1498 2015-11-12T22:19:22 <Luke-Jr> considering there is negative cost to keeping the priority logic in place, the answer is obvious
1499 2015-11-12T22:19:23 <sipa> Luke-Jr: imagine we make all mining selection based on just priority
1500 2015-11-12T22:19:36 <sipa> Luke-Jr: spam would likely be gone
1501 2015-11-12T22:19:52 <sipa> but only people with old coins would be sending transactions
1502 2015-11-12T22:20:06 <Luke-Jr> sipa: I'm not recommending that!
1503 2015-11-12T22:20:27 <sipa> i know you are not
1504 2015-11-12T22:20:32 *** rodkeys has quit IRC
1505 2015-11-12T22:21:05 <sipa> but imagine a place where spammers somehow decide burning huge amounts in fees is ok, and "legitimate" transactions (whatever those are have a hard time competing)
1506 2015-11-12T22:21:21 <sipa> now the priority space becomes the new block space to compete for
1507 2015-11-12T22:21:31 <sipa> and those who have old coins are privileged
1508 2015-11-12T22:21:57 <dgenr8> with priority only, if you don't have old coins, the prescription is "wait". with fee only, the prescription is "wait until the spammer has spent his wad"
1509 2015-11-12T22:22:11 <Luke-Jr> sipa: better than nothing working at all
1510 2015-11-12T22:22:33 *** neozaru has quit IRC
1511 2015-11-12T22:22:39 *** ThomasV has joined #bitcoin-dev
1512 2015-11-12T22:22:44 <dgenr8> OR pay up
1513 2015-11-12T22:22:45 *** ratbanebo has quit IRC
1514 2015-11-12T22:22:54 <sipa> pay up works :)
1515 2015-11-12T22:23:07 <sipa> and i think that in the long term it is the only thing that works
1516 2015-11-12T22:23:12 *** ratbanebo has joined #bitcoin-dev
1517 2015-11-12T22:23:58 <wizkid057> I think it'd be awesome if after a while (an hour or so) if a sent tx hasn't been mined the client would pester the user, "Hey pal, I bet this transaction would get mined if you re-sent it with a higher fee...."
1518 2015-11-12T22:24:06 <sipa> yes
1519 2015-11-12T22:24:42 <Luke-Jr> we don't have a good solution to the spam problem. that doesn't mean we shouldn't do the best we can.
1520 2015-11-12T22:24:56 <wizkid057> determining the appropriate fee based on current conditions is above my pay grade, but, would be cool if there was a sane way to do so :)
1521 2015-11-12T22:25:08 <Luke-Jr> wizkid057: Core already tries
1522 2015-11-12T22:26:24 <wizkid057> I mean, is there a setting to include a fee that basically guarantees inclusion in a block soon? If so, I bet people would use it
1523 2015-11-12T22:26:47 <Luke-Jr> wizkid057: you can set it to target the very next block
1524 2015-11-12T22:27:17 <wizkid057> fees are pretty darn cheap. If it costs $0.15 to guarantee quick inclusion vs $0.05 for an indefinite wait... I'd go with the former
1525 2015-11-12T22:27:29 <sipa> Luke-Jr: i very much disagree that setting apart two separate spaces for two separate policies is the best we can do
1526 2015-11-12T22:27:46 <sipa> Luke-Jr: even when disregarding incentive compatibility with mining
1527 2015-11-12T22:27:50 <Luke-Jr> sipa: it's certainly better than the feerate-only policy.
1528 2015-11-12T22:27:57 <wizkid057> sipa: I think it's a better than nothing scenario
1529 2015-11-12T22:28:17 <wizkid057> gotta run
1530 2015-11-12T22:28:25 <sipa> Luke-Jr: perhaps, but that doesn't mean you should keep defending the current solution at all costs
1531 2015-11-12T22:28:34 <Luke-Jr> wizkid057: right now, my non-247 Core node estimates 0.00088495 BTC/kB for next-block mining (vs 0.00001014 BTC for 25 blocks)
1532 2015-11-12T22:29:01 *** won9 has joined #bitcoin-dev
1533 2015-11-12T22:29:06 <Luke-Jr> sipa: as mentioned, the current solution has negative costs. removing it in Core costs more.
1534 2015-11-12T22:29:58 <sipa> Luke-Jr: i also very much disagree with that; it is complicating improvements to mempool, mining, estimation, ...
1535 2015-11-12T22:30:46 *** ThomasV has quit IRC
1536 2015-11-12T22:30:46 <Luke-Jr> estimation must take it into consideration (or not) regardless of what Core does, since miners may decide to use it despite removal
1537 2015-11-12T22:31:22 <Luke-Jr> mining is code I maintain anyway, and I also maintain LJR, so I have to maintain it either way, and it's more work to maintain it separate
1538 2015-11-12T22:31:28 <morcos> Luke-Jr: its not possible to estimate using it if you don't have priority txs in your mempool
1539 2015-11-12T22:31:39 <morcos> so thats already broken with limited mempool
1540 2015-11-12T22:31:55 <morcos> interesting that you have such a low estimate for 25 block confirmation
1541 2015-11-12T22:32:06 *** brson has joined #bitcoin-dev
1542 2015-11-12T22:32:17 <morcos> fees.chaincode.com is returning 4373 sat
1543 2015-11-12T22:32:47 <Luke-Jr> morcos: my node may not have been running for days
1544 2015-11-12T22:32:57 <Luke-Jr> 9 days it looks like
1545 2015-11-12T22:33:34 <morcos> still, this attack has been going on a long time... one possibility is that txs which meet your mempool policy actually do get mined at such a low fee rate...
1546 2015-11-12T22:33:50 <Luke-Jr> possible, yes
1547 2015-11-12T22:34:18 <sipa> estimation unfortunately relies on knowing other's policies...
1548 2015-11-12T22:34:27 <Luke-Jr> hmm, a real-world benefit to setting a sane relay policy: you might get better fee estimates :D
1549 2015-11-12T22:37:00 *** nwilcox has quit IRC
1550 2015-11-12T22:37:02 <Luke-Jr> although it'd probably be a good idea to try to figure out a way to account for that in estimation logic
1551 2015-11-12T22:37:14 *** aburan28 has joined #bitcoin-dev
1552 2015-11-12T22:38:05 *** tantalum has quit IRC
1553 2015-11-12T22:41:31 *** supasonic has joined #bitcoin-dev
1554 2015-11-12T22:43:46 *** won9 has quit IRC
1555 2015-11-12T22:44:35 *** sharperguy has joined #bitcoin-dev
1556 2015-11-12T22:45:59 *** bedeho has quit IRC
1557 2015-11-12T22:46:24 *** Lightsword has quit IRC
1558 2015-11-12T22:57:11 *** CoinMuncher has quit IRC
1559 2015-11-12T22:58:03 *** bedeho has joined #bitcoin-dev
1560 2015-11-12T22:58:25 *** pepesza has quit IRC
1561 2015-11-12T22:59:42 *** pepesza has joined #bitcoin-dev
1562 2015-11-12T23:10:05 *** Dizzle has quit IRC
1563 2015-11-12T23:11:56 *** rodkeys has joined #bitcoin-dev
1564 2015-11-12T23:21:42 *** mstang83 has quit IRC
1565 2015-11-12T23:33:14 *** hashtagg has quit IRC
1566 2015-11-12T23:33:53 *** DougieBot5000 has quit IRC
1567 2015-11-12T23:34:22 *** pepesza has quit IRC
1568 2015-11-12T23:41:41 *** metal_camp has joined #bitcoin-dev
1569 2015-11-12T23:42:54 *** kgk has joined #bitcoin-dev
1570 2015-11-12T23:44:08 *** metalcamp has quit IRC
1571 2015-11-12T23:46:41 *** GAit has quit IRC
1572 2015-11-12T23:50:14 *** arichnad has quit IRC
1573 2015-11-12T23:51:27 *** Barbatos has quit IRC
1574 2015-11-12T23:52:09 *** murr4y has quit IRC
1575 2015-11-12T23:52:20 *** Taek has quit IRC
1576 2015-11-12T23:52:21 *** kgk has quit IRC
1577 2015-11-12T23:52:39 *** LeMiner has joined #bitcoin-dev
1578 2015-11-12T23:53:12 *** dstien has quit IRC
1579 2015-11-12T23:53:27 *** Taek has joined #bitcoin-dev
1580 2015-11-12T23:54:08 *** dstien has joined #bitcoin-dev
1581 2015-11-12T23:55:04 *** nwilcox has joined #bitcoin-dev
1582 2015-11-12T23:55:59 *** Barbatos has joined #bitcoin-dev
1583 2015-11-12T23:56:30 *** rnvk has quit IRC
1584 2015-11-12T23:56:43 *** GAit has joined #bitcoin-dev
1585 2015-11-12T23:56:44 *** rnvk has joined #bitcoin-dev
1586 2015-11-12T23:57:40 *** dave4925 has quit IRC
1587 2015-11-12T23:58:07 *** GAit has quit IRC
1588 2015-11-12T23:58:51 *** murr4y has joined #bitcoin-dev
1589 2015-11-12T23:59:29 *** one_zero has joined #bitcoin-dev