1 2015-10-13 00:00:40 <dhill> can someone run decodescript 6a5451 on bitcoin core tip (last 7 days or so)
  2 2015-10-13 00:02:09 <petertodd> 9~
  3 2015-10-13 00:02:15 <petertodd> dhill: one sec
  4 2015-10-13 00:02:24 <dhill> yes, with your nulldata changes
  5 2015-10-13 00:02:31 <dhill> is that nonstandard or nulldata
  6 2015-10-13 00:02:56 <petertodd> dhill: nulldata
  7 2015-10-13 00:03:12 <petertodd> dhill: numeric pushes are nulldata
  8 2015-10-13 00:03:23 <petertodd> dhill: I mean, like OP_1, OP_4, etc.
  9 2015-10-13 00:03:24 <dhill> sweet, so my tests are good
 10 2015-10-13 00:03:45 <dhill> it was nonstandard before your changes, yes?
 11 2015-10-13 00:03:50 <petertodd> dhill: yup
 12 2015-10-13 00:03:55 <dhill> nice
 13 2015-10-13 00:04:08 <petertodd> dhill: well, at least if you had two of them, one numeric constant push was standard for obscure reasons
 14 2015-10-13 07:27:50 <paulo_> if I wanted to write an altcoin from scratch with just the bare essentials, is there anything I should be wary of?
 15 2015-10-13 07:28:08 <paulo_> I have a mostly complete understanding of how bitcoin works
 16 2015-10-13 07:28:43 <midnightmagic> paulo_: Yes, altcoins are offtopic in a good chunk of the #bitcoin* hierarchy.
 17 2015-10-13 07:28:56 <paulo_> but stuff like spam protection and security edge cases are where i'm lacking
 18 2015-10-13 07:29:38 <paulo_> oh ok. thanks though
 19 2015-10-13 16:20:19 <Cocodude> This is almost certainly a dumym question, but why do we have LOCK()s on what appear to be const read-only functions like CWallet::IsMine ?
 20 2015-10-13 16:22:26 <cfields> Cocodude: other functions touch class vars, looks like mapWallet in that case.
 21 2015-10-13 16:23:47 <Cocodude> cfields: Ah right, I'll look a little deeper, thanks
 22 2015-10-13 16:24:35 <Cocodude> I'm looking into parallelising something but it's looking to be pretty tricky
 23 2015-10-13 16:24:43 <cfields> Cocodude: locking isn't related to changing a var. The question is: can variables in this function change values in another thread while i'm looking at them here?
 24 2015-10-13 16:25:29 <cfields> er, isn't related to const'ness, i should say
 25 2015-10-13 16:26:30 <Cocodude> My const, I really meant "no side effects", but I didn't look into the mapWallet stuff (I have no idea what that does yet)
 26 2015-10-13 16:37:50 <KutmasteR> the creator of the Ledger wallet in here at all? Couple questions
 27 2015-10-13 18:35:27 <andytoshi> OxADADA: replying to your -wizards stuff here
 28 2015-10-13 18:35:45 <andytoshi> OxADADA: my library is https://github.com/apoelstra/rust-bitcoin which is actively maintained
 29 2015-10-13 18:36:04 <OxADADA> andytoshi: thx
 30 2015-10-13 18:36:06 <andytoshi> OxADADA: the wallet that exposed the script-tracing stuff over RPC is https://github.com/apoelstra/wizards-wallet and pretty-much needs to be rewritten
 31 2015-10-13 18:37:14 <OxADADA> ah, you're Andrew  Poelstra, we just read your Altcoin treasise in my bitcoin class ;p
 32 2015-10-13 18:37:18 <andytoshi> OxADADA: documentation for the lib is at https://www.wpsoftware.net/rustdoc/bitcoin/ ... looks like i forgot to put that in the github readme
 33 2015-10-13 18:37:25 <andytoshi> o.O really? where?
 34 2015-10-13 18:37:30 <OxADADA> MIT
 35 2015-10-13 18:37:48 <andytoshi> wow, i'm pretty flattered by that :P
 36 2015-10-13 18:37:51 <OxADADA> andytoshi: http://blockchain.media.mit.edu/syllabus.html
 37 2015-10-13 18:37:58 <OxADADA> its on the syllabus
 38 2015-10-13 18:39:07 <OxADADA> neat.
 39 2015-10-13 18:39:18 <andytoshi> very neat
 40 2015-10-13 18:40:45 <OxADADA> thx, i'll check those projects out.
 41 2015-10-13 18:48:15 <andytoshi> please do. pull requests are welcome for the library. for the wallet i dunno what to do about it, if you are actually interested in fixing it you should probably just fork it and take over
 42 2015-10-13 19:42:39 <castorsky> hi, I write software which need verify btc payment. For example check(payment, "0.3BTC")  returned true if payment is valid, or false if not. It is possibly?
 43 2015-10-13 19:43:11 <castorsky> without blockchain
 44 2015-10-13 19:48:06 <Cocodude> Hello again. Question about locks and wallets again.
 45 2015-10-13 19:49:05 <Cocodude> In wallet.cpp, in IsMine, there's a mutex lock. I don't see why it's there though as I don't think we're changing anything (even pointers / iterators) to do with the mapWallet. Am I missing something?
 46 2015-10-13 19:49:22 <jonasschnelli> Cocodude: which line?
 47 2015-10-13 19:49:50 <jonasschnelli> Do you mean: LOCK(cs_wallet);
 48 2015-10-13 19:50:07 <Cocodude> jonasschnelli: Yes
 49 2015-10-13 19:50:12 <jonasschnelli> https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L793
 50 2015-10-13 19:50:37 <jonasschnelli> The lock is there because we are reading from mapWallet
 51 2015-10-13 19:51:05 <jonasschnelli> Cocodude: reading also needs the lock
 52 2015-10-13 19:51:21 <Cocodude> jonasschnelli: Oh yes, in case it changes in another thread
 53 2015-10-13 19:52:01 <jonasschnelli> Cocodude: Right.
 54 2015-10-13 19:52:48 <Cocodude> I'm changing something in the initialisation section (regarding scanning) where I think there won't be any writing to the mapWallet, or at least I might be able to work around things, so I may write an alternate IsMine
 55 2015-10-13 19:56:01 <Cocodude> Actually, this might be harder than I thought. It looks like anything involving the wallet is pretty hard to parallelise
 56 2015-10-13 19:57:17 <jonasschnelli> Cocodude: The wallet works fine with multiple threads accessing it. The locking is suboptimal.
 57 2015-10-13 20:00:20 <Cocodude> Will investigate further and see what can be done. Thanks.
 58 2015-10-13 20:07:34 <Cocodude> jonasschnelli: Just bouncing this off you - is there any possibility that I could change the locks on the wallet to require a shared mutex (reads) or unique mutex (writes)?
 59 2015-10-13 20:10:07 <jonasschnelli> Cocodude: Not sure. Try it. :)
 60 2015-10-13 20:10:23 <Cocodude> Great, will do
 61 2015-10-13 20:11:15 <Cocodude> Do we use shared mutexes anywhere in core at all?
 62 2015-10-13 20:11:28 <Cocodude> I can't see anything in sync.h
 63 2015-10-13 20:13:07 <jonasschnelli> logdb, a new file backend for the/a wallet uses it: https://github.com/jonasschnelli/bitcoin/commit/d810c6fde476f2177c92b41675f1b4da2be5e20d
 64 2015-10-13 20:13:27 <jonasschnelli> (untested code)
 65 2015-10-13 20:13:38 <jonasschnelli> Its the only place i'm aware of.
 66 2015-10-13 20:13:48 <jonasschnelli> but it's not in bitcoin-core master
 67 2015-10-13 20:14:45 <Cocodude> Interesting. OK, thanks. On the face of it, it looks near trivial to use shared mutexes actually, and some new SLOCK(x) analogies to LOCK(x) could quite easily be created... in theory
 68 2015-10-13 20:16:50 <cfields> Cocodude: iirc, that's been rejected in the past due to the overhead of boost's implementation
 69 2015-10-13 20:18:13 <Cocodude> cfields: Shame, that puts a dampner on that plan
 70 2015-10-13 20:20:53 <jtimon> have we decided on consensus code moving towards C++11 or C ?
 71 2015-10-13 20:33:37 <andytoshi> i strongly prefer C, but i'm barely involved with core so that's all i'll say on that
 72 2015-10-13 20:35:52 <jtimon> I mean, libsecp is also in C, it makes a lot of sense to me
 73 2015-10-13 20:37:36 <jtimon> I'm asking because we should have this clear when making any type of changes to consensus code (sometimes it will be "free" (review and/or test-wise) to move it in one or another direction)
 74 2015-10-13 20:38:11 <jtimon> although is specially annoying to not know this when making refactors
 75 2015-10-13 20:38:32 <CodeShark> I don't think changing the language is what's most important (or most practical) right now
 76 2015-10-13 20:39:15 <CodeShark> the main problem that needs solving is fixing dependency issues and disentangling stuff
 77 2015-10-13 20:39:23 <jtimon> but concretely in the context of #6816, if we know we're moving to C++11, std::map is great, if we plan to move to C, we may as well just to waht we would do in C directly instead
 78 2015-10-13 20:40:03 <jtimon> agree with it not being a priority, we don't want to do that in the short term due to the risks involved anyway
 79 2015-10-13 20:40:37 <jtimon> but knowing where we are going seems important to me
 80 2015-10-13 20:40:57 <CodeShark> I have no intention of sacrificing my classes and templates in the near future ;)
 81 2015-10-13 20:41:08 <CodeShark> range-based loops and lambdas would be great, too
 82 2015-10-13 20:41:47 <CodeShark> the way I see it, once it's disentangled, reimplementing it in language X is pretty much mechanical stuff
 83 2015-10-13 20:41:53 <CodeShark> whatever X may bee
 84 2015-10-13 20:41:55 <CodeShark> *be
 85 2015-10-13 20:42:12 <CodeShark> but C++ is what we'll probably be most productive in right now
 86 2015-10-13 20:42:35 <jtimon> CodeShark I'm not talking about Bitcoin Core, just the consensus code, it is my understanding that we are clearly moving towards C++11 with the non-consensus code, the only thing that it's not clear it's the long term future of libconsensus
 87 2015-10-13 20:42:50 <CodeShark> I don't think we need to commit to that yet
 88 2015-10-13 20:42:50 <zooko> I'd like to know the answer to this, because of our maintenance of a code-fork for Zcoin.
 89 2015-10-13 20:43:10 <zooko> Yeah, I guess we can live without knowing the answer, but maybe if we did know we could make our patches more appealing to you.
 90 2015-10-13 20:43:46 <jtimon> CodeShark: the parts of the consensus code that currently depend on C++ features are very small
 91 2015-10-13 20:43:55 <CodeShark> the most pressing issue is not the packaging of a C library...but the disentangling of dependencies and isolation of critical paths
 92 2015-10-13 20:44:11 <CodeShark> at least that's how I see it
 93 2015-10-13 20:45:14 <CodeShark> and a gradual code reorganization is also desirable - but if we do it all at once we're going to make things very hard for others
 94 2015-10-13 20:45:34 <jtimon> CodeShark: and I agree with that, but answering this question as soon as possible will not delay the disentangling in any way
 95 2015-10-13 20:45:52 <jtimon> uncertainty on this issue makes things harder for ourselves and others
 96 2015-10-13 20:46:48 <jtimon> cfields already got some nits for removing boost_foreach and I was doing the same for consensus code, for example
 97 2015-10-13 20:47:40 <CodeShark> boost_foreach is an extra dependency...but at least it's a stable dependency, so it isn't what I'm most concerned about
 98 2015-10-13 20:47:50 <CodeShark> I'd much rather use C++11 range-based loops
 99 2015-10-13 20:47:57 <jtimon> in the same sense, it may not make sense to introduce c++ features alike std::map in new consensus features right now if we know we eventually want the consensus code to be C
100 2015-10-13 20:48:00 <CodeShark> but to me this is a minor issue
101 2015-10-13 20:48:18 <CodeShark> to me these issues are primarily stylistic
102 2015-10-13 20:48:24 <CodeShark> not fundamental
103 2015-10-13 20:48:27 <jtimon> because we know consensus code it's hard to change once deployed
104 2015-10-13 20:48:59 <CodeShark> fundamental is, for instance, the entanglement of network code with consensus structures with the wallet
105 2015-10-13 20:49:23 <jtimon> it would be orders of magnitude easier to remove the std::map dependency in #6816 now than it will be once the code is deployed in bitcoin main
106 2015-10-13 20:49:49 <zooko> I'd like to know what the intent/plan/policy is with regard to disentangling network from consensus, and with regard to dependencies, and I'd also like to know what the intent/plan/policy is for C++ vs C.
107 2015-10-13 20:52:13 <jtimon> zooko I'm preparing a document (with pictures, since CodeShark sked for them) with a plan for disentangling the consensus code first, then completing libconsensus' API, and finally having Bitcoin Core use libconsensus' C API directly instead of using a git subtree
108 2015-10-13 20:53:23 <jtimon> but the question of whether libconsensus will eventually be implemented in C++11 or C is orthogonal to this document (although it is a very important question in practice IMO)
109 2015-10-13 20:55:35 <zooko> *nod*
110 2015-10-13 21:03:13 <CodeShark> 6816 has no external dependencies, jtimon, other than chain.h and the standard libs
111 2015-10-13 21:03:21 <CodeShark> so changing std::map is a very simple change
112 2015-10-13 21:03:45 <CodeShark> it's just replacing one well-tested container with presumably another well-tested container
113 2015-10-13 21:04:38 <CodeShark> what makes changes to consensus code very risky is the intermixing of abstraction layers and the use of unstable dependencies
114 2015-10-13 21:06:13 <jtimon> I agree with you, but some people think (not unreasonably) that ANY change to consensus code is risky (no matter how unoffensive it looks)
115 2015-10-13 21:07:44 <CodeShark> I've purposely encapsulated all std::map operations inside the class interface to avoid any such difficulties (though I still expose std::set)
116 2015-10-13 21:08:00 <CodeShark> although std::set is even easier to reimplement from scratch if need be
117 2015-10-13 21:08:18 <jtimon> you are using its iterators as well
118 2015-10-13 21:08:29 <CodeShark> only inside the class implementation
119 2015-10-13 21:08:39 <jtimon> I mean, don't change anything before we have an answer to this
120 2015-10-13 21:09:56 <jtimon> your PR is just another example, I've been pushing for this discussion since I discovered the plan wasn't C for libconsensus C++11 for everything else (which for some reason I assumed)
121 2015-10-13 21:10:23 <CodeShark> I'd even be happy disentangling main.cpp without moving anything to other source files, to be honest ;)
122 2015-10-13 21:10:53 <jtimon> that's why I say the disentangling is orthogonal to this discussion
123 2015-10-13 21:11:04 <CodeShark> of course, we do need to reorganize the code - but I think the approach of doing it little bits at a time is more practical
124 2015-10-13 21:11:18 <jtimon> this is most relevant when creating new consensus functionality (like you're doing)
125 2015-10-13 21:11:53 <CodeShark> a libconsensus with a C interface and other language bindings would be nice...but is not super critical right now
126 2015-10-13 21:12:12 <CodeShark> at least that's how I see it
127 2015-10-13 21:12:22 <jamesob> what's the impetus to move away from c++? simplicity? just curious
128 2015-10-13 21:12:22 <jtimon> the implementation is also orthogonal from the API and bindings
129 2015-10-13 21:12:41 <CodeShark> separating mempool stuff from, say, block tree management and the block index IS critical
130 2015-10-13 21:13:13 <jtimon> jamesob: that's a good question that I may not be the best person to answer it
131 2015-10-13 21:13:47 <CodeShark> jamesob: some people like to have a C interface for greater compatibility with more projects
132 2015-10-13 21:14:01 <jamesob> oh, that makes sense
133 2015-10-13 21:14:06 <jamesob> wider portability
134 2015-10-13 21:14:20 <CodeShark> and some think C code is easier to check for correctness (although I think well-written C++ is far easier for a human to review)
135 2015-10-13 21:14:34 <jtimon> apparently C has more tools for static analysis and it's also simpler (specially when it comes to compilers and behaving exactly in the same way in different target machines)
136 2015-10-13 21:15:06 <jamesob> CodeShark agree on the latter point for most cases
137 2015-10-13 21:15:11 <jtimon> CodeShark: jamesob is asking about C implementation, not C API (currently libconsensus has C++ implementation and C API)
138 2015-10-13 21:16:07 <jamesob> is a "C API" just a header file with signatures that're all compatible with a C compiler?
139 2015-10-13 21:16:14 <CodeShark> yes
140 2015-10-13 21:16:31 <jtimon> jamesob: you may want to ask in #secp256k1 why libsecp256k1 is written in C instead of C++ and you may get better answers
141 2015-10-13 21:16:53 <CodeShark> that's different, though, jtimon, because that's largely about performance
142 2015-10-13 21:17:04 <CodeShark> well, it's not completely different
143 2015-10-13 21:17:15 <jamesob> jtimon gotcha. I think the issue of wider potential use sounds compelling.
144 2015-10-13 21:17:18 <CodeShark> but some parts of libsecp256k1 are written in in-line assembly
145 2015-10-13 21:17:34 <jamesob> but human-reviewability is pretty huge too ;)
146 2015-10-13 21:17:45 <jtimon> if it was my decision, it would be written in rpython (compilable to C, see pypy) and C for low level functions (ie for libsecp256k1)
147 2015-10-13 21:17:56 <cfields> CodeShark: fwiw, i started to complain about the chain.h dependency, but ultimately decided not to for now
148 2015-10-13 21:18:15 <cfields> i think it would be easy-ish to avoid, and would make that code consensus-friendly
149 2015-10-13 21:18:32 <CodeShark> cfields: I wasn't too happy about that either...but I have other plans for the block index
150 2015-10-13 21:19:05 <cfields> CodeShark: good, that's why i decided not to bother. a crippled wrapper would be ugly, but a general solution would be much appreciated
151 2015-10-13 21:19:35 <jtimon> CodeShark: if I understand the issues involved correctly is more about provable correctness than about performance
152 2015-10-13 21:19:45 <CodeShark> in this instance yes
153 2015-10-13 21:19:51 <CodeShark> in the case of libsecp256k1 both are important
154 2015-10-13 21:20:20 <CodeShark> in the case of 6818, we're FAR from the performance bottleneck
155 2015-10-13 21:20:51 <CodeShark> we can afford to be far less efficient than theoretically possible
156 2015-10-13 21:20:56 <jtimon> well, we should probably also consider performance when deciding for libconsensus' future
157 2015-10-13 21:21:33 <CodeShark> I do consider performance - it's just that there are some places where performance is far more critical
158 2015-10-13 21:21:47 <CodeShark> i.e. tight loops that run for many iterations
159 2015-10-13 21:21:48 <jtimon> and I would prefer to chose asap for the whole library instead of ad-hoc for each concrete case
160 2015-10-13 21:22:46 <jtimon> if we decide for C++11, that's fine too, but I would like to know asap (and I think it will be productive for review that we know asap too)
161 2015-10-13 21:23:24 <CodeShark> I don't think it's going to happen that way, jtimon - we will not be seeing a wholesale reimplementation of the consensus code in C in the very near term
162 2015-10-13 21:24:59 <CodeShark> or even reimplementation in C++ for that matter ;)
163 2015-10-13 21:25:23 <jtimon> CodeShark: I believe it will only happen (and this applies to both migrating to C++11 or C) in a very slow way while doing other changes (and maybe refactors if we know before libconsensus is complete), which is partly why I think it's important that we know where we are going asap
164 2015-10-13 21:25:35 <zooko> CodeShark: I think there's a difference between asking whether we should ultimately head toward C++ or head toward C, vs. suggesting that we start rewriting things in order to change the implementation now.
165 2015-10-13 21:25:53 <jtimon> I wouldn't call it a reimplementation, though, it would be just a slow migration
166 2015-10-13 21:26:06 <zooko> CodeShark: it kind of sounds like you don't want to commit to an ultimate destination because you don't want that to encourage people to do unnecessary or disruptive work now.
167 2015-10-13 21:26:59 <CodeShark> that's partly it...but more than that I don't think this is a fundamental architectural issue
168 2015-10-13 21:27:06 <CodeShark> to me it's primarily stylistic
169 2015-10-13 21:27:33 <jtimon> I agreed this is not a fundamental architectural priority
170 2015-10-13 21:28:16 <zooko> Style is important to me, because I'd like to contribute patches with a better chance of acceptance, and because I'd like to have a better prediction of what sorts of changes will be made upstream that we'll have to accomodate.
171 2015-10-13 21:28:39 <jtimon> but at some point we will have to decide for one of those two (stay on an old C++ implementation is not an option), what better time than before doing all the disentangling?
172 2015-10-13 21:29:01 <CodeShark> with a layered, modular codebase, different parts could be written in different languages for all I really care ;)
173 2015-10-13 21:29:34 <jamesob> as long as that's not done purely for variety's sake :)
174 2015-10-13 21:29:40 <CodeShark> haha
175 2015-10-13 21:30:01 <CodeShark> I'm a pragmatist - whatever code people will be working on, they should be working on using whatever tools help them be the most productive
176 2015-10-13 21:30:26 <jtimon> CodeShark: with a layered, modular codebase, we still have to decide between C++11 and C for libconsensus eventually
177 2015-10-13 21:30:50 <CodeShark> I say let's do both :p
178 2015-10-13 21:30:55 <CodeShark> lol
179 2015-10-13 21:31:01 <jtimon> being a pragmatist, you should agree with me asap it's the best time to decide on that
180 2015-10-13 21:31:20 <jtimon> even if you consider it just "style"
181 2015-10-13 21:31:42 <CodeShark> nah, I say let that evolve...and let's focus on architecture and be conservative on style
182 2015-10-13 21:32:00 <jtimon> but it's not, the stability of libconsensus will depend on some C++11 or C compilers respectively
183 2015-10-13 21:32:55 <CodeShark> once we solve the dependency issues, we can always reimplement pieces of it without affecting anyone els
184 2015-10-13 21:32:57 <jtimon> given that libconsensus has a C API anyway, I don't see any advantage in moving to C++11 instead of C
185 2015-10-13 21:33:12 <jamesob> jtimon readability
186 2015-10-13 21:33:17 <jtimon> reimplementation of consensus code is always risky
187 2015-10-13 21:33:36 <jtimon> jamesob I'm a strong readability advocate
188 2015-10-13 21:34:33 <jtimon> and for libconsensus, I don't think C hurts redability (people reading this need to be able to think about what machines will do at the lowest level)
189 2015-10-13 21:34:45 <CodeShark> point is with a proper architecture we can always rigorously test pieces and cover pretty much all cases of interest...and the interface can remain the same
190 2015-10-13 21:35:03 <CodeShark> so nobody else outside that unit is really affected as long as the behavior doesn't change
191 2015-10-13 21:36:01 <CodeShark> we can always write a C wrapper, then reimplement it in C later on...
192 2015-10-13 21:36:10 <jtimon> "we can always rigorously test pieces" I'm afraid that's easier said than done
193 2015-10-13 21:36:30 <jtimon> that's why "provably correct" techniques are so interseting for consensus code
194 2015-10-13 21:36:40 <CodeShark> anyhow, we're bikeshedding :p
195 2015-10-13 21:37:17 <jtimon> CodeShark: I disagree: with a layered, modular codebase, we still have to decide between C++11 and C for libconsensus eventually (stay on an old C++ implementation is not an option)
196 2015-10-13 21:37:31 <jtimon> for Bitcoin Core we've already decided: C++11
197 2015-10-13 21:38:01 <CodeShark> the units I write I would prefer to write in C++11 - but I'm not opposed to also using units written in C (i.e. libsecp256k1)
198 2015-10-13 21:38:56 <jtimon> CodeShark: exactly, libconsensus is in the middle but it has to move either to the libsecp256k1 or to the Bitcoin Core side
199 2015-10-13 21:39:02 <CodeShark> why?
200 2015-10-13 21:39:21 <jtimon> because "stay on an old C++ implementation is not an option"
201 2015-10-13 21:40:44 <jtimon> I would probably be happier deciding for C++11 now than deciding for C (my preference) 5 years from now
202 2015-10-13 21:42:20 <CodeShark> I'm not even entirely convinced that libconsensus is where we want to end up - why shouldn't consensus be, say, a runtime service?
203 2015-10-13 21:42:48 <CodeShark> but I don't think we need to decide that now
204 2015-10-13 21:42:49 <jtimon> (by then I bet C++ will have more "provable correctness" tools)
205 2015-10-13 21:45:08 <CodeShark> in any case, if what we're after is provability perhaps we should be looking into Coq or other interactive theorem provers
206 2015-10-13 21:45:27 <jtimon> we "don't have to decide" anything "now", but when making changes to the codebase that affect almost everyone working with the same code, it really helps to know as much as possible about the future
207 2015-10-13 21:45:50 <CodeShark> C and C++ are both rather unsafe languages in many respects
208 2015-10-13 21:46:24 <CodeShark> C++ lets you at least encapsulate all the low-level pointer arithmetic stuff, though
209 2015-10-13 21:46:28 <jtimon> CodeShark: that actually may be interesting for "script2.0", but probably belongs more to #wizards
210 2015-10-13 21:46:44 <jamesob> yeah, I'd argue C++ is harder to be unsafe with
211 2015-10-13 21:47:16 <gavinandresen> who is the “customer” for libconsensus?  You should ask them, whoever they are, if they’d prefer C or C++.
212 2015-10-13 21:47:32 <jtimon> disclaimer I usually prefer high level languages for specifications, like python (or rpython)
213 2015-10-13 21:48:03 <jtimon> gavinandresen: the first "customer" of libconsensus is Bitcoin Core itself
214 2015-10-13 21:48:18 <CodeShark> C and C++ are both fairly portable, integrate tightly with OSes, and can provide language bindings to pretty much any VHLL
215 2015-10-13 21:48:32 <jtimon> Bitcoin Core can evolve faster once the consensus code is encapsulated
216 2015-10-13 21:48:50 <jtimon> which is the most riskier part to modify
217 2015-10-13 21:49:30 <gavinandresen> mmmm…. my engineering-manager spidey sense is tingling.  “Just give us six months to rip things apart and we’ll save WEEKS of work in the future!”
218 2015-10-13 21:49:31 <CodeShark> gavinandresen: I think *we're* the immediate customer for libconsensus :)
219 2015-10-13 21:49:45 <CodeShark> this is to make our jobs easier, first and foremost
220 2015-10-13 21:49:59 <gavinandresen> Ok, as a potential customer of libconsensus I’d vote for C++, then.
221 2015-10-13 21:50:01 <jamesob> "easier" sounds like C++
222 2015-10-13 21:50:08 <zooko> If "bikeshedding" means this isn't an important question, I disagree.
223 2015-10-13 21:50:23 <jtimon> gavinandresen: alternative implementations, say libbitcoin or bitcoinj would also be great users for libconsensus, since they would remove the "consensus bugs" risks by running exaclty the same consensus code
224 2015-10-13 21:50:40 <gavinandresen> mmm.  I don’t think libbitcoin or bitcoinj are interested, though.
225 2015-10-13 21:51:14 <zooko> I'm a "customer" of libconsensus.
226 2015-10-13 21:51:26 <gavinandresen> zooko: cool, what do you want?
227 2015-10-13 21:51:27 <zooko> Although actually I'd have to ask my engineering team for their preferences on that question, if you wanted to know.
228 2015-10-13 21:52:30 <zooko> My own preference is C instead of C++, but I would defer to my chief engineer or a consensus of my other engineers.
229 2015-10-13 21:52:52 <CodeShark> zooko: would you be ok with a C API even if the internals are written in C++?
230 2015-10-13 21:52:53 <zooko> But most of all my preference is, as jtimon is saying, that it helps to know what the plan/policy/future is.
231 2015-10-13 21:53:04 <gavinandresen> zooko: a little document from your engineering team with “this is the API we wish we had” would be nifty.
232 2015-10-13 21:53:34 <zooko> CodeShark, gavinandresen: I was talking about being a "customer" in the sense of maintaining patches against the implementation, contributing patches, doing security audits of the implementation, etc., not in terms of API.
233 2015-10-13 21:53:40 <gavinandresen> There was a /r/programming article on “README-driven development” that I thought was good, and reflects how I tend to design APIs—  figure out the code I want to write, then make the API match that.
234 2015-10-13 21:53:57 <zooko> Yeah, I like that approach for APIs.
235 2015-10-13 21:54:37 <jtimon> gavinandresen: I think they should be interested in not having unnecessary consensus bugs, sometimes people say "the implementation is the specification" for consensus code, but Bitcoin Core has many more things than consensus code, so it is also a political issue to separate them
236 2015-10-13 21:54:40 <gavinandresen> There’s a lot of bad API design from premature optimization or over-generalization....
237 2015-10-13 21:55:01 <zooko> Yeah.
238 2015-10-13 21:55:19 <gavinandresen> jtimon: “meh” — we’ve got a thriving wallet ecosystem, a whole separate mining software stack....
239 2015-10-13 21:55:55 <gavinandresen> … and multiple implementations of the consensus code that keep consensus pretty well.
240 2015-10-13 21:56:55 <jtimon> gavinandresen: wouldn't a library that just (and only) checks the consensus rules (and nothing else Bitcoin Core does) help with such a new stack trend?
241 2015-10-13 21:58:21 <gavinandresen> jtimon: maybe… but just using bitcoind as an “edge router” works pretty well.
242 2015-10-13 21:58:52 <gavinandresen> The only reason to have a separate library is if performance is an issue, but I don’t see applications where that is a problem (we’re not talking millions of transactions per second)
243 2015-10-13 21:58:59 <jtimon> many people run bitcoin core in the edges of their internal network precisely because their own libraries aren't walways able to strictly follow consensus rules, running libconsensus behind their own ruby or java libraries could remove that need and increase the diversity at the network level
244 2015-10-13 21:59:08 <phantomcircuit> gavinandresen, at the very least the library work jtimon has been doing makes it significantly easier to fuzz core
245 2015-10-13 21:59:16 <phantomcircuit> it would all be worth it for that alone
246 2015-10-13 21:59:36 <gavinandresen> better testing is always a good thing
247 2015-10-13 22:00:24 <gavinandresen> … so focusing on unit tests for all the stuff that isn’t easily unit-testable would be excellent.
248 2015-10-13 22:01:21 <gavinandresen> I agree that thorough tests for the consensus code would DEFINITELY accelerate development.
249 2015-10-13 22:01:37 <jtimon> well, having a single folder for all the consensus code may not help with testing directly, but it would greatly help with review and with patches proposed (less people would unarvertidly make their patches consensus-risky)
250 2015-10-13 22:02:06 <gavinandresen> okey dokey
251 2015-10-13 22:08:15 <nwilcox> Hi. I missed a bit of the conversation about implementation language for consensus critical code.
252 2015-10-13 22:08:32 <nwilcox> Any outcome?
253 2015-10-13 22:08:52 <CodeShark> yes, we decided to use brainf!$@
254 2015-10-13 22:09:37 <jamesob> brainf!$@.js
255 2015-10-13 22:11:13 <nwilcox> You've got to be kidding. jsfuck is much more widely supported.
256 2015-10-13 22:11:46 <zooko> lol
257 2015-10-13 22:13:03 <nwilcox> I hope people are leaning towards C over C++(11).
258 2015-10-13 22:32:18 <jcorgan> make it LLVM intermediate representation
259 2015-10-13 23:21:53 <jtimon> good to hear more voices in favor of C over C++11 (again, just for the consensus code)
260 2015-10-13 23:23:01 <jtimon> if I'm interpreting jcorgan correctly
261 2015-10-13 23:58:08 <Luke-Jr> +1 for carefully-written C. probably the ideal would be a custom language specifically for consensus systems, though.
262 2015-10-13 23:58:47 <Luke-Jr> warren: I wonder if in addition to -dev and -discuss MLs, if a -support ML would be good to have.