1 2015-12-09 01:10:57 <jtimon> cfields: can you please please please ACK/nit/NACK #6625 (the commits still have your name in them) and #7091 ?
  2 2015-12-09 01:13:56 <jtimon> you already reviewed most of #6625 as part of #6672 anyway...(like many others that don't seem to have time to re-utACK)
  3 2015-12-09 01:15:48 <jtimon> since people don't seem to have time to re-review it, I don't think it's a wise use of my time to keep rebasing it and I don't intend to do so the next time it requires rebase (someone else can do it or you'll have to wait for me to rebase on top of the last commit in 0.13.99)
  4 2015-12-09 02:14:50 <ireen> hello
  5 2015-12-09 02:20:26 <jl2012> Luke-Jr: the leaves could be hash+total_input_value or hash+fee, so we could have proof of illegal inflation
  6 2015-12-09 02:59:16 <jtimon> https://github.com/bitcoin/bitcoin/commit/1cc0e96e9cc7aa094ddee9fe5b192b3ac1a59da8#commitcomment-14864214 would people prefer a getancestor function pointer or a getSkip function pointer as an additional parameter to VerifyHader()?
  7 2015-12-09 02:59:48 <jtimon> sipa: since you broke the previous encapsulation, I'm specially interested in your thoughts
  8 2015-12-09 03:16:55 <job_> anyone current on the state of coinjoin in core? is that worth throwing some work at?
  9 2015-12-09 03:23:44 <gmaxwell> job_: joinmarket has some early bitcoin core integration; though it's not very mature.
 10 2015-12-09 03:23:45 <gmaxwell> job_: joinmarket has some early bitcoin core integration; though it's not very mature.
 11 2015-12-09 03:25:39 <job_> gmaxwell: by way of rpc interface, or are they running a fork?
 12 2015-12-09 03:28:06 <job_> ah: https://github.com/JoinMarket-Org/joinmarket
 13 2015-12-09 03:28:11 <tulip> job_: it can use the RPC interface or centralised APIs.
 14 2015-12-09 03:29:48 <gmaxwell> jamesob: rpc.
 15 2015-12-09 03:29:49 <gmaxwell> jamesob: rpc.
 16 2015-12-09 03:49:43 <z0rg> hey guys, anyone still has "pool_strategies.pdf" on the harddrive? it was available here http://www.bitcoinservice.co.uk/files/111, but inactive for a while
 17 2015-12-09 03:57:04 <luke-jr_> archive.org?
 18 2015-12-09 03:59:25 <luke-jr_> oh, a .. not-so-pay thing
 19 2015-12-09 03:59:42 <luke-jr_> midnightmagic: you had it in 2011?
 20 2015-12-09 04:01:52 <z0rg> the very first version was 1btc, but then it was 0btc. found it here: http://web.archive.org/web/20110830173809/http://www.bitcoinservice.co.uk/files/111
 21 2015-12-09 04:02:37 <z0rg> but they didn't archive the pdf, so maybe if midnightmagic has something here that would make me pretty happy ;)
 22 2015-12-09 04:47:06 <midnightmagic> what?
 23 2015-12-09 04:47:48 <z0rg> hey, do you still have pool_strategies.pdf from 2011? :)
 24 2015-12-09 04:48:13 <midnightmagic> i have something.. lemme see
 25 2015-12-09 04:48:19 <midnightmagic> i have something.. lemme see
 26 2015-12-09 04:48:31 <midnightmagic> z0rg: install tor-browser-bundle, I'll pull it from archives and post it on my HS
 27 2015-12-09 04:49:02 <midnightmagic> this is mar 25, 2011
 28 2015-12-09 04:50:02 <z0rg> ok, ready in a minute
 29 2015-12-09 04:50:30 <midnightmagic> check pm
 30 2015-12-09 04:52:43 <z0rg> thank you so much
 31 2015-12-09 04:53:02 <z0rg> i got it from your HS
 32 2015-12-09 06:22:35 <ireen> good afternoon
 33 2015-12-09 06:34:36 <jtimon> how acceptable it would be to add a uint256 hashPrevBlock field in CBlockIndex for completing libconsensus?
 34 2015-12-09 07:00:53 <phantomcircuit> jtimon, er why?
 35 2015-12-09 07:10:36 <jtimon> erik from libconsensus doesn't think https://github.com/bitcoin/bitcoin/pull/5995/files#diff-5d284177f966cbad5a370e548271cb1dR90 with https://github.com/bitcoin/bitcoin/pull/5995/files#diff-87d56debcd8a29ea4041ff6aa9d483f6R11 (forget the phashBlock field there, that was a mistake) is an accetable API for libconsensus, he thinks the getter should get the hash of the previous block
 36 2015-12-09 07:10:53 <jtimon> phantomcircuit: ^
 37 2015-12-09 07:12:24 <jtimon> phantomcircuit: and since he is the only person who has reviewed my API proposal (that code is outdated now a GetAncestor getter would be needed as well), I value his opinion very much
 38 2015-12-09 07:24:06 <jtimon> I'm afraid that it will be very hard to find a C API that is acceptable to both Bitcoin Core and libbitcoin simultanously, maybe we should consider a C++ API instead
 39 2015-12-09 07:42:27 <phantomcircuit> jtimon, what's the current proposed api for libconsensus?
 40 2015-12-09 11:02:07 <Ren0v0_> Hey, when was encryption added to wallets on bitcoin core?
 41 2015-12-09 11:02:20 <sipa> 0.4 iirc
 42 2015-12-09 11:02:51 <Ren0v0_> When was that like 2010?
 43 2015-12-09 11:03:01 <Ren0v0_> I thought it was later
 44 2015-12-09 11:03:36 <Ren0v0_> I'm sure I rememeber it being added like 2011
 45 2015-12-09 11:03:57 <Ren0v0_> But maybe that was to the GUI?
 46 2015-12-09 11:04:26 <sipa> sep 2011
 47 2015-12-09 11:04:35 <sipa> the qt gui is from 0.11
 48 2015-12-09 11:04:38 <sipa> eh
 49 2015-12-09 11:04:41 <sipa> is from 0.5
 50 2015-12-09 11:05:23 <Ren0v0_> Ok, so this guy is a liar :) http://www.theguardian.com/technology/2015/dec/09/bitcoin-forgotten-currency-norway-oslo-home
 51 2015-12-09 11:05:38 <Ren0v0_> Apparently he remembered his password luckily, that he set in 2009 lol
 52 2015-12-09 11:05:39 <Ren0v0_> Apparently he remembered his password luckily, that he set in 2009 lol
 53 2015-12-09 11:12:50 <Luke-Jr> Ren0v0_: #bitcoin please
 54 2015-12-09 11:41:52 <Ren0v0_> Luke-jr no
 55 2015-12-09 11:41:56 <Ren0v0_> It was a dev qus
 56 2015-12-09 11:42:17 <Luke-Jr> #bitcoin-dev is for development discussion, not "ask devs a question"
 57 2015-12-09 11:42:24 <Ren0v0_> Question, I was asking about release version of certain implementation, thanks though
 58 2015-12-09 11:43:02 <Ren0v0_> Thanks sipa
 59 2015-12-09 11:43:03 <Ren0v0_> Thanks sipa
 60 2015-12-09 14:21:48 <ploopkazoo> what is the "id" parameter in the RPC for? is it supposed to be like a user agent?
 61 2015-12-09 14:21:49 <ploopkazoo> what is the "id" parameter in the RPC for? is it supposed to be like a user agent?
 62 2015-12-09 14:36:20 <phantomcircuit> ploopkazoo, no? there's a json rpc spec, you should read it :)
 63 2015-12-09 14:36:39 <phantomcircuit> even just the wikipedia page https://en.wikipedia.org/wiki/JSON-RPC
 64 2015-12-09 14:44:04 <ploopkazoo> phantomcircuit: that was my original assumption, but why would that be necessary if it uses http? if two requests are made, is there some chance of the server accidentally sending request 1 the response to request 2?
 65 2015-12-09 14:44:44 <phantomcircuit> ploopkazoo, json-rpc can work over any medium
 66 2015-12-09 14:44:49 <phantomcircuit> including udp
 67 2015-12-09 14:44:53 <phantomcircuit> thus id
 68 2015-12-09 14:44:57 <ploopkazoo> ah
 69 2015-12-09 14:45:23 <phantomcircuit> we dont support that, but maybe we should (although the way people use rpc maybe making it less reliable is a bad idea :P )
 70 2015-12-09 15:19:07 <jamesob> is MarcoFalke on here? I'd like to sync up about testing
 71 2015-12-09 15:23:50 <jonasschnelli> jamesob: he's probably in #bitcoin-core-dev
 72 2015-12-09 15:24:13 <jamesob> thanks, jonasschnelli
 73 2015-12-09 15:29:16 <jamesob> jonasschnelli: no dice. do you think it would be worthwhile to create a tracking ticket for getting all RPC commands covered?
 74 2015-12-09 15:29:41 <jonasschnelli> jamesob: covered by the RPC tests?
 75 2015-12-09 15:29:46 <jamesob> yes
 76 2015-12-09 15:30:06 <jonasschnelli> Not sure if creating issue helps... better creating the tests. :p
 77 2015-12-09 15:30:40 <jamesob> okay; just don't want to step on anyone else's toes -- I know MarcoFalke's been adding lots of tests, wouldn't want to collide
 78 2015-12-09 15:31:36 <jonasschnelli> jamesob: You could add a array to the testframework.py that counts/collects each called RPC command...., then collect and mix the array in rpc-tests.py, ...
 79 2015-12-09 15:32:05 <jonasschnelli> calling rpc-tests.py --extended should then give you an overview of which commands are being used.
 80 2015-12-09 15:32:21 <jonasschnelli> You could also track the arguments to make sure, all variations get tested.
 81 2015-12-09 15:32:27 <jonasschnelli> You could also track the arguments to make sure, all variations get tested.
 82 2015-12-09 15:33:44 <jonasschnelli> But every – little – improvement regarding (rpc)tests is well appreciated.
 83 2015-12-09 15:38:05 <jamesob> jonasschnelli: I've already added a framework for gathering basic coverage data: https://github.com/bitcoin/bitcoin/pull/6804
 84 2015-12-09 15:38:06 <jamesob> jonasschnelli: I've already added a framework for gathering basic coverage data: https://github.com/bitcoin/bitcoin/pull/6804
 85 2015-12-09 15:38:41 <jonasschnelli> hah. Didn't saw that. Nice!
 86 2015-12-09 15:39:04 <jamesob> so that's what I'm working off of :)
 87 2015-12-09 15:39:09 <jonasschnelli> jamesob: could that be combined with -gcov?
 88 2015-12-09 15:39:30 <jamesob> I'm not sure... they're at completely different layers
 89 2015-12-09 15:39:54 <jamesob> you're referring to https://github.com/bitcoin/bitcoin/pull/6813, right?
 90 2015-12-09 15:39:56 <jonasschnelli> Right. Would be nice to see the passed code coverage after a --extended rpc run of the rpcXXX.cpp files.
 91 2015-12-09 15:40:34 <jamesob> yeah, agree.
 92 2015-12-09 15:40:39 <jonasschnelli> no familiar with the PR 6813... but lcov/gcov can somehow measure the lines stepped through when running the unittests
 93 2015-12-09 15:41:04 <jonasschnelli> You could also add the arguments count to your rpc coverage report.
 94 2015-12-09 15:41:21 <jonasschnelli> amount of arguments would probably be sufficient
 95 2015-12-09 15:41:46 <jamesob> yeah, true. In time I think we can unite the two somehow... for now I'm just working on getting that uncovered list down to nothing
 96 2015-12-09 15:44:54 <jonasschnelli> right. That's more effective.
 97 2015-12-09 17:51:59 <claudio_> hello guys
 98 2015-12-09 17:52:43 <cla_> hello
 99 2015-12-09 17:52:55 <cla_> are people online?
100 2015-12-09 21:03:29 <ploopkazoo> how often is the alert system used?
101 2015-12-09 21:04:10 <gmaxwell> Virtually never.
102 2015-12-09 21:04:11 <gmaxwell> Virtually never.
103 2015-12-09 21:04:21 <ploopkazoo> is there a list of occurrences?
104 2015-12-09 21:04:22 <ploopkazoo> is there a list of occurrences?
105 2015-12-09 21:04:32 <ploopkazoo> was it used in the 2013 hardfork?
106 2015-12-09 21:04:33 <ploopkazoo> was it used in the 2013 hardfork?
107 2015-12-09 21:04:46 <gmaxwell> I last used it for the BIP66 network turbulance, and I think 2013 was the last time before that.
108 2015-12-09 21:05:08 <ploopkazoo> who has keys for it?
109 2015-12-09 21:05:41 <gmaxwell> actually it was used in 2014, https://en.bitcoin.it/wiki/Alert_system  (but clearly that list is not complete.)
110 2015-12-09 21:06:03 <gmaxwell> ploopkazoo: Thats not public knoweldge; to protect the key holders from being targeted.
111 2015-12-09 21:06:42 <ploopkazoo> are there non-devs with keys?
112 2015-12-09 21:06:43 <ploopkazoo> are there non-devs with keys?
113 2015-12-09 21:06:51 <gmaxwell> ploopkazoo: Yes.
114 2015-12-09 21:07:01 <ploopkazoo> neat
115 2015-12-09 21:07:41 <gmaxwell> alert system is not really useful though, and also doesn't have much risk of abuse; since anyone with the key can also completely disable the system; forcing it to a static key compromised messsage that can't be overridden.
116 2015-12-09 21:07:42 <gmaxwell> alert system is not really useful though, and also doesn't have much risk of abuse; since anyone with the key can also completely disable the system; forcing it to a static key compromised messsage that can't be overridden.
117 2015-12-09 21:11:07 <ploopkazoo> could there be some kind of system where a percentage of other keyholders can invalidate a compromised key?
118 2015-12-09 21:11:18 <ploopkazoo> seems like that would be easy
119 2015-12-09 21:18:46 <ploopkazoo> does anything other than alerts and "pre-release test build" go to the jsonrpc "errors" string?
120 2015-12-09 21:41:28 <gmaxwell> ploopkazoo: yes, locally detected network misbehavior. like if you start being fed a bunch of invalid blocks with high difficulty.
121 2015-12-09 23:08:33 <ale______> I just read Gavin's "Segregated Witness is cool" blog post. I'm left wondering how these new segwit locked outputs will look like an "anyone can spend" transaction? Is he referring to SIGHASH_ANY?
122 2015-12-09 23:09:06 <gmaxwell> ale______: no, like P2SH.
123 2015-12-09 23:09:07 <gmaxwell> ale______: no, like P2SH.
124 2015-12-09 23:12:36 <tachys_> gmaxwell: ok... I guess he's just referring to how block explorers will deal with this new type of tx
125 2015-12-09 23:23:10 <gmaxwell> tachys_: it'll look like p2sh to them. so no change even immediately needed, and only small ones.
126 2015-12-09 23:23:11 <gmaxwell> tachys_: it'll look like p2sh to them. so no change even immediately needed, and only small ones.