1 2015-05-01 00:44:28 <hulkhogan_> cfields_, i made a preliminary push of the jni stuff (expanding secp256k1 coverage) for you and sipa to check out .. mostly hoping to catch issues so i can fix them over the weekend, my C's a bit rusty
  2 2015-05-01 00:50:56 <hulkhogan_> anywho, do appreciate the review, i'll be floating in and out
  3 2015-05-01 01:32:07 <cfields_> jgarzik: https://github.com/theuni/bitcoin/tree/univalue
  4 2015-05-01 01:33:37 <cfields_> jgarzik: passes all tests. Only meant to be a reference for what needs attention, I certainly don't claim it's fixed properly.
  5 2015-05-01 01:33:45 <cfields_> hulkhogan_: thanks
  6 2015-05-01 01:33:53 <cfields_> i'll have a look
  7 2015-05-01 02:53:53 <notplato> I add an if ... else ... endif to makefile.test.include but I guess that the whitespace on the line before "if" caused the problem of "unexpected end of file".  So I moved the if, else, and endif to the beginning of the line.
  8 2015-05-01 02:54:43 <notplato> Now it seems that make hangs while generating the files that are supposed to be built with hexdump.  Here is the line:
  9 2015-05-01 02:54:44 <notplato> @$(OD) -v -t x1 - $< | $(SED) -n -e "s/........//p" | $(TR) "\n" " " | $(SED) -e "s/\([0-9a-f][0-9a-f]\)/0x\1,/g" >> $@
 10 2015-05-01 02:55:30 <notplato> AC_PATH_PROG(OD,od) AC_PATH_PROG(TR,tr)
 11 2015-05-01 02:55:30 <notplato> I added these to configure.ac:
 12 2015-05-01 02:57:10 <notplato> Perhaps I should have asked this question before: What does the $< mean in that line?  I thought it meant that stdin would come from an input file, and od takes - to mean that it should read input from stdin.  So that must be why it's hanging.
 13 2015-05-01 03:00:27 <notplato> Fixed.  Sorry to pollute the channel with my scribbling.  Maybe it'll help someone.  The - option to od was making it hang.
 14 2015-05-01 03:09:15 <jgarzik> cfields_, looking
 15 2015-05-01 03:11:26 <cfields_> jgarzik: feel free to take whatever you want/don't want. as discussed with sipa earlier, you probably planned to deviate from the current output formats somewhat anyway. But for the sake of testing as a whole, it was easier to just match the current output exactly for now
 16 2015-05-01 04:16:41 <notplato> make check output : PASS: test/test_bitcoin.exe FAIL: qt/test/test_bitcoin-qt.exe  Where can I look to see what failed for qt?
 17 2015-05-01 06:49:53 <fanquake> ;;blocks
 18 2015-05-01 06:49:54 <gribble> 354455
 19 2015-05-01 06:50:59 <fanquake> notplato src/qt/test/test_bitcoin-qt.log
 20 2015-05-01 10:09:43 <gdistasi> how do I unblock a wallet with bitcoin-cli without typing the password in the command and leaving it in the history?
 21 2015-05-01 10:10:04 <sipa> type a space before the command
 22 2015-05-01 10:10:15 <sipa> that way, the shell won't record it in history
 23 2015-05-01 10:10:17 <gdistasi> a space before the command?
 24 2015-05-01 10:10:19 <gdistasi> wow
 25 2015-05-01 10:10:42 <gdistasi> is it as secure as typing it in other ways?
 26 2015-05-01 10:10:50 <gdistasi> is the memory erased as soon as I typed it?
 27 2015-05-01 10:11:45 <sipa> unlikely
 28 2015-05-01 10:12:19 <sipa> you can of course use a different json-rpc client
 29 2015-05-01 10:12:43 <sipa> but the wallet passphrase is there to protect your wallet file _on disk_
 30 2015-05-01 10:12:46 <gdistasi> the trick didn't work... history reveal the pass
 31 2015-05-01 10:13:23 <sipa> if your attacker is able to read stuff from your ram, running a bitcoin wallrt on that system is not safe anyway
 32 2015-05-01 10:14:01 <sipa> bitcoind does make effort to avoid keeping secret keys or passphrases on memory
 33 2015-05-01 10:14:14 <sipa> but it is very hard to guarantee this
 34 2015-05-01 10:16:41 <gdistasi> ok... in any case on my system the space made the pass go in .bash_history anyway... I now erased the line by hand on the file :)
 35 2015-05-01 10:16:59 <gdistasi> I have a bleeding edge  arch linux
 36 2015-05-01 10:24:26 <michagogo> sipa: that space doesn't always work. It depends on your shell and how it's configured.
 37 2015-05-01 10:25:06 <michagogo> I mean, it does always work if it's set up for it
 38 2015-05-01 10:25:23 <michagogo> It doesn't work for everyone
 39 2015-05-01 10:26:09 <michagogo> gdistasi: note that your shell might still have it in memory and write it back when it quits
 40 2015-05-01 10:30:17 <paveljanik> do we have an address I can tell to people who want to support the Bitcoin Core development (e.g. in #6090).
 41 2015-05-01 10:30:19 <paveljanik> ?
 42 2015-05-01 10:33:07 <wumpus> space in front of commands works fine for me, in case of bash, but using another json-rpc client to enter the passphrase is also possible, for example there's a python script in contrib/bitrpc that explicitly asks for the passphrase
 43 2015-05-01 10:33:44 <wumpus> (that uses getpass, thus the password is also not visible while typing)
 44 2015-05-01 10:34:08 <wumpus> paveljanik: best to ask the developer you want to support directly
 45 2015-05-01 10:38:28 <gdistasi> michagogo... I had to logoff before it got written in the history
 46 2015-05-01 10:38:34 <gdistasi> then I erased it from it
 47 2015-05-01 10:53:52 <wumpus> also the passphrase will already be in bitcoin.conf in your (possibly another) disk
 48 2015-05-01 10:54:03 <wumpus> oh wait, no
 49 2015-05-01 10:54:15 <wumpus> 
ACTION was confused with the RPC password :)

 50 2015-05-01 11:05:54 <paveljanik> wumpus, I do not want to be one to choose... There is no general donation address?
 51 2015-05-01 11:06:12 <michagogo> paveljanik: well, how would it be divided?
 52 2015-05-01 11:06:31 <michagogo> There's no one donation address because of that question
 53 2015-05-01 11:06:48 <paveljanik> there are common expenses, ... ok
 54 2015-05-01 11:07:09 <michagogo> The question of "who do you want to support" needs to be answered by the donor
 55 2015-05-01 11:07:19 <michagogo> paveljanik: not much, I don't think
 56 2015-05-01 11:07:37 <paveljanik> hmm, I'll tell him the address of the project at mobbr...
 57 2015-05-01 11:07:45 <michagogo> Not sure I can think of any off the top of my head, actually
 58 2015-05-01 11:09:14 <sipa> paveljanik: in this case you helped him
 59 2015-05-01 11:09:33 <paveljanik> sure, but I want him to support the whole team instead of me.
 60 2015-05-01 11:09:55 <sipa> feel free to give an address of yours (but clearly indicate it as just yours)
 61 2015-05-01 11:10:45 <paveljanik> that exactly what I do not want to do ;-)
 62 2015-05-01 11:11:17 <michagogo> The problem is the definition of "the whole team"
 63 2015-05-01 11:12:58 <michagogo> In this case, though, he does specifically want to pay you…
 64 2015-05-01 11:18:49 <wumpus> heh, I did checkblock=0 when I meant checklevel=0 (to quickly start), so it started checking all blocks
 65 2015-05-01 11:19:10 <paveljanik> fsck over blockchain 8)
 66 2015-05-01 11:19:19 <wumpus> 
ACTION thinks we should have defined -1 as the special value, not 0

 67 2015-05-01 11:22:52 <sipa> wumpus: that was for compatibility with the older -checkblocks which checked everything
 68 2015-05-01 11:23:07 <wumpus> sipa: right, makes sense
 69 2015-05-01 11:38:37 <wumpus> <paveljanik> there are common expenses, ... ok <- yes there are a few, for example payment of travis, bitcoin.org as well as a dev server, this is currently still being paid by the Bitcoin Foundation, I don't know about the future though.
 70 2015-05-01 13:08:53 <sipa> wumpus, cfields_: so one of the problems with libconsensus or encapsulation of consensus code in general, is that it's cross-cutting; we have one organization based on datastructures/domains (script, transaction, block, proof), and one that wants to separate out everything consensus-critical. the problem is that all of these data structures have consensus-critical code and non-consensus-critical code
 71 2015-05-01 13:09:43 <wumpus> agreed on that
 72 2015-05-01 13:09:51 <sipa> i'm not sure what the solution is; so far, reorganization has mostly been done in terms of data structures (we have a script directory, and a pow file, ...)
 73 2015-05-01 13:10:05 <wumpus> I'm still not convinced that determining what is the longest chain is not part of consensus, though
 74 2015-05-01 13:10:16 <sipa> wumpus: i could agree either way
 75 2015-05-01 13:10:20 <Luke-Jr> this may be a shortcoming of C++ ;)
 76 2015-05-01 13:10:32 <Luke-Jr> with C, the code isn't tied so closely to the data
 77 2015-05-01 13:10:39 <sipa> Luke-Jr: this may be a shortcoming of directory structues being hierarchical and not dags :)
 78 2015-05-01 13:11:01 <sipa> Luke-Jr: assuming one is purely data definitions, and the other is purely code, i agree
 79 2015-05-01 13:11:04 <wumpus> I mean choosing the right chain is a consensus critical part of a bitcoin node, right?
 80 2015-05-01 13:11:21 <sipa> wumpus: well... to an extent
 81 2015-05-01 13:11:22 <cfields_> sipa: well so far, the effort has been to separate out the consensus code from the app-state. the logical next step imo is to filter out what's been separated so that it's as bare as possible
 82 2015-05-01 13:11:35 <aschildbach> I'm not sure if anyone noticed, I have worked a lot on UI design of Bitcoin Wallet lately. Here is a screenshot: https://plus.google.com/101256420499771441772/posts/izn47b4o6Dy
 83 2015-05-01 13:11:42 <Luke-Jr> files/dirs are straightforward with separate data/code
 84 2015-05-01 13:11:43 <wumpus> anyhow, I'm fine with getting rid of pow.cpp .h again
 85 2015-05-01 13:12:01 <sipa> wumpus: note that I have a PR which adds something to pow :)
 86 2015-05-01 13:12:26 <sipa> wumpus: assume someone changes the pow logic a bit, and makes a rounding error in the calculation of nChainWork (but not in the nBits/target conversion)
 87 2015-05-01 13:12:34 <wumpus> maybe that way of splitting up things was a mistake, but usually when things move around all the time something is wrong at a higher levl
 88 2015-05-01 13:13:05 <sipa> wumpus: we might see slightly more reorgs... but doing so as such will not guarantee failure to converge on the network
 89 2015-05-01 13:13:31 <sipa> wumpus: making _any_ behaviour change in script, however, will almost certainly be exploitable to cause a non-resolving fork
 90 2015-05-01 13:13:40 <wumpus> sipa: sure...
 91 2015-05-01 13:13:48 <sipa> wumpus, cfields_: i think we need a plan of where what is supposed to end up
 92 2015-05-01 13:13:57 <wumpus> well the plan is to make a consensus library
 93 2015-05-01 13:14:00 <cfields_> sipa: i'm not clear on what problem you're pointing out?
 94 2015-05-01 13:14:25 <wumpus> the last plan (that resulted in pow.cpp) wasn't really a plan, but some random move by jtimon :)
 95 2015-05-01 13:15:59 <sipa> cfields_: i guess the most baseline question is, do we want a directory structure consensus/{block,tx,script,pow}.{h,cpp}, or do we want a structure {block,tx,script,pow}/consensus.{h,cpp} :)
 96 2015-05-01 13:16:11 <sipa> i think we're now moving towards the first
 97 2015-05-01 13:16:23 <sipa> but that will for example also mean moving script/script and script/interpreter under consensus
 98 2015-05-01 13:16:30 <wumpus> cfields_: btw https://github.com/bitcoin/bitcoin/issues/5882 still happens all the time, something is wrong with the genbuild.sh script, see also https://github.com/bitcoin/bitcoin/issues/5902
 99 2015-05-01 13:17:34 <wumpus> sipa: I prefer the first, all the consensus source in one directory
100 2015-05-01 13:17:50 <jgarzik> +1
101 2015-05-01 13:18:04 <sipa> wumpus: right, so that's fundamentally incompatible with a pow.{h,cpp} file which contains all of the pow code
102 2015-05-01 13:18:09 <wumpus> cfields_: (oh I see you saw the second one)
103 2015-05-01 13:18:15 <wumpus> sipa: yes
104 2015-05-01 13:18:24 <jgarzik> though it's not a crime to have non-consensus code in consensus dir - be practical.  Do not want such a strict separation that you wind up have CFoo and CConsensusFoo for each data structure.
105 2015-05-01 13:18:24 <wumpus> sipa: if not all the pow code is consensus code
106 2015-05-01 13:18:50 <jgarzik> applying a rule strictly in source code generally leads to over-engineering ;p
107 2015-05-01 13:18:53 <sipa> jgarzik: we also have primitives, which are shared between consensus and non-consensus
108 2015-05-01 13:19:01 <wumpus> it does make sense to enforce this rule strictly
109 2015-05-01 13:19:11 <sipa> script/script would i guess become primitive
110 2015-05-01 13:19:24 <sipa> while script/interpreter would become consensus
111 2015-05-01 13:19:30 <sipa> script/sign would become wallet
112 2015-05-01 13:19:34 <cfields_> sipa: frankly, i haven't given that much thought. Up to this point, I've only been concerned with decoupling things. I think trying to engineer a logical file/dir structure before that's done will just cause more shuffling later
113 2015-05-01 13:19:40 <wumpus> if that results in some duplication that's not the end of the world, though I agree it shouldn't result in an overdesigned mess
114 2015-05-01 13:20:00 <sipa> cfields_: right, that's fine by me, but at some point we need to pick one priority over the other
115 2015-05-01 13:20:25 <sipa> and it seems we're here with a conflict - "a pow file that encapsulates all of pow" or "consensus that contains only consensus"
116 2015-05-01 13:20:31 <sipa> and it seems we're choosing the second
117 2015-05-01 13:21:09 <wumpus> yes
118 2015-05-01 13:21:19 <jgarzik> does libconsensus have a user?
119 2015-05-01 13:21:24 <jgarzik> besides bitcoind
120 2015-05-01 13:21:24 <wumpus> yes, me
121 2015-05-01 13:22:01 <jgarzik> wumpus, what is your project which links to libconsensus?
122 2015-05-01 13:22:01 <sipa> i think that question is not very relevant at this point - i think effectively decoupling consensus from utility/policy code is much more important that actually exposing its logic in a C api
123 2015-05-01 13:22:29 <sipa> if we end up with that, we can have separate review processes for example, for anything that will touch consensus code
124 2015-05-01 13:22:35 <wumpus> jgarzik: some testing/validation/fuzzing stuff
125 2015-05-01 13:23:02 <sipa> and more importantly, it means we can be much more assured about other changes, which don't touch those files, to not risk changing consensus
126 2015-05-01 13:23:11 <wumpus> sipa: agreed, that's much more important
127 2015-05-01 13:23:31 <cfields_> sipa: agreed very much. I'd rather get to a point where we can choose what we want to expose and expose it, rather than working the other way of trying to expose something and separating things out to make that happen
128 2015-05-01 13:23:58 <wumpus> the whole point is to have stronger review criteria for consensus code
129 2015-05-01 13:24:15 <wumpus> which is *much* easier if it's isolated in one directory and as minimal as possible
130 2015-05-01 13:25:33 <wumpus> and I don't think it's interesting at all if any other node implementations are using it at the moment, they all *could* be adopted to use it
131 2015-05-01 13:26:28 <wumpus> and that'd bring some reassurance to the users that they won't be forked for a stupid reason
132 2015-05-01 13:27:57 <cfields_> sipa: as far as structures go, i'd hoped to create a split like this one: https://github.com/bitcoin/bitcoin/pull/5458
133 2015-05-01 13:28:17 <sipa> cfields_: you know my opinion about that
134 2015-05-01 13:28:21 <cfields_> my intention was to do that for all of the "primitive" structures.
135 2015-05-01 13:29:00 <wumpus> "Specifically, I think uint256 should be separated into a bytes32 type or something which is just storage (but does have comparison operators, so it can be used as key in a map), but doesn't have any arithmetic logic." well at least that part was done
136 2015-05-01 13:30:19 <sipa> yup!
137 2015-05-01 13:30:37 <sipa> another problem area is CService/CNetAddr
138 2015-05-01 13:30:59 <sipa> i guess those can use a split base type and extended utility type (think cfields_ pointed that out)
139 2015-05-01 13:31:38 <cfields_> sipa: yea. I should've used those as a better example for 5458, but that would've been a ton of work for a POC
140 2015-05-01 13:31:48 <wumpus> those don't really matter in this scope?
141 2015-05-01 13:32:08 <sipa> not for consensus, as CAddress doesn't appear in any consensus-critical structure
142 2015-05-01 13:32:08 <wumpus> I mean, CService/CNetaddr have nothing to do with consensus or primitive data types right?
143 2015-05-01 13:32:22 <wumpus> I'm not sure why they would need to be spit up, then
144 2015-05-01 13:32:24 <cfields_> wumpus: in the consensus scope no, but from a general organizational standpoint
145 2015-05-01 13:32:24 <sipa> but for transaction/txin/txout/block/header i think we should just only have the primitive types, and anything that's more that serialization/construction should become some utility function (wherever they belong) rather than a method
146 2015-05-01 13:32:43 <wumpus> sipa: agreed, I like that more than using inheritance
147 2015-05-01 13:32:56 <sipa> same for script (where it's a lot harder...)
148 2015-05-01 13:33:28 <sipa> primitive/script would be a very thing wrapper around vector<unsigned char> (as that's all that's needed for serialization)
149 2015-05-01 13:33:31 <wumpus> script could just be a list of utility function acting on a vector<uint8> or even just a memory slice
150 2015-05-01 13:33:35 <sipa> yeah
151 2015-05-01 13:33:39 <cfields_> i don't necessarily agree, but i'd be perfectly fine with that. my hope was to rip out the base parts of the primitives, the inheritance was just the logical approach to me
152 2015-05-01 13:34:11 <wumpus> the latter would leave the actual in-memory type to the caller, so they could be packed into one large byte array for example
153 2015-05-01 13:34:20 <cfields_> wumpus: for script, very much so :)
154 2015-05-01 13:34:59 <wumpus> (of course, the mutating functions would act on a vector, but the const functions need not)
155 2015-05-01 13:35:21 <sipa> problem is that a lot of CScript methods are currently used by consensus
156 2015-05-01 13:35:21 <wumpus> (this is useful inthe scope of optimizing the memory usage of ccoinsview)
157 2015-05-01 13:35:31 <sipa> so we can't even change or improve them without risking consensus changes
158 2015-05-01 13:35:51 <sipa> i think in this case it's reasonable to even potentially copy them
159 2015-05-01 13:35:55 <wumpus> some mechanical rewriting could be done though
160 2015-05-01 13:35:58 <sipa> and then let one side evolve, but not touch the other
161 2015-05-01 13:38:36 <wumpus> I mean a change that changes the methods to act on an object that is explicitly passed in, instead of *this, would be easy to review
162 2015-05-01 13:39:29 <wumpus> after that yes you could have more sets of them, one for consensus one for say, creating and building script utilities
163 2015-05-01 13:39:46 <cfields_> sets of them?
164 2015-05-01 13:40:04 <wumpus> what sipa is saying
165 2015-05-01 13:40:21 <cfields_> script utility functions?
166 2015-05-01 13:40:22 <wumpus> make a copy for consensus, never touch that again
167 2015-05-01 13:40:40 <wumpus> then evolve and improve the other one
168 2015-05-01 13:41:02 <wumpus> yes, functions that act on a script
169 2015-05-01 13:41:11 <sipa> i once had a PR that improved how numbers are pushed onto a script
170 2015-05-01 13:41:22 <sipa> turns out, it would have caused a hardfork
171 2015-05-01 13:41:35 <sipa> very scary :)
172 2015-05-01 13:41:46 <cfields_> heh, the scriptnum stuff is a mess
173 2015-05-01 13:42:05 <wumpus> is it?
174 2015-05-01 13:42:12 <sipa> also, for consensus you don't need any mutability
175 2015-05-01 13:42:21 <sipa> while utility stuff does
176 2015-05-01 13:42:48 <wumpus> true
177 2015-05-01 13:46:29 <cfields_> so sipa: would you prefer that i/we hold up on the separation until a more long-term plan is established? From my pov, it's mostly been pretty straightforward app-state decoupling. I can see how it may look like flailing to an observer, though
178 2015-05-01 13:46:47 <sipa> cfields_: which PRs in particular?
179 2015-05-01 13:47:03 <sipa> i don't like 5458
180 2015-05-01 13:47:21 <sipa> the rest of the refactors are fine i guess - it's just a lot to review
181 2015-05-01 13:47:32 <sipa> but knowing what the general idea is about what we're trying to reach is good
182 2015-05-01 13:48:07 <cfields_> sipa: 6055 is the kind of decoupling i'm speaking of here
183 2015-05-01 13:48:47 <sipa> cfields_: just acked that :)
184 2015-05-01 13:48:53 <sipa> no, that's perfectly fine
185 2015-05-01 13:49:18 <cfields_> sipa: right. but that's the kind of work that i have queued up that i can put a hold on if you'd like to look at long-term organization first
186 2015-05-01 13:50:33 <sipa> cfields_: i think the general consensus is: move consensus logic into consensus directory, move methods of primitive types to utility/consensus functions
187 2015-05-01 13:50:45 <sipa> i hate using consensus in two meanings here
188 2015-05-01 13:51:12 <sipa> cfields_: i don't want to put anything on hold... just thought it might help if we were clear on what was supposed to happen
189 2015-05-01 13:52:17 <cfields_> sipa: well i suppose what may not be clear is that i've been ignoring the structure/organization of things for the sake of de-tangling first. so any kind of structure that's evolved from those movements has been purely accidental (on my part at least)
190 2015-05-01 13:52:39 <sipa> cfields_: i'm fine with any de-tangling that doesn't move stuff
191 2015-05-01 13:52:56 <sipa> cfields_: yes, i see, not a criticism
192 2015-05-01 13:57:34 <cfields_> wumpus: bah, looks like i let #5882 slip again. Sorry about that. Will address it today.
193 2015-05-01 14:00:52 <sipa> opinions on 5875?
194 2015-05-01 14:01:04 <wumpus> cfields_: it's not super-urgent, but everything that adds to the spam in the travis log is a nuisance :)
195 2015-05-01 14:03:24 <cfields_> wumpus: agreed. I have some other work on travis that i was holding off on until they fix a few issues on their end. It cleans up the output substantially. I'll go ahead and PR the chunk of that that's ready.
196 2015-05-01 14:08:20 <wumpus> sipa: concept ack, but seems hard to test
197 2015-05-01 14:08:31 <cfields_> wumpus: are you still interested in univalue for 0.11 ?
198 2015-05-01 14:09:16 <wumpus> cfields_: not for 0.11, but I'd like to merge it as soon as possible after 0.11 is split off
199 2015-05-01 14:09:23 <sdaftuar> wumpus: i'll rebase 5875 now that the python p2p testing framework is in, and include a test that might be helpful
200 2015-05-01 14:09:38 <wumpus> sdaftuar: great!
201 2015-05-01 14:09:53 <sipa> sdaftuar: ah, nice
202 2015-05-01 14:10:49 <sdaftuar> thanks for merging the python! :)  (though at this moment i'm trying to fix a race condition i overlooked in the initial pull)
203 2015-05-01 14:13:31 <wumpus> cfields_: (e.g., it's not the time for such a big overhaul, let's not take the risk of breaking some subtle edge cases in RPC last-minute before the 0.11 release, then spend months tweaking 0.11 instead of fixing them in master before the 0.12 release)
204 2015-05-01 14:14:32 <cfields_> wumpus: understood.
205 2015-05-01 14:15:13 <wumpus> but don't get me wrong, I don't want to postpone it or stop moving forward with it, it's just a matter of when merging it
206 2015-05-01 14:16:58 <Luke-Jr> easier to live with not merging stuff for a release, when you realise there's no inherent rate limit to releases ;)
207 2015-05-01 14:17:04 <Luke-Jr> worst case it's just another 6 months
208 2015-05-01 14:18:32 <sipa> imho, if we're going for scheduled releases, it means we shouldn't reason in terms of "do we want X for 0.11", we should just ask "is X ready to be merged" - which goes both ways (don't delay releases for things you want in a release, but also don't hold off merging because you're close to one)
209 2015-05-01 14:21:02 <Luke-Jr> well, "is X ready to be merged" may have varying definitions/standards depending on proximity to merge window. in this case, perhaps univalue has not had enough testing to be merged, but it is presumed it will inherently get testing before 0.12 if we merge it after branching 0.11
210 2015-05-01 14:21:44 <sipa> univalue has not had any testing, probably, which is good reason not to merge it now :)
211 2015-05-01 14:23:00 <sipa> also, i think there is low risk for dangerous errors in univalue - it's just the encoding layer for RPC, so i'm less worried about having it in a release
212 2015-05-01 14:23:14 <sipa> anyway, right now, it's just not ready, no question about that
213 2015-05-01 14:45:57 <morcos> i wasn't around when the 6 month release schedule was originally planned out, but doesn't it seem like a bit too much overhead is spent on doing releases and it might be nicer to have the spaced out a little more.
214 2015-05-01 14:46:50 <morcos> what is in master now, that we really want to get released quickly?  i suppose pruning, but it seems like it might be nice to take the time to do wallet support and relaying first
215 2015-05-01 14:47:33 <morcos> and there seem to be a couple other changes that would be nice to get in before we do all the overhead of a release again, such as CPFP, CLTV, and the new fee estimation.. :)
216 2015-05-01 14:48:04 <morcos> anyway, sorry if this is rehashing old arguments
217 2015-05-01 14:51:00 <sipa> morcos: well, i don't think releases as such as that much work on their own
218 2015-05-01 14:51:59 <sipa> but 0.10 required much work after it branched off (0.10.0 was delayed, and we quickly needed a 0.10.1), which caused attentioned to shift a bit away from 0.11
219 2015-05-01 14:52:44 <sipa> if we can do 0.11 as a relatively conservative one, we probably have more time to actually master, rather than fix things after the fact
220 2015-05-01 14:52:45 <morcos> well i was thinking more about the rather narrow window that exists after concentrating on bug fixes for the first minor release and before attention is devoted to testing for the next major release
221 2015-05-01 14:53:30 <sipa> not sure what you mean now
222 2015-05-01 14:53:36 <morcos> yes... perhaps.  i suppose 0.10 was a more significant change that both
223 2015-05-01 14:54:15 <morcos> more or less what you said, about 0.10.1 occupying our attention to recently, and then the merge window for 0.11 ending so soon after that
224 2015-05-01 14:54:25 <morcos> s/that both/than most/
225 2015-05-01 14:54:41 <sipa> but that is also why i think we should not delay merging things that are ready, even if they are big
226 2015-05-01 14:55:11 <sipa> master is pretty stable now, i think
227 2015-05-01 14:55:33 <morcos> is their agreement that CLTV for standard should go in?  i've been working on reviewing that and will post on the PR when done
228 2015-05-01 14:55:39 <morcos> i really can't spell
229 2015-05-01 14:56:09 <sipa> i should look at that again, no conceptual disagreement from me
230 2015-05-01 14:57:01 <Luke-Jr> I think there's a general idea that we want RCLTV though
231 2015-05-01 14:57:53 <morcos> yeah i wasn't clear on whether RCLTV was a blocker for CLTV, does it change the eventual desired semantics for the non R version?  perhaps i need to reread all that
232 2015-05-01 15:00:38 <sipa> i think cltv and rcltv are independent
233 2015-05-01 15:01:30 <sipa> there are several ideas
234 2015-05-01 15:02:09 <Luke-Jr> is there anything CLTV is needed for that RCLTV doesn't also satisfy?
235 2015-05-01 15:03:09 <sipa> that is a good question
236 2015-05-01 15:06:17 <StephenM347> I thought RCLTV was somewhat more dangerous than CLTV as it is not quite reorg-safe?
237 2015-05-01 15:08:22 <Luke-Jr> well, it's more complicated to implement
238 2015-05-01 15:08:31 <sipa> StephenM347: there are different proposals; some are reorg saff
239 2015-05-01 15:13:43 <zooko> Is the definition of "reorg-safe" written down somewhere that I can bookmark? Because it's one of those things that repeatedly falls out of my head.
240 2015-05-01 15:15:00 <sipa> zooko: it mesns that assuming no double spends, transactions can move to a reorg
241 2015-05-01 15:15:50 <sipa> coinbase transactions are by definition not reorg safe, but the impact of this is mitigated by requiring 100 blocks on top before they're spendable
242 2015-05-01 15:16:17 <StephenM347> From http://permalink.gmane.org/gmane.comp.bitcoin.devel/7409: "Thus RCTLV is only reorg safe if the height is compared against the actual block height of the block containing the spending transaction, not the spending transaction's nLockTime."
243 2015-05-01 15:18:33 <zooko> sipa: Thanks. I am still a bit unclear on the concept. It seems like requiring all transactions (excl coinbases) to be reorg-safe is a way to optimize out the work of
244 2015-05-01 15:18:42 <zooko> replaying all transactions in order to do a reorg. Is that right?
245 2015-05-01 15:19:00 <zooko> Oh, no it isn't that simple.
246 2015-05-01 15:19:26 <sipa> zooko: it's just to prevent a random non-malicious reorg from invalidating a non-malicious transaction
247 2015-05-01 15:19:41 <zooko> The reason I might care is that if I rely on a well-committed reorg-safe txn then I can be assured that txn will still be valid after a reorg, modulo coinbases and double-spends.
248 2015-05-01 15:19:49 <zooko> Okay, thanks.
249 2015-05-01 15:20:35 <sipa> many constructs that contain height comparisons introduce edge conditions, where if one transaction moves to a new chains, a spending transactions can become invalid
250 2015-05-01 15:21:23 <sipa> zooko: the most obvious way to introduce non-reorg-safeness is giving transactions a max height or time by which they need to be included in the chain
251 2015-05-01 15:25:02 <dgenr8> there is an edge condition every ~10 minutes ;p
252 2015-05-01 16:56:14 <cfields_> jonasschnelli: i'm very confused by the current locale code. Would you like me to jump in and play around, or would I just be stirring up dust?
253 2015-05-01 16:56:53 <jonasschnelli> cfields_: no. I think it would be very good if you could have a look at it.
254 2015-05-01 16:57:10 <jonasschnelli> It seems to be that this was always a problem.
255 2015-05-01 16:57:29 <cfields_> yes, it looks like it should be imo. a weird combo of things are done
256 2015-05-01 16:57:45 <jonasschnelli> I just tried 0.9.2 on window7 and window8 with Chinese language and Chinese chars in datadir.
257 2015-05-01 16:57:49 <cfields_> how to reproduce the win problem? is switching the language and creating a new user enough (win7) ?
258 2015-05-01 16:57:49 <jonasschnelli> boom. Exception
259 2015-05-01 16:57:57 <jonasschnelli> Right
260 2015-05-01 16:58:02 <cfields_> ok
261 2015-05-01 16:58:13 <jonasschnelli> i did change language and created a user with some chinese chars...
262 2015-05-01 16:58:24 <gribble> Chinese characters - Wikipedia, the free encyclopedia: <http://en.wikipedia.org/wiki/Chinese_characters>; Common Chinese Characters - Most Common 2500 Chinese ...: <http://www.commonchinesecharacters.com/>; Character full list - Learn Chinese Characters - Chinese-Tools.com: <http://www.chinese-tools.com/learn/characters/list.html>
263 2015-05-01 16:58:24 <jonasschnelli> ;;google chinese-chars
264 2015-05-01 16:58:41 <jonasschnelli> copy'n'paste some from the google findings would probably be enought
265 2015-05-01 16:58:46 <cfields_> thanks
266 2015-05-01 16:59:22 <jonasschnelli> i lost fun in hunting this down... it probably needs a "bigger brain". :)
267 2015-05-01 17:00:31 <wumpus> it may have been always a problem, but fact is that it did become worse with 0.10.1
268 2015-05-01 17:00:37 <cfields_> heh, then we're screwed :)
269 2015-05-01 17:02:58 <wumpus> I got it pretty much to work in 0.10
270 2015-05-01 17:05:47 <cfields_> jonasschnelli: dir cannot be created, but no crash. Is that what's to be expected atm?
271 2015-05-01 17:06:07 <wumpus> re:boost you can force utf-8 locale on windows, but from what I read back then that's discouraged
272 2015-05-01 17:06:20 <jonasschnelli> cfields_: hmm... you should get a exception
273 2015-05-01 17:06:23 <jonasschnelli> (crash)
274 2015-05-01 17:06:36 <cfields_> (this is 0.10.1 final i believe)
275 2015-05-01 17:06:38 <Luke-Jr> 
ACTION ponders if David and Tom Harding are related.

276 2015-05-01 17:08:00 <jonasschnelli> http://i.imgur.com/ZNELs4q.png
277 2015-05-01 17:08:00 <jonasschnelli> i normally see something like this:
278 2015-05-01 17:09:24 <cfields_> jonasschnelli: ah, i tested bitcoin-qt
279 2015-05-01 17:09:26 <jonasschnelli> cfields_: but i suppose there are many other cross-platform apps that uses boost and run on windows even with data/paths in users with Chinese chars.
280 2015-05-01 17:10:03 <jonasschnelli> cfields_: bitcoin-qt is a bit different. I had some strange chars in the propose datadir within the "choose-your-datadir-screen".
281 2015-05-01 17:10:18 <jonasschnelli> I could change the dir with the fileopen-promt-alert, but still ran into a crash
282 2015-05-01 17:14:03 <zooko> Does the exception generate diagnostic information?
283 2015-05-01 17:14:13 <zooko> Or maybe -- I forget how to C++ -- you have to run it under a debugger?
284 2015-05-01 17:37:29 <harding> Luke-Jr: I never knew dgenr8 before chatting with him in this very chatroom, and I don't know of any relatives named Tom Harding.  So we're likely only distantly related.
285 2015-05-01 17:38:11 <sipa> harding: omg!~
286 2015-05-01 17:38:20 <sipa> i always thought you were the same...
287 2015-05-01 17:38:47 <harding> sipa: haha, nope. :-)
288 2015-05-01 17:39:10 <sipa> wait, which of you is the one maintaining the dev documentation on the bitcoin.org?
289 2015-05-01 17:39:15 <harding> sipa: me
290 2015-05-01 17:39:18 <sipa> oh!
291 2015-05-01 17:39:23 <dgenr8> sipa: shocking ... David is the very model of uncontroversial ;)  harding: i have a crapload of genealogy info, might be interesting ... i'll PM
292 2015-05-01 17:39:54 <sipa> point is, i never saw harding's first name, and since it matched dgenr8's last name (which i did know), i assumed you were the same...
293 2015-05-01 17:39:58 <sipa> i apologize!
294 2015-05-01 17:42:54 <harding> Actually, I've always wondered how many people wondered if we were related :-)
295 2015-05-01 17:45:18 <dgenr8> wumpus: will follow your quest to decide if FindMostWorkChain is consensus-critical with great interest
296 2015-05-01 17:46:29 <sipa> i think the point is that inherently pretty much every piece of software on your computer is consensus critical... a bug in the kernel or libc can definitely cause forks
297 2015-05-01 17:46:45 <sipa> a bug in the kernel might even expose other programs to your memory space, causing forks
298 2015-05-01 17:47:14 <sipa> we also consensider leveldb to be consensus-critical in a way, because a bug in it may affect convergence
299 2015-05-01 17:47:25 <dgenr8> yeah, agreed
300 2015-05-01 17:47:31 <sipa> and in that sense, findmostworkchain etc... is definitely critical
301 2015-05-01 17:48:15 <sipa> but i think we should make a distinction between "if you do this wrong, you will inevitably create a forking risk", and "bugs here may affect convergence"
302 2015-05-01 17:48:45 <sipa> findmostworkchain can probably demonstrably be changed in a way that does not create permanent forks
303 2015-05-01 17:49:07 <dgenr8> :) and maybe that do very useful things?
304 2015-05-01 17:49:41 <sipa> ?
305 2015-05-01 17:51:11 <dgenr8> sipa: interested in your opinion on 6068
306 2015-05-01 17:51:52 <notplato> if I alter configure.ac, then I need to rerun autogen.sh, not just configure, right?
307 2015-05-01 17:53:03 <dgenr8> sipa: for instance there was discussion on bct about blockstream toying with variable difficulty to address sidechain security
308 2015-05-01 17:53:32 <sipa> dgenr8: what does that have to do with 6068?
309 2015-05-01 17:53:40 <sipa> that's about that sidechain's consensus rules
310 2015-05-01 17:53:46 <sipa> not about bitcoin's relay rules
311 2015-05-01 17:53:53 <dgenr8> was responding to your '?'
312 2015-05-01 17:54:05 <sipa> ah, sure
313 2015-05-01 17:54:45 <sipa> something like that would be implemented in things like GetNextBlockProof etc
314 2015-05-01 17:55:05 <sipa> as that would definitely be a consensus rule (ability to change difficulty is not allowed in bitcoin)
315 2015-05-01 17:55:28 <sipa> and as i said, findmostworkchain right now does not abey that "stricter" definition of consensus
316 2015-05-01 18:00:38 <dgenr8> yes, var diff not the best example then.  i have a better example but won't troll.  for findmostworkchain, doesn't it depend on the change?  for example, suddenly treating chainwork as (chainwork%2 ? chainwork : chainwork/2) would fork
317 2015-05-01 18:01:03 <sipa> yes
318 2015-05-01 18:01:05 <sipa> of course
319 2015-05-01 18:01:11 <sipa> re-read what i said
320 2015-05-01 18:01:19 <sipa> "bugs here may affect convergence"
321 2015-05-01 18:02:05 <zooko> ok
322 2015-05-01 18:02:08 <zooko> oops, wrong chan
323 2015-05-01 18:12:55 <notplato> From src, I did make check.  It reports PASS: test/test_bitcoin.exe FAIL: qt/test/test_bitcoin-qt.exe.  I searched src and subfolders for *.log and found only one, config.log.  Shouldn't I be getting a log for the test_bitcoin-qt.exe FAIL?
324 2015-05-01 18:13:07 <sipa> run it manually
325 2015-05-01 18:13:40 <sipa> src/test-suite.log is what you are looking for
326 2015-05-01 18:23:05 <hulkhogan_> is 4769 still on track for 0.11?
327 2015-05-01 18:23:42 <hulkhogan_> there hasn't been much from the original submitter since it was put in
328 2015-05-01 18:25:18 <sipa> hulkhogan_: in theory, that PR should do exactly nothing
329 2015-05-01 18:25:54 <hulkhogan_> well, i wanted to write negative tests for it, if it was still going in (needs tests)
330 2015-05-01 18:26:07 <sipa> hulkhogan_: oh, please do
331 2015-05-01 18:26:16 <sipa> hulkhogan_: cherry-pick his commit, rebase it, and add tests
332 2015-05-01 18:26:27 <hulkhogan_> sounds good
333 2015-05-01 18:26:32 <wumpus> depends on whether it's ready before the feature freeze (so by the 15th of this month)
334 2015-05-01 18:26:38 <wumpus> if you can help there, that's great!
335 2015-05-01 18:27:05 <sipa> hmm, i do wonder what actually happens in that case
336 2015-05-01 18:27:27 <sipa> does it disconnect the peer if we catch such an error?
337 2015-05-01 18:27:39 <sipa> that may be not what we want
338 2015-05-01 18:27:55 <sipa> as this is about _us_ accidentally sending a larger message than we think should be possible
339 2015-05-01 18:30:56 <hulkhogan_> it just throws
340 2015-05-01 18:31:49 <ajweiss> doesn't the code stop processing messages if the outbound buffer gets too far behind already?
341 2015-05-01 18:33:05 <sipa> ajweiss: yes, but this is about the size of single message
342 2015-05-01 18:33:30 <sipa> hulkhogan_: "throwing an exception" is not application behaviour
343 2015-05-01 18:33:51 <sipa> i can see that it throws an exception, but i mean... where is it caught, and what happens then?
344 2015-05-01 18:34:10 <hulkhogan_> right lol, didnt check
345 2015-05-01 18:34:17 <hulkhogan_> good to figure that one
346 2015-05-01 18:34:42 <hulkhogan_> might even be me..
347 2015-05-01 19:01:15 <cfields_> jonasschnelli: are win32 "bitcoind.exe /?" strings supposed to be translated?
348 2015-05-01 19:01:24 <cfields_> hulkhogan_: i swear i haven't forgotten about you!
349 2015-05-01 19:01:51 <sipa> cfields_: only bitcoin-qt, i think?
350 2015-05-01 19:01:57 <sipa> or am i mistaken
351 2015-05-01 19:02:24 <cfields_> sipa: that's what i'm hoping :)
352 2015-05-01 19:03:14 <cfields_> jonasschnelli: if that's the case, i think i have the win32 locale problem cracked
353 2015-05-01 19:04:06 <cfields_> on win32, presumably because we're using mingw, the c++ locales are of no use. But the good ol' c setlocale(LC_ALL,"") works as intended
354 2015-05-01 19:05:22 <sipa> heh
355 2015-05-01 19:05:55 <chile> hola
356 2015-05-01 19:06:26 <cfields_> so using c to set the localized locale, then using std::locale to grab it and imbue boost::path, all is (seems?) happy
357 2015-05-01 19:06:55 <chile> tengo una duda que siempre he tenido
358 2015-05-01 19:07:10 <sipa> chile: english please
359 2015-05-01 19:07:27 <chile> ok
360 2015-05-01 19:07:59 <chile> I have a doubt
361 2015-05-01 19:09:22 <chile> ponzi these pages when they promise to return the 200 % of your bitcoins at a certain time and then fleeing with bitcoin that lowers the value of bitcoin ?
362 2015-05-01 19:09:43 <sipa> chile: #bitcoin
363 2015-05-01 19:36:50 <hulkhogan_> any quick way to run boost tests in isolation?
364 2015-05-01 19:37:23 <hulkhogan_> nvm, found option for it
365 2015-05-01 20:24:14 <cfields_> jonasschnelli: half a day wasted on the locale thing for me too, now we're even :)
366 2015-05-01 21:33:45 <s7r> do we have log rotation (for debug.log) in bitcoin 0.10 or does that logfile grow infinitely? I did a cat debug.log and it took quite a bit of time so just wanted to check
367 2015-05-01 21:36:38 <helo> indefinitely (until restart)
368 2015-05-01 21:36:55 <s7r> helo restart bitcoind daemon or server?
369 2015-05-01 21:37:02 <helo> daemon
370 2015-05-01 21:37:53 <helo> hmm, well i thought it grew indefinitely, but i don't see the startup at the beginning of mine. i shouldn't have commented without verifying heh
371 2015-05-01 21:37:54 <warren> I haven't tried logrotate on debug.log, does bitcoind automatically use a new log if rotated?
372 2015-05-01 21:38:20 <warren> There's a standard to induce daemons to respect logrotate
373 2015-05-01 21:38:21 <sipa> warren: logrotate should work
374 2015-05-01 21:38:34 <sipa> if bitcoin receives a sighup, it will close and reopen the file
375 2015-05-01 21:38:45 <warren> ah
376 2015-05-01 21:39:04 <s7r> sipa so just create a bitcoin file in /etc/logrotate.d ?
377 2015-05-01 21:39:11 <s7r> that will do the trick?
378 2015-05-01 21:39:26 <sipa> i've never configured logrotate myself
379 2015-05-01 21:39:32 <sipa> so i can't promise that :)
380 2015-05-01 21:39:33 <s7r> helo your startup should be there
381 2015-05-01 21:39:59 <sipa> you need a postrotate killall -HUP bitcoind
382 2015-05-01 21:40:18 <helo> s7r: i was wrong, it does not truncate on startup
383 2015-05-01 21:40:56 <s7r> it grows infinitely then?
384 2015-05-01 21:41:08 <sipa> helo: it does
385 2015-05-01 21:41:15 <sipa> helo: unless -debug
386 2015-05-01 21:42:13 <helo> hmm, i'm not using -debug, but i have 11 occurrences of "Bitcoin version" in my log
387 2015-05-01 21:44:31 <s7r> sipa I have configured logrotate for debug.log and worked, it cleared the log
388 2015-05-01 21:44:37 <s7r> wonder if this will affect functionality in any way
389 2015-05-01 21:44:45 <helo> you should be fine
390 2015-05-01 21:44:46 <s7r> like time offset tracking or peer banscore?
391 2015-05-01 21:45:08 <s7r> right now I have debug.log and debug.log.1 (normal for logrotation) wonder when debug.log.1 will be removed...
392 2015-05-01 21:45:12 <sipa> s7r: peer banscore goes in, but peer ip's do not
393 2015-05-01 21:45:24 <sipa> etc
394 2015-05-01 21:45:24 <sipa> s7r: debug.log.1 will move to debug.log.2
395 2015-05-01 21:45:31 <sipa> until logrotate is configured for delete
396 2015-05-01 21:45:58 <s7r> why don't we make this a default
397 2015-05-01 21:46:00 <s7r> for bitcoind
398 2015-05-01 21:46:03 <s7r> what do we need infinite logs for
399 2015-05-01 21:46:14 <sipa> make what the default?
400 2015-05-01 21:46:26 <s7r> a logrotation system
401 2015-05-01 21:46:36 <sipa> not bitcoin's responsibility
402 2015-05-01 21:46:40 <sipa> use logrotate if you want it
403 2015-05-01 21:46:48 <sipa> and it doesn't have infinite logs - they get truncated
404 2015-05-01 21:47:35 <s7r> ok. thanks
405 2015-05-01 21:47:48 <sipa> good to know that logrotate works :)
406 2015-05-01 21:47:52 <s7r> so i use log rotation now. this will not affect its functionality in any way
407 2015-05-01 21:47:57 <sipa> no
408 2015-05-01 21:48:02 <s7r> because I can disable it if this is the case, don't have disk space problems
409 2015-05-01 21:48:16 <sipa> debug logging doesn't have any functionality, except logging...
410 2015-05-01 21:48:21 <s7r> now just the file being in /etc/logrotate.d will make it happen automatically or do I need to tell logrotate about it ?
411 2015-05-01 21:48:28 <s7r> like enable the config file somehow
412 2015-05-01 21:48:42 <sipa> no clue, ask logrotate people, or read the documentation :)
413 2015-05-01 21:49:35 <s7r> thanks - will do
414 2015-05-01 23:38:31 <hulkhogan_> hm, would testing specific p2p message behavior be better done with an rpc, or unit test?
415 2015-05-01 23:39:01 <hulkhogan_> i'm not too familiar with the networking to be sure...