1 2015-05-12 00:26:12 <hulkhogan_> some progress on that bug from yday, jni not behaving so well when given compressed keys, OK for decompressed, interesting case..
  2 2015-05-12 00:34:14 <hulkhogan_> yea i wasn't allocating enough mem for the pubkey when it expanded, hence all the oddness.. thats the last time i do memory allocation in the middle of the night (hah)
  3 2015-05-12 01:47:18 <andytoshi> hulkhogan_: you should try running stuff in valgrind when you're getting segfaults
  4 2015-05-12 01:55:04 <hulkhogan_> Yeah, I should, i just dont know how to read the output of valgrind, or never really tried
  5 2015-05-12 01:55:22 <sipa> hulkhogan_: just run it :)
  6 2015-05-12 01:55:37 <hulkhogan_> haha will do, on my next segfault
  7 2015-05-12 01:55:45 <andytoshi> if there's an actual segfault the output is really clear
  8 2015-05-12 01:56:24 <hulkhogan_> i was having issues yesterday since i'm running it on make
  9 2015-05-12 01:56:33 <hulkhogan_> and it was calling out to java
 10 2015-05-12 01:56:54 <hulkhogan_> have to make it follow forked procs
 11 2015-05-12 02:07:27 <hulkhogan_> having some trouble with the DER stuff, is there anywhere i can find out more about that?
 12 2015-05-12 02:08:57 <kanzure> probably in the openssl source vcode
 13 2015-05-12 02:09:00 <kanzure> *source code
 14 2015-05-12 02:13:56 <hulkhogan_> i hate trying to write c at night, my brain stops allocating cycles to figure out the memory mgmt shit
 15 2015-05-12 02:14:15 <hulkhogan_> thanks kanzure, ive got something
 16 2015-05-12 05:29:31 <volante> anyone seen this build failure?  ./compat/endian.h:109:17: error: expected unqualified-id before '__extension__'
 17 2015-05-12 05:29:38 <volante> i get it when i try to build the current master branch
 18 2015-05-12 05:29:48 <Luke-Jr> what compiler?
 19 2015-05-12 05:30:17 <volante> g++ 4.7.2
 20 2015-05-12 05:31:02 <Luke-Jr> and distro?
 21 2015-05-12 05:31:25 <volante> Debian 7
 22 2015-05-12 05:31:51 <Luke-Jr> you're sure it's current master? pretty sure this was fixed once already
 23 2015-05-12 05:33:15 <volante> i'm on commit 7e0e7f82
 24 2015-05-12 05:33:56 <volante> i ran autogen.sh, then configure and then make
 25 2015-05-12 05:33:57 <volante> i ran autogen.sh, then configure and then make
 26 2015-05-12 05:38:04 <Luke-Jr> is this a new git clone, or old?
 27 2015-05-12 05:38:26 <volante> old
 28 2015-05-12 05:38:30 <Luke-Jr> find -name bitcoin-config.h  # run this and tell me how many files it find
 29 2015-05-12 05:38:53 <volante> two (one in src/ and one in src/config/)
 30 2015-05-12 05:42:22 <volante> should i be removing one of them?
 31 2015-05-12 05:44:01 <volante> removing the src/ one seems to have fixed the error.  thanks Luke-Jr :)
 32 2015-05-12 05:44:28 <Luke-Jr> np
 33 2015-05-12 06:09:50 <ScarfFace> What would be your best guess, would a Payment Channel Hub be required to get a Licence, will it be considered a MSB?
 34 2015-05-12 06:10:18 <Luke-Jr> ScarfFace: #bitcoin for that
 35 2015-05-12 06:10:19 <ScarfFace> And would it be even feasible to have all transactions deleted, without hiding anywhere
 36 2015-05-12 06:10:23 <ScarfFace> oh okay
 37 2015-05-12 06:17:11 <Jacobutos> hello. in short, given you have a txid, how can you use electrum commands from cli to get wheter it's an incoming or outgoing tx.. I've been at this for a while now. given you have an address that belongs to you, getaddresshistory will give you height and tx_hash for each tx belonging to that address. But given you only have a list of tx's associated with an address, how do you see which category it belongs to, send or receive
 38 2015-05-12 06:36:39 <fanquake1> ;;blocks
 39 2015-05-12 06:36:40 <gribble> 356051
 40 2015-05-12 08:16:04 <leakypat> Anyone have any mining power they can point at testnet for a bit?
 41 2015-05-12 08:26:02 <jonasschnelli> leakypat: what do you want to do?
 42 2015-05-12 08:27:38 <leakypat> I'm tracking down a bug in my wallet which i uncovered the other week when testnet was doing a conf every second or so
 43 2015-05-12 08:28:02 <leakypat> I'm struggling to replicate it now
 44 2015-05-12 08:28:46 <leakypat> I guess I could use a regtest instance, but prefer testing in full UAT/testnet env
 45 2015-05-12 08:28:59 <jonasschnelli> leakypat: why not trying regrets? Much more controllable.
 46 2015-05-12 08:30:04 <jonasschnelli> IMO you get more of it when using regtest. You can test more in less time.
 47 2015-05-12 08:31:40 <leakypat> Yeah, makes sense
 48 2015-05-12 10:01:37 <bitcoin-dev529> I used to use bitcoind. now it no longer lets me issue rpc. I issue bitcoin-cli getbalance and it tells me method not found. I issue bitcoin-cli -regtest getbalance and it tells me couldn't connect to server. what am I missing
 49 2015-05-12 10:03:46 <bitcoin-dev529> bitcoin.conf was missing rpcconnect and rpcport values. restarting it has allowed me access I think
 50 2015-05-12 10:04:46 <sipa> is your bitcoind compiled without wallet support?
 51 2015-05-12 10:05:03 <sipa> that's the only way getbalance wouldn't exist
 52 2015-05-12 10:15:37 <wumpus> try a call that always exists, like 'help'
 53 2015-05-12 11:25:46 <nkuttler> sipa: benjamindees is in #bitcoin-bans. i think he wants to talk to you. maybe you can work it out
 54 2015-05-12 15:11:54 <wumpus> going to tag 0.10.2rc1 in a moment https://github.com/bitcoin/bitcoin/blob/ff325032678df25920fe0345701f714ad2f21c61/doc/release-notes.md
 55 2015-05-12 15:28:07 <fanquake1> ;;blocks
 56 2015-05-12 15:28:08 <gribble> 356096
 57 2015-05-12 16:16:47 <cfields> wumpus: looks good. ready to build
 58 2015-05-12 16:18:20 <wumpus>  * [new tag]         v0.10.2rc1 -> v0.10.2rc1
 59 2015-05-12 16:18:20 <wumpus> * [new tag]         v0.10.2rc1 -> v0.10.2rc1
 60 2015-05-12 16:18:25 <wumpus> cfields: thanks for checking
 61 2015-05-12 16:19:31 <fanquake1> Also building
 62 2015-05-12 16:19:32 <fanquake1> Also building
 63 2015-05-12 17:10:20 <cfields> gmaxwell: ping
 64 2015-05-12 17:10:34 <gmaxwell> cfields: bloop
 65 2015-05-12 17:11:34 <cfields> gmaxwell: looking at your libsecp256k1 blinding, would it be possible to have the context_randomize() return an object that could be passed back in for signing/creation, or would that violate the security model?
 66 2015-05-12 17:11:47 <cfields> i ask because that would help with threading issues around context state
 67 2015-05-12 17:12:41 <gmaxwell> cfields: It does, the object it passes back is the context.
 68 2015-05-12 17:13:06 <gmaxwell> Having to always carry around two context objects would not be an improvement.
 69 2015-05-12 17:13:33 <cfields> gmaxwell: yes, but that's the original context, right? presumably if 2 threads are simultaneously signing and re-randomizing, bad things would happen
 70 2015-05-12 17:15:40 <gmaxwell> cfields: The object would ultimately just end up being a copy of the state, and one could already copy the existing context-- though doing so would lose the property that one must successfully intercept all randomizations.
 71 2015-05-12 17:15:43 <cfields> two context objects, yes. I was picturing a thin seed object?
 72 2015-05-12 17:16:27 <gmaxwell> cfields: doesn't help. Data is either updated by the randomization; or its truly constant and should actually be made constant (we just haven't yet).
 73 2015-05-12 17:17:07 <cfields> gmaxwell: yea, that's where this came from. I was just writing a comment in the jni PR that it may be easier to copy/randomize/destroy the context rather than implementing locking, but that seems nasty and i assume unsafe
 74 2015-05-12 17:17:08 <cfields> gmaxwell: yea, that's where this came from. I was just writing a comment in the jni PR that it may be easier to copy/randomize/destroy the context rather than implementing locking, but that seems nasty and i assume unsafe
 75 2015-05-12 17:17:17 <cfields> ok
 76 2015-05-12 17:18:58 <gmaxwell> Yea, doing that would reduce the security (though this is angles dancing on the head of pins land). In any case; splitting the context wouldn't help that; since once we get around to making static the actually static data in signing there will be nothing in a signing context except the things blinding changes.
 77 2015-05-12 17:19:31 <gmaxwell> An alternative is to just not update the randomization frequently; e.g. it really could just be done at init and have most of the value.
 78 2015-05-12 17:19:58 <cfields> ok, thanks for explaining
 79 2015-05-12 17:20:22 <cfields> for jni, it'd sound like that's a saner approach than fiddling with locking
 80 2015-05-12 17:34:34 <hulkhogan_> we sort of need synch locking though, because context_destroy is not thread safe either
 81 2015-05-12 18:06:32 <kanzure> conformal has moved into #btcd
 82 2015-05-12 18:45:34 <s7r> StephenM347 right, that sounds good.
 83 2015-05-12 18:45:50 <s7r> I think we can also skip OP_CODESEPARATOR ?
 84 2015-05-12 18:46:06 <StephenM347> if you skip it, then the replay can be done
 85 2015-05-12 18:46:29 <s7r> if we do not skip it, doesn't it mean it won't be included in the scriptSig?
 86 2015-05-12 18:46:47 <s7r> the signature will cover everything after OP_CODESEPARATOR
 87 2015-05-12 18:47:04 <StephenM347> What we need is random nonce put into signature hash via the scriptSig
 88 2015-05-12 18:47:43 <StephenM347> And it's the spenders job to just not use the same nonce
 89 2015-05-12 18:49:22 <StephenM347> You don't want the nonce to be included in the prevout scriptPubKey, because then you can just replay a spending tx with the same nonce.
 90 2015-05-12 18:49:40 <StephenM347> It would be interesting if transactions themselves had a nonce field
 91 2015-05-12 18:50:04 <jonasschnelli> Luke-Jr: there?
 92 2015-05-12 18:50:38 <Luke-Jr> ?
 93 2015-05-12 18:51:39 <jonasschnelli> Just saw that when i build with Qt5, the icon coloring on my standard ubuntu system is orange, when building over gitian it is blue? But i assume Qt4 and Qt5 have different color schemas?
 94 2015-05-12 18:52:47 <Luke-Jr> odd
 95 2015-05-12 18:53:52 <Luke-Jr> is gitian static linking Qt on Linux these days?
 96 2015-05-12 18:54:48 <Luke-Jr> I'm not sure how big of a concern it is. People really shouldn't use static binaries on Linux.
 97 2015-05-12 18:57:02 <jonasschnelli> Hmm.. i think its static. Maybe cfields nows.
 98 2015-05-12 18:57:07 <jonasschnelli> *knows
 99 2015-05-12 18:57:34 <cfields> jonasschnelli: master is static, 0.10 is shared
100 2015-05-12 18:57:46 <jonasschnelli> 0.11 is static?
101 2015-05-12 18:57:50 <cfields> also, master is qt5, 0.10 is qt4
102 2015-05-12 18:59:06 <cfields> 0.10.* is shared qt4. master/0.11 will be static qt5
103 2015-05-12 19:01:48 <jonasschnelli> cfields: Nice. Wasn't aware of that (Qt5 for linux by over gitian).
104 2015-05-12 19:04:22 <jonasschnelli> *by default
105 2015-05-12 19:06:09 <morcos> gavinandresen: Thanks!
106 2015-05-12 19:06:24 <gavinandresen> morcos: sorry it took so long….
107 2015-05-12 19:09:18 <morcos> other than the bug fix i put in right at the end, the estimates produced have been the same for quite some time, the new commits didn't change behavior
108 2015-05-12 19:09:48 <morcos> anyway, i'm going to squash, and i think it'll be mergeable at that point..
109 2015-05-12 19:16:35 <morcos> gavinandresen: i know you were against changing nTxConfirmTarget, but I really think it should change.   Where is the right place to discuss that?  Here or a PR?  and I'm totally open on what to change it to, as long as it's not 1
110 2015-05-12 19:16:49 <morcos> it's already 25 in the GUI
111 2015-05-12 19:16:52 <gavinandresen> morcos: eleven is my favorite number....
112 2015-05-12 19:17:00 <morcos> i'll do it
113 2015-05-12 19:19:26 <gavinandresen> morcos: rationale for 1 is that would best match the current (over-estimating) behavior. But I don’t have a strong opinion. I don’t know what percentage of transcations on the network are generated from bitcoind, either.
114 2015-05-12 19:22:50 <morcos> my primary concern for 1 is that it could accidentally lead to very high payments, that hasn't been the case recently, but per the comment on the PR, the delay in reselecting transactions for mining, causes it to be almost impossible to go above 90%, so even with the cutoff at 85%, if you get some busy blocks it could shoot high.  then again, thats i think the correct answer, its just a question of is that what people want
115 2015-05-12 19:23:33 <morcos> i think it should either be 2, 6 or 25 i guess..
116 2015-05-12 19:26:13 <gmaxwell> Making the default be to race to fastest is kinda ugly; it arguably prevents people who really need faster from expressing that preference over people who just kept the defaults.
117 2015-05-12 19:27:24 <morcos> i'm just trying to look at the code again, so if you're running QT, it sets the variable to 25, even for your RPC commands.  seems weird for RPC behavior to default differently depending on whether you have the front end up or not
118 2015-05-12 19:28:35 <gmaxwell> Gavin previously gave me an example that convinced me at least with the prior eastimator making the default higher wasn't a free choice however.
119 2015-05-12 19:30:15 <morcos> well... didn't you say the one healthy part of the network is fees aren't dropping?
120 2015-05-12 19:30:36 <morcos> the new estimation code and increasing the default would both change that to extent people use fee estimation
121 2015-05-12 19:32:06 <gmaxwell> Fees aren't dropping, I believe, for stupid reasons.  Wallet authors are externalizing techsupport and development costs onto their end users with forced (or bad option) fee choices; as the users pay the fees, but they get the complaints if things get stuck (or the development effort in making things smarter)
122 2015-05-12 19:32:34 <gmaxwell> Most wallets can't even control their fees in terms of fees/kb... they set some static amount and if they happen to construct a 1-in 1-out they massively overpay.
123 2015-05-12 19:33:06 <gmaxwell> But it's hard to say what the behavior of everyone not doing silly things would be if not for the silly things. :)
124 2015-05-12 19:33:38 <gmaxwell> In any case, so long as the result wouldn't be crazy/unstable,  even just being a target of 2 would still give "one higher" to go to for people who actually care.
125 2015-05-12 19:35:16 <morcos> Yeah that's fine with me, only it seems a bit odd to be different than the GUI, but i seem to remember cozz (i think) felt pretty strongly about the 25 thats in the gui now
126 2015-05-12 19:36:15 <jtimon> BlueMatt you may be alone on reusing cltv's opcode for rcltv...
127 2015-05-12 19:40:30 <Luke-Jr> 
ACTION notes RCLTV could just use negative numbers

128 2015-05-12 19:41:02 <sipa> 
ACTION notes this would be a hard fork

129 2015-05-12 19:41:47 <Luke-Jr> it would?
130 2015-05-12 19:41:49 <btcdrak> 
ACTION notes the notes

131 2015-05-12 19:42:10 <Luke-Jr> shouldn't CLTV succeed for any negative requirement?
132 2015-05-12 19:42:12 <sipa> Luke-Jr: after cltv already being deployed, yes
133 2015-05-12 19:42:14 <sipa> ah
134 2015-05-12 19:42:17 <sipa> i see!
135 2015-05-12 19:44:23 <Luke-Jr> jtimon: see logs in /topic for discussion of what you said
136 2015-05-12 19:44:45 <btcdrak> luke-jr: Seems like a pretty good idea to use negative numbers
137 2015-05-12 19:45:12 <BlueMatt> jtimon: huh?
138 2015-05-12 19:45:27 <BlueMatt> jtimon: I'm not doing anything, yet
139 2015-05-12 19:48:53 <jtimon> and there it seems Bluematt is the only person who wants reuse
140 2015-05-12 19:48:53 <jtimon> Luke-Jr do you have a link or a date to search? I'm only guessing from what I've read on the mailing list and github
141 2015-05-12 19:54:01 <Luke-Jr> jtimon: just now, when you pinged out
142 2015-05-12 19:59:33 <StephenM347> using negative numbers for the RCLTV vs pos for CLTV may not be the best idea, as the nLockTime of transactions is unsigned... also year 2038 problem...
143 2015-05-12 20:35:00 <morcos> question about command line args, there are several options, such as -sendfreetransactions, which are parsed using GetArg instead of GetBoolArg, which means its interpreted as false unless you add '=1'.  Was this intentional for some reason?  I was planning on PR'ing a fix
144 2015-05-12 21:01:36 <StephenM347> morcos: AFAIK, it is interpreted as true if you do not specify. For example, launching with -gen starts the client miner. Are you seeing something different for that launch param?
145 2015-05-12 21:08:00 <morcos> if the argument is parsed using GetArg, then it is interpreted as false unless you give a '=n' where n is not 0.  -gen is correctly parsed with GetBoolArg.  PR'ing