1 2015-01-22 00:00:08 <benjamindees> one sidechain that is effectively unlimited
2 2015-01-22 00:01:03 <jtimon> ...and then I rebase on top of that?
3 2015-01-22 00:01:03 <jtimon> or cfields what about you building something on top of 96bacf45 Consensus: SQUASHME: MOVEONLY: Consensus::CheckTx() from main.o to consensus/consensus.o ?
4 2015-01-22 00:01:25 <benjamindees> I'm not even sure that is even technically feasible, but it seems like a compromise to consider.
5 2015-01-22 00:01:42 <sipa> benjamindees: if that's a perfect solution, why not a main chain with 1 kb limit, and an unlimited sidechain?
6 2015-01-22 00:01:46 <cfields> jtimon: that would be great for me, but i'm afraid it'd be a big hassle for you
7 2015-01-22 00:01:46 <jtimon> that doesn't involve any policy code at all
8 2015-01-22 00:01:59 <sipa> benjamindees: it just moves the problem
9 2015-01-22 00:03:09 <sipa> sorry, i'm making assumptions
10 2015-01-22 00:03:27 <benjamindees> sipa, like I said, I'm not sure it's technically feasible -- gmaxwell led me to believe it may be
11 2015-01-22 00:03:39 <sipa> it's possible to see sidechains as a place where 'overflow transactions' can happen which don't fit on the main chain
12 2015-01-22 00:03:53 <sipa> but it is a compromise
13 2015-01-22 00:04:23 <sipa> as that sidechain itself now gets all the problems that a main chain with the same size would have, at least
14 2015-01-22 00:04:32 <jtimon> well, it depends on what you do in the next commits, but I'm fine with rebasing
15 2015-01-22 00:05:15 <benjamindees> sipa, I'm not really thinking of overflow transactions... more like almost all transactions occur on the sidechain
16 2015-01-22 00:05:38 <cfields> jtimon: as far as you're concerned, rebasing should only require includes fixups
17 2015-01-22 00:05:42 <jtimon> my undesrtanding is that you want to avoid building some files twice for consensusliib and for the rest as a first step, right?
18 2015-01-22 00:05:43 <cfields> i hope
19 2015-01-22 00:05:47 <benjamindees> and then people with limited bandwidth or for whatever other reason can do transactions on the main chain
20 2015-01-22 00:06:02 <Luke-Jr> sipa: global + national sidechains may be workable
21 2015-01-22 00:06:09 <sipa> benjamindees: that's no better than just increasing the bitcoin block size
22 2015-01-22 00:06:17 <benjamindees> Luke-Jr, see, that's what I'd rather avoid
23 2015-01-22 00:06:21 <cfields> jtimon: yea, that part's done. now i'd like to start moving files into the consensus lib
24 2015-01-22 00:06:57 <jtimon> ok, sounds great, agter 70a502f6 Includes: Cleanup includes there should be less of those and those are relatively easy to solve conflicts on
25 2015-01-22 00:06:58 <Luke-Jr> another alternative is to have day-to-day transactions on a sidechain and reconcile with the main chain monthly or whatever
26 2015-01-22 00:07:02 <Luke-Jr> to compress history at least
27 2015-01-22 00:07:18 <benjamindees> sipa, it moves the perceived risk of increased block size to an (optional) side chain
28 2015-01-22 00:07:20 <cfields> jtimon: ok, i'll give that a shot
29 2015-01-22 00:07:23 <sipa> benjamindees: the problem with increasing the block size is that increases the costs to validate that nobody is cheating
30 2015-01-22 00:07:55 <sipa> benjamindees: if you have an infinite-size sidechain, then that sidechain also has that problem
31 2015-01-22 00:08:07 <Luke-Jr> sipa: at least a larger-but-not-infinite sidechain would make it opt-in
32 2015-01-22 00:08:12 <benjamindees> sipa, but you don't have to use the sidechain if you don't want
33 2015-01-22 00:08:25 <cfields> jtimon: basically, anything consensus-critical i want to move into the lib, which ofc means pruning app-state and boost first. that's all i'll be disturbing.
34 2015-01-22 00:08:32 <phantomcircuit> sipa, something pointed out to me today; ever doesn't seem to be much difference between increasing the block size and reducing the time between blocks
35 2015-01-22 00:08:54 <sipa> phantomcircuit: there is, but it's determined by network latency
36 2015-01-22 00:08:56 <Luke-Jr> phantomcircuit: disagree: reducing block interval makes attacks stronger
37 2015-01-22 00:09:05 <jtimon> so let's confirm what are you building on so that I don't touch that base...96bacf45, then you introduce the part that you have already done and we set another common base
38 2015-01-22 00:09:16 <benjamindees> phantomcircuit, global consensus suffers below a certain point
39 2015-01-22 00:09:21 <sipa> phantomcircuit: if propagation speed was perfectly proportional to block size, they would be equivalent
40 2015-01-22 00:09:29 <Luke-Jr> phantomcircuit: also makes more data for SPV nodes
41 2015-01-22 00:09:44 <phantomcircuit> sipa, right, i suspect the largely are above something like 5 seconds
42 2015-01-22 00:09:46 <sipa> phantomcircuit: but propagation has a constant term due to latency, so it's not entirely proportional
43 2015-01-22 00:09:49 <benjamindees> not to mention inter-planetary consensus
44 2015-01-22 00:09:50 <cfields> jtimon: ack
45 2015-01-22 00:10:11 <phantomcircuit> sipa, ie some small constant + blocksize * bandwidth
46 2015-01-22 00:10:16 <jtimon> yep, I would really like to keep consensus and policy stateless during the process to avoid disturbing on that
47 2015-01-22 00:10:16 <Luke-Jr> benjamindees: interplanetary is not really doable with the current blockchain
48 2015-01-22 00:10:16 <sipa> yes
49 2015-01-22 00:10:31 <benjamindees> Luke-Jr, haha, true
50 2015-01-22 00:11:01 <cfields> sipa: when you get a min after current discussions, could you please have a look at #5458? I'd like to know if you're opposed to going that route, or just not what you had in mind
51 2015-01-22 00:11:35 <sipa> cfields: i haven't had time to follow up on current pullreqs lately
52 2015-01-22 00:11:38 <sipa> there's too many!
53 2015-01-22 00:11:43 <sipa> let me see
54 2015-01-22 00:11:49 <cfields> sipa: heh np, it's an old one that you commented on
55 2015-01-22 00:11:56 <phantomcircuit> yes stop being so productive people!
56 2015-01-22 00:12:00 <phantomcircuit> ACTION runs away
57 2015-01-22 00:12:01 <sipa> (which is by no means saying that you should slow down)
58 2015-01-22 00:12:51 <Luke-Jr> phantomcircuit: well, it means perhaps the most prolific PR-ers should spend more of their time doing review ;)
59 2015-01-22 00:12:53 <jtimon> cfields great how are you going to name that branch when you push it to github? I'm going to bed soon, but I will check tomorrow morning
60 2015-01-22 00:13:17 <cfields> jtimon: i'll push to uhm.. consensus-refactor
61 2015-01-22 00:13:20 <sipa> cfields: so my opinion has always been that primitives should just be the primitives, and any non-primitive logic that is written as methods on it, should just become functions on higher level modules
62 2015-01-22 00:13:45 <sipa> cfields: introducing two laters of classes seems overkill for the small benefit of being able to use method syntax
63 2015-01-22 00:13:49 <jtimon> roger
64 2015-01-22 00:13:57 <cfields> sipa: that's exactly what that change does, while maintaining class structure
65 2015-01-22 00:13:59 <cfields> hmm
66 2015-01-22 00:14:33 <sipa> i think it's much easier to just move the non-primitive operations out of the classes, rather than trying to keep the class structure
67 2015-01-22 00:15:05 <cfields> sipa: i disagree, but maybe it'd help if i gave a use-case for going that way
68 2015-01-22 00:15:23 <jtimon> but the primitives remain mainly structs with the serialization
69 2015-01-22 00:15:39 <sipa> yeah, without use case it's abstract talk
70 2015-01-22 00:15:43 <jtimon> what class is the problem?
71 2015-01-22 00:16:55 <cfields> sipa: when done this way, we could pass (say) a CTransaction to the consensus lib, which receives a CBaseTransaction. In doing so, the consensus lib doesn't inherit/require any un-needed app-specific features
72 2015-01-22 00:18:04 <sipa> i'm just saying that CTransaction and CBaseTransaction should be the same, and neither should have any un-needed app-specific features
73 2015-01-22 00:18:52 <sipa> CMutableTransaction is actually already an example of that
74 2015-01-22 00:19:37 <sipa> a more featureful transaction datatype that gets converted to the core structure when interacting with other modules (including validation)
75 2015-01-22 00:19:41 <cfields> sipa: ok, let's take a stupidly simple example then. CTransaction.ToString(), which drags in our string handling. You'd rather see a CTransactionToString() added?
76 2015-01-22 00:20:08 <sipa> if string handling is considered unacceptable in some places, yes
77 2015-01-22 00:21:39 <sipa> is CTransaction::ToString() even still used anywhere?
78 2015-01-22 00:21:58 <jtimon> but what is being move from somewhere else to primitives?
79 2015-01-22 00:22:22 <sipa> in this PR, nothing
80 2015-01-22 00:23:26 <cfields> jtimon: the idea would be to do the same for the rest of the primitives, but i stopped there to discuss
81 2015-01-22 00:24:15 <jtimon> I'm still not sure what is being argued
82 2015-01-22 00:24:26 <sipa> look at the code
83 2015-01-22 00:25:00 <sipa> it's introducing two layers: a base primitive and a class layer on top for the same data types, but with more features
84 2015-01-22 00:26:55 <jtimon> sorry, I thought it was related to our previous conversation about consensus-refactor
85 2015-01-22 00:27:01 <jtimon> what's the PR?
86 2015-01-22 00:27:21 <sipa> #5458
87 2015-01-22 00:27:41 <sipa> yeah, having two simultaneous conversations with the same person is confusion
88 2015-01-22 00:28:25 <cfields> sorry :)
89 2015-01-22 00:36:30 <jtimon> so sipa how's what you want (moving app-specific code up) incompatible with what this PR does (cleanly separating what's purely data and serialization without breaking the upper level working interface)?
90 2015-01-22 00:37:30 <sipa> it should make it unnecessary, and is imho easier
91 2015-01-22 00:37:41 <jtimon> I think it will make what you want easier to do by greadually using the bases directly and abandoning the higher level class
92 2015-01-22 00:37:43 <sipa> but i'm willing to be convinced by actual use cases
93 2015-01-22 00:39:02 <cfields> sipa: after messing with some refactors and using the results of that PR, i disagree. So yes, speaking in terms of actual uses-cases here would be more useful. I'll add some.
94 2015-01-22 00:39:07 <jtimon> I mean ending up with CTransactionBase in all function headers instead of CTransaction is unfortunate
95 2015-01-22 00:40:25 <cfields> sipa: and i'm more than willing to be un-convinced. This just seems like an easier direction than moving lots of functionality out somewhere else
96 2015-01-22 00:40:25 <jtimon> the templating can be added without creating the base classes too
97 2015-01-22 00:41:11 <cfields> jtimon: what do you mean by "ending up with CTransactionBase in all function headers" ?
98 2015-01-22 00:41:13 <jtimon> and imo it is unfortunate that CBlockHeader and CBlockIndex don't share a common parent class
99 2015-01-22 00:42:16 <jtimon> void function_header(const CTransactionBase&) as opposed to void function_header(const CTransaction&), never mind was just bikesheding on that sentence
100 2015-01-22 00:42:22 <sipa> and we'll see what we can do with them?
101 2015-01-22 00:42:22 <sipa> cfields: so make a list of all currently problematic functions in primitive classes
102 2015-01-22 00:43:33 <cfields> sipa: well first/easiest is the string handling, those are in all primitive classes. i'd rather keep that stuff out of consensus.
103 2015-01-22 00:44:59 <jtimon> ACTION remembers formatMoney and the RPC btc doubles vs satoshi integer discussion
104 2015-01-22 00:45:31 <sipa> cfields: ok, fair enough; but that can just move to some utility module for string conversion of primitive types
105 2015-01-22 00:45:41 <sipa> (or perhaps in some cases just be removed)
106 2015-01-22 00:46:46 <jtimon> I still don't see what's the problem with making the bases and keeping others that implement at least ToString()
107 2015-01-22 00:47:23 <jtimon> which you probably want for logging anyway
108 2015-01-22 00:48:50 <sipa> if ToString is so essential that it needs to be in class, it should stay in the primitive class anyway
109 2015-01-22 00:49:00 <sipa> if it's not, make it optional by moving it to a function
110 2015-01-22 00:49:43 <sipa> just because you need to add a few extra methods is not sufficient reason for adding a class imho
111 2015-01-22 00:50:22 <sipa> (and certainly not a templated one)
112 2015-01-22 00:50:26 <cfields> sipa: i suppose the question of purity should be discussed first. with the inheritance model, we strip everything down, and can add back only _exactly_ what we need. When removing functions, some unused app-specific functions will be left behind
113 2015-01-22 00:50:56 <cfields> that means that if a "golden" consensus lib ever emerges, the barrier for entry there is very high
114 2015-01-22 00:51:32 <cfields> but if the app still depends on it for helpers, CTransaction::ComputePriority (as an example) will have to be modified in the lib to satisfy the app
115 2015-01-22 00:51:48 <sipa> ComputePriority has absolutely no reason to be in primitives
116 2015-01-22 00:51:50 <gmaxwell> hm? priority is not part of the consensus code at all.
117 2015-01-22 00:52:02 <cfields> that's my point
118 2015-01-22 00:52:12 <sipa> it should be moved out of it anyway
119 2015-01-22 00:52:17 <sipa> orthogonal to this discussion
120 2015-01-22 00:52:49 <cfields> sipa: not entirely. this change effectly moves it out of consensus
121 2015-01-22 00:52:55 <cfields> *would move
122 2015-01-22 00:53:04 <sipa> yes, i see that
123 2015-01-22 00:53:13 <sipa> but it's not useful in this discussion; it needs to move anyway
124 2015-01-22 00:53:26 <sipa> after that it's not an argument for having it in a class on top
125 2015-01-22 00:53:59 <jtimon> to be fair transaction.cpp is currently only 143 lines and the few methods that don't belong there probably belong to policy or txmempool
126 2015-01-22 00:54:30 <jtimon> not sure about CTransaction::GetValueOut()
127 2015-01-22 00:55:23 <sipa> cfields: imho the only thing you gain by building such an inheritance model is that you can call bla.X(foo) rather than X(bla, foo)
128 2015-01-22 00:57:14 <sipa> if you have a more featureful class that adds extra fields, perhaps precomputed values, ... that's different
129 2015-01-22 00:57:37 <cfields> sipa: ok, consider CNetAddr as a better example, then
130 2015-01-22 00:58:54 <cfields> imo it makes perfect sense to have an app layer of functions on top of bare data there.
131 2015-01-22 01:00:23 <benjamindees> Just to expand on my earlier comments, to address sipa's question of "why not 1k main chain/infinite sidechain"...
132 2015-01-22 01:00:25 <sipa> that's a better example, yes
133 2015-01-22 01:00:32 <benjamindees> I think it's been established that bandwidth is the limiting factor in increasing the block size. Right now there are two groups of users, those with Google fiber, and everyone else.
134 2015-01-22 01:00:44 <benjamindees> If the size of the main chain is increased too aggressively, those with Google fiber will take the network away from everyone else.
135 2015-01-22 01:00:55 <sipa> benjamindees: validation speed matters too
136 2015-01-22 01:00:58 <benjamindees> So that's the reason I suggested 5mb/unlimited. It doesn't have to be that exactly. It could be 2mb/2gb or whatever.
137 2015-01-22 01:01:33 <benjamindees> By splitting the functions of the chain into two parts, the main chain is still open to verification or use by everyone with an average connection, while a sidechain can grow to accomodate day-to-day transactions.
138 2015-01-22 01:01:44 <benjamindees> Instead of a situation with any kind of artificial limits or fees, the two chains compete with each other.
139 2015-01-22 01:02:34 <benjamindees> sipa, I'm not sure what you mean
140 2015-01-22 01:02:56 <sipa> benjamindees: the reason blocks have a limited size is because people need to be able to validate them
141 2015-01-22 01:03:07 <benjamindees> sipa, oh, as opposed to bandwidth, I see
142 2015-01-22 01:03:16 <sipa> bandwidth is part of that
143 2015-01-22 01:03:24 <sipa> but cpu/ram/disk also matter
144 2015-01-22 01:03:45 <benjamindees> yes but bandwidth is the most important factor, it's a local monopoly in most places
145 2015-01-22 01:03:55 <sipa> i'm not sure
146 2015-01-22 01:04:07 <benjamindees> economically
147 2015-01-22 01:04:26 <sipa> on typical hardware a 1MB block takes 1s to validate
148 2015-01-22 01:05:43 <moa> hmmm, i might need to upgrade
149 2015-01-22 01:06:55 <phantomcircuit> i got about 50mbps of validation with fScriptCheck = false and a very high checkpoint
150 2015-01-22 01:07:15 <phantomcircuit> ;;calc 50 * 600 / 8
151 2015-01-22 01:07:16 <gribble> 3750
152 2015-01-22 01:07:16 <sipa> phantomcircuit: well, i do think you want to check signatures :)
153 2015-01-22 01:07:29 <phantomcircuit> so certainly anything > 3.7GB/block is not going to work
154 2015-01-22 01:07:30 <phantomcircuit> :P
155 2015-01-22 01:07:42 <phantomcircuit> (that's a joke)
156 2015-01-22 01:07:58 <sipa> benjamindees: so there are several concerns here, and the priorities are unclear
157 2015-01-22 01:08:05 <phantomcircuit> my point is that anybody with > 50mbps of downstream bandwidth is going to be able to get the blocks faster than they can process them
158 2015-01-22 01:08:34 <benjamindees> phantomcircuit, what do you think the average connection is in Romania?
159 2015-01-22 01:08:39 <sipa> benjamindees: one is that you want to propagation time for blocks significantly lower than the block interval, or you create an incentive for miners to collude (to reduce orphaning rate)
160 2015-01-22 01:08:51 <phantomcircuit> unless there's substantial reorganization of bitcoin core to eliminate malloc calls and the merkle tree calculation is switched to sse4way
161 2015-01-22 01:09:10 <phantomcircuit> benjamindees, no idea but relatively slow should be good enough upto some pretty large limits
162 2015-01-22 01:09:18 <phantomcircuit> remember it's blocksize/ 10 minutes
163 2015-01-22 01:09:21 <sipa> benjamindees: another is that you want it to be able for people to validate the chain (if not, miners could just create infinite subdidy and nobody would notice)
164 2015-01-22 01:09:55 <gmaxwell> phantomcircuit: replacing the tree calculation with a faster one wouldn't be a huge deal, might also kill a bunch of the malloc overhead, since I think we're heap allocating for every node in the tree.
165 2015-01-22 01:10:10 <moa> imo, the biggest question that needs quantitative analysis is how many nodes will be disincentivised by an increase in storage/cpu overhead
166 2015-01-22 01:10:29 <moa> and at what rate
167 2015-01-22 01:11:25 <moa> nobody wants to grind on a spammy game-boy micro-tx
168 2015-01-22 01:17:51 <phantomcircuit> moa, hopefully storage would be negligible
169 2015-01-22 01:18:02 <phantomcircuit> since it's already a relatively small amount of storage
170 2015-01-22 01:18:20 <gmaxwell> moa: it's hard to say now, we know that the full node count has fallen substantially from its peak as the costs of running a node has increased even while the value and adoption of bitcoin has gone up. But some of this is due to software behavior which can be 'costlessly' (just development effort) improved.
171 2015-01-22 01:19:25 <benjamindees> as someone on a very slow broadband connection, bitcoind is nearly unusable without router throttling
172 2015-01-22 01:19:36 <moa> wonder if we can glean any data from the satoshi dice era?
173 2015-01-22 01:24:32 <justanotheruser> moa: here are some gambling websites address prefixes if you want to do analysis https://gitorious.org/bitcoin/luke-jr-bitcoin/source/9d9fdd42fea244d3f3886ab1b9b3b35048d17353:src/script.cpp#L1869
174 2015-01-22 01:28:22 <moa> need to normalise for price maybe
175 2015-01-22 01:29:19 <only> hi, does anyone know how my friend and I can spend some coins from a 2-of-2 multisig addy?
176 2015-01-22 01:29:54 <fanquake> only ask in #bitcoin
177 2015-01-22 01:31:55 <only> fanquake: dun, thanks
178 2015-01-22 01:32:11 <only> but no love so far over there
179 2015-01-22 03:06:36 <wumpus> sipa: cfields: I'm not really interested in spending time pushing 0.9.4 executables as gitian users don't have the problem that motivated 0.9.4
180 2015-01-22 03:08:42 <wumpus> I made my point about that here: https://github.com/bitcoin/bitcoin.org/pull/710#issuecomment-70415594
181 2015-01-22 03:09:10 <wumpus> also if the softfork is to make it into 0.10, it will be accompanied with a 0.9.5 that backports it
182 2015-01-22 03:09:17 <wumpus> so it is just better to skip it
183 2015-01-22 03:10:53 <sipa> ack
184 2015-01-22 03:11:43 <phantomcircuit> yup
185 2015-01-22 03:55:24 <jgarzik> hum
186 2015-01-22 03:56:07 <jgarzik> sipa, wumpus, local 0.10(git master) is stuck at hashBestChain=000000000000000017f84a6e30e8df6d80692ddbf94ff3e25f1b24283701335e height=339800
187 2015-01-22 03:56:10 <jgarzik> reindexing...
188 2015-01-22 03:56:36 <jgarzik> This is most definitely running bitcoind w/ OpenSSL patch
189 2015-01-22 03:58:19 <sipa> define stuck
190 2015-01-22 03:58:26 <sipa> ;;blocks
191 2015-01-22 03:58:27 <gribble> 339997
192 2015-01-22 03:58:46 <sipa> is it rc3 or later?
193 2015-01-22 03:59:52 <wumpus> jgarzik: any errors about rejecting blocks?
194 2015-01-22 04:00:03 <wumpus> and/or leveldb database erros
195 2015-01-22 04:00:37 <jgarzik> sipa, git master as of 24 hours ago
196 2015-01-22 04:00:47 <wumpus> how long had it been stuck there?
197 2015-01-22 04:01:14 <jgarzik> since height 339800
198 2015-01-22 04:02:59 <wumpus> if it is just a network issue, it will probably continue after restarting the client, although you may want to hold that off if people still want to know things about the running state for debugging
199 2015-01-22 04:03:49 <sipa> jgarzik: does getpeerinfo list any in-flight blocks?
200 2015-01-22 04:04:01 <sipa> does getchaintips list any headers-only chains beyond the tip?
201 2015-01-22 04:05:06 <jgarzik> There it goes.... A restart + ~10 minute wait, and suddenly it sync'd up to tip
202 2015-01-22 04:05:31 <jgarzik> sipa, I'll check, but answer probably has less value due to restart
203 2015-01-22 04:05:39 <sipa> oh!
204 2015-01-22 04:05:45 <sipa> is this after a reindex?
205 2015-01-22 04:06:00 <jgarzik> no, just restart. no reindex.
206 2015-01-22 04:06:05 <phantomcircuit> sipa, i should mention that i've seen weird stalls after a reindex
207 2015-01-22 04:06:08 <sipa> no, was it stuck after a reindex?
208 2015-01-22 04:06:15 <jgarzik> not here, no.
209 2015-01-22 04:08:23 <jgarzik> sipa, getchaintips output if you're curious, http://gtf.org/garzik/bitcoin/tips.json
210 2015-01-22 04:08:57 <sipa> looks normal
211 2015-01-22 05:17:52 <wumpus> cfields: I've looked a bit and it doesn't seem like llvm cross-compilation is much easier than gcc cross-compilation in practice. There are patched versions of crosstool-ng that can generate a clang toolchain, but it's the same idea as gcc, you need a binutils and clang for every target platform. Not the promised "one executable, all platforms" yet.
212 2015-01-22 05:18:04 <wumpus> cfields: but I may be missing something
213 2015-01-22 05:18:45 <cfields> wumpus: that's correct. compile is easy, binutils makes it more painful
214 2015-01-22 05:19:56 <wumpus> cfields: my conclusion is that it's still the same crap, and platform support seems more spotty
215 2015-01-22 05:20:22 <Luke-Jr> wumpus: eh, binutils supports multitarget
216 2015-01-22 05:20:59 <cfields> wumpus: the main benefit (as far as determinism goes) is that you can use the same compiler for builder and target
217 2015-01-22 05:21:04 <wumpus> Luke-Jr: ok, well if clang/llvm can be made multitarget then in theory we only have to compile the libc per target
218 2015-01-22 05:21:13 <cfields> Luke-Jr: s/binutils/linker/
219 2015-01-22 05:21:30 <cfields> apple doesn't use ld-bfd or gold, they use their own linker
220 2015-01-22 05:21:37 <wumpus> cfields: I think it doesn't make a difference for determinism, but it's less stuff to compile in total
221 2015-01-22 05:22:06 <Luke-Jr> cfields: GNU ld seems to be okay - except for assembly
222 2015-01-22 05:23:07 <wumpus> Luke-Jr: don't forget the ld plugins if you want -flto
223 2015-01-22 05:23:11 <cfields> wumpus: i agree with your conclusion, btw. It'd be nice if it could do it all, but atm it's not actually useful
224 2015-01-22 05:23:16 <cfields> Luke-Jr: hmm?
225 2015-01-22 05:23:40 <wumpus> cfields: it would have been nice
226 2015-01-22 05:24:45 <Luke-Jr> wumpus: do we use LTO? :o
227 2015-01-22 05:24:50 <cfields> wumpus: lld is working towards that, but afaik it's nowhere near ready
228 2015-01-22 05:24:50 <wumpus> Luke-Jr: 'we'? :p
229 2015-01-22 05:24:58 <Luke-Jr> wumpus: Bitcoin Core
230 2015-01-22 05:25:13 <cfields> wumpus: http://lld.llvm.org/
231 2015-01-22 05:25:38 <wumpus> Luke-Jr:esp for libbitcoinconsensus, flto is nice; I've tried it with bitcoind but gcc's runs out of memory and clang's crashes somewhere
232 2015-01-22 05:26:01 <Luke-Jr> last I heard, LTO stuff was highly experimental
233 2015-01-22 05:26:18 <wumpus> Luke-Jr: I do a lot of experimentation
234 2015-01-22 05:26:25 <Luke-Jr> âº
235 2015-01-22 05:26:39 <cfields> it's very functional with clang in my experience. gcc is a bit bumpier
236 2015-01-22 05:26:59 <wumpus> Luke-Jr: I'm certainly not arguing to use it for the gitian builds
237 2015-01-22 05:27:24 <Luke-Jr> ah, that's where I was confused.
238 2015-01-22 05:28:38 <wumpus> if the goal is to reduce the distribution size, there is plenty of low-hanging fruit like ffunction/data-sections, or eh actually sharing actual shared code
239 2015-01-22 05:29:44 <wumpus> cfields: I have the other experience; always crashes in e.g. this gold plugin
240 2015-01-22 05:30:09 <cfields> wumpus: ah, makes sense. most of my testing has been with osx
241 2015-01-22 05:30:34 <wumpus> cfields: but if llvm is developing their own linker, power to them, this interaction with ld has always been a bottleneck
242 2015-01-22 05:30:47 <wumpus> (in buggyness, not so much in performance)
243 2015-01-22 05:30:54 <cfields> yes, it certainly makes sense
244 2015-01-22 08:51:36 <jonasschnelli> does anyone know how travis runs the Win64/Win32 tests? My tests failing there and i'd like to reproduce this. Running the self-compiled tests on a Windows 7 is okay... so i'd like to get the same env. that travis uses.
245 2015-01-22 09:29:45 <wumpus> hmcool, llvm/clang has intrinsics for arithmetic w/ overflow detection
246 2015-01-22 09:29:57 <wumpus> jonasschnelli: wine
247 2015-01-22 09:36:42 <jonasschnelli> wumpus, a yes. Let my try to install it...
248 2015-01-22 09:40:47 <wumpus> (looks like these intrinsics are generated in secp256k1, and used to generate carries for 64+64->128 arithmetic)
249 2015-01-22 10:17:48 <cfields> wumpus: if you're talking about __builtin_addcl(), i tried those when i was working on a native num impl, and sadly didn't see any speedup over detecting myself
250 2015-01-22 10:18:09 <cfields> possible that my bench wasn't accurate enough, though
251 2015-01-22 10:26:02 <wumpus> cfields: I'm not sure what they're called in c; but it appears that it's smart enough to select them itself when you use uint128 arithmetic
252 2015-01-22 10:26:16 <wumpus> so possibly in your case it did just recognize the code as well
253 2015-01-22 10:27:50 <wumpus> but having overflow be an intrinsic is nice from a security viewpoint, it is easier to review and less error prone than hand-rolled overflow detectio
254 2015-01-22 10:29:34 <cfields> wumpus: ah, that explains it. i was comparing adding 2 64bit ints with overflow intrinsics against 128bit adds. given the what you said above, i suppose i did the same thing twice.
255 2015-01-22 10:30:10 <wumpus> yes :-)
256 2015-01-22 11:20:51 <wumpus> jonasschnelli: I'm quite certain the tests do run on linux
257 2015-01-22 11:21:10 <wumpus> jonasschnelli: e.g. in the evhttpd pull I had a travis test failure on linux only
258 2015-01-22 11:34:53 <wumpus> jonasschnelli: I do think the travis output is too spammy and it's hard to find things, e.g. if tests pass they'd ideally give no or only one line of output
259 2015-01-22 11:45:52 <jonasschnelli> wumpus, will final test this this by pushing a failing test...
260 2015-01-22 11:49:00 <wumpus> ok
261 2015-01-22 11:55:53 <jonasschnelli> damn windows!
262 2015-01-22 12:00:29 <jonasschnelli> on window: file size is 6 bytes, i do fwrite(logdb_frameheader_magic, 4, 1, file), after that, my filesize is 16 bytes. Where does these 6 bytes come from?
263 2015-01-22 12:03:31 <fanquake> jonasschnelli line endings being converted possibly?
264 2015-01-22 12:04:02 <jonasschnelli> fanquake, no. i don't think so. I mean it's +6 bytes?
265 2015-01-22 12:05:29 <fanquake> jonasschnelli Add another line to the file and see if it adds another byte?
266 2015-01-22 12:05:53 <jonasschnelli> fanquake, it's binary. I will now do a hex dump
267 2015-01-22 12:17:14 <jonasschnelli> strange: linux: 0000000 cc c4 e6 b0 90 4d , window: 0000000 c4cc b0e6 4d90
268 2015-01-22 12:18:53 <jonasschnelli> nevermind. Hexdump did mix that up.
269 2015-01-22 13:56:21 <akstunt600> Is there any reason why we cant use db4.9+ it fails if i use anything other than db4.8 :-/ I mean it woud be nice if it worked on db5.3
270 2015-01-22 13:58:54 <akstunt600> Making db version more flexible would help a bit for CO/RH/FC linux Are we using anything crazy in bdb?
271 2015-01-22 14:00:11 <wumpus> it works fine with db5.x
272 2015-01-22 14:00:27 <akstunt600> Oh must be just rc3 and the last few i tried
273 2015-01-22 14:00:41 <wumpus> what failure do you get exactly?
274 2015-01-22 14:00:53 <akstunt600> Just the disable wallet functionality one
275 2015-01-22 14:01:04 <wumpus> try --with-incompatible-bdb
276 2015-01-22 14:01:08 <wumpus> on configure
277 2015-01-22 14:01:11 <akstunt600> I am compiling now but i just stepped down to 4.8
278 2015-01-22 14:01:27 <akstunt600> Oh i have done that in the past
279 2015-01-22 14:01:46 <akstunt600> And had a working wallet before on an altcoin, is that typical?
280 2015-01-22 14:01:59 <wumpus> ok, that's the way to compile with a newer bdb, I don't think I've heard any reports ever that another version of bdb didn't work
281 2015-01-22 14:03:13 <akstunt600> Oh just wondering about oder bdb
282 2015-01-22 14:03:30 <akstunt600> like on old centos and fc install that hosting companies often use some are still on 4.6
283 2015-01-22 14:03:34 <akstunt600> and that can be a pain
284 2015-01-22 14:04:00 <akstunt600> So i mean it would be great to maybe just change that msg, especially if it works on 4.6 as well
285 2015-01-22 14:04:50 <akstunt600> I know more than a few people have been scared away by that, thinking waet would not work and such, at least at first.
286 2015-01-22 14:05:17 <wumpus> I doubt it will work with older
287 2015-01-22 14:05:23 <akstunt600> Ahh, cool
288 2015-01-22 14:05:25 <wumpus> it's at your own risk.
289 2015-01-22 14:05:26 <akstunt600> Figured
290 2015-01-22 14:06:27 <akstunt600> I cant remember which version I used where the wallet wasnt working. Its been awhile...
291 2015-01-22 14:06:50 <wumpus> ok, without detailed errors there no way to debug it anymore anyhow
292 2015-01-22 14:08:16 <akstunt600> Yeah, it was old maybe 4.3 or so. Anyway, you see my point right? We should probably make that message a bit more friendly.
293 2015-01-22 14:08:43 <akstunt600> Change it to something like wallet functionality "may" not work
294 2015-01-22 14:10:14 <wumpus> a wallet is not something to play around with, if people get scared by that message that may be just as well
295 2015-01-22 14:12:15 <akstunt600> LOL, it might as well read death too all who select anything other than 4.8 then
296 2015-01-22 14:12:24 <akstunt600> I mean i would get the message better then
297 2015-01-22 14:13:31 <wumpus> ...
298 2015-01-22 14:13:44 <akstunt600> Im just saying your making a silly argument. We should at least say incompatible is pretty strong verbage already we dont need to say anything else. Saying wallet functionality may not work is still much better.
299 2015-01-22 14:14:23 <akstunt600> Oops mistyped part of that.
300 2015-01-22 14:14:54 <akstunt600> Its just the more professional way to do it no?
301 2015-01-22 14:15:01 <wumpus> I'm done arguing this
302 2015-01-22 14:15:10 <akstunt600> me too, lol i was about to say that
303 2015-01-22 14:15:24 <akstunt600> Anyway another node up in test woot
304 2015-01-22 14:15:35 <akstunt600> now back to real work....
305 2015-01-22 15:10:32 <ruukasu> in an rpc response, what's the difference between result['errors'] and error?
306 2015-01-22 15:14:07 <akstunt600> the rpc listener is up and running but the command you sent errored
307 2015-01-22 15:25:12 <hazso> What would be the arguments against when we calculate the new bitcoin difficulty, also calculate the new block size -- and the new block size would always be such that the average tx fee would need to be a constant value, say 100 bits
308 2015-01-22 15:25:46 <hazso> i.e. If people have been paying too much to be included, we increase the block size. If people haven't been paying enough, we decrease it
309 2015-01-22 15:26:18 <jonasschnelli> any preferences between using c++'s fstream or c99 fopen/fwrite?
310 2015-01-22 15:27:05 <lclc> can I make a SIGHASH_ANYONECANPAY tx with a rule that all inputs need to be at least X satoshis?
311 2015-01-22 15:32:02 <akstunt600> hazso, BS doesnt matter its only really to keep spam down.
312 2015-01-22 15:35:11 <wumpus> jonasschnelli: for what?
313 2015-01-22 15:35:24 <jonasschnelli> wumpus, logdb
314 2015-01-22 15:35:50 <wumpus> for a database it makes sense to use low-level posix functions
315 2015-01-22 15:36:05 <jonasschnelli> wumpus, okay, will do that
316 2015-01-22 15:36:11 <wumpus> otherwise there is not enough control over flushing and such
317 2015-01-22 15:36:42 <wumpus> if you were to say you wanted to write a text file I'd recommend using fstream, like dumpwallet
318 2015-01-22 15:37:10 <wumpus> but for a database I think that's not a good idea
319 2015-01-22 15:40:58 <jonasschnelli> wumpus, okay, i just read something about performance, but this is not important in our case.
320 2015-01-22 15:42:43 <wumpus> well for performance the low-level functions give most control too
321 2015-01-22 16:11:28 <jtimon_> what is the last time you saw "AcceptToMemoryPool : free transaction rejected by rate limiter" or even "Rate limit dFreeCount" in your logs? I think that's death code...preparing a PR...
322 2015-01-22 16:12:29 <jtimon_> I believe AcceptToMemoryPool : not enough fees should always trigger first
323 2015-01-22 16:14:02 <jtimon_> nevermind, sorry, I was mistaken
324 2015-01-22 19:28:23 <michagogo> 02:10:43 <Luke-Jr> benjamindees: interplanetary is not really doable with the current blockchain
325 2015-01-22 19:28:32 <michagogo> Well, it's just mining that wouldn't work
326 2015-01-22 19:28:44 <michagogo> (right?)
327 2015-01-22 19:28:57 <Luke-Jr> michagogo: I suppose
328 2015-01-22 19:29:15 <michagogo> 17:27:33 <lclc> can I make a SIGHASH_ANYONECANPAY tx with a rule that all inputs need to be at least X satoshis?
329 2015-01-22 19:29:18 <michagogo> lclc: No, you can't
330 2015-01-22 19:29:40 <michagogo> SIGHASH_ANYONECANPAY removes all hashing (i.e. restrictions) on other inputs
331 2015-01-22 19:30:21 <lclc> ok thanks. I think if found another way for my idea :)
332 2015-01-22 19:31:54 <doop> Am I correct in assuming it should be completely impossible for two valid transactions to have the same inputs?
333 2015-01-22 20:02:11 <michagogo> doop: Yes, ever since block-height-in-coinbase
334 2015-01-22 20:02:49 <michagogo> Or, to clarify: two valid *mined* transactions
335 2015-01-22 20:24:41 <Luke-Jr> michagogo: mined or not
336 2015-01-22 20:24:53 <Luke-Jr> well, within the blockchain..
337 2015-01-22 20:25:11 <michagogo> Luke-Jr: right, that's what I mean
338 2015-01-22 20:25:36 <michagogo> You can have many valid transactions that spend the same inputs, until one of them is mined
339 2015-01-22 20:25:50 <Luke-Jr> ah, right
340 2015-01-22 20:44:44 <zooko`> Are there any other branches related to bipstrictder besides this branch https://github.com/sipa/bitcoin/commits/bipstrictder ?
341 2015-01-22 21:41:27 <Luke-Jr> hum, my USB Armory banned my host
342 2015-01-22 21:41:32 <Luke-Jr> even though I'm using -connect
343 2015-01-22 21:42:07 <Luke-Jr> ⦠and my host shouldn't be doing anything to get banned
344 2015-01-22 21:42:11 <Luke-Jr> 2015-01-22 06:46:45 ERROR: CheckBlock() : hashMerkleRoot mismatch
345 2015-01-22 21:42:39 <Luke-Jr> after 2015-01-22 06:46:45 UpdateTip: new best=000000000000012897da63429d603c448e899ffd02f8c8ce80bbf9036f3af3c9 height=226574 log2_work=69.570622 tx=14585158 date=2013-03-18 15:32:05 progress=0.118813 cache=164923
346 2015-01-22 22:46:34 <zuber> could libsecp256k1 be used to could improve the performance of vanitygen?
347 2015-01-22 23:13:56 <michagogo> zuber: I guess it depends on what the bottleneck is
348 2015-01-22 23:14:09 <michagogo> If it's a secp256k1 operation, then I would guess it probably could
349 2015-01-22 23:19:19 <zuber> michagogo: one of the bottlenecks was mentioned here: https://webcache.googleusercontent.com/search?q=cache:https://bitcointalk.org/index.php%3Ftopic%3D25804.100&strip=1#msg354987
350 2015-01-22 23:20:34 <teward> spinza: your client fixed now?
351 2015-01-22 23:20:37 <zuber> which improves performance by performing a computation on a batch of points instead of 1 by 1. but i have no clue of the math or underlying implementation, so don't know if libsecp256k1 can obviate the need for the batch computation
352 2015-01-22 23:22:37 <michagogo> If it's an EC operation, then libsecp256k1 is probably helpful
353 2015-01-22 23:22:48 <michagogo> Or rather, would be
354 2015-01-22 23:22:53 <michagogo> But that's a very old post