1 2016-04-04T00:19:49  <midnightmagic> is someone still mirroring the PRs, etc?
  2 2016-04-04T00:21:03  *** Ylbam has quit IRC
  3 2016-04-04T00:26:59  *** frankenmint has quit IRC
  4 2016-04-04T00:27:35  *** frankenmint has joined #bitcoin-core-dev
  5 2016-04-04T00:31:55  *** frankenmint has quit IRC
  6 2016-04-04T01:00:10  <gmaxwell> morcos: I am boggle at +class CompareTxMemPoolEntryByScore
  7 2016-04-04T01:00:38  <gmaxwell> oh no I'm not.
  8 2016-04-04T01:00:54  <gmaxwell> turns out that b and a look a lot like each other on the screen.
  9 2016-04-04T01:01:18  *** PRab has quit IRC
 10 2016-04-04T01:01:46  *** PRab has joined #bitcoin-core-dev
 11 2016-04-04T01:03:03  *** PRab has quit IRC
 12 2016-04-04T01:03:55  *** PRab has joined #bitcoin-core-dev
 13 2016-04-04T01:17:50  *** jtimon has quit IRC
 14 2016-04-04T01:27:06  *** molz has quit IRC
 15 2016-04-04T01:27:24  *** molz has joined #bitcoin-core-dev
 16 2016-04-04T01:28:06  *** frankenmint has joined #bitcoin-core-dev
 17 2016-04-04T01:31:13  *** frankenmint has quit IRC
 18 2016-04-04T01:31:35  *** frankenmint has joined #bitcoin-core-dev
 19 2016-04-04T03:10:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 20 2016-04-04T03:16:59  *** achow101 has quit IRC
 21 2016-04-04T03:17:22  *** achow101 has joined #bitcoin-core-dev
 22 2016-04-04T03:52:01  *** Alopex has quit IRC
 23 2016-04-04T03:52:06  *** zooko has joined #bitcoin-core-dev
 24 2016-04-04T03:53:06  *** Alopex has joined #bitcoin-core-dev
 25 2016-04-04T03:53:27  *** Chris_Stewart_5 has quit IRC
 26 2016-04-04T04:15:04  *** zooko has quit IRC
 27 2016-04-04T04:25:16  *** Giszmo has quit IRC
 28 2016-04-04T04:37:22  *** sanada has joined #bitcoin-core-dev
 29 2016-04-04T04:49:39  *** frankenmint has quit IRC
 30 2016-04-04T04:57:01  *** Alopex has quit IRC
 31 2016-04-04T04:58:06  *** Alopex has joined #bitcoin-core-dev
 32 2016-04-04T05:02:23  *** frankenmint has joined #bitcoin-core-dev
 33 2016-04-04T05:05:30  *** d_t has joined #bitcoin-core-dev
 34 2016-04-04T05:13:01  *** Alopex has quit IRC
 35 2016-04-04T05:14:06  *** Alopex has joined #bitcoin-core-dev
 36 2016-04-04T05:43:14  *** d_t has quit IRC
 37 2016-04-04T05:59:57  *** p15 has joined #bitcoin-core-dev
 38 2016-04-04T06:12:01  *** Alopex has quit IRC
 39 2016-04-04T06:13:06  *** Alopex has joined #bitcoin-core-dev
 40 2016-04-04T06:49:34  *** droark has quit IRC
 41 2016-04-04T06:51:30  *** paveljanik has quit IRC
 42 2016-04-04T07:06:25  <wumpus> does anyone know of a profiling/monitoring tool that can how how much % of the time a lock is held and by what threads?
 43 2016-04-04T07:09:45  <wumpus> (for linux)
 44 2016-04-04T07:13:24  <wumpus> thanks for all the work on the tests MarcoFalke
 45 2016-04-04T07:21:26  <Lightsword> wumpus, I think valgrind may have something for that
 46 2016-04-04T07:21:44  <wumpus> thanks
 47 2016-04-04T07:22:30  <Lightsword> http://valgrind.org/docs/manual/drd-manual.html#drd-manual.lock-contention
 48 2016-04-04T07:24:25  <sipa> if contention is really significant i expect it to show up in profilimg
 49 2016-04-04T07:25:53  <wumpus> yes the problem I usually have with profiling is that it gives way too much information, where I just need to know a specific thing :)
 50 2016-04-04T07:26:14  <sipa> haha
 51 2016-04-04T07:26:43  <wumpus> linux has about a gazillion tools to monitor the system, or a process, but I can hardly ever find the one I need when I need it
 52 2016-04-04T07:28:20  <wumpus> something that shows a timeline *wtf is this process doing now*, per thread, in a kind of GANTT graph would be awesome, we had something like that for Sun at ASML but I have no clue whether it exists for linux
 53 2016-04-04T07:28:37  <Lightsword> dtrace?
 54 2016-04-04T07:28:49  <wumpus> yes it was a proprietary tool based on dtrace
 55 2016-04-04T07:29:28  <Lightsword> https://github.com/dtrace4linux/linux
 56 2016-04-04T07:29:57  <wumpus> yes saw that one, there's also systemtap, and oprofile, which have similar aims but use slightly different mechanisms
 57 2016-04-04T07:30:24  <wumpus> oh and sysdig!
 58 2016-04-04T07:30:55  * wumpus mumbles something about fragmentation
 59 2016-04-04T07:33:06  <Lightsword> because who doesn’t like to have 10 different profiling tools that work slightly differently :P
 60 2016-04-04T07:33:12  <wumpus> :-)
 61 2016-04-04T07:34:09  <wumpus> well I suppose people who specialize in this appreciate the flexibility, but if you just want to investigate something quickly it's easy to get stuck in the "what tool to choose... oh wtf I'll just roll something myself" stage
 62 2016-04-04T07:34:22  * Lightsword has noticed ethereum has decided to do the same thing by apparently trying to write their clients in as many languages as possible
 63 2016-04-04T07:36:24  *** Ylbam has joined #bitcoin-core-dev
 64 2016-04-04T07:36:24  <wumpus> oh yes don't get me started on programming languages :) we have to rewrite every single thing and library in every programming language, sometimes it's good but sometimes it's also a waste, what could we accomplish if we just cooporated on a single version of *thing* that works awesomely
 65 2016-04-04T07:36:38  <wumpus> "we" is general, especially the open source community
 66 2016-04-04T07:36:53  *** slackircbridge has quit IRC
 67 2016-04-04T07:37:34  <wumpus> for c++ we even want multiple version of *thing* based on what the favourite combination of dependencies of the day is
 68 2016-04-04T07:37:50  *** dgenr8 has quit IRC
 69 2016-04-04T07:37:59  <Lightsword> heh, seems that’s why c is so common with linux stuff, since those libraries are pretty much compatible with any language
 70 2016-04-04T07:38:09  *** dgenr8 has joined #bitcoin-core-dev
 71 2016-04-04T07:39:29  *** p15 has quit IRC
 72 2016-04-04T07:41:32  *** justanotheruser has quit IRC
 73 2016-04-04T07:42:09  *** Evel-Knievel has quit IRC
 74 2016-04-04T07:42:30  *** justanotheruser has joined #bitcoin-core-dev
 75 2016-04-04T07:42:39  *** p15 has joined #bitcoin-core-dev
 76 2016-04-04T07:42:40  *** Evel-Knievel has joined #bitcoin-core-dev
 77 2016-04-04T07:44:16  <jonasschnelli> Any final feelings about RBF for createrawtx (https://github.com/bitcoin/bitcoin/pull/7159/files)?
 78 2016-04-04T07:44:28  <jonasschnelli> Should I remove the general opt-in boolean?
 79 2016-04-04T07:44:33  <jonasschnelli> And add a seq-nr per input?
 80 2016-04-04T07:44:52  <jonasschnelli> I like both approaches.
 81 2016-04-04T07:45:34  <jonasschnelli> The per-tx-global opt-in bool is a higher level function. The seq-nr per input is something we should have anyways.
 82 2016-04-04T07:45:42  <jonasschnelli> Maybe we can have both?
 83 2016-04-04T07:49:53  <jonasschnelli> Wait. The sequence option was added already.
 84 2016-04-04T07:50:38  <gmaxwell> needs nlock too.. globals could be used to autopopulate sequence/nlock if not overridden.
 85 2016-04-04T07:52:01  <sipa> hmm, i'm unsure
 86 2016-04-04T07:52:15  <sipa> the question is what createrawtransaction's goal os
 87 2016-04-04T07:52:37  <sipa> just only using explicit values would be more in line with its name
 88 2016-04-04T07:52:44  <gmaxwell> it bothers me that rawtxn are trivially distinguishable from txn created by bitcoin core itself for no good reason... and it's weird that there is _less_ functionality via rawtxn now.
 89 2016-04-04T07:53:27  <sipa> but given that it can now be used in conjunction in fundrawtransaction to just choose outputs, maybe there is a need fir slightly higher level behaviour
 90 2016-04-04T07:53:49  <gmaxwell> why make it gratitiously less useful?
 91 2016-04-04T07:53:51  <jonasschnelli> I'm also not sure if passing a CREATE_TX_RBF_OPT_IN - flag to FundTransaction is the way to go: https://github.com/bitcoin/bitcoin/pull/7159/files#diff-12635a58447c65585f51d32b7e04075bR747
 92 2016-04-04T07:58:13  *** laurentmt has joined #bitcoin-core-dev
 93 2016-04-04T07:58:50  <GitHub77> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e662a7628801...a9149688f87c
 94 2016-04-04T07:58:50  <GitHub77> bitcoin/master 8efed3b Jonas Schnelli: [Qt] Support for abandoned/abandoning transactions
 95 2016-04-04T07:58:51  <GitHub77> bitcoin/master a914968 Jonas Schnelli: Merge #7707: [RPC][QT] UI support for abandoned transactions...
 96 2016-04-04T07:59:00  <GitHub144> [bitcoin] jonasschnelli closed pull request #7707: [RPC][QT] UI support for abandoned transactions (master...2016/03/abandon_ui) https://github.com/bitcoin/bitcoin/pull/7707
 97 2016-04-04T07:59:17  *** laurentmt has quit IRC
 98 2016-04-04T08:02:48  <sipa> gmaxwell: i dislike feature creep
 99 2016-04-04T08:03:26  <sipa> making createrawtransaction do things automagically may be confusing "i was making a raw transaction... why did it put things in the transaction i didn't tell it to?"
100 2016-04-04T08:03:27  <gmaxwell> I dislike having functionality which doesn't get used but for small shortcoming that take away its utility.
101 2016-04-04T08:05:25  <sipa> i just don't know how to reconcile it being "raw" with the suggested functionality
102 2016-04-04T08:05:55  <gmaxwell> raw is the fact that it returns a rawtransaction to you.
103 2016-04-04T08:06:06  <sipa> my preference would be just allowing setting nlocktime and nsequence
104 2016-04-04T08:06:22  <sipa> it also doesn't create change outputs automatocally
105 2016-04-04T08:06:24  <gmaxwell> Createrawtransaction is the only way to do manual coin selection from the command-line, it works great for that, and I use it that way several times per week.  It has a nice workflow that allows offline signing and allows review of the completed transaction before signing.
106 2016-04-04T08:06:52  *** jannes has joined #bitcoin-core-dev
107 2016-04-04T08:07:25  <sipa> but have another RPC for higher level operations like this
108 2016-04-04T08:07:53  <gmaxwell> it would just be an exact copy of createrawtransaction, with extra flags and or slightly different defaults.
109 2016-04-04T08:10:55  <sipa> so you would suggest having the ability to set nlocktime and nsequence specifically, and also have options to change defaults based on rbf, transaction sniping, relative locktime, ...?
110 2016-04-04T08:11:00  <gmaxwell> I wouldn't object to just having another RPC like that... but it seems a waste.
111 2016-04-04T08:11:34  <gmaxwell> sipa: yes.
112 2016-04-04T08:12:25  <gmaxwell> the problem with 'global defaults' however, is that I don't see a clean way to make it work with fundrawtransaction unless side information is added to the raw transaction.
113 2016-04-04T08:12:44  <sipa> so what if you want the rbf/sniping/rellocktime/... logic, but not createrawtransaction?
114 2016-04-04T08:12:57  <gmaxwell> sounds like arguments for sendmany.
115 2016-04-04T08:13:20  <sipa> so we'd add those to both sendmany and createrawtransaction?
116 2016-04-04T08:14:53  <sipa> just trying to think this through
117 2016-04-04T08:14:56  <gmaxwell> See any reason why we wouldn't? sendmany's workflow requires that the transaction it creates be valid now, that isn't so for the raw workflow.
118 2016-04-04T08:15:10  <gmaxwell> e.g. totally reasonable to use the rawworkflow to make a nlocked transaction for the future.
119 2016-04-04T08:16:10  <sipa> it's just so ugly to have both high level logic and the ability to override
120 2016-04-04T08:16:28  <sipa> say we didn't add csv support now, just optinrbf or not
121 2016-04-04T08:16:53  <sipa> someone starts using csv by setting the sequence number explicitly, but also passes optinrbf=no
122 2016-04-04T08:17:06  <sipa> and expects a transaction that is not replacable
123 2016-04-04T08:18:18  <gmaxwell> I get what you're saying, but a sequenced transaction implies at least sequence succession relplacability. But yes, ... that would not by far be the biggest footguns around that interface.
124 2016-04-04T08:19:06  <sipa> if createrawtransaction was instead just something that took an existing raw tx (empty be default?) and allowed adding inputs and outputs
125 2016-04-04T08:33:55  <jonasschnelli> sipa: the question is, do we think that rawtx users need to know the MAXINT-2 RBF opt-in seqnr? I think we should abstract these magic numbers from the rpc-users.
126 2016-04-04T08:34:40  <jonasschnelli> IMO it's on a different level then the rawtx abstraction
127 2016-04-04T08:35:12  <sipa> jonasschnelli: createrawtransaction users also need to know that creating less outouts than inputs will send their life savings to miners
128 2016-04-04T08:35:29  <jonasschnelli> sipa: not if they use fundraw. :)
129 2016-04-04T08:35:54  <sipa> i totally agree that there should be a way for users to need to learn all the ugly details ofnthe semantics of all fields
130 2016-04-04T08:36:23  <sipa> but so far, createrawtransaction has been the way to actually do control the exact values, and not the high level behaviour
131 2016-04-04T08:36:55  <sipa> and mixing them may be seen as a recommendation for people to use createrawtransaction when it actually cannot guarantee safety without learning the details
132 2016-04-04T08:36:56  <jonasschnelli> sipa: I agree. But knowing also the magic numbers we use for nSequence is another "level":
133 2016-04-04T08:37:22  <jonasschnelli> At least we should offer some nSequence=BIP125 abstraction.
134 2016-04-04T08:37:36  <sipa> yes, agree
135 2016-04-04T08:37:40  <jonasschnelli> The per-tx-general opt-in-to-Bip125 is probably to high. I agree.
136 2016-04-04T08:37:42  <gmaxwell> the magic nsquence is really MAX-1 which is not replacable when it logically should be (after all, the transaction is locktimed and non-final)
137 2016-04-04T08:38:22  <sipa> but you should not be using createrawtransaction if you don't know what the semantics of the raw transaction fields are, or you'll shoot yourself in the foot
138 2016-04-04T08:38:30  <jonasschnelli> Yes. Agree.
139 2016-04-04T08:38:47  <jonasschnelli> But the BIP125 MAXINT-2 is a policy we should offer directly.
140 2016-04-04T08:39:18  <jonasschnelli> {"txid": <txid>, "vout" : 0, "sequence": "BIP12"} <--- feels ugly
141 2016-04-04T08:39:19  <sipa> what will you do to add csv supoort to createrawtransaction?
142 2016-04-04T08:39:42  * jonasschnelli is thinking...
143 2016-04-04T08:40:04  <sipa> i really dislike mixing magic smart behaviour with raw overriding
144 2016-04-04T08:40:29  <gmaxwell> I don't really like mixing types in a single argument name.
145 2016-04-04T08:40:29  <sipa> that feels like the rpc is trying to solve things at different levels
146 2016-04-04T08:41:03  <jonasschnelli> flags per input? FLAG_BIP125_RBF, SEQUENCE_LOCKTIME_TYPE_FLAG?
147 2016-04-04T08:41:08  <gmaxwell> e.g. sequence: 12345  / and seqtype: "BIP12" and have their use be mutually exclusive would seem preferable to me.
148 2016-04-04T08:41:35  <jonasschnelli> no. flags per input is bad.
149 2016-04-04T08:41:42  <sipa> i'd almost argue for a computensequencevalue RPC
150 2016-04-04T08:41:56  <sipa> which just gives you the number to use, which you can put in crt
151 2016-04-04T08:42:08  <sipa> but that's cumbersome for human users...
152 2016-04-04T08:42:20  <jonasschnelli> RPC is not made for "human" users.
153 2016-04-04T08:42:26  <jonasschnelli> I think its fine...
154 2016-04-04T08:42:38  <jonasschnelli> Chains of commands is something that increase the modularity
155 2016-04-04T08:43:41  <gmaxwell> the RPC is our commandline interface as well, and its usefulness aids in discoverability which makes it much easier to use as an RPC too.
156 2016-04-04T08:43:52  <gmaxwell> like having an REPL makes python accessible to people.
157 2016-04-04T08:43:55  <jonasschnelli> A "setoptinrbf <rawtx>" is probably a bad design and leads to overriding ther nsequence magics
158 2016-04-04T08:44:02  <sipa> jonasschnelli: agree
159 2016-04-04T08:44:15  <sipa> optinrbf should be something you choose per tx
160 2016-04-04T08:44:24  <jonasschnelli> gmaxwell: imo RPC != commandline, .. bitcoin-cli == commandline
161 2016-04-04T08:44:32  <sipa> some receivers may not want such transactions
162 2016-04-04T08:44:33  <jonasschnelli> bitcoin-cli could combine stuff
163 2016-04-04T08:44:48  *** Thireus has quit IRC
164 2016-04-04T08:45:00  <jonasschnelli> sipa: "setoptinrbf" would be per rawtx.
165 2016-04-04T08:45:09  <jonasschnelli> It would just set the nSequence number of all inputs to MAXINT-2
166 2016-04-04T08:45:12  <gmaxwell> jonasschnelli: that would harm discoverability, I think it is unfortunate to create wildly different interfaces.
167 2016-04-04T08:45:20  <jonasschnelli> But I don't like the override character.
168 2016-04-04T08:45:33  <gmaxwell> jonasschnelli: I hope it wouldn't do that, I hope it would move anything from MAXINT/-1 to -2 and leave the rest alone.
169 2016-04-04T08:45:42  <jonasschnelli> gmaxwell: Yes. It would add another level.. which I agree its bad.
170 2016-04-04T08:46:14  <jonasschnelli> gmaxwell: Yes. That could be nice (move MAXINT/-1 to -2)
171 2016-04-04T08:46:41  <jonasschnelli> but would "optinrbf <rawtx>" not be to prominent for a policy flag?
172 2016-04-04T08:46:42  <gmaxwell> (and unix has worked for decades where the programmatic interface to unix commands is the same as the human one)
173 2016-04-04T08:47:37  <sipa> our 'default' of using positional arguments does not help
174 2016-04-04T08:47:53  <gmaxwell> jonasschnelli: I don't think that it's "policy" makes it any less useful to set it. From a api fanout perspective it might be better to have a tweakrawtxn that is multimodal.
175 2016-04-04T08:48:05  <sipa> multimodal?
176 2016-04-04T08:48:13  <CodeShark> https://bitcoincore.org/en/2016/04/04/announcing_sponsorship_programme/
177 2016-04-04T08:48:50  <gmaxwell> positional arguments are sadness. but the json style of arguments is sadness squared. Thats a place where I think bitcoin-cli translating unix style arguments to json might be OK, as long as it was done consistently so someone could just learn the cli to rpc mapping.
178 2016-04-04T08:49:14  <gmaxwell> sipa: as it tweakrawtxn "hex" optinrbf
179 2016-04-04T08:49:31  <sipa> gmaxwell: ah, reimplementing bitcoin-tx as an rpc? ;)
180 2016-04-04T08:49:48  <gmaxwell> Ha. Indeed.
181 2016-04-04T08:49:51  <jonasschnelli> hehe..
182 2016-04-04T08:50:09  *** laurentmt has joined #bitcoin-core-dev
183 2016-04-04T08:50:32  <jonasschnelli> what speaks against having these tweak-flags in crt?
184 2016-04-04T08:50:40  <gmaxwell> right now the api has excessive fanout. seperate top level functions for varioations on the same thing, side effect of positional arguments and legacy.  It means when looking up a command you have to go through long lists.
185 2016-04-04T08:51:00  *** laurentmt has quit IRC
186 2016-04-04T08:51:05  <gmaxwell> crt?
187 2016-04-04T08:51:07  <jonasschnelli> createrawtransaction
188 2016-04-04T08:51:20  <jonasschnelli> createrawtransaction <inputs> <outputs> <flag|flag>
189 2016-04-04T08:51:22  <gmaxwell> the existance of fundraw for one.
190 2016-04-04T08:51:36  <jonasschnelli> fundrawtx interacts with the wallet
191 2016-04-04T08:52:01  <gmaxwell> the point is that if you set flags in createraw, they won't be visible in fundraw and it might violate them.
192 2016-04-04T08:52:03  <jonasschnelli> <flag|flag> could be {"bip125rbf":true, etc.}
193 2016-04-04T08:52:18  <jonasschnelli> gmaxwell: good point.
194 2016-04-04T08:52:23  <gmaxwell> where as createraw | fundraw | tweak | signraw | sendraw is a fine pipeline.
195 2016-04-04T08:52:55  <jonasschnelli> hmm.. not bad. Fundraw could then remove the opt-in-rbf flag (because it can add inputs).
196 2016-04-04T08:53:27  <jonasschnelli> alternative names for "tweak"?
197 2016-04-04T08:53:33  <sipa> mutate
198 2016-04-04T08:53:35  <jonasschnelli> alter?
199 2016-04-04T08:53:36  <sipa> alter
200 2016-04-04T08:53:38  <sipa> modify
201 2016-04-04T08:53:52  <jonasschnelli> modify is probably most understandable... but that blitcoin-cli in RPC!
202 2016-04-04T08:53:55  <sipa> in the bitcoin-tx source code they are called mutate
203 2016-04-04T08:54:02  <gmaxwell> spindletx
204 2016-04-04T08:54:12  <sipa> transmogrifyrawtx
205 2016-04-04T08:54:19  <gmaxwell> Presotchangotx
206 2016-04-04T08:54:25  * jonasschnelli lol
207 2016-04-04T08:54:25  <gmaxwell> alterrawtx is probably fine.
208 2016-04-04T08:54:44  <jonasschnelli> +1 for alterrawttransaction
209 2016-04-04T08:55:05  <jonasschnelli> We could start with RBF...
210 2016-04-04T08:55:11  <jonasschnelli> add CSV..
211 2016-04-04T08:55:13  <gmaxwell> I guess thats more consistent. (the fact that transaction is spelled out is one of the sadder parts of the interface)
212 2016-04-04T08:55:19  <jonasschnelli> and someone could also implement adding ins and outs.
213 2016-04-04T08:55:39  <jonasschnelli> But once we said keep the utilities outside of the RPC level
214 2016-04-04T08:55:51  <gmaxwell> We sometimes made made choices.
215 2016-04-04T08:56:17  <jonasschnelli> I agree. RPC is very handy for utitilites...
216 2016-04-04T08:56:21  *** Thireus has joined #bitcoin-core-dev
217 2016-04-04T09:03:25  *** Thireus has quit IRC
218 2016-04-04T09:05:13  *** Thireus has joined #bitcoin-core-dev
219 2016-04-04T09:06:20  <jonasschnelli> gmaxwell, sipa: If you interested to review the enc/auth BIP again, a new version is here https://github.com/bitcoin/bips/pull/362/files
220 2016-04-04T09:10:50  <gmaxwell> 64-bit MAC, really?  This leaks message lengths.
221 2016-04-04T09:12:32  <gmaxwell> probably should remove the performance claims from the document? they'll just invite debate over the document text. AES-128-GCM is quite a bit faster than chacha when AES-NI is used. (I'm not arguing it here, just pointing out the argument)
222 2016-04-04T09:12:43  *** Guyver2 has joined #bitcoin-core-dev
223 2016-04-04T09:13:42  <gmaxwell> Is there any need to limit the rekeying that strictly? if it's just a hash operation, someone can just send us transactions to make us hash over and over again.
224 2016-04-04T09:13:50  <wumpus> when AES-NI is used <- but our odroid C2 doesn't have AES-NI :o
225 2016-04-04T09:14:10  <jonasschnelli> gmaxwell: why 64bit mac? Because of the SHA512?
226 2016-04-04T09:14:21  <gmaxwell> hah I know, I was advocating before that we only use chacha here... (the alternative is to support both and negoiate when both ends have aes-ni).
227 2016-04-04T09:15:22  <wumpus> agree, let's just settle on that. I don't think the performance considerations in the cipher are the problem here so I also agree with not making it primary in the document
228 2016-04-04T09:15:26  <jonasschnelli> gmaxwell: the rekeying is local policy, but should not be under 600 seconds to avoid dos (https://github.com/bitcoin/bips/pull/362/files#diff-0bd7a3b80179294f4bcb38cae13c8534R142)
229 2016-04-04T09:15:31  <gmaxwell> jonasschnelli: it's using a 4byte length, which is very wasteful. (on average 2.5 bytes will be wasted) but then only an 8 byte mac which is quite weak.
230 2016-04-04T09:15:52  <sipa> jonasschnelli: poly1305 does not have 256-bit security, and certainly not when you truncate the tag to 64 bits!
231 2016-04-04T09:16:07  <gmaxwell> jonasschnelli: if the timeout is 600 seconds, then a sender cannot rekey for some multiple of that for fear that the far end has a different idea of the arrival time.
232 2016-04-04T09:16:47  <jonasschnelli> sipa: Chacha20 offers 256bit security. I though the poly MAC does not affect the security itself,... only the authentication? Not?
233 2016-04-04T09:17:03  <sipa> jonasschnelli: authentication is part of the security
234 2016-04-04T09:17:12  <sipa> it protects against different types of tlattacks
235 2016-04-04T09:17:15  <sipa> *attacks
236 2016-04-04T09:17:24  <jonasschnelli> Okay... I see.
237 2016-04-04T09:17:27  <gmaxwell> jonasschnelli: the cipher and authentication security go hand in hand, if you can compromise the authentication you can usually make the endpoints leak information about the content.
238 2016-04-04T09:18:10  <jonasschnelli> But 256bit security does not reflect the overall robustness....
239 2016-04-04T09:18:16  <jonasschnelli> But right. Let me better remove this line.
240 2016-04-04T09:18:43  <jonasschnelli> gmaxwell: So you think truncate the TAG to 8 byte is still to long?
241 2016-04-04T09:18:49  <gmaxwell> no it's too short.
242 2016-04-04T09:19:05  <gmaxwell> I would suggest the length be made variable length, self-delimiting, encrypted like in the ssh spec... and that tag length be increased.
243 2016-04-04T09:20:08  <jonasschnelli> Okay. So using the non-truncated full 128bit poly1305 tag?
244 2016-04-04T09:20:29  <gmaxwell> much of the cost of a longer tag could be paid by making the length shorter.  There are some things using 12 byte tags, but I'm not sure what I think about that.
245 2016-04-04T09:20:47  <jonasschnelli> gmaxwell: length variable length -> do you mean varint serialization?
246 2016-04-04T09:21:07  <sipa> gmaxwell: i think varint serialization is overkill
247 2016-04-04T09:21:56  <jonasschnelli> The current message structure also has a int32 for the length. Maybe we keep the varint outside of the message header.
248 2016-04-04T09:22:27  <gmaxwell> sipa: better than truncating the MAC to 8 bytes.
249 2016-04-04T09:22:52  <wumpus> varint is slightly inconvenient, it's nice to be able to read network headers at once
250 2016-04-04T09:23:05  <wumpus> how does ssh handle this?
251 2016-04-04T09:23:11  *** laurentmt has joined #bitcoin-core-dev
252 2016-04-04T09:23:23  <gmaxwell> uses a fixed width interger, it's encrypted however.
253 2016-04-04T09:23:48  <gmaxwell> The varint suggestion was trying to recover the overhead from the longer mac tag, I'm not wed to the idea.
254 2016-04-04T09:24:02  <wumpus> I don't think we should couple the MAC size discussion to the packet length field discussion in any case, at most you'd save ~2 bytes for the typical packet
255 2016-04-04T09:24:08  <gmaxwell> Many of the messages in bitcoin are quite small, so the extra lengths do make a meaningful impact.
256 2016-04-04T09:24:24  <wumpus> yes, but reading one byte of a time from a TCP stream :-(
257 2016-04-04T09:24:51  <gmaxwell> average message size in bitcoin p2p is someting like 100 bytes right now.
258 2016-04-04T09:24:52  <wumpus> let's increase the MAC size and leave the length at four bytes for now
259 2016-04-04T09:24:59  <gmaxwell> yup
260 2016-04-04T09:25:04  <jonasschnelli> Okay. Will do.
261 2016-04-04T09:25:23  <wumpus> gmaxwell: well you had the idea to collate P2P packets into encryption packets ...
262 2016-04-04T09:25:39  <wumpus> (I know, futur work.)
263 2016-04-04T09:25:41  <sipa> wumpus: which is also in the bip, btw
264 2016-04-04T09:25:44  <jonasschnelli> gmaxwell: re-keying minimum of 600 seconds is to large?
265 2016-04-04T09:25:45  <wumpus> oh!
266 2016-04-04T09:25:54  <gmaxwell> yes, though there is 4 byte lengths at each level. At least that helps with mac overhead.
267 2016-04-04T09:26:03  <wumpus> well in the inner packet I'm not opposed to varints
268 2016-04-04T09:26:07  <wumpus> those packets are in memory already
269 2016-04-04T09:26:08  <gmaxwell> jonasschnelli: I'd make it 10 seconds or something very small.
270 2016-04-04T09:26:30  <sipa> rekey every 10 seconds?
271 2016-04-04T09:26:38  <jonasschnelli> sipa: min. 10 sec
272 2016-04-04T09:26:43  <jonasschnelli> flexible local policy.
273 2016-04-04T09:26:57  <jonasschnelli> A node could detect repeating re-keys and ban
274 2016-04-04T09:27:25  <jonasschnelli> I just want a minimum timespan between re-key in the BIP.
275 2016-04-04T09:27:51  <gmaxwell> I don't think a minimum timespan is needed, but if one is there it shouldn't be 600 seconds.
276 2016-04-04T09:28:47  <jonasschnelli> gmaxwell: Yes. We could also leave that open to the implementation. But the most obvious attack vectors maybe should be covered by the BIP?
277 2016-04-04T09:28:51  <sipa> if we care about overhead, the first thing to consider would be making those 12-byte message names varlen :)
278 2016-04-04T09:29:06  <jonasschnelli> Indeed.
279 2016-04-04T09:29:13  <wumpus> yes
280 2016-04-04T09:29:26  <jonasschnelli> We could do this for the encrypted message stucture.
281 2016-04-04T09:29:35  <sipa> jonasschnelli: rekeying every second will still be much lower overhead than normal transaction relay...
282 2016-04-04T09:29:56  <wumpus> +1 for making those varlen, that padding is ugly and people have accidentally leaked memory contents into them in the past :)
283 2016-04-04T09:30:03  <jonasschnelli> sipa: Hmm... right. Its just a 2xSHA256.
284 2016-04-04T09:30:17  <sipa> jonasschnelli: no, it's an ecdh
285 2016-04-04T09:30:24  *** AaronvanW has joined #bitcoin-core-dev
286 2016-04-04T09:30:31  <sipa> which is similar to a signature validation in time
287 2016-04-04T09:30:33  <jonasschnelli> sipa: No. The ECDH is done already,... its only hash(old_key)?
288 2016-04-04T09:30:42  <sipa> jonasschnelli: rekey means doing ecdh again
289 2016-04-04T09:30:48  <gmaxwell> it shouldn't.
290 2016-04-04T09:30:54  <gmaxwell> it doesn't in the spec.
291 2016-04-04T09:31:26  <sipa> ah
292 2016-04-04T09:31:31  <gmaxwell> sipa: it's logically just cranking the initial KDF csprng to the next state.
293 2016-04-04T09:33:11  <jonasschnelli>  okay. 1.) command varlen 2.) AEAD-tag 128bits, 3.) remove 256bit security mentioning.
294 2016-04-04T09:33:47  <gmaxwell> on auth, this protocol looks like it would result in a bitcoin daemon announcing a persistant identity to everyone that connects to it?
295 2016-04-04T09:34:14  <jonasschnelli> According to https://www.ietf.org/proceedings/88/slides/slides-88-tls-1.pdf AES-128-GCM is slower then ChaCha20+Poly1305
296 2016-04-04T09:34:43  <gmaxwell> Is there a reason not to use the scheme I suggested where the client sends an auth challenge which is H(session-id||server-pubkey)  and if the server reconizes one of his keys, he responds with a signature?
297 2016-04-04T09:34:52  <sipa> jonasschnelli: aes-gcm is slowish without hardware support, very fast with
298 2016-04-04T09:35:08  <gmaxwell> jonasschnelli: only if you don not have AES-NI. If you do AES-128-GCM is maybe 7 times faster.
299 2016-04-04T09:35:20  <sipa> jonasschnelli: aes-gcm can get to 1 cycle/byte on modern hardware with asm code
300 2016-04-04T09:35:51  <sipa> jonasschnelli: chacha20-poly1305 is hard to get under 4ish, i think
301 2016-04-04T09:35:53  <jonasschnelli> a... i see. AES-NI: 892 MB/s, ChaCha20+Poly1305, -march=native = 560 MB/s
302 2016-04-04T09:36:41  <jonasschnelli> gmaxwell: the identity would only be revealed by the requesting peer.
303 2016-04-04T09:36:52  <jonasschnelli> So the requesting peer would know who he wants to give its identity price.
304 2016-04-04T09:37:22  <jonasschnelli> The responding peers only reveals its identity if the requesting peers identity "was accepted".
305 2016-04-04T09:37:52  <sipa> jonasschnelli: gmaxwell's protocol never reveals identity, and only works if both sides know the pubkey beforehand
306 2016-04-04T09:38:16  <jonasschnelli> Hmm... yes: H(session-id||server-pubkey)  makes sense.
307 2016-04-04T09:38:42  <sipa> jonasschnelli: those numbers are certainly not the best possible ones
308 2016-04-04T09:38:53  <jonasschnelli> okay.
309 2016-04-04T09:38:59  <gmaxwell> then it hast to be mutual, but what if you just have a trusted node and many things that connect to it. You don't want to do per-peer setup on each side (if you do-- you could setup symmetric keys).  The downside of my protocol is that if you have many different identities you'd have to try all of them, but hashing is cheap, and I don't see a reason to have a huge number of alternative identitie
310 2016-04-04T09:39:06  <gmaxwell> s.
311 2016-04-04T09:39:58  <jonasschnelli> hmm.. so we assume the requesting peer can link a IP to a pubkey
312 2016-04-04T09:40:01  <sipa> i'd prefer focussing on encryption first :)
313 2016-04-04T09:40:19  <gmaxwell> I'd also made a suggestion that auth trigger a rekeying. with the pubkey in the rekeying. Because this has a cute property of being forever forward secure even if ecc is broken, if the public keys are kept private.
314 2016-04-04T09:41:02  <gmaxwell> jonasschnelli: well he hopefully knows who he thinks he's connecting to-- more like the other way around, he has something he wants to connect to (pubkey), and has an IP he thinks belongs to it.
315 2016-04-04T09:41:24  <gmaxwell> but yea, maybe hammer out encryption first.
316 2016-04-04T09:41:27  <jonasschnelli> Could the responding peer answer with a signature of the received hash(received-hash || session-id||server-pubkey)?
317 2016-04-04T09:41:55  <jonasschnelli> I think auth and enc has some overlaps.
318 2016-04-04T09:42:07  <jonasschnelli> (at least in thinking about a solution)
319 2016-04-04T09:43:05  * jonasschnelli needs to go afk for 1h
320 2016-04-04T09:43:11  <gmaxwell> All he should need to do is sign the session-id.
321 2016-04-04T09:48:49  *** Anduck has joined #bitcoin-core-dev
322 2016-04-04T09:49:07  <Anduck> who answers from contact@bitcoincore.org?
323 2016-04-04T09:49:22  <Anduck> i see lots of "contact us" etc. but no names
324 2016-04-04T09:49:27  <Anduck> like who actually run it
325 2016-04-04T09:52:04  *** laurentmt has quit IRC
326 2016-04-04T10:01:28  <GitHub148> [bitcoin] gmaxwell opened pull request #7805: Eliminate TX trickle bypass, sort TX invs for privacy and priority. (master...sorted_invs) https://github.com/bitcoin/bitcoin/pull/7805
327 2016-04-04T10:02:55  *** AtashiCon has quit IRC
328 2016-04-04T10:02:59  *** Arnavion3 has joined #bitcoin-core-dev
329 2016-04-04T10:03:03  *** Arnavion3 is now known as AtashiCon
330 2016-04-04T10:03:08  *** chris2000 has joined #bitcoin-core-dev
331 2016-04-04T10:42:34  *** jtimon has joined #bitcoin-core-dev
332 2016-04-04T11:05:18  <jonasschnelli> sipa: I agree that encryption should be made first. But I just want to avoid that people start using it, and think: "okay, now everything is encrypted, let me use minimum BF FPR", but MITM is still trivial. Auth would allow to reduce the MITM scenario.
333 2016-04-04T11:08:59  <GitHub1> [bitcoin] laanwj closed pull request #7543: [0.12] Backport BIP9, BIP68 and BIP112 with softfork (0.12...dot12_backport_bip68) https://github.com/bitcoin/bitcoin/pull/7543
334 2016-04-04T11:08:59  <GitHub144> [bitcoin] laanwj pushed 24 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/c5f94f6584cb...834aaef7bd37
335 2016-04-04T11:09:00  <GitHub144> bitcoin/0.12 15ba08c Alex Morcos: Implement SequenceLocks functions...
336 2016-04-04T11:09:00  <GitHub144> bitcoin/0.12 0d09af7 Suhas Daftuar: Add RPC test exercising BIP68 (mempool only)
337 2016-04-04T11:09:01  <GitHub144> bitcoin/0.12 0a79c04 Alex Morcos: Bug fix to RPC test
338 2016-04-04T11:10:29  <sipa> jonasschnelli: bf for?
339 2016-04-04T11:10:36  <sipa> bf fpr?
340 2016-04-04T11:10:45  <jonasschnelli> bloomfilter false positive rate
341 2016-04-04T11:10:58  <jonasschnelli> (in case you want to connect a SPV wallet to a node over enc. channels)
342 2016-04-04T11:11:07  <sipa> jonasschnelli: i don't mean that we should encryption running first in production
343 2016-04-04T11:11:23  <sipa> but just have it designed and perhaps implemented first
344 2016-04-04T11:11:31  <sipa> as it interacts heavily with network code
345 2016-04-04T11:11:32  <jonasschnelli> gmaxwell: H(session-id||server-pubkey) would have once downside: extending to an concept where you can connect to a peer where you don't have pre-shared identity-keys
346 2016-04-04T11:11:59  <jonasschnelli> sipa: okay. Yes. That make sense.
347 2016-04-04T11:12:10  <sipa> jonasschnelli: if you don't have pre-shared keys, what are you trying to accomplish?
348 2016-04-04T11:12:46  <jonasschnelli> sipa: I agree. It's a different security level. But it would allow to make sure that further connections are going to the same node.
349 2016-04-04T11:13:04  <sipa> jonasschnelli: that's by definition fingerprinting the node
350 2016-04-04T11:13:37  <sipa> i'm unconvinced that's something we should aim for
351 2016-04-04T11:14:10  <sipa> at least, it's a very different thing from what we've been doing recently, namely trying to avoid fingerprinting
352 2016-04-04T11:14:50  <sipa> maybe there is some mechanism possible where the key is based on the ip, and you never leak identity information for other incoming network addresses
353 2016-04-04T11:15:10  <jonasschnelli> sipa: Yes. Probably. Well, .. i though you could connect to a node, reveal you identity, get the pubkey if the remote node wants to show its identity, .. further MITM would be detectable. But agree. If MITM would be there in first place you have lost anyways.
354 2016-04-04T11:15:34  <sipa> jonasschnelli: yes, that's called tofu (trust on first use)
355 2016-04-04T11:15:51  *** abritoid has joined #bitcoin-core-dev
356 2016-04-04T11:16:10  <jonasschnelli> Ah.. that's the tofu. Thanks.
357 2016-04-04T11:16:54  <sipa> but that may not something you want in general... for example if a node is available over tor and over a normal iov4, you don't want it to have the same identity on both
358 2016-04-04T11:18:08  <jonasschnelli> sipa: hmm.. this would mean one identity per net-type?
359 2016-04-04T11:18:15  <sipa> maybe something you only want for servers on static ips, and only on the listening side
360 2016-04-04T11:19:28  <sipa> so i think it's an orthogonal use case
361 2016-04-04T11:20:47  <sipa> not just per net type
362 2016-04-04T11:21:24  <sipa> if you receive a connection on localhost, what key do you use? that may depend on whether it's a trusted local connection, or it's coming via a proxied tor
363 2016-04-04T11:35:08  <jonasschnelli> If the authack signature would also contain the encryption-session-id (for the opposite com. direction) and the identity-pubkey from the responding peer, that would probably avoid an auth/authack initiated from the responding peer.
364 2016-04-04T11:35:40  <jonasschnelli> auth: H(enc-session-id-A || indenity-pubkey)-A
365 2016-04-04T11:36:21  <jonasschnelli> auth: H(enc-session-id-A || indenity-pubkey-A), authack: sig(H(enc-session-id-B || indenity-pubkey-B))
366 2016-04-04T11:36:34  <jonasschnelli> no wait...
367 2016-04-04T11:36:46  <jonasschnelli> auth: H(enc-session-id-A || indenity-pubkey-A), authack: sig(H(auth-request-hash || enc-session-id-B || indenity-pubkey-B))
368 2016-04-04T11:37:08  <sipa> where does the pubkey of the other side come from?
369 2016-04-04T11:37:56  <jonasschnelli> sipa: the identity pubkey from the other side.
370 2016-04-04T11:38:19  <jonasschnelli> (should be node by the requesting peer because we assume pre-shared keys)
371 2016-04-04T11:38:26  <jonasschnelli> *pre-shared pubkey*
372 2016-04-04T11:40:46  <sipa> let's go over the use cases one by one
373 2016-04-04T11:40:48  <sipa> i know 3
374 2016-04-04T11:41:18  <sipa> 1) light client connecting to a trusted full node; in this case the light client needs to have the pubkey of the trusted node
375 2016-04-04T11:42:03  <sipa> 2) full node only provides (part of) its services to known peers, for example bloom filtering, or block download, or whitelisting, ...; in this case the full node needs to have the pubkey of the client
376 2016-04-04T11:42:30  <sipa> 3) tofu security between any nodes on the network
377 2016-04-04T11:42:37  <sipa> i think 1 and 2 are fundamentally different from 3
378 2016-04-04T11:42:42  *** OGF`off is now known as OGF
379 2016-04-04T11:42:57  <jonasschnelli> I think we should focus for 1/2.
380 2016-04-04T11:42:58  <sipa> because 1 and 2 never need to reveal identities, only provide proof when requested
381 2016-04-04T11:43:12  *** OGF is now known as Guest33626
382 2016-04-04T11:43:18  <jonasschnelli> Do you think 1 without 2 is something we should aim for?
383 2016-04-04T11:43:33  <sipa> i think 1 and 2 are orthogonal
384 2016-04-04T11:43:41  <jonasschnelli> Yes. I agree.
385 2016-04-04T11:43:43  <sipa> and they can use the exact same code, just in the other direction
386 2016-04-04T11:44:05  <jonasschnelli> Then we probably need: auth: H(enc-session-id-A || indenity-pubkey-A), authack: sig(requesting-hash)
387 2016-04-04T11:44:09  <jonasschnelli> For both sides.
388 2016-04-04T11:45:07  <sipa> i don't think that adds anything over signing just the session id
389 2016-04-04T11:45:39  <sipa> Schnorr signatures internally compute a message hash, which is based on the message and the signing pubkey
390 2016-04-04T11:45:48  <sipa> so they already do that internally
391 2016-04-04T11:46:28  <jonasschnelli> if we assume ECDSA, would you then recover the pubkey from the sig to lookup the identity?
392 2016-04-04T11:47:13  <sipa> ? you asked for it, you know it already
393 2016-04-04T11:47:31  <sipa> "hey, are you X?" - "yes, here is proof"
394 2016-04-04T11:48:16  <sipa> we could use bitcoin script for the signatures, so you can do multisig auth :p
395 2016-04-04T11:48:24  <jonasschnelli> heh.
396 2016-04-04T11:48:39  <sipa> "hey, are you X, Y, or Z?" - "yes, here is a scriptSig"
397 2016-04-04T11:49:04  <sipa> no good use case for that though, so let's not exaggerate
398 2016-04-04T11:49:30  * jonasschnelli thinking...
399 2016-04-04T11:50:00  <jonasschnelli> For your usecase 2) when or how would the responding peer ask for "hey, are you X?" - "yes, here is proof"?
400 2016-04-04T11:50:20  <jonasschnelli> A new message-type from the requesting peer?
401 2016-04-04T11:50:36  <jonasschnelli> Or as soon as the requesting peer accesses a restrictied service?
402 2016-04-04T11:50:49  *** Guest33626 has left #bitcoin-core-dev
403 2016-04-04T11:57:16  <sipa> let's say there are two new messages "areyou"(H(peer-pubkey || receive-session-id)) and "yesiam"(H(my-pubkey || send-session-id), sig(key=my-privkey, msg=send-session-id))
404 2016-04-04T11:58:57  <sipa> if you're making/accepting a connection to/from someone and want them to authenticate, you send the areyou as first message inside the encrypted channel, before version
405 2016-04-04T11:59:28  <sipa> there should probably be an explicit "i don't need you to authenticate" ?
406 2016-04-04T12:00:04  <sipa> actually, no
407 2016-04-04T12:00:31  <sipa> you either send an 'areyou' (in which case you wait for a yesiam first), or you send a version yourself
408 2016-04-04T12:05:26  <jonasschnelli> sipa: Hmm.. a requesting peer that seeks access to "filtering" would first send a "areyou"-message to hope the responding peer will also request auth over a "areyou" message?
409 2016-04-04T12:05:59  <jonasschnelli> Or could the requesting peer not just send a "yesiam"(H(my-pubkey || send-session-id)
410 2016-04-04T12:06:27  <sipa> the protocol doesn't continue if they don't respond
411 2016-04-04T12:08:37  <jonasschnelli> sipa: for your usecase 2) the requesting peer first needs to authenticate the responding peer... i think thats fine.
412 2016-04-04T12:08:59  <jonasschnelli> But I don't see a way to do 2) without 1)
413 2016-04-04T12:11:15  <jonasschnelli> but however, let me think a bit about it. My brain usually needs some minutes for processing the input. :)
414 2016-04-04T12:12:05  <sipa> jonasschnelli: 1 and 2 are exactly the same!
415 2016-04-04T12:12:32  <sipa> except initiated by the one listening instead of the one connecting
416 2016-04-04T12:13:11  <sipa> 1 is "are you the server I know? if not, i won't tell you anything about myself!"
417 2016-04-04T12:13:25  <sipa> 2 is "are you the client I know? if not, i won't tell you anything about myself!"
418 2016-04-04T12:13:45  <sipa> but the p2p protocol has no distinction between the one connecting and the one listening
419 2016-04-04T12:13:57  <jonasschnelli> sipa: yes. But for 2) you might not want to ask every peer for authentication.
420 2016-04-04T12:14:21  <sipa> ah, i see
421 2016-04-04T12:14:50  <jonasschnelli> I think in practice, 2 makes only sense with 1
422 2016-04-04T12:15:40  <jonasschnelli> Though, it could be policy (ask every peer, ask only peer where you have authacked).
423 2016-04-04T12:16:24  <sipa> let's get encryption flushed out first :)
424 2016-04-04T12:16:42  <sipa> that's a part that can be shared across all use cases
425 2016-04-04T12:17:00  <jonasschnelli> okay... lets do that.
426 2016-04-04T12:17:24  <jonasschnelli> I'll update the auth bip with all the stuff we have disusses but focus on the enc BIP
427 2016-04-04T12:26:54  *** cryptapus_afk is now known as cryptapus
428 2016-04-04T12:30:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
429 2016-04-04T12:39:49  *** chris2000 has quit IRC
430 2016-04-04T12:40:13  *** Chris_Stewart_5 has quit IRC
431 2016-04-04T12:41:23  <GitHub28> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/834aaef7bd37...e3341aa94e1f
432 2016-04-04T12:41:23  <GitHub28> bitcoin/0.12 e10c044 BtcDrak: [0.12] Update release notes
433 2016-04-04T12:41:23  <GitHub158> [bitcoin] laanwj closed pull request #7800: [0.12] Update release notes (0.12...docs) https://github.com/bitcoin/bitcoin/pull/7800
434 2016-04-04T12:41:24  <GitHub28> bitcoin/0.12 e3341aa Wladimir J. van der Laan: Merge #7800: [0.12] Update release notes...
435 2016-04-04T12:44:16  *** p15 has quit IRC
436 2016-04-04T12:54:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
437 2016-04-04T13:00:01  *** Alopex has quit IRC
438 2016-04-04T13:01:06  *** Alopex has joined #bitcoin-core-dev
439 2016-04-04T13:23:49  <wumpus> oh wow re: tracing and profiling https://github.com/brendangregg/FlameGraph
440 2016-04-04T13:25:04  *** gevs_ has joined #bitcoin-core-dev
441 2016-04-04T13:27:13  *** gevs has quit IRC
442 2016-04-04T13:29:00  *** frankenmint has quit IRC
443 2016-04-04T13:50:20  *** d_t has joined #bitcoin-core-dev
444 2016-04-04T13:50:22  *** d_t has quit IRC
445 2016-04-04T13:51:02  *** zooko has joined #bitcoin-core-dev
446 2016-04-04T13:52:28  *** AaronvanW has quit IRC
447 2016-04-04T14:10:21  *** gevs_ has quit IRC
448 2016-04-04T14:12:56  *** laurentmt has joined #bitcoin-core-dev
449 2016-04-04T14:14:26  *** gevs has joined #bitcoin-core-dev
450 2016-04-04T14:14:38  *** AaronvanW has joined #bitcoin-core-dev
451 2016-04-04T14:29:51  *** frankenmint has joined #bitcoin-core-dev
452 2016-04-04T14:34:38  *** frankenmint has quit IRC
453 2016-04-04T14:39:39  *** laurentmt has quit IRC
454 2016-04-04T14:45:33  *** zooko has quit IRC
455 2016-04-04T14:57:19  *** Giszmo has joined #bitcoin-core-dev
456 2016-04-04T14:57:34  *** dirtynewshoes has quit IRC
457 2016-04-04T15:20:46  <GitHub163> [bitcoin] instagibbs closed pull request #7784: miner_tests number clarification (master...patch-4) https://github.com/bitcoin/bitcoin/pull/7784
458 2016-04-04T15:20:51  <GitHub6> [bitcoin] instagibbs opened pull request #7807: Fixed miner test values, gave constants for less error-prone values. (master...mintest) https://github.com/bitcoin/bitcoin/pull/7807
459 2016-04-04T15:30:34  *** frankenmint has joined #bitcoin-core-dev
460 2016-04-04T15:31:04  *** abritoid has quit IRC
461 2016-04-04T15:35:04  *** frankenmint has quit IRC
462 2016-04-04T15:59:48  *** paveljanik has joined #bitcoin-core-dev
463 2016-04-04T16:31:29  *** frankenmint has joined #bitcoin-core-dev
464 2016-04-04T16:36:42  *** frankenmint has quit IRC
465 2016-04-04T16:53:48  *** paveljanik has quit IRC
466 2016-04-04T16:58:28  *** paveljanik has joined #bitcoin-core-dev
467 2016-04-04T16:58:28  *** paveljanik has joined #bitcoin-core-dev
468 2016-04-04T17:34:11  *** frankenmint has joined #bitcoin-core-dev
469 2016-04-04T17:38:38  *** frankenmint has quit IRC
470 2016-04-04T17:56:00  <Luke-Jr> FWIW, it sounds like bc.i is making bogus problems for 0.12 txns
471 2016-04-04T17:56:12  <Luke-Jr> the fee sniping chang
472 2016-04-04T17:56:13  <Luke-Jr> change*
473 2016-04-04T17:56:58  <gmaxwell> making bogus problems?
474 2016-04-04T17:58:43  <btcdrak> ?
475 2016-04-04T17:58:51  <gmaxwell> sipa:  the client could send [h(session_id||serverkey), h(session_id||clientkey)]  and the server could respond with a signature, and then "ah, you claim to be h(sessionid||clientkey||2), prove it with a signature."
476 2016-04-04T17:59:33  <gmaxwell> sipa: and if the client doesn't wish to identify itself/not configured for mutual auth it just sends a random number in the clientkey field. Server can't meet that challenge, so server doesn't learn anything about client identity.
477 2016-04-04T17:59:54  <gmaxwell> sipa: so this lets you do mutual auth without leaking client identities to people who don't already know them.
478 2016-04-04T18:41:00  *** molz has quit IRC
479 2016-04-04T19:35:02  *** frankenmint has joined #bitcoin-core-dev
480 2016-04-04T19:40:34  *** frankenmint has quit IRC
481 2016-04-04T20:22:32  *** Don_John has joined #bitcoin-core-dev
482 2016-04-04T20:45:51  *** droark has joined #bitcoin-core-dev
483 2016-04-04T21:05:04  *** frankenmint has joined #bitcoin-core-dev
484 2016-04-04T21:09:46  *** frankenmint has quit IRC
485 2016-04-04T21:21:53  *** cheese_ has joined #bitcoin-core-dev
486 2016-04-04T21:21:53  *** cheese_ has joined #bitcoin-core-dev
487 2016-04-04T21:24:39  *** Cheeseo has quit IRC
488 2016-04-04T21:25:51  *** Chris_Stewart_5 has quit IRC
489 2016-04-04T21:31:33  *** da2ce7 has quit IRC
490 2016-04-04T21:34:12  *** da2ce7 has joined #bitcoin-core-dev
491 2016-04-04T21:36:39  *** Guyver2 has quit IRC
492 2016-04-04T21:39:37  *** randy-waterhouse has joined #bitcoin-core-dev
493 2016-04-04T21:40:45  *** frankenmint has joined #bitcoin-core-dev
494 2016-04-04T21:44:13  *** cguida has quit IRC
495 2016-04-04T21:56:53  *** cryptapus__ has joined #bitcoin-core-dev
496 2016-04-04T22:02:27  *** cryptapus__ has quit IRC
497 2016-04-04T22:04:18  *** cryptapus_ has joined #bitcoin-core-dev
498 2016-04-04T22:04:18  *** cryptapus_ has joined #bitcoin-core-dev
499 2016-04-04T22:06:29  *** cryptapus is now known as cryptapus_afk
500 2016-04-04T22:08:15  *** cryptapus_afk is now known as cryptapus
501 2016-04-04T22:09:47  *** cryptapus_ has quit IRC
502 2016-04-04T22:11:19  *** cryptapus has quit IRC
503 2016-04-04T22:14:41  *** cryptapus has joined #bitcoin-core-dev
504 2016-04-04T22:14:41  *** cryptapus has joined #bitcoin-core-dev
505 2016-04-04T22:15:03  *** cryptapus is now known as cryptapus_afk
506 2016-04-04T22:36:21  *** MarcoFalke has quit IRC
507 2016-04-04T22:43:33  *** moli has joined #bitcoin-core-dev
508 2016-04-04T23:10:01  *** frankenmint has quit IRC
509 2016-04-04T23:21:46  *** AaronvanW has quit IRC
510 2016-04-04T23:44:32  *** zooko has joined #bitcoin-core-dev
511 2016-04-04T23:47:03  *** zooko` has joined #bitcoin-core-dev
512 2016-04-04T23:48:36  <GitHub124> [bitcoin] theuni opened pull request #7809: depends: some base fixes/changes (master...depends-updates) https://github.com/bitcoin/bitcoin/pull/7809
513 2016-04-04T23:50:04  *** zooko has quit IRC
514 2016-04-04T23:54:32  *** zooko` has quit IRC
515 2016-04-04T23:56:59  *** zooko has joined #bitcoin-core-dev