1 2014-11-26 07:33:31 <earlz> around how big is the testnet blockchain these days?
2 2014-11-26 07:36:54 <fanquake> 1.7GB
3 2014-11-26 07:39:20 <earlz> ah, not too big for my laptop then
4 2014-11-26 10:47:15 <cfields> out of town 'til next sunday, happy hacking everyone
5 2014-11-26 11:07:22 <gavinandresen> sipa: I donât understand your comment âWhatever we are or were comfortable with, this adds
6 2014-11-26 11:07:25 <gavinandresen> another 100 nonprunable blocks."
7 2014-11-26 11:08:33 <gavinandresen> sipa: also: none of the block indices keep track of the blockâs coinbase transaction, do they?
8 2014-11-26 11:12:48 <gavinandresen> sipa: also, re: re-orgs hitting the disk a little bit more and maybe propagating slightly slower: seems like a feature, not a bug; disincentivizing reorg-the-chain is good for making attacks like selfish mining unprofitable.
9 2014-11-26 11:22:40 <jtimon> I can't build the current master
10 2014-11-26 11:22:42 <jtimon> ^
11 2014-11-26 11:22:42 <jtimon> __THROW __attribute_pure__ __nonnull ((1));
12 2014-11-26 11:22:42 <jtimon> /usr/include/string.h:407:33: error: conflicts with new declaration with âCâ linkage
13 2014-11-26 11:22:42 <jtimon> /usr/include/string.h:407:33: error: declaration of âsize_t strnlen(const char*, size_t) throw ()â has a different exception specifier
14 2014-11-26 11:23:26 <wumpus> jtimon: you need to remove src/bitcoin-config.h, I had the same problem
15 2014-11-26 11:23:28 <Luke-Jr> jtimon: sounds like somehow the fallback strnlen is getting in there
16 2014-11-26 11:23:48 <paveljanik> you are all faster when typing than I am ;-)
17 2014-11-26 11:23:54 <Luke-Jr> wumpus: that suggests something is broken with the build system? :/
18 2014-11-26 11:24:09 <paveljanik> #5374
19 2014-11-26 11:24:11 <wumpus> people moved around the bitcoin-config.h but somehow the old one is being picked up
20 2014-11-26 11:24:16 <Luke-Jr> ah
21 2014-11-26 11:24:28 <paveljanik> jtimon: please try #5374
22 2014-11-26 11:24:40 <paveljanik> if it fixes it in your current build tree please
23 2014-11-26 11:24:50 <jtimon> wumpus yes thank you that seemed to work
24 2014-11-26 11:24:54 <wumpus> I'd really prefer if you'd stop moving it, all those moving files make me dizzy
25 2014-11-26 11:26:59 <wumpus> paveljanik: yup we should test if that solves the issue
26 2014-11-26 11:27:03 <paveljanik> move over it
27 2014-11-26 11:27:24 <paveljanik> jtimon: can you re-create the file with probably #error inside?
28 2014-11-26 11:28:48 <jtimon> paveljanik I'm not sure what you want me to do, fetch and build #5374 ?
29 2014-11-26 11:29:28 <paveljanik> jtimon: grab the one-liner from #5374, recreate removed file, put #error inside it somewhere and build again.
30 2014-11-26 11:29:49 <paveljanik> jtimon: https://github.com/bitcoin/bitcoin/pull/5374/files
31 2014-11-26 11:30:11 <jtimon> ok, maybe later I don't have much time right now
32 2014-11-26 11:30:20 <paveljanik> ok
33 2014-11-26 11:31:18 <Luke-Jr> wumpus: how about we have headers with the same filename, but different purpose?
34 2014-11-26 11:31:24 <Luke-Jr> like Linux does
35 2014-11-26 11:32:00 <Luke-Jr> :P
36 2014-11-26 11:34:54 <wumpus> Luke-Jr: does linux do that?
37 2014-11-26 11:35:44 <Luke-Jr> wumpus: it's worse than I make it sound; they have the same installed-path in /usr/include too XD
38 2014-11-26 11:36:01 <Luke-Jr> /usr/include/linux/i2c-dev.h has two flavours
39 2014-11-26 11:36:07 <Luke-Jr> one for kernel code, and one for userspace
40 2014-11-26 11:36:46 <wumpus> that can indeed be kind of confusing, they didn't need to use the same name
41 2014-11-26 11:41:19 <wumpus> paveljanik: strange, I can't reproduce the issue at all anymore. I created a src/bitcoin-config.h with #error and it doesn't get included not even without your patch. I'm happy that jtimon can confirm it really happened and I didn't imagine it :)
42 2014-11-26 11:41:39 <paveljanik> wumpus: strange - see my last comment in #5374
43 2014-11-26 11:41:45 <paveljanik> I can recreate it.
44 2014-11-26 11:42:16 <paveljanik> recompiling crypto/...
45 2014-11-26 11:42:23 <paveljanik> try make clean.
46 2014-11-26 11:42:57 <paveljanik> ACTION should finally add ccache to his builds
47 2014-11-26 11:43:56 <jtimon> wumpus also "make clean; ./autogen.sh; ./configure" didn't help, I had to remove the file as you said
48 2014-11-26 11:44:52 <paveljanik> make clean doesn't probably remove src/bitcoin-config.h
49 2014-11-26 11:45:18 <wumpus> paveljanik: it doesn't remove files it doesn't know about
50 2014-11-26 11:45:44 <paveljanik> yes. I didn't said it is wrong :-)
51 2014-11-26 11:45:55 <Luke-Jr> git clean can do it, but .. git clean is scary
52 2014-11-26 11:46:08 <Luke-Jr> it will gladly delete everything not in git
53 2014-11-26 11:46:15 <Luke-Jr> including your important todo file
54 2014-11-26 11:46:30 <wumpus> Luke-Jr: for 0.11 we should really have out-of-tree builds working
55 2014-11-26 11:46:51 <Luke-Jr> we don't? :/
56 2014-11-26 11:47:08 <wumpus> no, due to leveldb
57 2014-11-26 11:47:12 <Luke-Jr> oh right
58 2014-11-26 11:47:17 <Luke-Jr> well, that's easily solved <.<
59 2014-11-26 11:47:44 <wumpus> nothing with this build system is easy
60 2014-11-26 11:47:56 <Luke-Jr> no, I mean by not embedding dependencies
61 2014-11-26 11:48:16 <Luke-Jr> (an alternative probably more accepted is to autotools leveldb)
62 2014-11-26 11:48:38 <wumpus> sigh, not that discussion again
63 2014-11-26 11:49:34 <Luke-Jr> wumpus: actually, it might seriously be worth revisiting after 0.10 - consider that we have a full package manager to get all our other deps now
64 2014-11-26 12:38:04 <jonasschnelli> building the master on OSX 10.10. Getting: /usr/include/string.h:133:10: error: declaration of 'strnlen' has a different language linkage
65 2014-11-26 12:38:18 <jonasschnelli> ^
66 2014-11-26 12:38:18 <jonasschnelli> ./compat.h:92:8: note: previous declaration is here
67 2014-11-26 12:38:18 <jonasschnelli> size_t strnlen(const char *, size_t) __OSX_AVAILABLE_STARTING(__MAC_10_7, __IPHONE_4_3);
68 2014-11-26 12:38:18 <jonasschnelli> size_t strnlen( const char *start, size_t max_len);
69 2014-11-26 12:38:51 <wumpus> jonasschnelli: please re-run autogen.sh and configure
70 2014-11-26 12:39:09 <jonasschnelli> trying right now....
71 2014-11-26 12:39:58 <jonasschnelli> okay. a autoreconf -i / configure solved the issue. Thanks wumpus.
72 2014-11-26 13:18:02 <sipa> gavinandresen: if we believe we should keep enough blocks around to reorg X blocks back when pruned, this change means we can't prune beyond X-100
73 2014-11-26 13:37:39 <jonasschnelli> rpc unit-test: would it be worth to include a http client library (like libcurl) to kosher test the rpc/rest interface? currently the http-layer gets skipped.
74 2014-11-26 13:38:42 <jonasschnelli> alternatively a small incomplete http client class would also do the job
75 2014-11-26 13:39:02 <sipa> i'm not so worried about dependencies for the python tests
76 2014-11-26 13:39:07 <sipa> but maybe others have more opinions
77 2014-11-26 13:40:52 <jonasschnelli> hmm... i was thinking around the c++ boost unit tests. I overlooked the python based utest. Let me dive in there...
78 2014-11-26 13:59:23 <wumpus> yes please use a python-based test for that
79 2014-11-26 14:02:17 <jonasschnelli> wumpus, Okay. I just started to play around with the py test framework in /qa/pull-tester
80 2014-11-26 15:16:02 <michagogo> Erm, new commits on the 0.9.3 branch? o_O
81 2014-11-26 15:16:42 <wumpus> in principle we have all the functionality required for connecting to the RPC in the C++ code, no need for external dependencies, but it's better to use python for functional tests than try to stuff it in unit tests
82 2014-11-26 15:17:04 <wumpus> michagogo: pre-0.9.4
83 2014-11-26 15:17:12 <michagogo> Hm.
84 2014-11-26 15:17:16 <wumpus> michagogo: use the v0.9.3 tag if you want to build 0.9.3
85 2014-11-26 15:17:27 <michagogo> ACTION would have expected a new branch, or an 0.9 branch...
86 2014-11-26 15:17:53 <wumpus> sigh, yes that's possible too...
87 2014-11-26 15:18:24 <michagogo> Not saying you should do that, just seemed weird to me
88 2014-11-26 15:18:37 <wumpus> agree that it should have been a 0.9 branch, instead of branching from branches for every minor release, let's do that for 0.10
89 2014-11-26 15:19:15 <michagogo> Yeah, that makes sense
90 2014-11-26 15:19:35 <michagogo> (I assume it's not very likely to ever have 2 minor releases in the works at the same time?)
91 2014-11-26 15:21:15 <wumpus> that never happens, and if it does, it's still possible to create branches for them
92 2014-11-26 15:22:04 <wumpus> that reminds me, we should remove branches for in-between minor versions
93 2014-11-26 15:22:28 <wumpus> makes no sense to still have a 0.9.0 tag, we have v0.9.0 tag for that
94 2014-11-26 15:22:41 <wumpus> eh.. first tag should be branch ofc
95 2014-11-26 15:24:16 <michagogo> Is 0.9.0 HEAD identical to v0.9.0?
96 2014-11-26 15:24:55 <wumpus> likely not
97 2014-11-26 15:25:04 <wumpus> 0.9.0 HEAD is pre-0.9.1
98 2014-11-26 15:26:21 <wumpus> (for the same reason that we've committed pre-0.9.4 commits to the 0.9.3 branch, it may be weird but it is consistent :-)
99 2014-11-26 15:27:24 <michagogo> erm, so at what point did 0.9.1 branch off?
100 2014-11-26 15:27:31 <michagogo> At the rc1 tag?
101 2014-11-26 15:27:34 <wumpus> I don't know that by heart.
102 2014-11-26 15:27:39 <wumpus> use the source, luke
103 2014-11-26 15:28:36 <michagogo> https://github.com/bitcoin/bitcoin/compare/0.9.0...v0.9.0
104 2014-11-26 15:28:43 <michagogo> 0.9.0 is up to date with all commits from v0.9.0.
105 2014-11-26 15:28:43 <michagogo> There isn't anything to compare.
106 2014-11-26 15:28:45 <wumpus> the historical reason for doing it this way is that people tended to post all over reddit and the bt forums as soon as they saw a new version appear
107 2014-11-26 15:29:08 <michagogo> oh, wait
108 2014-11-26 15:29:15 <michagogo> 0.9.1 and v0.9.1 are identical.
109 2014-11-26 15:29:15 <michagogo> There isn't anything to compare.
110 2014-11-26 15:29:35 <wumpus> anyhow, creating a 0.10 branch makes more sense, there is no need for branches for minor versions
111 2014-11-26 15:29:38 <michagogo> I was doing it wrong
112 2014-11-26 15:29:45 <michagogo> https://github.com/bitcoin/bitcoin/compare/v0.9.0...0.9.0
113 2014-11-26 15:32:26 <jonasschnelli> just run a memory leak check on bitcoind, is that normal that libdb_cxx-4.8.dylib is leaking all over?
114 2014-11-26 15:35:12 <wumpus> I don't think that's normal
115 2014-11-26 15:38:17 <michagogo> What's our OS X minimum version?
116 2014-11-26 15:38:44 <wumpus> 10.6 I guess
117 2014-11-26 15:38:49 <sipa> 10.7 for building, 10.6 for running, afaik
118 2014-11-26 15:39:41 <michagogo> I thought that OS X ditched 32-bit a while back
119 2014-11-26 15:40:02 <michagogo> I checked, and it turns out that 10.6 was the last version to support it
120 2014-11-26 15:40:12 <sipa> we only do 64-bit builds anymore, afaik
121 2014-11-26 15:40:22 <wumpus> we don't have 32-bit binaries for MacOSX on gitian, but there's no reason why you couldn't build it for 32 bit
122 2014-11-26 15:40:23 <sipa> so even on 10.6, i expect it to only work on 64-bit systems
123 2014-11-26 15:40:30 <michagogo> Oh, do we?
124 2014-11-26 15:40:40 <michagogo> https://github.com/bitcoin/bitcoin/pull/5371 seemed to suggest otherwise
125 2014-11-26 15:41:09 <sipa> the dmg is the installer, but i still think it only contains a 64-bit binary
126 2014-11-26 15:41:17 <wumpus> ... no osx32 there
127 2014-11-26 15:41:26 <michagogo> wait
128 2014-11-26 15:41:27 <michagogo> ignore me
129 2014-11-26 15:41:32 <wumpus> dmg is the gui, .tar.gz is the bitcoind etc
130 2014-11-26 15:41:36 <michagogo> I saw osx and osx64
131 2014-11-26 15:41:39 <sipa> cfields-away: any reason why the dmg for osx is called 'osx', while the tgz in is called 'osx64' ?
132 2014-11-26 15:41:44 <michagogo> and missed the ext... derp
133 2014-11-26 15:42:13 <wumpus> the .tar.gz is new, we never used to have that for macosx, but some people requested it
134 2014-11-26 15:42:22 <michagogo> Does the tgz include the GUI too?
135 2014-11-26 15:42:28 <wumpus> no clue
136 2014-11-26 15:42:37 <michagogo> (is it the same full package as the linux tgzs and the win zips?)
137 2014-11-26 15:42:48 <wumpus> I suggest building it and trying
138 2014-11-26 15:42:49 <sipa> try it!
139 2014-11-26 15:43:05 <sipa> i'll set up a gitian env soon again as well
140 2014-11-26 15:43:08 <michagogo> I guess I should...
141 2014-11-26 15:43:13 <sipa> i believe 24 GB of ram should suffice
142 2014-11-26 15:43:17 <michagogo> I'm not 100% sure what state my ubuntu vm is in atm
143 2014-11-26 15:43:38 <michagogo> Also, I never got around to testing the deps builder, so that'll be new too
144 2014-11-26 15:43:42 <wumpus> even my measly 8GB is easily enough
145 2014-11-26 15:43:50 <sipa> the depends system *just works*
146 2014-11-26 15:43:59 <michagogo> sipa: yeah, I meant as it was being worked on
147 2014-11-26 15:44:09 <sipa> i mean: i can build bitcoind for ARM...
148 2014-11-26 15:44:14 <michagogo> (sorry, cfields-away!)
149 2014-11-26 15:44:19 <sipa> without any weird installation or hackery
150 2014-11-26 15:44:42 <wumpus> indeed, cross compile for other platforms and architectures is now easy
151 2014-11-26 15:45:31 <hearn> gavinandresen: do you remember when the cent rule was dropped?
152 2014-11-26 15:45:42 <hearn> i.e. fee requires special logic when any output is <1 btcent
153 2014-11-26 15:47:48 <sipa> hearn: merged october 19th 2013
154 2014-11-26 15:47:49 <michagogo> hearn: https://github.com/bitcoin/bitcoin/pull/4305?
155 2014-11-26 15:47:58 <paveljanik> We're sorry -- the Sourceforge site is currently in Disaster Recovery mode
156 2014-11-26 15:47:59 <michagogo> Oh, wait
157 2014-11-26 15:48:00 <paveljanik> 8)
158 2014-11-26 15:48:08 <wumpus> hey he was asking gavinandresen specifically :p
159 2014-11-26 15:48:13 <sipa> paveljanik: oh no, DRM!
160 2014-11-26 15:48:17 <hearn> michagogo: that was the gui level change?
161 2014-11-26 15:48:28 <michagogo> hearn: the coin-control change, I think
162 2014-11-26 15:48:30 <hearn> sipa: ah ok, so it's long since dead
163 2014-11-26 15:48:34 <sipa> hearn: #3008
164 2014-11-26 15:48:34 <tdlfbx> What is the logic behind accepting blocks up to 2 hours in the future? Why not reject all blocks in the future?
165 2014-11-26 15:48:37 <hearn> michagogo: i'm talking about the fee rule
166 2014-11-26 15:48:39 <hearn> thanks sipa
167 2014-11-26 15:48:41 <michagogo> As in, if you left it autoselecting, I think it would not use the rule
168 2014-11-26 15:48:42 <sipa> tdlfbx: clocks are not identical
169 2014-11-26 15:48:48 <wumpus> tdlfbx: because the future is not evenly distributed!
170 2014-11-26 15:49:05 <michagogo> PR was https://github.com/bitcoin/bitcoin/pull/3008
171 2014-11-26 15:49:06 <tdlfbx> So I'd reject everything that disagrees with my clock...until it does.
172 2014-11-26 15:49:11 <tdlfbx> Why is that a problem?
173 2014-11-26 15:49:25 <michagogo> tdlfbx: because what if you clock is an hour behind
174 2014-11-26 15:49:36 <tdlfbx> Then you're an idiot and your node will remain out of sync.
175 2014-11-26 15:49:37 <sipa> the 2 hour window is likely overkill (iirc, satoshi wanted to account for incorrect timezone/dst settings), but it doesn't hurt compared to the 2 week retarget period
176 2014-11-26 15:50:27 <tdlfbx> If there were hard timing limits, wouldn't this force node operators to use a reasonable clock source?
177 2014-11-26 15:50:29 <michagogo> hearn: the CENT removal was in v0.9.0
178 2014-11-26 15:50:40 <michagogo> tdlfbx: well, who decides what the right clock is?
179 2014-11-26 15:50:42 <sipa> tdlfbx: if you allow *zero* seconds in the future, and assuming your clock is average in term of time offset, half the network will still reject your blocks
180 2014-11-26 15:50:47 <michagogo> There *is* a hard timing limit
181 2014-11-26 15:50:49 <michagogo> it's 2 hours
182 2014-11-26 15:50:57 <sipa> tdlfbx: so you need some grace window
183 2014-11-26 15:50:59 <wumpus> michagogo: hah
184 2014-11-26 15:51:01 <tdlfbx> No one decides, but this is a problem solved by others and there's an obvious "right" answer.
185 2014-11-26 15:51:11 <michagogo> tdlfbx: like sipa says, maybe it's overkill
186 2014-11-26 15:51:11 <tdlfbx> e.g. NTP, GPS, etc.
187 2014-11-26 15:51:12 <sipa> tdlfbx: so what window would be acceptable?
188 2014-11-26 15:51:14 <michagogo> But it's harmless
189 2014-11-26 15:51:20 <sipa> i believe 1 minute would be fine
190 2014-11-26 15:51:27 <sipa> but 2 hours does not hurt
191 2014-11-26 15:51:35 <michagogo> Meh, a minute is pushing it IMO
192 2014-11-26 15:51:35 <tdlfbx> Why not 1 second?
193 2014-11-26 15:51:59 <tdlfbx> We can measure ping time, we can compare clocks and correct for it. NTP does this and achieves sub-second resolution.
194 2014-11-26 15:52:06 <michagogo> ...aaaand I started typing what I thought the safe minimum should be
195 2014-11-26 15:52:11 <sipa> tdlfbx: and what would we gain?
196 2014-11-26 15:52:16 <wumpus> tdlfbx: why require a clock to be synced to one second, when not necessary? it puts extra requirements on the users for no gain
197 2014-11-26 15:52:18 <sipa> yes, maybe 1 second is fine
198 2014-11-26 15:52:22 <sipa> but why bother?
199 2014-11-26 15:52:25 <wumpus> fine for what?
200 2014-11-26 15:52:28 <wumpus> why?
201 2014-11-26 15:52:34 <michagogo> ...and then stopped when I realized that this is exactly the conversation that doesn't need to happen :P
202 2014-11-26 15:52:50 <michagogo> And, no, I would argue that one second isn't fine
203 2014-11-26 15:52:56 <tdlfbx> I was looking at timewarp attacks. They're enabled by allowing people with stupid clocks to participate.
204 2014-11-26 15:53:09 <michagogo> If you're connected to the ipv4/6 internet through a wired connection, fine
205 2014-11-26 15:53:12 <wumpus> it would be like arguing that people should have at least 16GB of memory and a 16 core computer to run a node, just because it's possible
206 2014-11-26 15:53:18 <sipa> the timewarp attack could be fixed without imposing such strict timing constraints
207 2014-11-26 15:53:20 <michagogo> What happens if you're using tor?
208 2014-11-26 15:53:25 <michagogo> Or a sattelite connection?
209 2014-11-26 15:53:27 <sipa> if it was an actual problem
210 2014-11-26 15:53:29 <michagogo> Satellite*
211 2014-11-26 15:53:36 <michagogo> Or IPoAC?
212 2014-11-26 15:53:37 <tdlfbx> There have been actual timewarp attacks against alts.
213 2014-11-26 15:53:46 <sipa> ok, try it against bitcoin
214 2014-11-26 15:53:49 <michagogo> tdlfbx: so complain to them
215 2014-11-26 15:53:53 <tdlfbx> ;-)
216 2014-11-26 15:54:10 <sipa> i did say that 2 hours is not a problem compared to the normal retarget period of 2 weeks
217 2014-11-26 15:54:21 <michagogo> I would say that what matters is that the window be a very small fraction of the retarget window
218 2014-11-26 15:54:32 <sipa> if your retarget period is much less, you may require much lower tolerance on the tinme window
219 2014-11-26 15:54:32 <tdlfbx> Well throwing an arbitrary number at the problem like 2 hours does not solve it, it just changes the timescale of an attack.
220 2014-11-26 15:54:38 <michagogo> If you reduce the window for some reason, you should require stricter times
221 2014-11-26 15:54:49 <sipa> tdlfbx: agree
222 2014-11-26 15:55:05 <sipa> but changing rules is much harder than leaving them, especially in a consensus system
223 2014-11-26 15:55:27 <michagogo> If it were being designed now, there would doubtless be a huge amount of bikeshedding over this
224 2014-11-26 15:55:40 <michagogo> As well as many other parts of the system, for that matter
225 2014-11-26 15:55:41 <tdlfbx> ACTION is going to have to look up "bikeshedding"
226 2014-11-26 15:55:51 <michagogo> Fortunately, we're using the original, Bitcoin
227 2014-11-26 15:56:09 <sipa> tdlfbx: pointless discussion going in circles, where everyone has very strong opinions, but nobody works towards a solution
228 2014-11-26 15:56:10 <michagogo> With the parameters defined by "What Satoshi was first thinking"
229 2014-11-26 15:56:26 <michagogo> sipa: hm, interesting
230 2014-11-26 15:57:13 <sipa> tdlfbx: it derives from a story about 3 teams... one had to design a rocket, one had to design the cabin inside or something, and a third had to decide on the color of the bikeshed outside the workplace; each of the 3 teams took the same amount of time to reach a decision
231 2014-11-26 15:57:25 <michagogo> Not the definition I think of... More like "what color to paint the bike shed at a nuclear facility", lots of discussion over a very minor issue that doesn't necessarily have one correct answer
232 2014-11-26 15:57:36 <sipa> yeah, maybe
233 2014-11-26 15:57:50 <wumpus> michagogo: sometimes it's good that someone just comes up with some numbers and it's accepted by default that works, instead of arguing about every little thing and never making progress
234 2014-11-26 15:57:56 <michagogo> Right.
235 2014-11-26 15:58:09 <michagogo> 17:55:53 <michagogo> Fortunately, we're using the original, Bitcoin 17:56:12 <michagogo> With the parameters defined by "What Satoshi was first thinking"
236 2014-11-26 15:58:15 <tdlfbx> Well I think it's rather interesting. Because an accurate timestamping mechanism can be used as a consensus mechanism. So dumping timestamping altogether seems odd in bitcoin, which has a consensus mechanism.
237 2014-11-26 15:58:31 <michagogo> uh, what?
238 2014-11-26 15:58:36 <tdlfbx> One consensus mechanism can be used to create another.
239 2014-11-26 15:58:42 <sipa> tdlfbx: the accuracy of bitcoin as a timestamping mechanism is in the same order of magnitude anyway
240 2014-11-26 15:58:47 <sipa> if you need a few blocks of confirmation
241 2014-11-26 15:59:12 <sipa> and it's not 'dumping' it; just it's reducing its accuracy
242 2014-11-26 15:59:40 <tdlfbx> Well it's attempting to make timestamps irrelevant. You might as well not include timestamps at all in block headers.
243 2014-11-26 15:59:46 <michagogo> Uh, no...
244 2014-11-26 15:59:48 <michagogo> Not at all
245 2014-11-26 16:00:05 <sipa> tdlfbx: we need the timestamps for retargetting
246 2014-11-26 16:00:28 <wumpus> for most purposes (say, if you want to prove that a document existed) a timestamp within two hours is easily accurate enough
247 2014-11-26 16:00:35 <tdlfbx> sipa: true.
248 2014-11-26 16:00:43 <sipa> that's the only reason they are there
249 2014-11-26 16:01:22 <tdlfbx> Hmmm....hmmm...
250 2014-11-26 16:01:28 <wumpus> anyhow there is no point in arguing this
251 2014-11-26 16:03:17 <tdlfbx> There's a lot of point. I learned something wumpus. :-P
252 2014-11-26 16:03:42 <sipa> cool!
253 2014-11-26 16:04:43 <wumpus> tdlfbx: hah, ok yes then there is a point
254 2014-11-26 16:05:05 <tdlfbx> I know there are lot of bikeshed questions here. And now I know what bikeshedding is. :-P
255 2014-11-26 16:05:22 <tdlfbx> But I'm frustrated with the large number of arbitrary numbers in the bitcoin code, and wonder if they can be optimized...
256 2014-11-26 16:06:07 <sipa> well a lot of them are part of consensus rules, and many others do affect the ability to converge in some indirect way
257 2014-11-26 16:06:43 <wumpus> in many cases consensus hinges on those being the same for the entire network, there is not much chance to change them
258 2014-11-26 16:07:10 <tdlfbx> Of course.
259 2014-11-26 16:07:53 <wumpus> that doesn't apply to all numbers though, for example the smartfee changes in 0.10 are an example of a number that used to be an arbitrary constant that is now dynamic
260 2014-11-26 16:08:40 <tdlfbx> Ooooh! Are fees going to become dyanmic?!?!
261 2014-11-26 16:08:46 <michagogo> well
262 2014-11-26 16:08:56 <michagogo> Fees have never been a consensus thing
263 2014-11-26 16:08:58 <sipa> fees have always been dynamic
264 2014-11-26 16:09:01 <michagogo> So it's always been possible
265 2014-11-26 16:09:13 <sipa> you could always choose what fee to use yourself
266 2014-11-26 16:09:17 <michagogo> And in some ways they always have been dynamic
267 2014-11-26 16:09:31 <michagogo> But now smarter fee estimation is entering Bitcoin Core
268 2014-11-26 16:09:35 <sipa> but the client now tries to measure what fees are typical on the network
269 2014-11-26 16:09:55 <tdlfbx> Great!!! https://bitcoinfoundation.org/2014/07/floating-fees-for-0-10/
270 2014-11-26 16:10:03 <tdlfbx> i hadn't seen this before, but it's a good idea.
271 2014-11-26 16:12:41 <wumpus> michagogo: of course it's always been possible, sigh, I just mean that it is happening that arbitrary numbers are being replaced by smarter code
272 2014-11-26 16:12:54 <wumpus> and I've already said that that's not possible for the consensus code
273 2014-11-26 16:13:10 <michagogo> wumpus: I was talking to tdlfbx
274 2014-11-26 16:14:02 <tdlfbx> If nodes rejected blocks in the future, wouldn't that mean they'd just follow the main chain with some delay given by their local clock offset? They'd be unable to mine, but would it actually destroy consensus?
275 2014-11-26 16:15:25 <michagogo> tdlfbx: well, you'd end up on a delay, yes
276 2014-11-26 16:15:37 <tdlfbx> A node with a clock in the future would be able to mine, but no one would accept his mined blocks.
277 2014-11-26 16:15:38 <michagogo> And you may end up on the wrong chain, if you see one mined with a past timestamp
278 2014-11-26 16:16:42 <tdlfbx> michagogo: Yes you may end up on the wrong chain, but the rest of the network would have been partially on that wrong chain before, and discarded it. So eventually you'd see that update too.
279 2014-11-26 16:17:23 <michagogo> Well, no, you could see a block that forked off 11 blocks ago
280 2014-11-26 16:17:30 <michagogo> But yeah, eventually you'd probably be fine
281 2014-11-26 16:17:40 <tdlfbx> Oh the 11 block thing...what was that...
282 2014-11-26 16:17:58 <michagogo> well, in this case it's just 2 hours divided into block times
283 2014-11-26 16:18:14 <michagogo> But that's in the other direction
284 2014-11-26 16:18:29 <michagogo> A block must be timestamped greater than the median timestamp of the past 11 blocks
285 2014-11-26 16:18:38 <tdlfbx> Ah yes, thanks.
286 2014-11-26 16:18:47 <michagogo> That rule forces the overall blockchain timestamps to move forward
287 2014-11-26 16:21:25 <tdlfbx> This rule also allows timestamps to be non-monotonic, and thus an attack should exist where I roll my clock <2 hours forward.
288 2014-11-26 16:21:38 <michagogo> How so?
289 2014-11-26 16:22:10 <tdlfbx> The timestamps of sequential blocks don't have to monotonically increase, using the 11-block-median rule.
290 2014-11-26 16:22:19 <michagogo> Right, that's the purpose of that rule
291 2014-11-26 16:22:41 <tdlfbx> Wait, you *want* later blocks to have timestamps before previous blocks sometimes?
292 2014-11-26 16:22:52 <michagogo> Yes
293 2014-11-26 16:22:55 <tdlfbx> Why?
294 2014-11-26 16:23:00 <sipa> because it's inevitable
295 2014-11-26 16:23:14 <sipa> (but not as much as 2 hours)
296 2014-11-26 16:23:15 <michagogo> Because without enforcing clock identicality, that is going to happen
297 2014-11-26 16:23:48 <sipa> otherwise if someone mines a block exactly at the limit, you're stuck
298 2014-11-26 16:24:00 <michagogo> Well,
299 2014-11-26 16:24:06 <michagogo> what's the resolution? Seconds?
300 2014-11-26 16:24:06 <tdlfbx> sipa: can you elaborate? Which limit?
301 2014-11-26 16:24:14 <michagogo> tdlfbx: now+2hours
302 2014-11-26 16:24:46 <sipa> tdlfbx: if the limit is 2 hours in the future, but require timestamps to be monotonic, you have 0 wiggle room left if someone mines a block with a timestamp 2 hours in the future
303 2014-11-26 16:25:03 <sipa> if you make the limit *now*, it becomes even worse
304 2014-11-26 16:25:15 <michagogo> I mean, you're only stuck for a second
305 2014-11-26 16:25:17 <michagogo> But still
306 2014-11-26 16:25:49 <sipa> again, this window could be significantly reduced, and perhaps be made small enough that it doesn't matter anymore
307 2014-11-26 16:25:59 <sipa> but the current infrastructure out there relies on it being there
308 2014-11-26 16:26:08 <tdlfbx> Why would I ever want to include a block mined in the future?
309 2014-11-26 16:26:16 <sipa> timestamps are used as nonce
310 2014-11-26 16:26:28 <michagogo> tdlfbx: your clock could be a bit behind
311 2014-11-26 16:26:35 <michagogo> Or a miner could be a bit ahead
312 2014-11-26 16:27:25 <tdlfbx> This is what I mean by one consensus mechanism used to create another. If my clock disagrees with the majority of the network, I won't be able to mine. Removing or shortening the 2-hour window incentivizes accurate clocks.
313 2014-11-26 16:27:47 <sipa> i don't see what you accomplish by doing that
314 2014-11-26 16:27:55 <sipa> it incentives accurate clocks... for what?
315 2014-11-26 16:28:04 <sipa> if i want an accurate clock, i'll use ntp
316 2014-11-26 16:28:07 <tdlfbx> To prevent time-based attacks.
317 2014-11-26 16:28:22 <sipa> time-based attacks can be completely fixed without constraining time
318 2014-11-26 16:28:43 <sipa> the timewarp attack is just due to using non-overlapping retarget periods
319 2014-11-26 16:29:06 <tdlfbx> Maybe I'm using the wrong terminology
320 2014-11-26 16:29:46 <tdlfbx> So let's say I mine a block with a timestamp 2 hours in the future, and I want to use it for a double-spend.
321 2014-11-26 16:30:09 <sipa> ok?
322 2014-11-26 16:30:09 <tdlfbx> After 6 confirmations, I have a 1-hour window to mine a second block that reverts my transaction in the first one I mined.
323 2014-11-26 16:30:20 <sipa> ?
324 2014-11-26 16:30:28 <sipa> what does the timestamp have to do with that?
325 2014-11-26 16:30:43 <wumpus> transactions are interpreted in block order, not in time order
326 2014-11-26 16:30:47 <tdlfbx> I was able to mine the first one 2 hours in the future because the network will accept it. If we required accurate clocks I couldn't do that.
327 2014-11-26 16:31:02 <sipa> it doesn't change your ability to pull of that attack one bit
328 2014-11-26 16:31:10 <sipa> you need hashpower to do so, and nothing else
329 2014-11-26 16:31:20 <tdlfbx> Yes, I see.
330 2014-11-26 16:31:25 <michagogo> 18:30:11 <tdlfbx> After 6 confirmations, I have a 1-hour window to mine a second block that reverts my transaction in the first one I mined. <-- yeah, no.
331 2014-11-26 16:31:35 <sipa> the only reason the timestamps are there is to compute the new difficulty
332 2014-11-26 16:31:54 <sipa> yes there is one known attack which allows miners to game the difficulty, but it can be fixed without changing the timing constraints
333 2014-11-26 16:32:09 <michagogo> Which attack?
334 2014-11-26 16:32:12 <sipa> for actual consensus or acceptance of transactions, it is irrelevant
335 2014-11-26 16:32:17 <sipa> timewrap
336 2014-11-26 16:32:19 <sipa> *warp
337 2014-11-26 16:32:23 <tdlfbx> So, essentially, as long as this 2-hour window is much less than the 2-week retarget window, we don't care. It could be 1s too.
338 2014-11-26 16:32:27 <michagogo> Oh, not in Bitcoin
339 2014-11-26 16:32:34 <michagogo> tdlfbx: pretty much
340 2014-11-26 16:32:40 <michagogo> Except that 1s would probably be too short
341 2014-11-26 16:32:55 <tdlfbx> The only reason it's not 1s is some argument that node operators are idiots and can't set their clock correctly?
342 2014-11-26 16:33:00 <michagogo> Well, no
343 2014-11-26 16:33:06 <michagogo> Consider higher latency
344 2014-11-26 16:33:13 <michagogo> As I was saying earlier
345 2014-11-26 16:33:20 <tdlfbx> That could be adjusted, as NTP does.
346 2014-11-26 16:33:29 <wumpus> as said - 'node operators' includes a lot of people, artificially reducing the number of full nodes by making it harder to run them succesfully sounds like a bad strategy
347 2014-11-26 16:33:38 <michagogo> +1
348 2014-11-26 16:33:42 <wumpus> you're going in circles
349 2014-11-26 16:34:18 <sipa> michagogo: higher latency is actually not a problem
350 2014-11-26 16:34:25 <tdlfbx> That's an odd argument. Time is pretty important for finances.
351 2014-11-26 16:34:38 <sipa> tdlfbx: so use a accurate time if you need it
352 2014-11-26 16:34:45 <sipa> tdlfbx: bitcoin already cannot provide accurate timestamping
353 2014-11-26 16:35:00 <sipa> so relying on bitcoin's timestamps for anything that needs more accuracy than ~hours is already impossible
354 2014-11-26 16:35:18 <sipa> increasing the requirements of the system without improving the result doesn't make sense
355 2014-11-26 16:35:19 <michagogo> And the thing is, requiring a completely accurate clock means everyone needs to precisely agree on the time
356 2014-11-26 16:35:24 <michagogo> And who defines the current time?
357 2014-11-26 16:35:48 <wumpus> at the limit you could not get more precision than the time between blocks
358 2014-11-26 16:36:05 <wumpus> so more precision than say 10 minutes doesn't make sense
359 2014-11-26 16:36:16 <tdlfbx> You guys keep arguing as though atomic clocks, GPS, NTP don't exist. Accurate timekeeping is an old, solved problem.
360 2014-11-26 16:36:47 <wumpus> no, we're arguing as though it doesn't matter for bitcoin
361 2014-11-26 16:36:51 <michagogo> tdlfbx: But then the operator of your NTP server gets the ability to kick you off the network by tweaking your time by a second
362 2014-11-26 16:37:04 <tdlfbx> The only reason a clock would be off is if an attack is being executed, or error on the operator's part.
363 2014-11-26 16:37:14 <tdlfbx> Why should I want to keep either around?
364 2014-11-26 16:37:23 <wumpus> michagogo: yup, time warp by GPS spoofing ;)
365 2014-11-26 16:37:33 <sipa> tdlfbx: accurate timekeeping is an old, solved problem in a *centralized* setting
366 2014-11-26 16:37:43 <sipa> tdlfbx: in a decentralized system, there exists no 'true time'
367 2014-11-26 16:37:52 <tdlfbx> Sure, but I can pick which centralization I use. ;-)
368 2014-11-26 16:37:59 <sipa> yes, so use one if you need it
369 2014-11-26 16:38:01 <michagogo> Right
370 2014-11-26 16:38:05 <sipa> bitcoin doesn't need one (or not an accurate one)
371 2014-11-26 16:38:18 <sipa> forcing you to pick an accurate one results in 0 gain for bitcoin itself
372 2014-11-26 16:38:20 <michagogo> But what you're suggesting would mean there would have to be one centralization that everyone uses
373 2014-11-26 16:38:22 <sipa> and now i'm done with this discussion
374 2014-11-26 16:39:10 <helo> tdlfbx: #bitcoin for more
375 2014-11-26 16:39:33 <tdlfbx> Thanks folks.
376 2014-11-26 18:55:52 <dgenr8> https://github.com/bitcoin/bitcoin/issues/4521
377 2014-11-26 18:57:51 <dgenr8> node's local clock is a valuable resource, and less fussing around with it would be nice
378 2014-11-26 19:41:53 <gmaxwell> tdlfbx: "wouldn't this force node operators to use a reasonable clock source" there _are_ not reasonable clock sources in wide use in the context of bitcoin. Every one of the automated clocks sources is centerally controlled, completely unauthenticated, and has been wrong by chance in recent memory with remarkable frequency.
379 2014-11-26 19:42:31 <helo> just use the sun and stars, duh
380 2014-11-26 19:42:39 <helo> ACTION runs
381 2014-11-26 19:43:08 <gmaxwell> yes, sure you can set the time with enough accuracy for bitcoin using an almanic, knowledge of your location, and observation of the sun. :P
382 2014-11-26 19:43:17 <gmaxwell> but thats a bit user unfriendly. :P
383 2014-11-26 19:46:52 <gmaxwell> But forcing people to go around and use ntp on their hosts would only degrade the security of the bitcoin network, since public use of autheticated NTP is non-existant (there is only one publically advertised authenticed ntp server set, the one run by NIST, and to use it you have to send them snail mail to recieve a key). NTP is remarkably unskeptical about claims from peers and can be happily skewed totally off the mark by bogus ...
384 2014-11-26 19:46:58 <gmaxwell> ... traffic. I'd love to have some time to work on a time protocol that is robust against an adversarial network; but its a low priority, and bitcoin's time requirements are intentionally very humble.
385 2014-11-26 19:48:52 <tdlfbx> Define "bitcoin time" to be the average reported time from communicating nodes, and use it to reject blocks with bad timestamps.
386 2014-11-26 19:49:40 <gmaxwell> tdlfbx: uhhh. In bitcoin we assume that your peers (perhaps all but one or two, or even all for a short period of time) are malicious.
387 2014-11-26 19:50:59 <gmaxwell> tdlfbx: a system that didn't would be immediately vulnerable to sybil attacks. E.g. I spin up a million 'nodes' using a botnet, and as you connect to my nodes they claim the maximum far in the future (or past) time that you'll accept, and continue to do so to push your time way out.
388 2014-11-26 19:51:39 <tdlfbx> true.
389 2014-11-26 19:52:46 <tdlfbx> OTOH, does that matter? As long as it's monotonic...
390 2014-11-26 19:53:34 <gmaxwell> yes it matters (uh and wtf. monotonic time is irrelevant in bitcoin, and you can make any stream of time claims monotoinc by simply running a max() operation over it)
391 2014-11-26 19:53:37 <kadoban> tdlfbx: What would be the point, even if it could be done in a way that makes sense, which sounds dubious to say the least...
392 2014-11-26 19:55:07 <gmaxwell> total freedom over the control of tiem can screw up the inflation schedule of bitcoin, they also can drive the interblock gaps down to the point where centeralized attacks enjoy a reorginization advantage. Or, alternatively, can freeze the system into useless ness...
393 2014-11-26 19:57:54 <tdlfbx> gmaxwell: I was thinking that time only be reported with PoW (e.g. in blocks) so Sybil attacks are 51% attacks.
394 2014-11-26 20:00:22 <gmaxwell> that isn't what you were saying. :) But okay, what you should understand with bitcoin is that majority hashpower attacks are less of a threat because the majority hashpower is so throughly confined in what it can do. Letting miners control your clock is isomorphic to not having a timestamp in block headers at all and just letting the miners decide on the blockrate. This may well unhinge their incentives; since they would share a common ...
395 2014-11-26 20:00:28 <gmaxwell> ... interest in inflating the coin (coins go to them), or in centeralizing and then cracking the blockrate down so they'd enjoy an unfair share of the blocks.
396 2014-11-26 20:16:32 <dgenr8> i suspect any kind of internal time protocol, even the one we have, will turn out to be less accurate and less robust than nodes just taking responsibility for their clocks.
397 2014-11-26 20:16:35 <dgenr8> it seems pretty hard to argue that a node using ntp is bad. ntp is just a protocol and nodes would inevitably use a diversity of servers, or if they prefer, some other way of telling time
398 2014-11-26 20:17:15 <gmaxwell> it's very easy to argue that ntp is bad.
399 2014-11-26 20:17:39 <gmaxwell> a local network attacker (something we're otherwise very strong against) can partition the network if the node accepts its time from ntp.
400 2014-11-26 20:18:12 <gmaxwell> because ntp (as its deployed on the internet) is completely unauthenticated, and a local network attacker can make it report whatever they want.. you think you're talking to "a diversity of servers" but you're not.
401 2014-11-26 20:18:41 <dgenr8> the diversity comes from 4000 nodes not being on the same local network
402 2014-11-26 20:19:06 <paveljanik> anyone ever used -printblockindex?
403 2014-11-26 20:19:21 <sipa> as a node operator i don't really care about other nodes; i care about me not being attackable :)
404 2014-11-26 20:19:29 <gmaxwell> dgenr8: small comfort to someone who lost thousands of other people's bitcoin that not _every_ bitcoin user was exploited.
405 2014-11-26 20:20:03 <gmaxwell> Also even not a local network attacker, common ntp configuration just uses DNS to resolve three distinct servers. An attacker that controls two of the three (e.g. via dns poisoning or from a sybil attack) can, again, freely set your time.
406 2014-11-26 20:21:09 <gmaxwell> (well, freely is suject to some slew limitatoins; but they're very permissive)
407 2014-11-26 20:23:09 <dgenr8> sipa: you are attackable today via the busted adjusted time protocol which can skew your clock no matter how carefully you set it
408 2014-11-26 20:24:20 <dgenr8> gmaxwell: the consequences being bad does not support one argument or another
409 2014-11-26 20:25:14 <dgenr8> i'm just here to be a pain ... people are too chicken of you guys ;)
410 2014-11-26 20:25:22 <tdlfbx> What if the 2-hour window was halved on a regular schedule, until it reached 1s? Clock sources would diversify, secure authenticated ntp would be incentivized...
411 2014-11-26 20:26:07 <tdlfbx> sipa doesn't like me.
412 2014-11-26 20:26:58 <kadoban> tdlfbx: I'm still missing what that would actually accomplish. Have you responded to that? I know it came up more than a few times. What's the benefit?
413 2014-11-26 20:27:05 <gmaxwell> dgenr8: Sure what we have today need some improvement; but it's not outright busted. A node which is up, running, and correct is fine and own't be broken by an attack.