1 2014-12-17 00:24:47 <average> do you remember when I was here last time ?
2 2014-12-17 00:24:58 <average> and I asked "hey, give me a reading list about bitcoin development"
3 2014-12-17 00:25:26 <average> and you just told me "read the bitcoin developer guide" ?
4 2014-12-17 00:25:42 <lechuga_> wat happens if we say yes
5 2014-12-17 00:25:52 <average> lechuga_: you would be right if you said yes
6 2014-12-17 00:26:05 <lechuga_> then yes
7 2014-12-17 00:26:17 <average> https://github.com/jashmenn/bitcoin-reading-list
8 2014-12-17 00:26:23 <average> I found this in teh meantime ^^
9 2014-12-17 00:26:37 <lechuga_> ah thats cool
10 2014-12-17 00:26:41 <gmaxwell> Glad to know you don't take advice after asking for it them, I guess? :)
11 2014-12-17 00:26:59 <average> gmaxwell: oh I did take the advice and I really appreciated it then and I appreciate it now
12 2014-12-17 00:27:13 <average> but I found something more vast and more complete, so I thought I'd come back and share :)
13 2014-12-17 00:27:16 <gmaxwell> Oh good!
14 2014-12-17 00:28:12 <gmaxwell> hey that list has things I'd recommend on it. (this is high remarks, most lists of bitcoin information I've seen has had basically 0 overlap with what I'd suggest).
15 2014-12-17 00:28:53 <average> :)
16 2014-12-17 00:29:53 <sipa> average: i believe i was the one pointing you to the dev guide; good to know there's something else i should be pointing people to too :)
17 2014-12-17 00:30:47 <gmaxwell> apparently some around here knew about it already, https://github.com/TheBlueMatt/bitcoinninja/pull/10
18 2014-12-17 00:37:06 <proserpine-> average: wow thanks for that, really helpful
19 2014-12-17 00:59:23 <Luke-Jr> if I forget to address Sergio's comments on prioritise, feel free to pester/remind me
20 2014-12-17 01:01:19 <lechuga_> hmm i dont use 'pester' enough
21 2014-12-17 02:01:03 <sand3r> hi
22 2014-12-17 02:01:06 <sand3r> bitcoind getinfo
23 2014-12-17 02:01:08 <sand3r> terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid
24 2014-12-17 02:01:11 <sand3r> Aborted
25 2014-12-17 02:01:14 <sand3r> why this error? :/
26 2014-12-17 02:12:38 <BlueMatt> sand3r: uhhh....thats...strange
27 2014-12-17 02:12:58 <BlueMatt> looks like your C_ALL/system locale is some strange value?
28 2014-12-17 02:13:02 <gwillen> BlueMatt: some discussion in #bitcoin
29 2014-12-17 02:13:09 <BlueMatt> nvm
30 2014-12-17 02:13:13 <gwillen> (it does seem like his system locales are messed up)
31 2014-12-17 02:13:22 <BlueMatt> yup
32 2014-12-17 02:19:26 <sand3r> BlueMatt:
33 2014-12-17 02:19:28 <sand3r> dpkg-reconfigure locales
34 2014-12-17 02:19:37 <BlueMatt> sand3r: please continue on #bitcoin
35 2014-12-17 02:19:40 <sand3r> fixed this. now its working :)
36 2014-12-17 02:19:58 <BlueMatt> ahh, ok, good
37 2014-12-17 03:13:02 <duuude> hi. I have a question on the original C++ code written by Satoshi. is there a copy somewhere?
38 2014-12-17 03:13:29 <duuude> also, does it have a mix of styles/endianness etc that strongly suggests it was not one person but multiple sharing a pseudonym?
39 2014-12-17 03:14:45 <BlueMatt> duuude: (a) no one cares who satoshi is, (b) attacking his preference towards psudonimity is not appreciated, and (c) you arent gonna do any better than the last 100 people who tried and came up with bullshit conclusions
40 2014-12-17 03:15:24 <duuude> BlueMatt, I don't care who he is. I'm just asking what the consensus is, i.e. is it obviously multiple people based on mixing endianness, etc.
41 2014-12-17 03:15:59 <BlueMatt> its really not obviously anything
42 2014-12-17 03:16:16 <duuude> I mean if one part of the code ALWAYS writes (for i = 0; i < 10; i++) and the other ALWAYS writes for(i = 0; i <= 9; i++) and so forth, it's pretty clear.
43 2014-12-17 03:16:23 <duuude> BlueMatt, are you a coder?
44 2014-12-17 03:17:17 <duuude> or one part always does casts this way (int) x and the other always does casts this way int (x)
45 2014-12-17 03:26:30 <s1w> duuude: look for yourself. you know how to use git, right?
46 2014-12-17 04:32:54 <gmaxwell> 20:32 < adam3us> gavin on scalability live stream https://www.youtube.com/watch?v=7K5AQdbo0nY
47 2014-12-17 06:29:22 <aburan28> has anyone seen the talk "The End of Crypto" from the IACR conference?
48 2014-12-17 06:29:30 <aburan28> this is the url https://www.youtube.com/watch?v=3ijjHZHNIbU
49 2014-12-17 06:30:02 <aburan28> basically it assumes that the endpoint/client can never be secured
50 2014-12-17 06:30:34 <aburan28> and if that holds true that has broad implications for bitcoin wallets
51 2014-12-17 06:30:50 <gmaxwell> aburan28: this is why bitcoin can use multisignature, and I believe we're the first largescale user of threshold cryptography.
52 2014-12-17 06:34:02 <aburan28> yeah but we gotta get the adoption rate of multisig way up
53 2014-12-17 06:34:15 <aburan28> have you heard of white box cryptography?
54 2014-12-17 06:40:15 <gmaxwell> aburan28: mostly snake oil; e.g. there was just another paper on breaking obfuscator-llvm that I saw last week.
55 2014-12-17 08:14:57 <jcorgan> clear
56 2014-12-17 08:54:20 <Luke-Jr> sipa: wumpus: just a FYI, 0.10 branch does already break ABI with secp256k1 master
57 2014-12-17 08:55:02 <Luke-Jr> I doubt it's a concern, since we're embedding a copy in the BCCore codebase, but just in case it wasn't intentional
58 2014-12-17 08:57:31 <bedeho> Does anyone know if picocoin is mature enough to be used in production?
59 2014-12-17 08:57:41 <gmaxwell> Luke-Jr: It's intentional.
60 2014-12-17 09:06:02 <bedeho> Different way of asking: how would you recommend adding an spv client and wallet to c++ software while avoiding a copyleft license (libbitcoin)? Talking to bitcoinj through JNI is a last resort :/
61 2014-12-17 09:08:36 <phantomcircuit> bedeho, if you need a library for an spv client being written in c++
62 2014-12-17 09:08:56 <bedeho> C or C++, yes
63 2014-12-17 09:08:57 <phantomcircuit> asking whether picocoin is mature is maybe not the first question to ask
64 2014-12-17 09:09:09 <bedeho> why?
65 2014-12-17 09:10:12 <Luke-Jr> bedeho: what's the problem with copyleft?
66 2014-12-17 09:10:50 <bedeho> There is no problem with copyleft, but I cannot commit to it in my project at this point, so I need something more permissive
67 2014-12-17 09:44:18 <Luke-Jr> wumpus: If I drop .lighter, won't everything become the same colour shade (ignoring alpha)?
68 2014-12-17 09:49:04 <phantomcircuit> bedeho, because writing the logic you need for an spv client is relatively easy... if you can do it at all
69 2014-12-17 09:50:02 <Luke-Jr> gmaxwell: sipa: wumpus: the libsecp256k1 bundled in 0.10 also is forcing GMP when available..
70 2014-12-17 10:23:32 <midnightmagic> cool
71 2014-12-17 10:23:37 <midnightmagic> 2014-12-17 10:22:07 ERROR: CScriptCheck() : 7f2b48481f16a4900431b0885facd7274ca9ab64aaf937310e06eacc19bc2f52:0 VerifySignature failed: Public key is neither compressed or uncompressed
72 2014-12-17 10:25:53 <Luke-Jr> s/or/nor/
73 2014-12-17 10:26:28 <sipa> Luke-Jr: yeah, we should pass --with-bignum=none to the subconfigure, but no idea how to do that
74 2014-12-17 10:27:10 <Luke-Jr> sipa: --with-bignum=none doesn't work, I mean
75 2014-12-17 10:28:19 <Luke-Jr> libsecp256k1 at that commit still ignores it
76 2014-12-17 10:29:20 <sipa> heh?
77 2014-12-17 10:33:10 <midnightmagic> as of commit 5f7279ac70b755d3aac9582d36e08bdf0e3f4fc6, bitcoind -testnet with -txindex is using 98MB RSS, mainline 648MB on a 32-bit hoat.
78 2014-12-17 10:33:24 <midnightmagic> so, I guess that's a bit less than it was using last time I checked
79 2014-12-17 10:36:26 <Luke-Jr> sipa: the easy fix seems to be to cherry-pick your configure changes on top of the older code
80 2014-12-17 10:36:39 <Luke-Jr> (the ones that make --without-bignum work)
81 2014-12-17 10:39:03 <paveljanik> midnightmagic, that commit should not have any effect...
82 2014-12-17 10:39:11 <paveljanik> maybe other change affected that
83 2014-12-17 10:40:15 <midnightmagic> paveljanik: I am describing only what I checked out when I grabbed HEAD the other day, not the results of any sort of analysis as to why the tx are being listed in debug.log
84 2014-12-17 10:40:41 <midnightmagic> nor memory consumption
85 2014-12-17 10:47:33 <paveljanik> midnightmagic, ah, ok. I thought that this exact commit is the cause of this.
86 2014-12-17 10:48:17 <midnightmagic> no, I just didn't recall whether I checked out HEAD or 0.10 branches
87 2014-12-17 10:52:27 <sipa> Luke-Jr: before, it was --with-bignum=none
88 2014-12-17 10:52:42 <Luke-Jr> sipa: yes, but that got ignored if GMP was installed
89 2014-12-17 10:53:02 <sipa> heh, that shouldn't
90 2014-12-17 10:53:14 <Luke-Jr> ACTION double checks one more time..
91 2014-12-17 10:53:41 <Luke-Jr> maybe it was field, not bignum?
92 2014-12-17 10:53:41 <sipa> in any case, that would have been a big i'm unaware of
93 2014-12-17 10:53:46 <sipa> oh, right
94 2014-12-17 10:53:48 <sipa> you need both
95 2014-12-17 10:53:53 <Luke-Jr> ?
96 2014-12-17 10:54:10 <sipa> --with-field=somethingnotGMP --with-bignum=none
97 2014-12-17 10:54:24 <Luke-Jr> hm
98 2014-12-17 10:54:38 <sipa> the problem is that that something is platform dependent
99 2014-12-17 10:55:18 <Luke-Jr> I thought I had tried that too.. but not reproducing it now, so maybe not
100 2014-12-17 10:55:26 <Luke-Jr> sipa: 32bit isn't generic C?
101 2014-12-17 10:55:53 <sipa> field=32bit uses uint64_t, field=64bit uses __int128
102 2014-12-17 10:56:06 <sipa> but field=32bit is very slow
103 2014-12-17 10:56:34 <sipa> (well, still faster than openssl, but several times slower than field=64bit, and even slower than field=gmp on most platforms, which is why field=gmp still exists)
104 2014-12-17 10:59:58 <Luke-Jr> why do you say it is platform dependent then?
105 2014-12-17 11:01:20 <sipa> on x86_64 you want field=64bit, on x86 you want field=32bit
106 2014-12-17 11:02:29 <wumpus> sipa: ah yes I did some benchmarks with different settings on ARM, still mean to look at them and publish them
107 2014-12-17 11:02:47 <sipa> wumpus: on ARM, field=32bit is actually faster than field=gmp
108 2014-12-17 11:02:53 <sipa> gmaxwell did benchmarks too
109 2014-12-17 11:02:57 <wumpus> OK
110 2014-12-17 11:03:08 <sipa> so the easy option is to remove field=gmp :)
111 2014-12-17 11:03:13 <wumpus> whoo mips32be testnet sync is at 78%, this beast is crawling but getting there
112 2014-12-17 11:03:14 <wumpus> agreed
113 2014-12-17 11:03:34 <sipa> which we probably should do anyway, as it is harder to guarantee constant-time behaviour for it
114 2014-12-17 11:03:45 <Luke-Jr> sipa: but then it's slower for me?
115 2014-12-17 11:04:15 <sipa> Luke-Jr: yes, but if libsecp256k1 ever ends up being used for consensus code, i don't think we want the GMP dependency anyway
116 2014-12-17 11:04:24 <wumpus> also -O3 was slightly faster in ARM, so that was good
117 2014-12-17 11:04:40 <Luke-Jr> sipa: assuming it's only ever used in consensus code
118 2014-12-17 11:04:43 <wumpus> I wonder if it makes sense to write the asm parts in NEON
119 2014-12-17 11:05:00 <Luke-Jr> wumpus: isn't -O3 dangerous?
120 2014-12-17 11:05:19 <sipa> libsecp now compiles with -O3 by default, it's a few % faster
121 2014-12-17 11:05:21 <wumpus> Luke-Jr: the default was switched to that for secp256k1
122 2014-12-17 11:05:31 <wumpus> Luke-Jr: no comment on that being dangerous :<
123 2014-12-17 11:05:51 <Luke-Jr> sipa: yeah, I mean in the sense that -O3 has been known to produce broken code in some cases
124 2014-12-17 11:05:54 <sipa> well, we run the unit tests, even in bitcoin
125 2014-12-17 11:06:21 <wumpus> -O2 has also produced broken code in some cases, but sure the more optimization passes the more scope for error
126 2014-12-17 11:06:35 <wumpus> still, the unit tests didn't catch anything
127 2014-12-17 11:07:00 <Luke-Jr> wumpus: going to just go ahead and remove the lighten; who cares about the about icon âº
128 2014-12-17 11:07:09 <Luke-Jr> lighter*
129 2014-12-17 11:07:09 <sipa> btw, bitcoin compiles libsecp with -O2
130 2014-12-17 11:07:14 <sipa> as it inherits the flags
131 2014-12-17 11:07:34 <sipa> at this point, performance doesn't matter all that much (as it's just for signing)
132 2014-12-17 11:07:40 <Luke-Jr> wumpus: when -O2 breaks code, it's a compiler bug :p
133 2014-12-17 11:07:51 <sipa> when -O3 breaks code it's a compiler bug too
134 2014-12-17 11:07:57 <wumpus> Luke-Jr: oh the about icon was the one with variability in the color?
135 2014-12-17 11:07:59 <Luke-Jr> sipa: not always
136 2014-12-17 11:08:01 <wumpus> sipa: yup!
137 2014-12-17 11:08:04 <Luke-Jr> wumpus: yep
138 2014-12-17 11:08:05 <null> depends on the compiler
139 2014-12-17 11:08:16 <sipa> there are experimental options, but those shouldn't be enabled by -O3 afaik
140 2014-12-17 11:08:19 <null> sometimes -O disables stuff from the standard
141 2014-12-17 11:08:33 <null> *language standard
142 2014-12-17 11:08:35 <Luke-Jr> sipa: -O3 enables some optimisations that break code that isn't strictly adhering to C/C++
143 2014-12-17 11:08:44 <wumpus> for GCC -O should not disable any standards behavior
144 2014-12-17 11:08:46 <Luke-Jr> sipa: particularly, casting between pointers of different types
145 2014-12-17 11:09:04 <wumpus> ie, the potentially disastrous non-IEEE floating point options from -ffast-math are not included
146 2014-12-17 11:09:10 <sipa> yeah, peephole optimization iirc?
147 2014-12-17 11:09:16 <null> wumpus: gcc true, icc different story
148 2014-12-17 11:09:32 <null> ms* idk :)
149 2014-12-17 11:09:43 <sipa> or strict aliasing
150 2014-12-17 11:09:56 <wumpus> yes your code needs to be aliasing free for -O3 to not shoot you in the foot
151 2014-12-17 11:10:35 <wumpus> null: makes sense to make the default compiler options compiler dependent
152 2014-12-17 11:10:53 <wumpus> icc and msvc's optimizations are different so it would require separate testing and benchmarking
153 2014-12-17 11:11:07 <wumpus> sweet spot could be completely somewhere else
154 2014-12-17 11:11:14 <wumpus> also * architectures
155 2014-12-17 11:11:18 <sipa> unsure whether they will work at all
156 2014-12-17 11:11:21 <sipa> icc/msvc
157 2014-12-17 11:11:26 <wumpus> though luckily ICC and MSVC don't exist for ARM
158 2014-12-17 11:11:39 <Luke-Jr> wumpus: they don't? what does Windows use for ARM?
159 2014-12-17 11:11:46 <wumpus> Luke-Jr: eh.. good point
160 2014-12-17 11:13:09 <sipa> let me benchmark field=gmp and field=32bit
161 2014-12-17 11:13:12 <wumpus> so for every CPU architecture / compiler combo, the best settings would have to be determined. Normally you'd default to 'normal' optimization unless a better choice is known for that specific combo
162 2014-12-17 11:13:22 <Luke-Jr> ACTION ponders if Windows Phone can actually revive itself with Bitcoin
163 2014-12-17 11:13:41 <wumpus> 'normal' optimization level would hopefully be as safe as possible, independent of the compiler...
164 2014-12-17 11:13:43 <sipa> wumpus: pull requests welcome :p
165 2014-12-17 11:13:59 <wumpus> sipa: well apart from 'default to safe' I have no suggestions here
166 2014-12-17 11:14:09 <Luke-Jr> wumpus: pretty sure autotools just uses -O2 by default regardless of compiler
167 2014-12-17 11:14:12 <wumpus> primarily, bitcoin needs to be safe
168 2014-12-17 11:14:44 <sipa> heh, bitcoin could of course override the flags with -O1 or something :)
169 2014-12-17 11:15:02 <Luke-Jr> personally, I tend to be crazy and build with -O0 -ggdb
170 2014-12-17 11:15:07 <Luke-Jr> which disables inlining and crap
171 2014-12-17 11:15:17 <wumpus> -O2 is usually considered safe
172 2014-12-17 11:15:28 <wumpus> though of course you could go full paranoid and use -O
173 2014-12-17 11:15:33 <wumpus> -O0 is not recommended either
174 2014-12-17 11:15:40 <wumpus> not inlining has been known to trigger bugs in some cases
175 2014-12-17 11:15:44 <Luke-Jr> -O2 screws up my debugger
176 2014-12-17 11:16:12 <wumpus> it shouldn't, but I've seen mess-ups with -O0, not with bitcoin though.
177 2014-12-17 11:16:15 <sipa> -O0 will hurt :)
178 2014-12-17 11:16:22 <sipa> in terms of performance
179 2014-12-17 11:16:26 <wumpus> oh yes
180 2014-12-17 11:16:29 <sipa> like 5 times slower
181 2014-12-17 11:16:47 <Luke-Jr> wumpus: it shouldn't? if I build with -O2, gdb jumps to like line 50, 47, 49, 48, 50, 47
182 2014-12-17 11:17:03 <Luke-Jr> very annoying and hard to follow
183 2014-12-17 11:17:07 <wumpus> Luke-Jr: oh yes- any optimization will make debugging a lot harder, especially with C++
184 2014-12-17 11:17:24 <wumpus> with C I've managed to debug -O3 codebases, but gdb and c++ and optimization, oh please
185 2014-12-17 11:17:56 <sipa> recently i've mostly been debugging by adding printf's, and looking at generated assembly
186 2014-12-17 11:18:04 <wumpus> sipa: indeed, -O0 won't even pick the low-hanging fruit, which is bound to be most
187 2014-12-17 11:18:27 <sipa> -O0 won't do things like "oh, you divide by 64... should i perhaps use a shift instead?"
188 2014-12-17 11:18:30 <Luke-Jr> For my OS, I have Gentoo build with -march=core-avx2 -pipe -ggdb -O0 -mavx -fauto-inc-dec -fdce -fdse -fguess-branch-probability -fipa-pure-const -fmerge-constants -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-sra -fthread-jumps -fcaller-saves -finline-small-functions -findirect-inlining -foptimize-sibling-calls -fregmove -fstrict-aliasing -fstrict-
189 2014-12-17 11:18:31 <Luke-Jr> overflow -mno-ssse3
190 2014-12-17 11:19:17 <Luke-Jr> (which I hand-picked based on whether they affect my ability to debug)
191 2014-12-17 11:19:19 <sipa> 32bit or 64bit?
192 2014-12-17 11:19:23 <Luke-Jr> 32-bit
193 2014-12-17 11:20:00 <Luke-Jr> there's a few packages I disable SSE4 and AVX for too, since Valgrind can't handle it
194 2014-12-17 11:20:37 <wumpus> gdb is nice as it can add 'dynamic printfs', especially with some python scripting you can do cool things without even recompiling
195 2014-12-17 11:20:47 <wumpus> though as said it works better for C than C++
196 2014-12-17 11:20:52 <Luke-Jr> ACTION has some insane gdb scripts
197 2014-12-17 11:21:17 <Luke-Jr> http://codepad.org/UbFSgb3g <-- .gdbinit
198 2014-12-17 11:23:13 <wumpus> me, too winner is https://github.com/laanwj/etna_viv/blob/master/tools/etnaviv_gdb.py which parses and disassembles out GPU state in-memory
199 2014-12-17 11:23:20 <Luke-Jr> :o
200 2014-12-17 11:23:44 <sipa> :o
201 2014-12-17 11:25:58 <sipa> field=gmp is about 22% faster (for verification) when not using gmp or GLV otherwise
202 2014-12-17 11:26:26 <sipa> on 32bit i mean
203 2014-12-17 11:28:14 <hearn> good afternoon
204 2014-12-17 11:31:32 <sipa> i'm going to delete field=gmp; we can very likely beat it by having x86 assembly for field mul/sqr, if performance is actually that relevant
205 2014-12-17 11:32:09 <sipa> an alternative would be to just never select it through autodetection
206 2014-12-17 11:32:33 <sipa> as it has lower guarantees, but is perhaps useful as a simple reference implementation to compare with
207 2014-12-17 11:33:17 <wumpus> it's only simple if you don't consider the complexity in gmp itself, but yeah
208 2014-12-17 11:34:19 <sipa> yeah, i don't mean encouraging its use for production
209 2014-12-17 11:35:23 <wumpus> yes I understood what you meant, the gmp code may be easiest to follow
210 2014-12-17 11:35:34 <wumpus> hearn: hello
211 2014-12-17 11:39:41 <sipa> wumpus: if that's the purpose i think i'd rather have a dead-simple totally-slow reference C implementation; that's likely even more readable
212 2014-12-17 11:41:51 <sipa> not arguing with you; more arguing with myself btw :)
213 2014-12-17 14:54:28 <cfields> sipa: i meant to ask you about bitcoin forcing libsecp to -02 but completely forgot
214 2014-12-17 14:54:44 <cfields> i take it you're ok with not worrying about that for now?
215 2014-12-17 14:54:55 <sipa> nope
216 2014-12-17 14:55:29 <sipa> cfields: though we should have a way to pass flags to the subconfigure
217 2014-12-17 14:55:42 <sipa> --with-bignum=none, specifically
218 2014-12-17 14:55:46 <cfields> stupid language and un-answerable questions..
219 2014-12-17 14:55:55 <cfields> sipa: sure, pass it --with-bignum=none :)
220 2014-12-17 14:56:01 <cfields> the subconfigure inherits it
221 2014-12-17 14:56:10 <sipa> Ah.
222 2014-12-17 14:56:53 <cfields> granted, not at all obvious. but afaik it's designed to work that way
223 2014-12-17 14:57:18 <sipa> i would expect the bitcoin configure to complain about an unknown option
224 2014-12-17 15:01:20 <cfields> looks like option-checking defaults to false when configure calls a sub-configure
225 2014-12-17 15:02:14 <sipa> it seems to work fine
226 2014-12-17 16:32:56 <wumpus> re: 0.10, need some ACKs for https://github.com/bitcoin/bitcoin/pull/5485 https://github.com/bitcoin/bitcoin/pull/5481 https://github.com/bitcoin/bitcoin/pull/5253
227 2014-12-17 16:33:27 <wumpus> two are fixes for smartfee in the wallet, one extends mempool checks
228 2014-12-17 16:48:10 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/5485 could use some tests to verify
229 2014-12-17 16:54:30 <gmaxwell> wumpus: "I think that requires extra mention." can you suggest language? I was actually trying to make that clear with "Absolute maximum value"
230 2014-12-17 16:55:12 <wumpus> gmaxwell: that didn't make it clear to me, I'd expect a wording like 'total fee', but I'm not native english so I may be looking at these things differently
231 2014-12-17 17:01:45 <wumpus> gmaxwell: 'this option is not like the others' may require a more verbose warning, not one word
232 2014-12-17 17:02:11 <wumpus> although it's actually *more* intuitive than the others
233 2014-12-17 17:03:17 <wumpus> very little foot-shooting potential too. if you set it too low it results in not sending transactions
234 2014-12-17 17:03:23 <wumpus> so maybe it's just ok.
235 2014-12-17 17:04:08 <gmaxwell> Adding 'total fee' in there seems reasonable to me.
236 2014-12-17 17:04:34 <gmaxwell> and yes, it's what a lot of people have expected the fee controls to do in the past, even though it makes a bit less sense from the network perspective.
237 2014-12-17 17:05:05 <gmaxwell> I do worry we'll get some complaints, e.g. when people set it quite low and cannot send a 50k transaction... but its harmless at least.
238 2014-12-17 17:13:43 <wumpus> at least that has an easy fix
239 2014-12-17 18:23:19 <wumpus> in rest.cpp, there's a class RestErr and a function RESTERR that creates a RestErr and assigns fields. I can't think of a reason why it's not just a constructor.
240 2014-12-17 18:25:20 <jonasschnelli> wumpus RESTERR, truly. I can change this. RF_UNDEF needs also be removed.
241 2014-12-17 18:26:34 <wumpus> it's also not deriving from sd::exception
242 2014-12-17 18:26:49 <wumpus> I'm not saying you should change it, I'm just trying to understand
243 2014-12-17 18:27:48 <wumpus> but yes RF_UNDEF is used so can certainly go
244 2014-12-17 18:28:11 <wumpus> UNused
245 2014-12-17 18:53:32 <jonasschnelli> wumpus: JSONRPCError is also not derived from std::exception, both (RESTERR and JSONRPCError) could be subclasses of std::exception....
246 2014-12-17 19:00:38 <wumpus> jonasschnelli: at least in Python it's customary to always inherit from Exception, I'd suppose it's the same for c++, it makes reporting errors easier
247 2014-12-17 19:02:30 <jonasschnelli> wumpus: indeed. throwing objects not inherited from std::exception should be avoided IMO. But application behavior with error catching in REST/RPC looks generally okay.
248 2014-12-17 20:06:25 <prettymuchbryce> This is tangentially related to bitcoin, but I think it is probably the right audience. Does anyone know of any open source frameworks or building-blocks that exist for creating trustless decentralized systems ?
249 2014-12-17 20:08:43 <Dizzle> A better question for #Bitcoin or #Bitcoin-Wizards.
250 2014-12-17 20:12:17 <wumpus> we're far from those things being generic enough that there are open source frameworks for that
251 2014-12-17 20:14:55 <arioBarzan> any news regarding block size limits? Surprisingly, the difficulty has decreased for last two adjustments. Since there is a chance that the hash power could follow a down trend, for some time, one could expect average time between the blocks become more than 10 minutes, and the transactions would probably have a hard time to get through.
252 2014-12-17 20:16:54 <gmaxwell> wumpus: Morcos is saying that we no longer prevent relaying 0 fee, 0 priority transactions.
253 2014-12-17 20:17:18 <wumpus> gmaxwell: I'm sure we do
254 2014-12-17 20:19:50 <wumpus> see accepttomempool, if (fLimitFree && nFees < txMinFee)
255 2014-12-17 20:20:51 <morcos> txMinFee is 0 for reasonably small transactions
256 2014-12-17 20:21:12 <wumpus> that code hasn't changed for ages
257 2014-12-17 20:21:28 <wumpus> yes, so larger transactions without fee are rejected
258 2014-12-17 20:22:21 <morcos> but small, 0 fee transactions can be relayed up to the rate limit without regard to priority
259 2014-12-17 20:22:48 <wumpus> sure
260 2014-12-17 20:23:21 <wumpus> the reasoning is that miners will put them in a 'free area' in blocks
261 2014-12-17 20:24:31 <wumpus> afaik that's always been the case. but gmaxwell's 'no longer' implies that this changed recently?
262 2014-12-17 20:24:36 <morcos> I think the question just comes down to whether the rate limiter is sufficiently strict and also whether higher priority transactions should have some precedence
263 2014-12-17 20:24:58 <morcos> I wasn't implying it changed, I thought it was always like that, but always isn't a long time for me.. :)
264 2014-12-17 20:25:42 <prettymuchbryce> Wumpus I was thinking about trying to create a generic open source consensus module similar to ripple's algorithm.
265 2014-12-17 20:26:01 <lechuga_> ACTION smdh
266 2014-12-17 20:27:30 <wumpus> morcos: I don't think it makes sense to change that logic, it works, though it is questionable anyway whether miners will keep including free transactions at all. But right now it's IMO fine.
267 2014-12-17 20:49:40 <voidDotClass> How do nodes running bitcoin find other nodes?
268 2014-12-17 20:53:54 <lechuga_> https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery
269 2014-12-17 20:54:33 <voidDotClass> ty
270 2014-12-17 21:25:15 <voidDotClass> lechuga_: I've read the wiki link you sent, but i'm still not completely clear. It says 'Nodes receive the callback address of remote nodes that connect to them.' How do the remote nodes find the node?
271 2014-12-17 21:25:29 <voidDotClass> do they simply ping everyone that has a particular port open?
272 2014-12-17 21:26:37 <voidDotClass> i.e when you first start a bitcoin client, how does it register with the network so other nodes can connect to it?
273 2014-12-17 21:29:57 <kadoban> voidDotClass: You may want to read closer, it lists several sources for nodes to connect to.
274 2014-12-17 21:44:30 <voidDotClass> I see, thanks. Where do the dnsseed sites come from? i.e who runs them?
275 2014-12-17 21:53:36 <jonasschnelli> voidDotClass: check https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L155
276 2014-12-17 21:54:18 <voidDotClass> jonasschnelli: I see, but who runs these servers?
277 2014-12-17 21:54:39 <jonasschnelli> static, and run by devs and service operators
278 2014-12-17 21:54:49 <voidDotClass> ah
279 2014-12-17 21:55:23 <jonasschnelli> just for seed, don't see them as kind of "master server"
280 2014-12-17 21:56:10 <phantomcircuit> this is really more #bitcoin material
281 2014-12-17 23:39:00 <voidDotClass> Question. During mining, who sets how many zero bits are required to be found?
282 2014-12-17 23:39:24 <voidDotClass> I.e when you hear about the difficulty 'increasing', who actually increases it? Since there's no central server.
283 2014-12-17 23:39:35 <tdlfbx> voidDotClass: the target is recalculated once every 2016 blocks. look for RETARGET in the code or your debug.log.
284 2014-12-17 23:39:38 <tdlfbx> Everyone calculates it.
285 2014-12-17 23:40:40 <tdlfbx> Someone remind me...with multisig addresses there is no canonical ordering of the pubkeys, correct? Is there a BIP to require ordering of the keys?
286 2014-12-17 23:41:03 <voidDotClass> tdlfbx: So it increases automatically in the software being run by the clients?
287 2014-12-17 23:41:14 <tdlfbx> voidDotClass: yes.
288 2014-12-17 23:42:03 <voidDotClass> So in the early days, when there might've only been 2-3 miners, what stopped the two miners from not upping the difficulty and hoarding coins?
289 2014-12-17 23:42:16 <voidDotClass> i.e staying at a low difficulty?
290 2014-12-17 23:42:36 <sipa> #bitcoin please
291 2014-12-17 23:42:53 <tdlfbx> The change in difficulty, and how to calculate it is encoded in bitcoind
292 2014-12-17 23:42:55 <voidDotClass> I think this is a dev question.
293 2014-12-17 23:43:11 <tdlfbx> voidDotClass: let's go to #bitcoin.
294 2014-12-17 23:43:36 <sipa> ok then: the formula for computing the difficulty is a block validity rule; if you set it wromg, your block is invalid
295 2014-12-17 23:43:41 <tdlfbx> Mine is bitcoin-dev. I'm going to write a BIP for canonical ordering of multisig keys, unless there's one already, or it's a bad idea.
296 2014-12-17 23:45:24 <sipa> tdlfbx: it's been suggested before, but never took off
297 2014-12-17 23:45:45 <sipa> or some programs are doing so... and they can
298 2014-12-17 23:46:21 <voidDotClass> Assume this is the very early days, there's only 2-3 miners. What stops someone from recompiling the bitcoind software but changing it to not up the difficulty after 2016 blocks? If out of the 2-3 early miners, 2 use this rogue version, then their blocks would be considered valid even if they didn't up the difficulty
299 2014-12-17 23:46:46 <sipa> voidDotClass: nothing
300 2014-12-17 23:47:00 <sipa> but nobody else would accept their blocks
301 2014-12-17 23:47:20 <sipa> please, miners do not set the rules
302 2014-12-17 23:47:25 <sipa> full nodes do
303 2014-12-17 23:47:32 <sipa> mimers try to.satisfy the.rules
304 2014-12-17 23:47:57 <voidDotClass> The majority sets the rules, right. So if the majority use a rogue version of the software, then their blocks would be considered valid?
305 2014-12-17 23:48:05 <sipa> NO
306 2014-12-17 23:48:18 <sipa> forget majority
307 2014-12-17 23:48:32 <sipa> bitcoin is a zero-trust system
308 2014-12-17 23:48:41 <sipa> every node checks all the rules
309 2014-12-17 23:48:49 <sipa> miners do not choose the.rules
310 2014-12-17 23:49:12 <sipa> miners make us choose between.otherwise fully *valid* blocks
311 2014-12-17 23:49:44 <sipa> they cannot change the rules, or they start living.in their own little.world, but the rest.of the system.ignores them
312 2014-12-17 23:49:59 <sipa> sorry for typing, small screen
313 2014-12-17 23:50:45 <voidDotClass> I see
314 2014-12-17 23:53:20 <phantomcircuit> sipa, small.screen.
315 2014-12-17 23:53:32 <sipa> yeah.true
316 2014-12-17 23:59:19 <voidDotClass> Is there DDos protection built into the clients? e.g, someone could just learn the ips of the peers from one of the dns seeds, and DDos them