1 2015-10-28 01:54:41 <rusty> Luke-Jr: hmm... probably a knee-jerk reaction to "another post on moderation".   I'm pretty sure if gavinandresen reposted the "Should it be a requirement that..." onwards on a new thread, it wouldn't have got a second look.
 2 2015-10-28 01:55:39 <rusty> Luke-Jr: and here's my reply to that same post gavinandresen replied to: http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-October/000000.html
 3 2015-10-28 06:41:13 <drazisil> Is there any good documentation (official or otherwise) that explains how to create a pool? Mainly understanding how to generate shares,
 4 2015-10-28 07:07:36 <Luke-Jr> drazisil: shares are just a lower difficulty than a block
 5 2015-10-28 07:09:53 <drazisil> Luke-Jr: Thanks. I found https://bitcoin.org/en/developer-guide#pool-mining which I think is what I was looking for :)
 6 2015-10-28 10:27:08 <frank1e> let's see if I get a little further with this Bitcoin Core UI/UX redesign today :)
 7 2015-10-28 10:42:08 <rusty> Anyone else on Ubuntu 15.10?  I get a classic boost link error, as per: https://github.com/bitcoin/bitcoin/issues/6772
 8 2015-10-28 10:43:03 <rusty> Hmm, wait, it's trying to run g++4.9 for some reason...
 9 2015-10-28 10:45:08 <rusty> Oops, I had ccontrol set g++ to g++-4.9 in the src/ dir....  Mu bad.
10 2015-10-28 10:45:29 <wumpus> what's wrong with gcc 4.9?
11 2015-10-28 10:46:21 <rusty> wumpus: there's some libstdc++/boost weirdness with specific compiler versions.  You want gcc5 (the default) on Ubuntu 15.10.
12 2015-10-28 10:46:29 <wumpus> OHH ABI conflict
13 2015-10-28 10:46:53 <rusty> wumpus: yeah, C++ random bullshit, basically.
14 2015-10-28 10:46:55 <wumpus> yes, never combine g++4.9 code with g++ 5.1 code
15 2015-10-28 10:48:48 <rusty> wumpus: yeah, assume the boost libs build with g++5.1, so basically don't expect g++4.9 to work.  But, y'know, you can install it just fine...
16 2015-10-28 10:50:09 <rusty> wumpus: and linker errors which actually say useful stuff like "X was built with gcc A, Y was built with gcc B, and ABI has changed" are so pedestrian.  Because I'm sure they'll never change the C++ ABI again.
17 2015-10-28 10:51:03 <wumpus> that would make a lot of sense
18 2015-10-28 10:51:59 <wumpus> but hey, you know, you're lucky that the linker generates errors at all. If it wouldn't the ABI conflicts would likely unearth some evil while running your program
19 2015-10-28 10:52:29 <rusty> wumpus: that's actually a good point.  I could be cursing inside gdb right now...
20 2015-10-28 10:52:34 <wumpus> I've had lots of issues with that on openbsd which, for license reasons, ships a very strange g++ and library by default, and allows installing newer versions from ports but they're all an ABI conflict party
21 2015-10-28 11:14:29 <rodmar> hi
22 2015-10-28 11:16:10 <rodmar> I pushed a transaction to the network using my node running bitcoin core version v0.11.1.0 but the transaction does not appear in certain blockchain explorers.
23 2015-10-28 11:16:29 <rodmar> this is the txid of my transaction 6810ee3700d01447f1ad243c7942e0d829cd9062c0a94cbc50da02e5da421b0e
24 2015-10-28 11:17:04 <rodmar> can someone help me figure out if I am doing something wrong when constructing the transaction
25 2015-10-28 11:49:38 <frank1e> someone of you on OS X right now?
26 2015-10-28 11:50:35 <frank1e> My OS fonts seem to be messed up, need to fix that soon. Until then I need someone to provide me 1 screenshot of the latest Bitcoin Core UI on OS X (latest version) so I can continue working on that. :)
27 2015-10-28 12:52:49 <frank1e> alright got it.
28 2015-10-28 13:29:31 <azariah> Question about this commit: https://github.com/bitcoin/secp256k1/commit/f79aa88373bba12544ba1f19f10765787759706e - does this have any security implications?
29 2015-10-28 13:30:11 <azariah> I looked at https://tools.ietf.org/html/rfc6979#section-3.2 and https://github.com/bitcoin/secp256k1/blob/master/src/secp256k1.c#L308 and to me it seems it shouldn't actually matter what the order is, since it's concatenated and then hashed in the HMAC
30 2015-10-28 15:16:43 <sipa> azariah: sure, both will work, but one is wrong and one is right :)
31 2015-10-28 15:16:53 <sipa> azariah: it's a convention
32 2015-10-28 15:17:49 <sipa> azariah: and there are other places in the code where it is done right, so tests that do conparisons failed as a result
33 2015-10-28 15:33:05 <azariah> sipa: cool, thanks
34 2015-10-28 15:38:19 <treehug88> Anyone ever succeed in getting an IDE to handle bitcoin code well? I know it'd have to use the external makefile, but it would be cool to use an IDE to develop and debug. I've seen some docs on the subject but nothing that seemed to work well. I think CLion might be the best candidate
35 2015-10-28 16:09:30 <treehug88> rephrasing: does anyone use a dev env that's not Vim or emacs?
36 2015-10-28 16:10:04 <jcorgan> such a thing exists?
37 2015-10-28 16:13:16 <zooko> I think people experimented with non-vim-non-emacs dev envs in the 2000's.
38 2015-10-28 16:14:21 <bsm1175321> Eclipse is pretty popular.
39 2015-10-28 16:14:37 <treehug88> bsm1175321 for bitcoin development?
40 2015-10-28 16:15:09 <bsm1175321> I'm a vim man.  Can't speak for anyone else.  Eclipse is the most popular *other* IDE I know of...
41 2015-10-28 16:17:19 <treehug88> bsm1175321 : me too, but I can see some benefits of using an IDE to debug/browse the code
42 2015-10-28 16:18:09 <bsm1175321> There are a tremendous number of fantastic vim plugins.  For instance YouCompleteMe
43 2015-10-28 16:19:29 <treehug88> if anyone has suggestions actually answering my questions above, I'm all ears!
44 2015-10-28 16:21:00 <bsm1175321> heheee
45 2015-10-28 16:31:08 <sipa> i use a text editor for coding, though i have used eclipse cdt in the past
46 2015-10-28 16:33:39 <treehug88> spia: thanks, that's useful. I see some references to setting that up on the web. If you have any tips about that please let me know. We'd really love to set it up in CLion here but I'll give eclipse a shot
47 2015-10-28 16:33:47 <treehug88> err, sipa
48 2015-10-28 16:34:15 <jcorgan> i used to use Eclipse and CDT a lot in the past (like 10 years ago)
49 2015-10-28 16:34:47 <jcorgan> the main issue i had was really the project management--it really wants to own the project and make stuff from the beginning
50 2015-10-28 16:35:11 <jcorgan> it works with external makefiles, but you loose a lot of the benefit
51 2015-10-28 16:35:26 <jcorgan> of course, it could have undergone major changes in the last 10 years, so who knows
52 2015-10-28 16:36:39 <treehug88> also good info, thanks jcorgan
53 2015-10-28 17:34:59 <instagibbs> from my research it doesn't appear C++ IDEs work very well
54 2015-10-28 18:31:48 <rusty> jtimon: https://github.com/rustyrussell/bitcoin/tree/bip-9-versionbits   Completely untested, but that's where I'm going...
55 2015-10-28 18:42:12 <rusty> jtimon: reworking it into C code for libconsensus will be possible, but a bit awkward, eg. BIPActive(&BIP133) instead of "BIP133.Active()".
56 2015-10-28 18:45:28 <jtimon> the important thing is keeping statefull structures out of the consensus dir
57 2015-10-28 18:47:06 <jtimon> I'm working on a skeleton with some code from CodeShark and my modifications, then you tell me if that's enough for you
58 2015-10-28 18:47:49 <sipa> rusty: how do you deal with reorgs?
59 2015-10-28 18:48:36 <rusty> sipa: the current code is completely cacheless, and recursive, building the current view of what BIP_status is based on the previous.
60 2015-10-28 18:48:54 <sipa> rusty: i don't understand
61 2015-10-28 18:48:55 <rusty> sipa: it's trivial to add a cache, but that's logically a separate patch (after tests)
62 2015-10-28 18:49:09 <sipa> you recompute the entire state for every block?
63 2015-10-28 18:49:18 <rusty> sipa: yes!
64 2015-10-28 18:49:45 <sipa> ok
65 2015-10-28 18:50:02 <rusty> sipa: dumb, but good for testing.  Then add a simple map of hash to bipstate.
66 2015-10-28 18:51:22 <sipa> rusty: which you only maintain for (x % 2016) == 0 blocks?
67 2015-10-28 18:51:28 <rusty> sipa: exactly.
68 2015-10-28 19:54:39 <jtimon> rusty I have to go now, but this is what I have: https://github.com/bitcoin/bitcoin/compare/bitcoin:master...jtimon:softforks
69 2015-10-28 19:55:34 <rusty> jtimon: yeah, it'll need a complete rework.  I'll think about it more once I've got some tests for BIP9 written.
70 2015-10-28 19:59:24 <jtimon> rusty what's most important for me it's defining Consensus::VersionBits::State as a static struct, and defining the changes to consensus/params
71 2015-10-28 20:00:06 <rusty> jtimon: yeah, I can spin on that.  Eventually you'll want the whole versionbits bip table, I think.  Making that plain C is not too hard.
72 2015-10-28 20:00:10 <jtimon> then move everything non libconsensus-almost-ready (tm) out of the consensus folder
73 2015-10-28 20:01:03 <jtimon> I have separated the table in 2: static per-chain config and changing state
74 2015-10-28 23:36:13 <denisx> sipa: is there something planned for #6077? is invalidating the cache in case of a reorg not enough to fix this problem?
75 2015-10-28 23:42:18 <sipa> denisx: that's a bit ugly... either we need the cache and it should always work, or we don't need it :)
76 2015-10-28 23:42:37 <sipa> denisx: making reorgs (even more) slower than normal operation isn't very good
77 2015-10-28 23:42:44 <denisx> sipa: how often does a reorg happen?
78 2015-10-28 23:43:00 <gmaxwell> denisx: also reorg is by far not the only area of risk in caching transaction validity.
79 2015-10-28 23:43:12 <sipa> new softforks is another
80 2015-10-28 23:43:22 <sipa> or changed consensus logic in general
81 2015-10-28 23:43:42 <sipa> or with bip68... height and timestamp
82 2015-10-28 23:43:49 <gmaxwell> it seems likely much of the reason for this being useful at all is that the sigcache is too small and inefficient (get a low hitrate for no good reason).
83 2015-10-28 23:44:58 <denisx> I thought a very nice approach to spread the work out in time before the block is validated
84 2015-10-28 23:45:18 <gmaxwell> denisx: virtually all of the work is already spread out by virtue of the sigcache.
85 2015-10-28 23:45:33 <gmaxwell> denisx: the most expensive part of validation is already cached, but at a lower level.
86 2015-10-28 23:45:52 <denisx> gmaxwell: is that a new feature?
87 2015-10-28 23:46:36 <gmaxwell> denisx: No, since 0.6 or 0.7 ish?  Wthout it most blocks now would take several seconds to validate.
88 2015-10-28 23:46:43 <sipa> 0.7