1 2014-12-01 05:53:57 <erasmospunk> Checkout the new version of the Coinomi Universal Wallet - http://coinomi.com/
2 2014-12-01 09:00:07 <smokeyfires> test
3 2014-12-01 09:06:07 <sipa> test failed
4 2014-12-01 09:07:09 <phantomcircuit> ha
5 2014-12-01 09:09:45 <wumpus> please use the testnet channel for testing, not the mainnet development channel ;)
6 2014-12-01 09:16:12 <JackH> lol
7 2014-12-01 12:35:04 <Luke-Jr> blah, the prioritisetransaction RPC interface is being changed? -.-
8 2014-12-01 13:10:20 <wumpus> hm? where?
9 2014-12-01 13:11:08 <Luke-Jr> wumpus: back in July. you poked me, but I missed it
10 2014-12-01 13:11:29 <Luke-Jr> ebdcc360b65816f7ad7cdedce6a1114d5e014b7b
11 2014-12-01 13:11:53 <wumpus> calling something that happened in july 'is being changed' is kind of a far stretch
12 2014-12-01 13:13:03 <Luke-Jr> wumpus: well, changed from what it's been since 2012 :P
13 2014-12-01 13:13:11 <wumpus> using AmountFromValue makes sense though
14 2014-12-01 13:13:31 <wumpus> if you want satoshis there, change AmountFromValue to use satoshis everywhere...
15 2014-12-01 13:13:34 <Luke-Jr> perhaps, but it's not what's in use
16 2014-12-01 13:13:40 <Luke-Jr> we should.
17 2014-12-01 13:14:13 <wumpus> I had a pull making that configurable once, but no one cared
18 2014-12-01 13:14:41 <wumpus> anyhow, for sake of consistency it's not going to be changed back, it is not in any releases yet so changing the interface is fine
19 2014-12-01 13:14:56 <Luke-Jr> wumpus: it's in releases, just not Bitcoin Core ones
20 2014-12-01 13:15:00 <Luke-Jr> since v0.6.1
21 2014-12-01 13:15:06 <wumpus> bitcoin core releases are all we care about
22 2014-12-01 13:15:25 <Luke-Jr> that kind of attitude is extremely hostile to open development IMO
23 2014-12-01 13:15:59 <wumpus> anyhow I highlighted you there back then to ask even
24 2014-12-01 13:16:00 <Luke-Jr> "all that matters is one official branch, and we'll break compatibility with other branches even if they've been in use for 2 years"
25 2014-12-01 13:16:05 <wumpus> it's too late now
26 2014-12-01 13:16:06 <Luke-Jr> yes, I missed that. sorry.
27 2014-12-01 13:16:11 <Luke-Jr> why?
28 2014-12-01 13:16:19 <sipa> Luke-Jr: how many people use prioritizetransaction>
29 2014-12-01 13:16:21 <Luke-Jr> nothing has been released with the incompatible change yet
30 2014-12-01 13:16:27 <Luke-Jr> sipa: no idea
31 2014-12-01 13:16:35 <sipa> i'm sure you do
32 2014-12-01 13:16:40 <Luke-Jr> indeed
33 2014-12-01 13:17:22 <kinlo> there are not that many ppl that can actually use it
34 2014-12-01 13:17:28 <kinlo> 5 pools, that's it?
35 2014-12-01 13:17:46 <kinlo> my transactions are confirmed way before my pool finds a block, so no need to use prioritize :)
36 2014-12-01 13:18:12 <Luke-Jr> that's a point
37 2014-12-01 13:19:06 <Luke-Jr> wumpus: re changing it everywhere: every time that comes up, I think we conclude we should just break the interface, but nobody wants to put effort into every change we want to make at once, so it never happens :p
38 2014-12-01 13:19:22 <wumpus> Luke-Jr: what, I had actual code that did it
39 2014-12-01 13:19:34 <Luke-Jr> wumpus: breaking compatibility rather than an option, I mean
40 2014-12-01 13:19:59 <Luke-Jr> various people have had code to do it since 2011ish I think
41 2014-12-01 13:20:03 <Luke-Jr> maybe genjix's was 2010 even
42 2014-12-01 13:20:11 <Luke-Jr> but there are other RPC changes people want at the same time
43 2014-12-01 13:20:11 <wumpus> well having an option would be the first step, later the default could change, and even later the option could go away again
44 2014-12-01 13:20:29 <wumpus> but even the first step is not going to happen, it just doesn't have priority
45 2014-12-01 13:20:36 <Luke-Jr> sure, seems this might be a case of "perfect is enemy of the good"
46 2014-12-01 13:20:42 <wumpus> right
47 2014-12-01 13:20:46 <sipa> the only way that will happen is by doing RPCv2
48 2014-12-01 13:20:51 <wumpus> I don't care about it anymore
49 2014-12-01 13:20:55 <sipa> neither do i
50 2014-12-01 13:20:56 <wumpus> lots of other things that do matter
51 2014-12-01 13:21:25 <wumpus> without the wallet the number of RPC calls with monetary amounts would drop to almost zero anyhow
52 2014-12-01 13:21:44 <wumpus> (though prioritisetransaction would stay...)
53 2014-12-01 13:21:45 <Luke-Jr> anyhow, just seems a shame to be making releases for 4 years now, and have the main branch release an incompatible version of it; but as kinlo points out, not many people can possibly be using it
54 2014-12-01 13:22:09 <Luke-Jr> wumpus: that might be an argument for doing prioritise in satoshis - rather than having it change twice
55 2014-12-01 13:22:18 <wumpus> sigh...
56 2014-12-01 13:22:37 <Luke-Jr> are there any other BTC-value RPCs that don't go away when wallet does?
57 2014-12-01 13:22:56 <wumpus> that's always when you submit code upstream, you can't count on interfaces staying the same
58 2014-12-01 13:23:11 <wumpus> e.g. try adding a syscall to the linux kernel
59 2014-12-01 13:23:37 <Luke-Jr> wumpus: Linux's development model is very centralised in this regard. I don't think it makes a good example to follow if we want a decentralised ecosystem.
60 2014-12-01 13:23:39 <wumpus> other people will have opinions on things before they are merged
61 2014-12-01 13:24:21 <Luke-Jr> wumpus: people didn't have an opinion to change this for the 2 years
62 2014-12-01 13:24:25 <wumpus> I also don't like how prioritisetransaction took that long to get merged, but that's another issue
63 2014-12-01 13:24:41 <wumpus> why didn't *all those users* ever comment on the issue?
64 2014-12-01 13:25:22 <Luke-Jr> yeah, kinlo's point that not many can use it is strong - but then the point that we're likely to change it back at some future time seems to go for satoshis again :p
65 2014-12-01 13:25:37 <sipa> why would we ever want to change it back?
66 2014-12-01 13:25:48 <gmaxwell> because they're getting patches from luke instead of reading github. but... in any case, thats the cost of out of master patches, stuff may change if merged.
67 2014-12-01 13:25:48 <sipa> yes, when and if the RPC as a whole gets overhauled, sure
68 2014-12-01 13:25:54 <Luke-Jr> sipa: with wallet gone, it's the only thing left usign BTC now?
69 2014-12-01 13:26:11 <gmaxwell> I agree I'd rather everything be base units; ... but alas, it's not, and having a single call using them would likely trip up people more than the other way around.
70 2014-12-01 13:26:34 <wumpus> Luke-Jr: no it's not... the transaction parsing json etc also uses amounts
71 2014-12-01 13:26:38 <Luke-Jr> (other mining calls also use satoshis)
72 2014-12-01 13:26:46 <sipa> oh?
73 2014-12-01 13:27:11 <Luke-Jr> such as GBT
74 2014-12-01 13:27:34 <sipa> hmm, that's an argument in favor actually
75 2014-12-01 13:28:07 <sipa> if it's already inconsistant, keep it closer to whatever interface are likely more used together
76 2014-12-01 13:28:17 <gmaxwell> since its the txlist that gbt gives you that your prioritizing relative to? I suppose that does make sene.
77 2014-12-01 13:29:38 <wumpus> AmountFromValue is used 2 times in non-wallet RPC code, ValueFromAmount 10 times, mostly for fee-related things
78 2014-12-01 13:32:54 <Luke-Jr> anyhow, I think we've now covered every angle to this.. so the only question is what the consensus is for 0.10; I think overall, leaving it satoshis is best - but since few use it, it's not a huge deal if we change it (unless we then change it back later, when more people will hopefully use it)
79 2014-12-01 13:34:56 <wumpus> ...so, does AmountFromValue even work for negative values?
80 2014-12-01 13:37:48 <Luke-Jr> lol, good question >_<
81 2014-12-01 13:37:51 <wumpus> another reason it took so long to merge prioritisetransaction is that it has no tests
82 2014-12-01 13:37:59 <Luke-Jr> I don't think it can
83 2014-12-01 13:38:00 <wumpus> so no one noticed it doesn't work.
84 2014-12-01 13:38:09 <Luke-Jr> wumpus: it did as merged ;)
85 2014-12-01 13:38:09 <wumpus> (well, at least for half the cases)
86 2014-12-01 13:38:43 <Luke-Jr> so yeah, if we keep it BTC, we need to at least fix that >_<
87 2014-12-01 13:39:29 <gmaxwell> if we'd change it back, we'd change everything. or have some other mode or something.. so I'm not worried there.
88 2014-12-01 13:41:33 <Luke-Jr> gmaxwell: ?
89 2014-12-01 13:41:48 <Luke-Jr> nm, got it
90 2014-12-01 13:42:51 <wumpus> well I think making the RPC call work again is a good reason to merge #5398
91 2014-12-01 13:43:28 <wumpus> although it still really needs tests...
92 2014-12-01 13:46:32 <Luke-Jr> it would fit in nicely with CreateNewBlock_validity which already generates transactions, but.. it's RPC :/
93 2014-12-01 13:46:54 <Luke-Jr> I suppose we can test the internal interface there, but that won't catch bugs like this one\
94 2014-12-01 13:46:55 <wumpus> it would need an rpc test in qa/rpc-tests
95 2014-12-01 13:47:32 <wumpus> sure, testing the internal interface in unit tests also doesn't hurt, although as you say it wouldn't have caught this
96 2014-12-01 13:47:51 <Luke-Jr> it would need to have validly spendable coins, is the issue
97 2014-12-01 13:48:09 <wumpus> that's easy in a rpc test
98 2014-12-01 13:48:37 <wumpus> less so in a unit test
99 2014-12-01 13:48:38 <sipa> the RPC tests already have code for that
100 2014-12-01 13:49:24 <wumpus> yes
101 2014-12-01 13:49:33 <Luke-Jr> ah
102 2014-12-01 14:00:48 <wumpus> right, there are plenty of things that require spendable coins for testing
103 2014-12-01 14:09:02 <Luke-Jr> wumpus: this look okay? // NOTE: Unlike wallet RPC (which use BTC values), mining RPCs follow GBT (BIP 22) in using satoshi amounts
104 2014-12-01 14:17:56 <wumpus> Luke-Jr: sure
105 2014-12-01 14:18:18 <Luke-Jr> k, pushed
106 2014-12-01 14:19:32 <sipa> wumpus: after secp256k1 #119 is merged, i'll PR the changes into bitcoin, ok? (which should make gmp optional)
107 2014-12-01 14:21:01 <wumpus> sipa: sounds good; we should then also update doc/build-unix.md again to move it to the optional dependencies
108 2014-12-01 14:21:42 <sipa> after a few more changes, i also think the difference between using and not using gmp (for verification) should be less than 30-40% ish in performance
109 2014-12-01 14:22:02 <sipa> so it's very reasonable to just never use the gmp version inside bitcoin
110 2014-12-01 14:22:41 <sipa> (no dependencies in consensus code is probably even worth a 30% performance cost)
111 2014-12-01 14:24:37 <wumpus> indeed, I suppose so, and it's just the initial drop, I suppose people will optimize secp256k1 further over time
112 2014-12-01 14:25:38 <wumpus> it's still plenty faster than openssl based verification :)
113 2014-12-01 14:53:01 <jgarzik> sipa, hum, I don't see https://github.com/sipa/secp256k1/issues/119
114 2014-12-01 14:53:14 <jgarzik> link to "secp256k1 #119"?
115 2014-12-01 15:05:07 <wumpus> https://github.com/bitcoin/secp256k1/pull/119/files
116 2014-12-01 15:15:32 <sipa> jgarzik: as wumpus says, master repo is bitcoin/secp256k1
117 2014-12-01 15:19:48 <jgarzik> wumpus, sipa: whoops, cut-n-paste error indeed
118 2014-12-01 16:43:39 <gavinandresen> FYI to anybody having trouble with qa/rpc-tests #!/usr/bin/env python2 on OSX: brew install python will install a /usr/local/bin/python2 symlink.
119 2014-12-01 17:29:56 <hearn> gavinandresen: i noticed a lot of blocks are topping out at 731kb - that's pretty much what we'd expect from hitting the 750k soft limit, right?
120 2014-12-01 17:30:02 <hearn> gavinandresen: maybe it's time to bump soft limit == hard limit
121 2014-12-01 17:30:50 <gavinandresen> hearn: yup
122 2014-12-01 17:31:37 <Luke-Jr> hearn: so talk to miners.. are we really hitting 750 kB of non-spam, or is it just miners neglecting to filter spam that are hitting it?
123 2014-12-01 17:31:55 <Jouke> yes
124 2014-12-01 17:33:41 <hearn> setting aside for one moment the never-ending argument over what "spam" is, in block 332459 which was 731kb, i see only one transaction with a "dice" labelled address on blockchain.info
125 2014-12-01 17:34:05 <Luke-Jr> hmm, looks like Eligius's most recent 2 blocks were >900k, but previous 6 were much smaller
126 2014-12-01 17:34:09 <hearn> if dice sites are still popular, then they must have switched addresses
127 2014-12-01 17:34:27 <hearn> well it's very dependent on the spacings between them
128 2014-12-01 17:34:41 <hearn> if we go 20-30 minutes with no block the next one should be full because it's going to try and stuff several blocks worth of traffic into a single block
129 2014-12-01 17:34:53 <hearn> a block that comes 60 seconds after the previous can be tiny. avg block size is only about 350kb according to b.i
130 2014-12-01 17:35:15 <hearn> however, it's not healthy to have blockages piling up because of natural variance, i think
131 2014-12-01 17:35:15 <Luke-Jr> wtf @ a bunch of 0 BTC transactions
132 2014-12-01 17:35:49 <Luke-Jr> https://blockchain.info/tx/d517a40dcae12011aea3b61c764784e6b5fb00c7c48a7b9783c8c5cd9311e956?show_adv=true looks like spam of a new style?
133 2014-12-01 17:36:39 <hearn> looks like someone is timestamping a document
134 2014-12-01 17:36:53 <Luke-Jr> http://www.proofofexistence.com/about yeah
135 2014-12-01 17:37:07 <Luke-Jr> except.. a lot of them
136 2014-12-01 17:39:46 <hearn> well, depends how you define a lot. in that block (332450) there are only a handful of "unable to decode output address" transactions in b.i's view, but it was 882kb
137 2014-12-01 17:39:54 <hearn> the block would have been about the same size even without them
138 2014-12-01 17:40:51 <Luke-Jr> yeah, looks like more LuckyBit spam than PoE spam there - but probably still over 750 kB even without them I guess
139 2014-12-01 17:40:55 <hearn> this is a good reminder that ye olde "7 transactions per second" limit is kind of handwavy and bogus because we'd start to encounter really unpredictable confirmation delays long before reaching that traffic level
140 2014-12-01 17:41:05 <hearn> just due to the variance
141 2014-12-01 17:41:27 <gavinandresen> hearn: yup
142 2014-12-01 17:42:19 <Luke-Jr> too bad it'd totally screw up miner incentives (I think) to scale block size based on time since previous
143 2014-12-01 17:42:38 <hearn> hmm. would it?
144 2014-12-01 17:42:54 <Luke-Jr> hearn: well, miners could suddenly start timestamping +2h just to get more fees
145 2014-12-01 17:43:08 <hearn> oh, i thought you meant scaling soft block size
146 2014-12-01 17:43:34 <Luke-Jr> I suppose that would make sense to do.. but not sure it's worth it if we're getting close to max anyway
147 2014-12-01 17:43:58 <dgenr8> really unpredictable confirmation delays are pretty much built in )
148 2014-12-01 17:44:09 <hearn> i guess there are two max limits. there's the theoretical limit at 7 tx/sec where we basically are redlining the system and it'd fall over, because if there was ever even a single spurt beyond capacity the network would fall behind and never be able to catch up
149 2014-12-01 17:44:34 <hearn> and then there's the practical limit at which people start complaining and abandoning the system because confirmations become so unpredictable that it's hard to do business
150 2014-12-01 17:45:04 <hearn> not sure where that latter limit might be. could be anywhere i suppose
151 2014-12-01 17:45:51 <hearn> gavinandresen: think it's too late to get such a change into 0.10? i mean set soft block size == 1mb, to tide us through the winter growth period
152 2014-12-01 17:46:31 <Luke-Jr> ACTION ughs at further pressing the idea of developers determining miner policy
153 2014-12-01 17:47:15 <gavinandresen> hearn: good question for wumpus, heâs driving the 0.10 release.
154 2014-12-01 17:48:40 <hearn> Luke-Jr: block size should really be automatically decided anyway. it always makes sense to maximise your block size up to some level of orphaning at which point the extra fees don't offset the money lost to orphans -this is the sort of calculation software is good at and humans kind of suck at. so eventually i hope it'll be automated.
155 2014-12-01 17:51:25 <Luke-Jr> that's true, max block size would be irrelevant if we were weighing things like that
156 2014-12-01 17:55:05 <Luke-Jr> still, in the meantime, better to have people with blogs lart miners if transactions get slow, rather than trying to maintain some constants in the software ;)
157 2014-12-01 17:58:02 <hearn> sigh. i hate gpgtools. just managed to encrypt a message i was trying to send, to myself instead of the recipient. fail.
158 2014-12-01 18:02:37 <Luke-Jr> >_<
159 2014-12-01 18:07:33 <wumpus> hearn: well I suppose the code has been tested well enough with big blocks by now, so the regression risk isn't that high
160 2014-12-01 18:07:56 <hearn> right. there are quite a lot of blocks near to 1mb
161 2014-12-01 18:11:18 <wumpus> I'm fine with it, although I wonder how many miners are still using the default soft maximum
162 2014-12-01 18:11:36 <sipa> or are using a recent bitcoin core release at all...
163 2014-12-01 18:12:34 <hearn> well, the number of blocks that top out at exactly the Core default limit suggests quite a few are
164 2014-12-01 18:12:48 <hearn> you can just browse https://www.biteasy.com/blockchain/blocks and look for 732kb
165 2014-12-01 18:13:06 <hearn> there are other clusters corresponding to previous releases soft limits
166 2014-12-01 18:13:10 <sipa> right, but that default limit has been in place for a long time
167 2014-12-01 18:13:14 <sipa> no?
168 2014-12-01 18:13:43 <hearn> i don't think so? the 750kb bump was somewhat recent, i think. before that it was 350kb and then 250kb. unless my memory is faulty
169 2014-12-01 18:13:44 <sipa> anyway, hopefully 0.10 is sufficiently more efficient that they will wan tto upgrade
170 2014-12-01 18:13:47 <hearn> right
171 2014-12-01 18:14:10 <sipa> (not that i agree that bitcoin core default limit should be what drives the network, but it's probably inevitable)
172 2014-12-01 18:15:03 <Luke-Jr> we should be discouraging miners from using the defaults, not changing them IMO
173 2014-12-01 18:15:54 <Luke-Jr> (says the hypocrite who recently had a default-policy-change PR..) :p
174 2014-12-01 18:23:49 <hearn> In the long run there should be virtually nothing for miners to configure, because miners should have virtually no information on which to discriminate between transactions and every policy decision left would have a clearly correct, automatically calculable answer. In the short run, guesstimation in the code doesn't seem too horrible a compromise. Leaving things to randomly drift though - not great.
175 2014-12-01 18:37:17 <wumpus> Luke-Jr: yes, disabling bare multisig is more controversial than bumping the block size default
176 2014-12-01 18:37:26 <Luke-Jr> hearn: you're ignoring out-of-band information, such as from partners who subscribe to priority services\
177 2014-12-01 18:38:00 <Luke-Jr> wumpus: that doesn't seem obvious since everyone seemed in agreement with the former
178 2014-12-01 18:38:19 <wumpus> there's almost no argument *against* increasing the soft limit
179 2014-12-01 18:38:35 <sipa> Luke-Jr: everyone who commented was personally in favor, but at least I doubt whether nobody who didn't comment wouldn't be against
180 2014-12-01 18:38:37 <Luke-Jr> except miners that neglect to filter spam end up putting more in as a result
181 2014-12-01 18:38:42 <Luke-Jr> which are the same miners who run defaults
182 2014-12-01 18:39:30 <Luke-Jr> it also encourages miners to run with defaults, if defaults get changed like that
183 2014-12-01 18:40:07 <sipa> i wouldn't be against disabling GBT etc without configuring some variables
184 2014-12-01 18:40:49 <sipa> But i'm not sure whether that would actually result in miners deciding sanely...
185 2014-12-01 18:41:10 <Luke-Jr> sipa: I think that PR got closed, but I could rebase it if wanted
186 2014-12-01 18:41:38 <hearn> it's a philosophical point. does decentralisation mean people *have* to make decisions about the minutiae? or merely that they can, if they want to
187 2014-12-01 18:41:53 <hearn> i would say the latter. the former gets you australia's "vote or you get whacked" system :)
188 2014-12-01 18:42:06 <Luke-Jr> hearn: someone always *has* to.
189 2014-12-01 18:42:10 <sipa> hearn: well, *I* don't want to be deciding about the network policy
190 2014-12-01 18:42:19 <Luke-Jr> in this case, that someone should be the miner, NOT some third-party developer
191 2014-12-01 18:42:23 <sipa> though I would like people to listen to my opinion about it :)
192 2014-12-01 18:42:35 <hearn> is it a decision, if anyone who disagrees can override it?
193 2014-12-01 18:42:45 <sipa> but defaults are powerful
194 2014-12-01 18:43:03 <sipa> you may argue that core maintainers are not in charge of network policy, because anyone can override it
195 2014-12-01 18:43:05 <hearn> yeah, because in good software they're normally sanely chosen by people who know what they're doing :)
196 2014-12-01 18:43:10 <wumpus> well the drawback of forcing people to make decisions before it works is that they may fill in nonsense values just to get rid of the choice
197 2014-12-01 18:43:26 <hearn> i've always been a fan of delegated voting systems (for countries). the idea is, everything that goes before parliament is a referendum. but because that's impractical - nobody wants to vote on everything a country does - you can optionally delegate your votes by category.
198 2014-12-01 18:43:34 <Luke-Jr> wumpus: at least it stops neglegent miners from simply passing the responsibility on
199 2014-12-01 18:43:35 <hearn> the delegation heirarchy forms a tree.
200 2014-12-01 18:43:43 <hearn> you can override your delegation and vote directly at any time.
201 2014-12-01 18:43:48 <hearn> but, you don't *have* to. that's what makes it scale.
202 2014-12-01 18:44:03 <wumpus> voting makes very little sense for difficult technical decisions
203 2014-12-01 18:44:34 <hearn> the issue is not voting. technical committees resolve things by voting all the time, when there's disagreement. the issue is voting when you don't understand or don't care about the outcome. that's clearly suboptimal
204 2014-12-01 18:44:55 <hearn> delegated voting represents a pragmatic ideal - vote if you want to, delegate to someone else if you aren't sure you know how, or don't care.
205 2014-12-01 18:45:03 <hearn> which is effectively what overridable sane defaults in software do
206 2014-12-01 18:45:26 <Luke-Jr> another option is random defaults within sane ranges
207 2014-12-01 18:45:43 <wumpus> it turns things into a popularity show, and people that don't understand the compromise choose what is desirable instead of what is realistic
208 2014-12-01 18:46:16 <wumpus> Luke-Jr: what would be the use of a random block limit?
209 2014-12-01 18:46:49 <sipa> encouraging overriding the limit, i guess
210 2014-12-01 18:46:51 <Luke-Jr> wumpus: so miners have a reason to set something, and can't just simply defer to developers
211 2014-12-01 18:47:02 <wumpus> I guess randomness is useful if there is an advantage to having diverse configurations
212 2014-12-01 18:47:22 <Luke-Jr> wumpus: eg, trying to discourage the "not using defaults is bad for bitcoin" mindset
213 2014-12-01 18:47:54 <wumpus> Luke-Jr: right
214 2014-12-01 18:47:57 <hearn> what's wrong with that mindset? there are clearly values for various default settings that make sense
215 2014-12-01 18:48:19 <hearn> do you want to stop bitcoind starting up until someone configures a max number of connections?
216 2014-12-01 18:48:19 <sipa> hearn: one argument against that is that bitcoin core releases don't keep up with the network
217 2014-12-01 18:48:45 <sipa> the network is a changing environment, and it may be more optimal if people reevaluate the policy they're committing too, more frequently then we're doing releases
218 2014-12-01 18:49:02 <sipa> because it shouldn't be our job; perhaps it should be the community's job (which we're part of)
219 2014-12-01 18:49:09 <wumpus> sipa: indeed
220 2014-12-01 18:49:22 <hearn> sipa: sure, but people hardly do better. besides, requiring everyone to be an expert in a thousand settings in order to run a node can't really help decentralisation. you just end up with a tiny p2p network of people who are either experts, or just very opinionated. that's why i'd like to see everything be automatic one day.
221 2014-12-01 18:49:47 <sipa> hearn: i understand; which is also my hesitation; it may just result in much less informed decisions overall
222 2014-12-01 18:50:11 <wumpus> the thing is that there is very little incentive for miners to tweak settings, it's not like it substantially increases profits
223 2014-12-01 18:50:18 <Luke-Jr> hearn: for example, you have people like petertodd who threaten to would-testify in court against Eligius if we don't confirm the same transaction "everyone else" does.
224 2014-12-01 18:50:33 <Luke-Jr> trying to imply we are responsible for the transactions mined
225 2014-12-01 18:50:35 <wumpus> (though the blocksize does have an impact there, more fees)
226 2014-12-01 18:50:50 <hearn> hah, he did huh
227 2014-12-01 18:51:02 <Luke-Jr> hearn: no, it hasn't come up. he implied he would, if it did.
228 2014-12-01 18:51:15 <hearn> right
229 2014-12-01 18:51:30 <hearn> perhaps it's easier to think about other settings that aren't block related. the issue of defaults is general.
230 2014-12-01 18:51:34 <hearn> e.g. max connections
231 2014-12-01 18:51:51 <Luke-Jr> those aren't the same sensitivity
232 2014-12-01 18:51:59 <wumpus> those are not controversial at all
233 2014-12-01 18:52:02 <Luke-Jr> if you neglect to configure max connections, it only affects you
234 2014-12-01 18:52:02 <wumpus> indeed Luke-Jr
235 2014-12-01 18:52:26 <wumpus> well max *outgoing* connections is
236 2014-12-01 18:52:35 <hearn> right. it affects other apps on the network.
237 2014-12-01 18:52:40 <hearn> i meant "max total slots available"
238 2014-12-01 18:53:08 <hearn> the right answer is basically always some function of RAM available for the node (which may be limited below total RAM because the user wants some to play games or whatever)
239 2014-12-01 18:53:38 <hearn> but trying to make users pick that and configure it themselves isn't quite right. letting people configure RAM limits is. but forcing people to specify how much RAM to use .... that's MacOS 9 territory.
240 2014-12-01 18:53:41 <Luke-Jr> and routers in between
241 2014-12-01 18:53:50 <Luke-Jr> and maybe IP filters if the user doesn't want to talk to some other node(s)
242 2014-12-01 18:54:09 <Luke-Jr> hearn: again, if the user has these things wrong, it only affects them
243 2014-12-01 18:54:11 <Luke-Jr> not everyone else
244 2014-12-01 18:54:19 <wumpus> yes, many consumer routers get messed up with too many connections
245 2014-12-01 18:54:28 <sipa> if everyone suddenly would only make 1 outgoing connection, the network *would* have a problem
246 2014-12-01 18:54:42 <sipa> if everyone decreases it to 4, or increases it to 12... less sure
247 2014-12-01 18:54:54 <sipa> i think there's a reasonably wide range within which it probably doesn't matter all that much
248 2014-12-01 18:55:05 <wumpus> indeed
249 2014-12-01 18:55:24 <sipa> but miners are in a privileged position, where the poilicy they select affects the whole network, outside of people's choice
250 2014-12-01 18:55:44 <sipa> so i do think that treating them differently may be acceptable
251 2014-12-01 18:56:02 <sipa> still not sure about the give-reasonable-defaults vs force-people-to-choose-them
252 2014-12-01 18:56:25 <Luke-Jr> ACTION wonders if we need to think more on CVE-2013-2292 at some point
253 2014-12-01 18:57:57 <wumpus> hearn: for the case of networking easiest would be to offer different network profiles, ie have a setting for typical home dsl, for typical vps, etc, like in some torrent clients
254 2014-12-01 18:58:15 <hearn> you mean for max conn slots?
255 2014-12-01 18:58:15 <sipa> that makes sense
256 2014-12-01 18:58:18 <gavinandresen> speaking of denial of service attacks⦠the Foundation is now paying Sergio to work part-time on reviewing changes, etc.
257 2014-12-01 18:58:19 <wumpus> hearn: this would automatically select defaults for the number of connections, bandwidth limits, etc
258 2014-12-01 18:58:30 <hearn> gavinandresen: that's good news
259 2014-12-01 18:58:30 <Luke-Jr> reasonable-but-uncomfortable defaults have the potential to improve awareness of miners needing to decide policy
260 2014-12-01 18:58:32 <sipa> gavinandresen: ah, is Sergio the secret new hire?
261 2014-12-01 18:58:37 <wumpus> gavinandresen: yup good news
262 2014-12-01 18:58:48 <hearn> wumpus: limiting fact in conn slots is RAM rather than bandwidth, i think
263 2014-12-01 18:58:52 <gavinandresen> sipa: yes, contract signed in the last day or so.
264 2014-12-01 18:58:53 <Luke-Jr> gavinandresen: great news
265 2014-12-01 18:59:02 <sipa> gavinandresen: awesome!
266 2014-12-01 18:59:14 <wumpus> hearn: oh possibly, but that shouldn't be the case
267 2014-12-01 18:59:16 <hearn> will he be coding as well?
268 2014-12-01 19:00:06 <gavinandresen> hearn: yes, he should have more time to both find and help fix issues he finds.
269 2014-12-01 19:00:33 <hearn> that's good
270 2014-12-01 19:03:51 <hearn> i hope he can work on a resource scheduling/limiter architecture
271 2014-12-01 19:04:28 <gavinandresen> I donât think Sergio is the right person for that job, but Iâd be very happy to be wrong abou that.
272 2014-12-01 19:08:52 <sipa> so... all libsecp256k1 pull requests together result in verification performance 5.7x that of openssl l, without runtime dependencies
273 2014-12-01 19:09:16 <sipa> with GMP it's 7.3x
274 2014-12-01 19:10:02 <HM> now make it run on 32 cores
275 2014-12-01 19:10:53 <sipa> thV
276 2014-12-01 19:11:21 <sipa> zAazd
277 2014-12-01 19:12:48 <hearn> sipa's keyboard encountered a 32-way data race
278 2014-12-01 19:14:38 <sipa> nope,.forgot to lock my phone while putting it in my pocket
279 2014-12-01 19:18:52 <hearn> missing locks! see, i was right after all
280 2014-12-01 19:23:54 <sipa> ha
281 2014-12-01 22:00:03 <sipa> Travis is down?
282 2014-12-01 22:03:41 <lechuga_> looks like it
283 2014-12-01 22:52:44 <jtimon> am I missing something obvious about overflows or something here? https://github.com/jtimon/bitcoin/compare/checkinputs
284 2014-12-01 22:52:54 <jtimon> Is it possible for nValueIn - tx.GetValueOut() < 0 to be false after nValueIn < tx.GetValueOut() being true?
285 2014-12-01 23:13:16 <gmaxwell> jtimon: you're not longer accumulating nFees?
286 2014-12-01 23:15:18 <jtimon> nFees and nTxFee are in the same context, nobody else's uses nFees within checkinputs, there was no accumulation
287 2014-12-01 23:15:47 <jtimon> that's the first commit
288 2014-12-01 23:21:43 <jtimon> I'm assuming that and the second one are correct, really asking about the last one
289 2014-12-01 23:26:38 <gmaxwell> I don't see how it could be unless CAmounts were something far stranger than an integer.
290 2014-12-01 23:30:07 <jtimon> thank yo I'll create a PR
291 2014-12-01 23:30:46 <sipa> gmaxwell: i want a sidechain with amounts that are quaternions
292 2014-12-01 23:37:10 <lechuga_> isn't that what ethers are measured in
293 2014-12-01 23:38:45 <gmaxwell> sipa: issued assets with vector valued outputs? "you added a sparse matrix library to the consensus code?!?"
294 2014-12-01 23:38:59 <gmaxwell> lechuga_: well I suppose it's all imaginary numbers.
295 2014-12-01 23:39:10 <lechuga_> lol
296 2014-12-01 23:39:46 <sipa> aren't there any ethereal or surreal numbers?
297 2014-12-01 23:46:35 <jtimon> #5402 done
298 2014-12-01 23:53:16 <michagogo> Erm, wtf is up with travis?
299 2014-12-01 23:53:25 <michagogo> Chrome says This webpage is not available
300 2014-12-01 23:53:28 <michagogo> ...
301 2014-12-01 23:53:29 <michagogo> Error code: DNS_PROBE_FINISHED_NXDOMAIN
302 2014-12-01 23:54:11 <sipa> dns resolver issues
303 2014-12-01 23:55:47 <michagogo> ...their Twitter account links to http://status.travis-ci.com/incidents/0z5p05dnfn58
304 2014-12-01 23:55:53 <michagogo> ...which has the same problem, apparently