1 2015-04-27 00:02:31 <kanzure> sell it back to me
2 2015-04-27 00:04:07 <Luke-Jr> lol
3 2015-04-27 00:12:18 <phantomcircuit> kanzure, with headers-first you still pick one peer to get the headers from
4 2015-04-27 00:12:28 <phantomcircuit> if you get unlucky with that it takes a while to switch
5 2015-04-27 00:23:12 <sinetekVI> hey guys
6 2015-04-27 00:23:20 <sinetekVI> the bitcoin testcase segfaults here
7 2015-04-27 00:23:27 <sinetekVI> gcc 5.1.1 on DragonFlyBSD
8 2015-04-27 00:23:39 <phantomcircuit> sinetekVI, pastebin + github issue
9 2015-04-27 00:23:40 <sinetekVI> anyone tried gcc 5.??
10 2015-04-27 00:23:56 <sinetekVI> well i'll try to compile with debuggging symbols
11 2015-04-27 00:24:11 <sinetekVI> oddly enough the qt testcase passes fine
12 2015-04-27 00:24:18 <sinetekVI> bitcoin itself also works
13 2015-04-27 00:28:28 <phantomcircuit> sinetekVI, appears to work
14 2015-04-27 00:28:50 <sinetekVI> ok great then its dragonfly problem
15 2015-04-27 00:29:17 <sinetekVI> the error is 'stack smashing detected'
16 2015-04-27 00:34:31 <sinetekVI> how do i build with debug symbols
17 2015-04-27 00:34:52 <phantomcircuit> sinetekVI, can you pastebin the result?
18 2015-04-27 00:35:00 <phantomcircuit> sinetekVI, ./configure --enable-debug
19 2015-04-27 00:35:08 <sinetekVI> i can but its not very interesting
20 2015-04-27 00:35:09 <phantomcircuit> that sounds maybe ungood
21 2015-04-27 00:35:16 <phantomcircuit> sinetekVI, you might be surprised
22 2015-04-27 00:35:49 <sinetekVI> https://github.com/bitcoin/bitcoin/issues/6070
23 2015-04-27 00:37:56 <phantomcircuit> sinetekVI, illegal instruction?
24 2015-04-27 00:37:58 <phantomcircuit> that's weird
25 2015-04-27 00:39:08 <phantomcircuit> sinetekVI, can you
26 2015-04-27 00:39:10 <phantomcircuit> make check
27 2015-04-27 00:39:15 <phantomcircuit> instead of ./test_bitcoin
28 2015-04-27 00:39:37 <sinetekVI> once it's done building with debugging, sure
29 2015-04-27 00:42:05 <sinetekVI> phantomcircuit: you have gcc 5.1.1 yes?
30 2015-04-27 00:43:10 <phantomcircuit> sinetekVI, no but it wont much matter since draonflybsd is probably super patched
31 2015-04-27 00:44:33 <sinetekVI> phantomcircuit: well a contact reports lots of breakage with gcc 5.1.1 on Linux as well (gentoo)
32 2015-04-27 00:44:46 <sinetekVI> so it might be a broken release like 4.9 was
33 2015-04-27 00:45:26 <phantomcircuit> hmm
34 2015-04-27 00:45:50 <sinetekVI> but i suppose you're right
35 2015-04-27 00:46:42 <phantomcircuit> let me see
36 2015-04-27 00:46:57 <phantomcircuit> it doesn't look like gentoo has 5.x either but maybe they installed it specially?
37 2015-04-27 00:47:15 <phantomcircuit> or maybe im outdated
38 2015-04-27 00:47:17 <phantomcircuit> lets see
39 2015-04-27 00:47:21 <sinetekVI> gentoo users just use whatever they feel like
40 2015-04-27 00:48:11 <sinetekVI> might not be in stable yet
41 2015-04-27 00:48:34 <phantomcircuit> sinetekVI, i wasn't seeing it in the normal portage tree
42 2015-04-27 00:48:47 <phantomcircuit> lol it's masked like three times
43 2015-04-27 00:53:23 <sinetekVI> lol
44 2015-04-27 00:55:47 <sinetekVI> well it's really broken somehow
45 2015-04-27 00:55:55 <sinetekVI> the backtrace is not showing with debugging enable
46 2015-04-27 00:55:57 <sinetekVI> i dunno.
47 2015-04-27 00:56:33 <phantomcircuit> sinetekVI, ./autogen.sh;./configure --enable-debug;make clean;make check
48 2015-04-27 01:08:56 <kanzure> is there a "reject chaintip" command?
49 2015-04-27 01:10:10 <phantomcircuit> kanzure, invalidateblock
50 2015-04-27 01:19:57 <sinetekVI> phantomcircuit: http://pastebin.com/hyAtpCP4
51 2015-04-27 01:20:24 <kanzure> phantomcircuit: i am still getting stuck on the wrong blockchain
52 2015-04-27 01:21:52 <phantomcircuit> kanzure, ha
53 2015-04-27 01:22:06 <phantomcircuit> kanzure, bitcoind version?
54 2015-04-27 01:23:00 <kanzure> phantomcircuit: v0.10.99.0-3ce454f
55 2015-04-27 01:24:36 <phantomcircuit> kanzure, which commit is head?
56 2015-04-27 01:45:36 <phantomcircuit> sinetekVI, still building gcc:5.1
57 2015-04-27 02:22:25 <phantomcircuit> sinetekVI, i cant even get boost to build with 5.1
58 2015-04-27 02:22:26 <phantomcircuit> fun
59 2015-04-27 02:22:30 <phantomcircuit> so
60 2015-04-27 02:22:33 <phantomcircuit> yeah it's probably broken
61 2015-04-27 02:22:41 <sinetekVI> lol
62 2015-04-27 02:22:42 <sinetekVI> ok
63 2015-04-27 02:46:18 <phantomcircuit> sinetekVI, lets see just how broken my system is after rebuilding everything with gcc:5.1
64 2015-04-27 02:46:45 <sinetekVI> phantomcircuit: probably very
65 2015-04-27 02:47:13 <sinetekVI> its weird though cause this build was compiled with it
66 2015-04-27 02:47:36 <sinetekVI> everything else seems fine
67 2015-04-27 02:52:00 <phantomcircuit> sinetekVI, well lets see what happens when i rebuild my entire system
68 2015-04-27 02:52:06 <phantomcircuit> this will take a while...
69 2015-04-27 02:52:24 <sinetekVI> do backups?
70 2015-04-27 02:54:18 <phantomcircuit> sinetekVI, dev system
71 2015-04-27 02:54:36 <sinetekVI> gotcha
72 2015-04-27 02:54:39 <phantomcircuit> gentoo so im actually rebuilding everything
73 2015-04-27 02:55:42 <sinetekVI> i'll try clang now
74 2015-04-27 02:57:08 <sinetekVI> by the way are all the core devs on linux?
75 2015-04-27 02:57:12 <sinetekVI> i find that a bit curious
76 2015-04-27 03:05:50 <phantomcircuit> sinetekVI, probably
77 2015-04-27 03:15:43 <Luke-Jr> sinetekVI: lack of any sane alternatives? O.o
78 2015-04-27 03:16:02 <sinetekVI> hm?
79 2015-04-27 03:16:47 <phantomcircuit> sinetekVI, he's answering the linux question
80 2015-04-27 03:18:58 <sinetekVI> i'm finding recent linux developments quite insane personally, but in comparison to windows/os x I would agree
81 2015-04-27 03:19:51 <sinetekVI> not that i care, just curious
82 2015-04-27 03:21:34 <sinetekVI> bah not just an opinion, i notice regressions everywhere i look lately
83 2015-04-27 03:24:09 <Luke-Jr> my gitian sigs pushed
84 2015-04-27 03:26:01 <jonasschnelli> Luke-Jr: did you once got response to your email to the icon designer?
85 2015-04-27 03:26:49 <Luke-Jr> jonasschnelli: nope
86 2015-04-27 03:40:16 <sinetekVI> hm, can't link boost with clang
87 2015-04-27 03:40:24 <sinetekVI> have to recompile boost \i suppose
88 2015-04-27 04:59:37 <sinetekVI> well, boost has been compiling for the last hour
89 2015-04-27 05:21:48 <wumpus> sinetekVI: regressions tend to happen at the tip where there's lots of active development. I stick to ubuntu LTS versions these days, haven't had any serious brokenness in a long time
90 2015-04-27 05:28:42 <wumpus> I have used bsds for embedded systems in the past, but I wouldn't use it as main development system. just too much extra porting work to get new software to work (as you're noticing). And I like the GNU command-line tools much better than the more limited ones that tend to come with other unices
91 2015-04-27 05:37:22 <sinetekVI> i find it easier, 4 variants as opposed to 30.
92 2015-04-27 05:37:24 <sinetekVI> but okay
93 2015-04-27 05:40:27 <sinetekVI> i'm not here to start a flame though, just asking since linux is like 1% of all machines
94 2015-04-27 06:03:15 <Krellan> Serialization question (shudder)
95 2015-04-27 06:03:58 <Krellan> Is nType and nVersion ever used for anything? They seem passed around a lot, but finally ignored when it finally boils down to Serialize() and Unserialize() being called.
96 2015-04-27 06:04:26 <Krellan> WRITEDATA() and READDATA() don't use them at all. Are they just unused overhead, or do they have a meaning elsewhere I'm not aware of?
97 2015-04-27 06:09:59 <wumpus> they are used here and there
98 2015-04-27 06:10:35 <wumpus> in general if you want to version a data structure, you need to make decisions during deserialization based on the nVersion
99 2015-04-27 06:27:00 <Krellan> wumpus: Thanks - I get the overall concept
100 2015-04-27 06:27:47 <Krellan> nVersion is used in a somewhat confusing way, though: nVersion (SerializationOp function parameter) vs. nVersion (member variable of many classes)
101 2015-04-27 06:27:48 <wumpus> harding: do we have a magnet link for 0.10.1?
102 2015-04-27 06:33:56 <harding> wumpus: it'll be up on the download page momentarily. See https://github.com/bitcoin/bitcoin.org/commit/28d7ef0f1dda4c36ba7cc235e509e095c934bafe
103 2015-04-27 06:34:05 <wumpus> okay thanks
104 2015-04-27 06:34:08 <harding> ... it's up now.
105 2015-04-27 06:34:21 <wumpus> I didn't remember where I got it from last time :)
106 2015-04-27 06:36:03 <harding> wumpus: each time I do the bitcoin.org side of a release, I keep thinking I should have better documentation/automation :-)
107 2015-04-27 06:57:16 <wumpus> or maybe make sure there's less time between releases, so we don't unlearn everything in between
108 2015-04-27 06:59:25 <harding> Monthly releases would be cool.
109 2015-04-27 07:01:06 <wumpus> reminds me that I have to announce the merge window close for 0.11 soon
110 2015-04-27 07:57:12 <jonasschnelli> wumpus: i think It would be nice to get autoprune wallet support (#6057) and fundrawtransaction (#5503) in 0.11
111 2015-04-27 07:57:39 <wumpus> yeah
112 2015-04-27 08:05:26 <wumpus> fundrawtransaction certainly, autoprune wallet sounds risky
113 2015-04-27 08:05:43 <sipa> what's risky about it?
114 2015-04-27 08:06:33 <wumpus> changes to wallet are risky in the first place, and even autoprune itself may still have some unknown bug
115 2015-04-27 08:06:51 <sipa> well sure, but 0.11 isn't released yet either
116 2015-04-27 08:07:15 <wumpus> but we don't want to drag it out too long
117 2015-04-27 08:07:58 <sipa> the wallet accesses old blocks only when rescanning, which does not happen during normal operation (only if you swap wallet.dat files, or specify -rescan manually)
118 2015-04-27 08:08:00 <wumpus> I really want to aim for tagging first RC in june and final in july
119 2015-04-27 08:08:15 <sipa> ok, whatever isn't ready, isn't ready
120 2015-04-27 08:08:21 <wumpus> and last time we decided to not wait for features
121 2015-04-27 08:08:26 <wumpus> right
122 2015-04-27 08:08:28 <sipa> sure
123 2015-04-27 08:08:29 <jonasschnelli> I think autoprune (with wallet support) would allow people to run a bitcoind wallet connected to a non pruned full-node.
124 2015-04-27 08:08:54 <sipa> jonasschnelli: why is that non pruned node relevant?
125 2015-04-27 08:08:55 <wumpus> sipa: sure, or if you import keys
126 2015-04-27 08:09:02 <sipa> wumpus: right, indeed
127 2015-04-27 08:09:21 <jonasschnelli> Kind of a third possibility next to full node and SPV
128 2015-04-27 08:09:35 <sipa> jonasschnelli: i don't understand how that is different from just a pruned full node
129 2015-04-27 08:09:52 <sipa> jonasschnelli: by definition it already connects to non pruned nodes in the network, which it does not need to trust
130 2015-04-27 08:10:00 <sipa> so why does having your own non-pruned node matter?
131 2015-04-27 08:10:32 <wumpus> saving bandwidth, maybe
132 2015-04-27 08:10:46 <sipa> sure, but that's an optimization - not a fundamentally different model
133 2015-04-27 08:10:52 <sipa> anyway, semantics
134 2015-04-27 08:10:55 <wumpus> right
135 2015-04-27 08:10:57 <jonasschnelli> I have a such case in my LAN
136 2015-04-27 08:11:40 <jonasschnelli> I don't want to download the blocks twice. But right... not much of a difference
137 2015-04-27 08:11:50 <sipa> jonasschnelli: you mean wallet support = wallet fetching missing blocks on rescan?
138 2015-04-27 08:12:17 <jonasschnelli> Right. And some disabled import features.
139 2015-04-27 08:12:33 <sipa> if it can fetching missing blocks, why disable import?
140 2015-04-27 08:12:45 <sipa> either the wallet cannot fetch missing blocks, and you can't rescan or import
141 2015-04-27 08:12:51 <sipa> or the wallet can, and it doesn't matter :)
142 2015-04-27 08:13:09 <jonasschnelli> sorry. Got you wrong. No missing blocks download at rescan.
143 2015-04-27 08:13:18 <jonasschnelli> (Sry. Phone typing)
144 2015-04-27 08:13:29 <sipa> then why does the non-pruned node matter?
145 2015-04-27 08:14:17 <wumpus> maybe if you have multiple pruned nodes on your network, and one non-pruned node to jumpstart them from
146 2015-04-27 08:14:32 <sipa> copy the chainstate :)
147 2015-04-27 08:14:37 <jonasschnelli> Internet<->LAN<->Fullnode<->pruned node with wallet.
148 2015-04-27 08:14:56 <wumpus> sure, that's an option too...
149 2015-04-27 08:15:01 <sipa> jonasschnelli: right, but if the pruned node cannot go fetch missing blocks anyway, why does that full node matter at all?
150 2015-04-27 08:15:26 <jonasschnelli> Bandwidth (afk 5min)
151 2015-04-27 08:15:37 <sipa> jonasschnelli: i don't understand
152 2015-04-27 08:15:42 <sipa> oh
153 2015-04-27 08:15:43 <wumpus> but at least for development it makes sense to re-do a sync sometimes
154 2015-04-27 08:15:54 <sipa> because a pruned node does not relay new blocks
155 2015-04-27 08:16:11 <sipa> if pruned nodes would do that, it wouldn't matter whether your intermediate node is pruned or not, right?
156 2015-04-27 08:16:31 <sipa> as the only difference would be that it can't serve historic blocks, but that's not something the wallet nodes need
157 2015-04-27 08:17:08 <wumpus> unless you create new ones all the time, e.g. for testing
158 2015-04-27 08:17:18 <sipa> right, sure - but that's just an optimization
159 2015-04-27 08:17:29 <wumpus> but 'just an optimization' can be a valid use case!
160 2015-04-27 08:17:33 <sipa> absolutely
161 2015-04-27 08:17:38 <sipa> not saying it's a bad architecture
162 2015-04-27 08:17:49 <sipa> but it's not some "extra model" that we need to support
163 2015-04-27 08:18:01 <wumpus> 'we' don't need to do anything, it just works
164 2015-04-27 08:18:19 <sipa> anyway, as long as pruned nodes cannot relay, the point is valid for sure
165 2015-04-27 08:21:40 <jonasschnelli> Maybe I'm blinded. But if I run two nodes in my local network, a non-pruned and a pruned. I have to spend two times the bandwidth? If I connect the pruned node to only my none pruned node in my local network I would save traffic?
166 2015-04-27 08:21:57 <sipa> jonasschnelli: yes
167 2015-04-27 08:22:17 <sipa> jonasschnelli: i'm saying that from an architecture point of view, whether that full node is your own, or some random one on the internet doesn't matter
168 2015-04-27 08:22:30 <wumpus> sipa was trying to argue something else as us :)
169 2015-04-27 08:23:01 <wumpus> indeed, from an architecture point of view it doesn't matter, just from an organization point
170 2015-04-27 08:23:20 <sipa> jonasschnelli: and also, that if pruned nodes were able to relay, both your nodes could be pruned, and you'd only spend the bandwidth once (at least to keep up; initial sync is a different problem)
171 2015-04-27 08:23:22 <wumpus> ("where do you point the connections")
172 2015-04-27 08:31:39 <jonasschnelli> For my personal case I really find it useful to have a non-pruned fullnode running on Server where you can do all the -txindex, etc. stuff (personal blockexplorer) and a laptop based pruned node for wallet services.
173 2015-04-27 08:34:15 <sipa> ok
174 2015-04-27 08:36:38 <jonasschnelli> I mean what option do you got if you like to run a wallet on a laptop and dont want to "waste" >25GB of blockchain data? SPV?
175 2015-04-27 08:36:52 <sipa> yes
176 2015-04-27 08:36:53 <sipa> :)
177 2015-04-27 08:37:27 <jonasschnelli> Thats why i think autoprune can be a state between fullnode and SPV
178 2015-04-27 08:37:46 <sipa> yes, yes, i understand your point now
179 2015-04-27 08:37:59 <sipa> it was just a semantics difference :)
180 2015-04-27 08:38:26 <jonasschnelli> Right. î
181 2015-04-27 08:39:52 <jonasschnelli> I think the complicate part is to make the pruned node relay blocks...
182 2015-04-27 08:51:26 <Luke-Jr> jonasschnelli: eh, pretty sure pruned nodes can't use txindex?
183 2015-04-27 08:51:39 <wumpus> they indeed can't
184 2015-04-27 08:52:12 <sipa> Luke-Jr: that's why he has a non-pruned node :)
185 2015-04-27 08:59:15 <jtimon> so no thoughts on http://sourceforge.net/p/bitcoin/mailman/message/34042751/ ?
186 2015-04-27 09:00:08 <jtimon> that would be a softfork and will the current uses of CTxIn::nSequence (but make things easier and cleaner for op_maturity)
187 2015-04-27 09:21:21 <s1w> wow the sourceforge mailing list is still active? heh
188 2015-04-27 09:23:40 <Luke-Jr> s1w: ⦠it's the primary development mailing list O.o
189 2015-04-27 09:25:15 <nkuttler> wasn't sourceforge closing down or something?
190 2015-04-27 09:26:52 <s1w> Luke-Jr: haha yeah I just thought everyone would have moved somewhere else now
191 2015-04-27 09:26:55 <s1w> nkuttler: i thought so too
192 2015-04-27 10:10:10 <jgarzik> morning
193 2015-04-27 10:10:41 <jgarzik> Regarding https://github.com/bitcoin/bitcoin/pull/3753 mempool janitor: periodic sweep and clean of not-confirming transactions #3753
194 2015-04-27 10:10:57 <jgarzik> the main sticking point is marking transactions as "precious" in the mempool
195 2015-04-27 10:11:12 <jgarzik> and not zapping those
196 2015-04-27 10:11:40 <jgarzik> I wonder how that best fits into a context where the wallet is a separate process
197 2015-04-27 10:24:36 <sipa> jgarzik: i much more prefer resource limitation... whenever the mempool grows too large, dekete something from it
198 2015-04-27 10:25:39 <sipa> interaction with wallet... if we only had a mechanism to test whether a transaction would not conflict with the mempool, and not violate rules, we could use that as "conflict" state marker
199 2015-04-27 10:25:59 <sipa> which would break the strict dependency the wallet now has on the mempool
200 2015-04-27 10:28:51 <sipa> jgarzik: could be as easy as: pick random tx, if it has children, randomly pick one of those, recurse
201 2015-04-27 10:29:02 <sipa> the one you end with is removed
202 2015-04-27 10:49:09 <jgarzik> sipa, it's not about testing for conflicts. the discussion in #3753, which applies to any TX removal strategy, is more about letting the wallet know when a transaction it cares about was removed / should not be removed from the mempool. For example a transaction that takes a week to confirm.
203 2015-04-27 10:49:50 <jgarzik> sipa, TX removal strategy of janitor was resource limitation - simply it was a periodic sweep rather than continuous testing
204 2015-04-27 10:50:10 <jgarzik> to enact the resource limitation
205 2015-04-27 10:51:06 <jgarzik> wallet should notice when a TX it thought to be in the mempool is no longer
206 2015-04-27 11:23:55 <sipa> jgarzik: i understand
207 2015-04-27 11:24:35 <sipa> jgarzik: but the reason why we care about mempool-wallet consistency in the first place, is because we rely on the mempool for conflict testing
208 2015-04-27 11:30:25 <sipa> jgarzik: which is something that is for example not possible anyway in spv mode
209 2015-04-27 13:21:43 <hearn> sipa: what's up with the sudden change of the max message size from 32mb to 2mb?
210 2015-04-27 13:23:00 <hearn> i mean, i figured the change would be elsewhere rather than introducing a new check and constant
211 2015-04-27 13:24:53 <sipa> hearn: we currently wouldn't accept any larger message than 2mb anyway - the constant can easily be changed when we do
212 2015-04-27 13:25:03 <hearn> yeah, i see that.
213 2015-04-27 13:25:08 <hearn> but i thought the 32mb limit was defined elsewhere?
214 2015-04-27 13:25:12 <hearn> or was i imagining that
215 2015-04-27 13:25:27 <sipa> the 32 mb limit is globally, for everything that uses the serialize infrastructure
216 2015-04-27 13:25:30 <hearn> ah
217 2015-04-27 13:25:32 <sipa> which is more than just the p2p protocol
218 2015-04-27 13:26:04 <hearn> i see. i wonder if anything >2mb is actually serialized to disk at any point
219 2015-04-27 13:26:41 <sipa> probably not
220 2015-04-27 13:26:57 <sipa> but it's not really a good idea to mix those concerns
221 2015-04-27 13:28:47 <sipa> 2015-04-27 13:27:19 receive version message: /btccrawler.ch:v0.1/: version 70002, blocks=666903, us=178.18.90.41:8333, peer=37
222 2015-04-27 13:28:52 <sipa> ^- that's a lot of blocks!
223 2015-04-27 13:38:30 <hearn> sipa: it's a satanic chain!
224 2015-04-27 13:40:34 <sipa> hearn: wait until BIP66 goes into action
225 2015-04-27 13:40:58 <priidu> :p
226 2015-04-27 13:41:06 <hearn> we should make the bitcoin logo turn into a pentagram on any date the block chain height contains the figure 666
227 2015-04-27 13:41:49 <priidu> or embed an OP_RETURN that contains satanic texts when decoded backwards :p
228 2015-04-27 13:42:56 <sipa> hearn: i'll be happy to announce "Execute order, i mean BIP, 66"
229 2015-04-27 13:45:23 <kanzure> i am having trouble connecting to more peers on testnet. i only have 8 connections. the listen port is open (although i'm using an unusual number).
230 2015-04-27 13:45:33 <kanzure> does the port number matter to other testnet nodes?
231 2015-04-27 13:46:03 <sipa> kanzure: i believe so - nodes preferentially connect to default-port nodes - but in case there are few known other peers, they should divert from that
232 2015-04-27 13:46:44 <kanzure> oh that's interesting
233 2015-04-27 13:46:54 <kanzure> sipa: so do they preferentially reject/ignore non-default-port nodes?
234 2015-04-27 13:47:10 <sipa> just when selecting outbound connections
235 2015-04-27 13:47:46 <kanzure> so my testnet node is probably trying to connect, and the only nodes it can connect with are these bozo testnet nodes with the wrong blockchain
236 2015-04-27 13:49:19 <hearn> odd
237 2015-04-27 13:49:26 <hearn> sipa: what does this mean?
238 2015-04-27 13:49:26 <hearn> ./src/field_5x52_impl.h:24:2: error: "Please select field_5x52 implementation"
239 2015-04-27 13:49:46 <hearn> i'm rebasing bitcoin XT on 0.10.1 and this error cropped up. some kind of build flake .... do a blast cleaning and recompile?
240 2015-04-27 13:49:52 <sipa> hearn: there are two field_5x52 implementations (an asm one, and a __int128 one)
241 2015-04-27 13:50:10 <sipa> oh, if this is just bitcoin core, yes, git clean -dfx and rerun
242 2015-04-27 13:50:13 <hearn> ok
243 2015-04-27 13:50:20 <sipa> though i've never seen that error before when compiling bitcoin
244 2015-04-27 13:50:33 <hearn> it happened in the configure stage, oddly enough
245 2015-04-27 13:50:40 <hearn> ok, will try again
246 2015-04-27 13:52:23 <kanzure> hmm unfortunately i am not using unusual port numbers
247 2015-04-27 13:53:01 <kanzure> using testnet listen port 18333
248 2015-04-27 13:57:43 <kanzure> has anyone synced a testnet node recently?
249 2015-04-27 13:57:55 <priidu> yeah, I have
250 2015-04-27 13:58:00 <PRab> kanzure: I just did yesterday.
251 2015-04-27 13:58:15 <kanzure> PRab: is your blockheight >300k?
252 2015-04-27 13:59:06 <priidu> should be 373,417 right now
253 2015-04-27 13:59:48 <PRab> kanzure: Just bringing it back up.
254 2015-04-27 14:00:11 <kanzure> i am still stuck with 26859 (000000000b68a105541621853e18d7a5ca41e83f835a74708b9a6ecc6173eac8)
255 2015-04-27 14:00:56 <PRab> I'm at 343417
256 2015-04-27 14:02:22 <PRab> I noticed yesterday that almost all of the testnet block explorers were stuck at different points, but I doubt that is related.
257 2015-04-27 14:02:24 <kanzure> "getblock 000000001586e2333bcb737348b9463a7cfffcf64e0a09d38e23d9beae96984c" (the next one) gives me "confirmations: -1"
258 2015-04-27 14:03:42 <priidu> I think the block explorers being stuck has something to do with periods where a buttload of blocks are generated in a rapid succession
259 2015-04-27 14:03:45 <priidu> might be wrong though
260 2015-04-27 14:03:54 <priidu> but it happens on the testnet
261 2015-04-27 14:04:20 <kanzure> yes, i suspect my problem is unrelated (although i have no evidence)
262 2015-04-27 14:04:20 <PRab> yep, yesterday, I got 6 confirmations in under 1 minute, so that could be possible.
263 2015-04-27 14:05:51 <michagogo> What's the difficulty?
264 2015-04-27 14:06:42 <michagogo> If the 20-minute difficulty 1 rule kicks in at a retarget boundary, the difficulty for further blocks is also reset to 1
265 2015-04-27 14:06:51 <michagogo> And it can take a while to build back up from that
266 2015-04-27 14:07:07 <michagogo> And until that happens, blocks have been coming very quickly
267 2015-04-27 14:11:06 <priidu> yeah
268 2015-04-27 14:11:21 <PRab> I might have bitcoind-ncurses configured wrong, but it shows Diff=1
269 2015-04-27 14:11:32 <priidu> nope, it is entirely possible
270 2015-04-27 14:11:48 <PRab> The default testnet RPC port is 18332, right?
271 2015-04-27 14:11:48 <priidu> same here
272 2015-04-27 14:11:56 <priidu> basically, what michagogo said
273 2015-04-27 14:12:29 <PRab> Understood, but this is the first time I've tried to hook bitcoind-ncurses up to testnet bitcoind.
274 2015-04-27 14:12:39 <PRab> I was afraid that I might have messed up.
275 2015-04-27 14:12:52 <priidu> PRab: default RPC port for testnet is 18332, yes
276 2015-04-27 14:13:45 <michagogo> PRab: important to know, though, what difficulty that is
277 2015-04-27 14:13:59 <michagogo> Difficulty of the last block, or difficulty of the next block?
278 2015-04-27 14:15:03 <PRab> michagogo: https://imgur.com/9oP62xp
279 2015-04-27 14:28:51 <kanzure> ERROR: CScriptCheck() : ca05e4f0ad93be876a6abea6405c080a9c78141403753a9885c8c36ec379cf4f:0 VerifySignature failed: Script evaluated without error but finished with a false/empty top stack element
280 2015-04-27 14:29:01 <kanzure> InvalidChainFound: invalid block=000000001586e2333bcb737348b9463a7cfffcf64e0a09d38e23d9beae96984c height=26860 log2_work=48.903793 date=2012-09-20 01:03:40
281 2015-04-27 14:29:13 <kanzure> oh.
282 2015-04-27 14:30:07 <sipa> kanzure: try reconsiderblock
283 2015-04-27 14:30:19 <kanzure> https://github.com/bitcoin/bitcoin/pull/5634#issuecomment-69484895
284 2015-04-27 14:31:38 <kanzure> sipa: http://pastebin.com/vAmPTszg
285 2015-04-27 14:32:34 <sipa> kanzure: hmm, and if you go back further?
286 2015-04-27 14:33:22 <kanzure> in the logs? nothing unusual
287 2015-04-27 14:33:35 <kanzure> the invalid chaintip messages did appear before
288 2015-04-27 14:34:40 <sipa> kanzure: i mean do an invalidate + reconsider further back
289 2015-04-27 14:48:29 <kanzure> sipa: thank you for the assist, it turns out my problem was caused by a bad build (i suspect wrong openssl version during compiletime?)
290 2015-04-27 14:48:51 <sipa> kanzure: bad openssl shouldn't matter anymore with recent bitcoin core
291 2015-04-27 14:49:01 <kanzure> my build was not so recent :-)
292 2015-04-27 14:49:09 <kanzure> i am still experiencing an inability to connect to more than 8 nodes
293 2015-04-27 14:49:49 <sipa> kanzure: bitcoin core never makes more than 8 outgoing connections
294 2015-04-27 14:50:48 <kanzure> i am running a mainnet node and getinfo reports >60 connections
295 2015-04-27 14:50:59 <sipa> then you have 52 incoming connections
296 2015-04-27 14:51:00 <sipa> :)
297 2015-04-27 14:51:22 <sipa> and it takes a while before the network and crawlers learn about you
298 2015-04-27 14:51:43 <sipa> if you weren't synced up for a long time, your node may not have self-advertized for a long time
299 2015-04-27 14:51:53 <kanzure> this node has been up for a few weeks stuck at that other blockheight
300 2015-04-27 14:52:00 <sipa> yeah
301 2015-04-27 14:52:22 <kanzure> hm.
302 2015-04-27 14:52:25 <kanzure> alright
303 2015-04-27 14:52:31 <sipa> just wait a while :)
304 2015-04-27 14:52:38 <bengt_> hrm, aren't the checksums of the binaries from bitcoin.org supposed to match gitian builds? whats different? (the windows setup binaries are different) is it because they've been signed?
305 2015-04-27 14:52:43 <kanzure> estimated waitlength?
306 2015-04-27 14:52:51 <sipa> bengt_: indeed, they are signed
307 2015-04-27 14:52:58 <kanzure> actually, nevermind- i'm syncing fast enough as-is
308 2015-04-27 14:53:00 <sipa> kanzure: on testnet? no clue :)
309 2015-04-27 14:53:06 <kanzure> seems to be 1k blocks/sec
310 2015-04-27 14:53:30 <kanzure> i sure hope this isn't headers
311 2015-04-27 14:53:44 <sipa> how do you assess sync speed?
312 2015-04-27 14:53:54 <kanzure> getinfo blocks. is this wrong?
313 2015-04-27 14:54:06 <kanzure> also, with headers-first, does blocknotify trigger before the transactions are received?
314 2015-04-27 14:54:19 <bengt_> sipa: I see, thanks
315 2015-04-27 14:54:19 <sipa> blocknotify triggers on new tip
316 2015-04-27 14:54:25 <sipa> tip implies fully validated
317 2015-04-27 14:54:29 <kanzure> coolio
318 2015-04-27 14:54:45 <sipa> getblockchaininfo (or was it getinfo?) lists both blocks and headers
319 2015-04-27 14:54:51 <sipa> headers should always >= blocks
320 2015-04-27 14:55:12 <kanzure> getblockchaininfo is correct
321 2015-04-27 14:55:37 <kanzure> reconsiderblock is a neat trick, thank you
322 2015-04-27 15:46:49 <esso> Are there any good libraries written in C currently?
323 2015-04-27 15:51:13 <Luke-Jr> esso: lots?
324 2015-04-27 15:52:03 <timothy> https://github.com/MatthewLM/cbitcoin || https://github.com/jgarzik/picocoin
325 2015-04-27 15:52:17 <esso> Luke-Jr: what do you consider the best?
326 2015-04-27 15:52:48 <Luke-Jr> uh.. libc I guess? O.o
327 2015-04-27 15:53:17 <Luke-Jr> ACTION feels confused. XD
328 2015-04-27 15:53:24 <timothy> I think he was asking for bitcoin library written in C
329 2015-04-27 15:54:39 <Luke-Jr> "bitcoin" is a rather wide subject matter in the context of libraries.
330 2015-04-27 15:55:51 <Luke-Jr> I mean, there's libbitcoinconsensus for consensus stuff, libsecp256k1 for ECDSA, libblkmaker for GBT, libbase58 for base58check, â¦
331 2015-04-27 15:56:12 <Luke-Jr> I guess libbitcoinconsensus isn't C though, but the others are
332 2015-04-27 16:08:36 <jgarzik> timothy, I'm highly biased of course :)
333 2015-04-27 16:09:16 <jonasschnelli> Is there a way to pause (or stop and resume later) a -reindex? gdb attach pid and interrupt?
334 2015-04-27 16:09:17 <jgarzik> timothy, libccoin (picocoin's lib) is endian clean, valgrind clean, and validates all modern blocks
335 2015-04-27 16:10:03 <jgarzik> timothy, CBitcoin tries to reinvent every basic C101 data structure such as red-black trees or dictionaries, sometimes poorly ;0
336 2015-04-27 16:10:57 <jgarzik> picocoin itself is an unfinished SPV client. libccoin is feature complete and usable in other apps.
337 2015-04-27 16:14:05 <harding> jonasschnelli: if your considering using gdb to pause an app on Linux, you can just do kill -SIGSTOP and (later) -SIGCONT. I'm not sure whether or not that's POSIX, so other *Nix might have different signals.
338 2015-04-27 16:14:49 <jonasschnelli> harding: thanks. Will try.
339 2015-04-27 17:08:24 <Luke-Jr> jgarzik: libccoin uses glib IIRC though, which is "reinvent every basic C101 data structure" :/
340 2015-04-27 17:21:47 <jgarzik> Luke-Jr, Nod - I can be confident that the GLib stuff works, works on embedded, and is valgrind clean. CBitcoin starts from scratch with both C101 & bitcoin 101, and fails at both.
341 2015-04-27 17:40:04 <StephenM347> Is the zero_after_free_allocator used out of concern that a base58 private key might remain in RAM?
342 2015-04-27 17:42:07 <sipa> StephenM347: yes
343 2015-04-27 17:45:06 <andytoshi> in c++ can you prevent things from ever being relocated in memory implicitly?
344 2015-04-27 17:45:20 <andytoshi> in rust you cannot, zero-after-free is stymied by this :/
345 2015-04-27 17:47:17 <sipa> andytoshi: nope
346 2015-04-27 17:48:17 <sipa> the compiler can decide to load data in a register, and later spill that register on the stck
347 2015-04-27 18:17:23 <Marklock> Can you create a blockchain or coin that doesn't allow spending coins? E.G only pays out to users after a "mining" process.
348 2015-04-27 18:38:51 <michagogo> jonasschnelli: what exactly do you want to do? (cc harding)
349 2015-04-27 18:39:14 <michagogo> The -reindex option basically wipes the current index
350 2015-04-27 18:39:55 <michagogo> So after you -reindex, you can just shut down the node and it'll pick up where it left off when you restart it.
351 2015-04-27 18:40:53 <michagogo> If that's what you meant, then you don't need to do anything special.
352 2015-04-27 18:41:07 <michagogo> Marklock: you can do anything
353 2015-04-27 18:41:22 <michagogo> (Anything that you can write code for, that is)
354 2015-04-27 18:41:40 <michagogo> Not sure I see the point, though.
355 2015-04-27 18:42:11 <Marklock> I was thinking it could then function as purely a proof-of-work record for a system.
356 2015-04-27 18:44:36 <sipa> Marklock: you can throw away all of transactions and coins
357 2015-04-27 18:44:56 <sipa> Marklock: just create a block chain where every block can commit to some data
358 2015-04-27 18:52:55 <phantomcircuit> sipa, i had actually considered modifying the "Periodically clear setAddrKnown" logic to clear something less than all the addresses
359 2015-04-27 18:53:44 <phantomcircuit> clearing the entire thing -- potentially including stuff that was just added -- is suboptimal
360 2015-04-27 18:54:04 <phantomcircuit> not sure how that could be done if it's a bloom filter (or even if it could be done)
361 2015-04-27 18:54:40 <sipa> phantomcircuit: meh, good enough i think
362 2015-04-27 18:55:28 <sipa> it's already sor of an mru anyway, so it gets cleared over time
363 2015-04-27 18:57:51 <phantomcircuit> sipa, possibly with the bloom filter stuff it doesn't need to be cleared at all
364 2015-04-27 18:59:24 <michagogo> 0:45:49 <sipa> my gitian build fails
365 2015-04-27 18:59:32 <michagogo> Yeah, I was getting that too
366 2015-04-27 18:59:39 <michagogo> I opened an issue
367 2015-04-27 19:00:18 <michagogo> I think that particular change was done a bit sloppily -- that redirects to install.log, but within the script it redirects elsewhere
368 2015-04-27 19:00:24 <michagogo> And also uses a quiet flag
369 2015-04-27 19:00:53 <michagogo> And also has one line that has two > redirects, to a file and then to /dev/null, don't know what happens there
370 2015-04-27 19:01:15 <michagogo> Anyway, a bit of editing to actually get the output, and it's something to do with a grub upgrade
371 2015-04-27 19:02:04 <michagogo> Anyway, I worked around it by rerunning make-base-vm, which had the effect of having all the packages up to date so it didn't try to do the upgrade
372 2015-04-27 19:02:13 <michagogo> sipa: do you use lxc or KVM?
373 2015-04-27 19:03:04 <Marklock> In multi-sig set-ups can you have to have all user consensus instead of just 3-of-5 or 5-of-7?
374 2015-04-27 19:10:35 <michagogo> Marklock: yes
375 2015-04-27 19:10:48 <michagogo> m-of-n, where m<=n
376 2015-04-27 19:21:22 <sipa> phantomcircuit: the reason for clearing is to make periodic reannouncements work
377 2015-04-27 19:22:01 <phantomcircuit> sipa, i know but if it's an mru maybe trickling nonsense through it would be more effective
378 2015-04-27 19:30:14 <sipa> phantomcircuit: it already was an mru, so the periodic cleearning likely did not do much already
379 2015-04-27 19:33:54 <sipa> phantomcircuit: at least it puts a bound on the age of entries
380 2015-04-27 19:34:19 <phantomcircuit> hmm
381 2015-04-27 19:35:51 <michagogo> 6:26:53 <leakypat> Am I correct in thinking newer version s of Bitcoin core have an "insane miners fee" error check built in?
382 2015-04-27 19:36:06 <michagogo> leakypat: I may me misremembering, but I think that's just in sendrawtransaction
383 2015-04-27 19:36:13 <michagogo> May be*
384 2015-04-27 19:36:22 <michagogo> But yes
385 2015-04-27 20:09:48 <StephenM_> sipa: Peter Todd mentioned in an email chain that you were working on some sort of an nVersion soft-fork mechanism, could you elaborate?
386 2015-04-27 20:14:20 <sipa> StephenM_: i should just finish it and publish it :)
387 2015-04-27 20:14:30 <petertodd> sipa: please do :)
388 2015-04-27 20:15:40 <StephenM> Okay, I can be patient :)
389 2015-04-27 20:21:15 <jgarzik> It is vaguely tempting to -remove- the current notifications mechanism, replacing it with socket or $whatever, and add a separate program which maintains compatibility with the execution-based notification mechanism.
390 2015-04-27 20:21:45 <jgarzik> move forward in bitcoind, but maintain compat for those that need it
391 2015-04-27 20:22:16 <phantomcircuit> jgarzik, is the current notification stuff a separate thread already?
392 2015-04-27 20:22:41 <phantomcircuit> if so changing it to work that way should be pretty easy
393 2015-04-27 20:22:51 <phantomcircuit> just have bitcoind spin up the external program
394 2015-04-27 20:23:23 <jgarzik> phantomcircuit, context is #6072
395 2015-04-27 20:23:48 <phantomcircuit> yeah that's not a good idea
396 2015-04-27 20:23:49 <jgarzik> phantomcircuit, current system isn't so great for high volume events
397 2015-04-27 20:24:10 <sipa> phantomcircuit: the notifications stuff is currently just spawning a shell script for every event
398 2015-04-27 23:44:54 <fanquake> ;;blocks
399 2015-04-27 23:44:55 <gribble> 353999