12016-04-04T00:19:49  <midnightmagic> is someone still mirroring the PRs, etc?
  22016-04-04T00:21:03  *** Ylbam has quit IRC
  32016-04-04T00:26:59  *** frankenmint has quit IRC
  42016-04-04T00:27:35  *** frankenmint has joined #bitcoin-core-dev
  52016-04-04T00:31:55  *** frankenmint has quit IRC
  62016-04-04T01:00:10  <gmaxwell> morcos: I am boggle at +class CompareTxMemPoolEntryByScore
  72016-04-04T01:00:38  <gmaxwell> oh no I'm not.
  82016-04-04T01:00:54  <gmaxwell> turns out that b and a look a lot like each other on the screen.
  92016-04-04T01:01:18  *** PRab has quit IRC
 102016-04-04T01:01:46  *** PRab has joined #bitcoin-core-dev
 112016-04-04T01:03:03  *** PRab has quit IRC
 122016-04-04T01:03:55  *** PRab has joined #bitcoin-core-dev
 132016-04-04T01:17:50  *** jtimon has quit IRC
 142016-04-04T01:27:06  *** molz has quit IRC
 152016-04-04T01:27:24  *** molz has joined #bitcoin-core-dev
 162016-04-04T01:28:06  *** frankenmint has joined #bitcoin-core-dev
 172016-04-04T01:31:13  *** frankenmint has quit IRC
 182016-04-04T01:31:35  *** frankenmint has joined #bitcoin-core-dev
 192016-04-04T03:10:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 202016-04-04T03:16:59  *** achow101 has quit IRC
 212016-04-04T03:17:22  *** achow101 has joined #bitcoin-core-dev
 222016-04-04T03:52:01  *** Alopex has quit IRC
 232016-04-04T03:52:06  *** zooko has joined #bitcoin-core-dev
 242016-04-04T03:53:06  *** Alopex has joined #bitcoin-core-dev
 252016-04-04T03:53:27  *** Chris_Stewart_5 has quit IRC
 262016-04-04T04:15:04  *** zooko has quit IRC
 272016-04-04T04:25:16  *** Giszmo has quit IRC
 282016-04-04T04:37:22  *** sanada has joined #bitcoin-core-dev
 292016-04-04T04:49:39  *** frankenmint has quit IRC
 302016-04-04T04:57:01  *** Alopex has quit IRC
 312016-04-04T04:58:06  *** Alopex has joined #bitcoin-core-dev
 322016-04-04T05:02:23  *** frankenmint has joined #bitcoin-core-dev
 332016-04-04T05:05:30  *** d_t has joined #bitcoin-core-dev
 342016-04-04T05:13:01  *** Alopex has quit IRC
 352016-04-04T05:14:06  *** Alopex has joined #bitcoin-core-dev
 362016-04-04T05:43:14  *** d_t has quit IRC
 372016-04-04T05:59:57  *** p15 has joined #bitcoin-core-dev
 382016-04-04T06:12:01  *** Alopex has quit IRC
 392016-04-04T06:13:06  *** Alopex has joined #bitcoin-core-dev
 402016-04-04T06:49:34  *** droark has quit IRC
 412016-04-04T06:51:30  *** paveljanik has quit IRC
 422016-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?
 432016-04-04T07:09:45  <wumpus> (for linux)
 442016-04-04T07:13:24  <wumpus> thanks for all the work on the tests MarcoFalke
 452016-04-04T07:21:26  <Lightsword> wumpus, I think valgrind may have something for that
 462016-04-04T07:21:44  <wumpus> thanks
 472016-04-04T07:22:30  <Lightsword> http://valgrind.org/docs/manual/drd-manual.html#drd-manual.lock-contention
 482016-04-04T07:24:25  <sipa> if contention is really significant i expect it to show up in profilimg
 492016-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 :)
 502016-04-04T07:26:14  <sipa> haha
 512016-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
 522016-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
 532016-04-04T07:28:37  <Lightsword> dtrace?
 542016-04-04T07:28:49  <wumpus> yes it was a proprietary tool based on dtrace
 552016-04-04T07:29:28  <Lightsword> https://github.com/dtrace4linux/linux
 562016-04-04T07:29:57  <wumpus> yes saw that one, there's also systemtap, and oprofile, which have similar aims but use slightly different mechanisms
 572016-04-04T07:30:24  <wumpus> oh and sysdig!
 582016-04-04T07:30:55  * wumpus mumbles something about fragmentation
 592016-04-04T07:33:06  <Lightsword> because who doesn’t like to have 10 different profiling tools that work slightly differently :P
 602016-04-04T07:33:12  <wumpus> :-)
 612016-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
 622016-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
 632016-04-04T07:36:24  *** Ylbam has joined #bitcoin-core-dev
 642016-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
 652016-04-04T07:36:38  <wumpus> "we" is general, especially the open source community
 662016-04-04T07:36:53  *** slackircbridge has quit IRC
 672016-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
 682016-04-04T07:37:50  *** dgenr8 has quit IRC
 692016-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
 702016-04-04T07:38:09  *** dgenr8 has joined #bitcoin-core-dev
 712016-04-04T07:39:29  *** p15 has quit IRC
 722016-04-04T07:41:32  *** justanotheruser has quit IRC
 732016-04-04T07:42:09  *** Evel-Knievel has quit IRC
 742016-04-04T07:42:30  *** justanotheruser has joined #bitcoin-core-dev
 752016-04-04T07:42:39  *** p15 has joined #bitcoin-core-dev
 762016-04-04T07:42:40  *** Evel-Knievel has joined #bitcoin-core-dev
 772016-04-04T07:44:16  <jonasschnelli> Any final feelings about RBF for createrawtx (https://github.com/bitcoin/bitcoin/pull/7159/files)?
 782016-04-04T07:44:28  <jonasschnelli> Should I remove the general opt-in boolean?
 792016-04-04T07:44:33  <jonasschnelli> And add a seq-nr per input?
 802016-04-04T07:44:52  <jonasschnelli> I like both approaches.
 812016-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.
 822016-04-04T07:45:42  <jonasschnelli> Maybe we can have both?
 832016-04-04T07:49:53  <jonasschnelli> Wait. The sequence option was added already.
 842016-04-04T07:50:38  <gmaxwell> needs nlock too.. globals could be used to autopopulate sequence/nlock if not overridden.
 852016-04-04T07:52:01  <sipa> hmm, i'm unsure
 862016-04-04T07:52:15  <sipa> the question is what createrawtransaction's goal os
 872016-04-04T07:52:37  <sipa> just only using explicit values would be more in line with its name
 882016-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.
 892016-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
 902016-04-04T07:53:49  <gmaxwell> why make it gratitiously less useful?
 912016-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
 922016-04-04T07:58:13  *** laurentmt has joined #bitcoin-core-dev
 932016-04-04T07:58:50  <GitHub77> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e662a7628801...a9149688f87c
 942016-04-04T07:58:50  <GitHub77> bitcoin/master 8efed3b Jonas Schnelli: [Qt] Support for abandoned/abandoning transactions
 952016-04-04T07:58:51  <GitHub77> bitcoin/master a914968 Jonas Schnelli: Merge #7707: [RPC][QT] UI support for abandoned transactions...
 962016-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
 972016-04-04T07:59:17  *** laurentmt has quit IRC
 982016-04-04T08:02:48  <sipa> gmaxwell: i dislike feature creep
 992016-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?"
1002016-04-04T08:03:27  <gmaxwell> I dislike having functionality which doesn't get used but for small shortcoming that take away its utility.
1012016-04-04T08:05:25  <sipa> i just don't know how to reconcile it being "raw" with the suggested functionality
1022016-04-04T08:05:55  <gmaxwell> raw is the fact that it returns a rawtransaction to you.
1032016-04-04T08:06:06  <sipa> my preference would be just allowing setting nlocktime and nsequence
1042016-04-04T08:06:22  <sipa> it also doesn't create change outputs automatocally
1052016-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.
1062016-04-04T08:06:52  *** jannes has joined #bitcoin-core-dev
1072016-04-04T08:07:25  <sipa> but have another RPC for higher level operations like this
1082016-04-04T08:07:53  <gmaxwell> it would just be an exact copy of createrawtransaction, with extra flags and or slightly different defaults.
1092016-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, ...?
1102016-04-04T08:11:00  <gmaxwell> I wouldn't object to just having another RPC like that... but it seems a waste.
1112016-04-04T08:11:34  <gmaxwell> sipa: yes.
1122016-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.
1132016-04-04T08:12:44  <sipa> so what if you want the rbf/sniping/rellocktime/... logic, but not createrawtransaction?
1142016-04-04T08:12:57  <gmaxwell> sounds like arguments for sendmany.
1152016-04-04T08:13:20  <sipa> so we'd add those to both sendmany and createrawtransaction?
1162016-04-04T08:14:53  <sipa> just trying to think this through
1172016-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.
1182016-04-04T08:15:10  <gmaxwell> e.g. totally reasonable to use the rawworkflow to make a nlocked transaction for the future.
1192016-04-04T08:16:10  <sipa> it's just so ugly to have both high level logic and the ability to override
1202016-04-04T08:16:28  <sipa> say we didn't add csv support now, just optinrbf or not
1212016-04-04T08:16:53  <sipa> someone starts using csv by setting the sequence number explicitly, but also passes optinrbf=no
1222016-04-04T08:17:06  <sipa> and expects a transaction that is not replacable
1232016-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.
1242016-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
1252016-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.
1262016-04-04T08:34:40  <jonasschnelli> IMO it's on a different level then the rawtx abstraction
1272016-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
1282016-04-04T08:35:29  <jonasschnelli> sipa: not if they use fundraw. :)
1292016-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
1302016-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
1312016-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
1322016-04-04T08:36:56  <jonasschnelli> sipa: I agree. But knowing also the magic numbers we use for nSequence is another "level":
1332016-04-04T08:37:22  <jonasschnelli> At least we should offer some nSequence=BIP125 abstraction.
1342016-04-04T08:37:36  <sipa> yes, agree
1352016-04-04T08:37:40  <jonasschnelli> The per-tx-general opt-in-to-Bip125 is probably to high. I agree.
1362016-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)
1372016-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
1382016-04-04T08:38:30  <jonasschnelli> Yes. Agree.
1392016-04-04T08:38:47  <jonasschnelli> But the BIP125 MAXINT-2 is a policy we should offer directly.
1402016-04-04T08:39:18  <jonasschnelli> {"txid": <txid>, "vout" : 0, "sequence": "BIP12"} <--- feels ugly
1412016-04-04T08:39:19  <sipa> what will you do to add csv supoort to createrawtransaction?
1422016-04-04T08:39:42  * jonasschnelli is thinking...
1432016-04-04T08:40:04  <sipa> i really dislike mixing magic smart behaviour with raw overriding
1442016-04-04T08:40:29  <gmaxwell> I don't really like mixing types in a single argument name.
1452016-04-04T08:40:29  <sipa> that feels like the rpc is trying to solve things at different levels
1462016-04-04T08:41:03  <jonasschnelli> flags per input? FLAG_BIP125_RBF, SEQUENCE_LOCKTIME_TYPE_FLAG?
1472016-04-04T08:41:08  <gmaxwell> e.g. sequence: 12345  / and seqtype: "BIP12" and have their use be mutually exclusive would seem preferable to me.
1482016-04-04T08:41:35  <jonasschnelli> no. flags per input is bad.
1492016-04-04T08:41:42  <sipa> i'd almost argue for a computensequencevalue RPC
1502016-04-04T08:41:56  <sipa> which just gives you the number to use, which you can put in crt
1512016-04-04T08:42:08  <sipa> but that's cumbersome for human users...
1522016-04-04T08:42:20  <jonasschnelli> RPC is not made for "human" users.
1532016-04-04T08:42:26  <jonasschnelli> I think its fine...
1542016-04-04T08:42:38  <jonasschnelli> Chains of commands is something that increase the modularity
1552016-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.
1562016-04-04T08:43:52  <gmaxwell> like having an REPL makes python accessible to people.
1572016-04-04T08:43:55  <jonasschnelli> A "setoptinrbf <rawtx>" is probably a bad design and leads to overriding ther nsequence magics
1582016-04-04T08:44:02  <sipa> jonasschnelli: agree
1592016-04-04T08:44:15  <sipa> optinrbf should be something you choose per tx
1602016-04-04T08:44:24  <jonasschnelli> gmaxwell: imo RPC != commandline, .. bitcoin-cli == commandline
1612016-04-04T08:44:32  <sipa> some receivers may not want such transactions
1622016-04-04T08:44:33  <jonasschnelli> bitcoin-cli could combine stuff
1632016-04-04T08:44:48  *** Thireus has quit IRC
1642016-04-04T08:45:00  <jonasschnelli> sipa: "setoptinrbf" would be per rawtx.
1652016-04-04T08:45:09  <jonasschnelli> It would just set the nSequence number of all inputs to MAXINT-2
1662016-04-04T08:45:12  <gmaxwell> jonasschnelli: that would harm discoverability, I think it is unfortunate to create wildly different interfaces.
1672016-04-04T08:45:20  <jonasschnelli> But I don't like the override character.
1682016-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.
1692016-04-04T08:45:42  <jonasschnelli> gmaxwell: Yes. It would add another level.. which I agree its bad.
1702016-04-04T08:46:14  <jonasschnelli> gmaxwell: Yes. That could be nice (move MAXINT/-1 to -2)
1712016-04-04T08:46:41  <jonasschnelli> but would "optinrbf <rawtx>" not be to prominent for a policy flag?
1722016-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)
1732016-04-04T08:47:37  <sipa> our 'default' of using positional arguments does not help
1742016-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.
1752016-04-04T08:48:05  <sipa> multimodal?
1762016-04-04T08:48:13  <CodeShark> https://bitcoincore.org/en/2016/04/04/announcing_sponsorship_programme/
1772016-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.
1782016-04-04T08:49:14  <gmaxwell> sipa: as it tweakrawtxn "hex" optinrbf
1792016-04-04T08:49:31  <sipa> gmaxwell: ah, reimplementing bitcoin-tx as an rpc? ;)
1802016-04-04T08:49:48  <gmaxwell> Ha. Indeed.
1812016-04-04T08:49:51  <jonasschnelli> hehe..
1822016-04-04T08:50:09  *** laurentmt has joined #bitcoin-core-dev
1832016-04-04T08:50:32  <jonasschnelli> what speaks against having these tweak-flags in crt?
1842016-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.
1852016-04-04T08:51:00  *** laurentmt has quit IRC
1862016-04-04T08:51:05  <gmaxwell> crt?
1872016-04-04T08:51:07  <jonasschnelli> createrawtransaction
1882016-04-04T08:51:20  <jonasschnelli> createrawtransaction <inputs> <outputs> <flag|flag>
1892016-04-04T08:51:22  <gmaxwell> the existance of fundraw for one.
1902016-04-04T08:51:36  <jonasschnelli> fundrawtx interacts with the wallet
1912016-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.
1922016-04-04T08:52:03  <jonasschnelli> <flag|flag> could be {"bip125rbf":true, etc.}
1932016-04-04T08:52:18  <jonasschnelli> gmaxwell: good point.
1942016-04-04T08:52:23  <gmaxwell> where as createraw | fundraw | tweak | signraw | sendraw is a fine pipeline.
1952016-04-04T08:52:55  <jonasschnelli> hmm.. not bad. Fundraw could then remove the opt-in-rbf flag (because it can add inputs).
1962016-04-04T08:53:27  <jonasschnelli> alternative names for "tweak"?
1972016-04-04T08:53:33  <sipa> mutate
1982016-04-04T08:53:35  <jonasschnelli> alter?
1992016-04-04T08:53:36  <sipa> alter
2002016-04-04T08:53:38  <sipa> modify
2012016-04-04T08:53:52  <jonasschnelli> modify is probably most understandable... but that blitcoin-cli in RPC!
2022016-04-04T08:53:55  <sipa> in the bitcoin-tx source code they are called mutate
2032016-04-04T08:54:02  <gmaxwell> spindletx
2042016-04-04T08:54:12  <sipa> transmogrifyrawtx
2052016-04-04T08:54:19  <gmaxwell> Presotchangotx
2062016-04-04T08:54:25  * jonasschnelli lol
2072016-04-04T08:54:25  <gmaxwell> alterrawtx is probably fine.
2082016-04-04T08:54:44  <jonasschnelli> +1 for alterrawttransaction
2092016-04-04T08:55:05  <jonasschnelli> We could start with RBF...
2102016-04-04T08:55:11  <jonasschnelli> add CSV..
2112016-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)
2122016-04-04T08:55:19  <jonasschnelli> and someone could also implement adding ins and outs.
2132016-04-04T08:55:39  <jonasschnelli> But once we said keep the utilities outside of the RPC level
2142016-04-04T08:55:51  <gmaxwell> We sometimes made made choices.
2152016-04-04T08:56:17  <jonasschnelli> I agree. RPC is very handy for utitilites...
2162016-04-04T08:56:21  *** Thireus has joined #bitcoin-core-dev
2172016-04-04T09:03:25  *** Thireus has quit IRC
2182016-04-04T09:05:13  *** Thireus has joined #bitcoin-core-dev
2192016-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
2202016-04-04T09:10:50  <gmaxwell> 64-bit MAC, really?  This leaks message lengths.
2212016-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)
2222016-04-04T09:12:43  *** Guyver2 has joined #bitcoin-core-dev
2232016-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.
2242016-04-04T09:13:50  <wumpus> when AES-NI is used <- but our odroid C2 doesn't have AES-NI :o
2252016-04-04T09:14:10  <jonasschnelli> gmaxwell: why 64bit mac? Because of the SHA512?
2262016-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).
2272016-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
2282016-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)
2292016-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.
2302016-04-04T09:15:52  <sipa> jonasschnelli: poly1305 does not have 256-bit security, and certainly not when you truncate the tag to 64 bits!
2312016-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.
2322016-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?
2332016-04-04T09:17:03  <sipa> jonasschnelli: authentication is part of the security
2342016-04-04T09:17:12  <sipa> it protects against different types of tlattacks
2352016-04-04T09:17:15  <sipa> *attacks
2362016-04-04T09:17:24  <jonasschnelli> Okay... I see.
2372016-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.
2382016-04-04T09:18:10  <jonasschnelli> But 256bit security does not reflect the overall robustness....
2392016-04-04T09:18:16  <jonasschnelli> But right. Let me better remove this line.
2402016-04-04T09:18:43  <jonasschnelli> gmaxwell: So you think truncate the TAG to 8 byte is still to long?
2412016-04-04T09:18:49  <gmaxwell> no it's too short.
2422016-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.
2432016-04-04T09:20:08  <jonasschnelli> Okay. So using the non-truncated full 128bit poly1305 tag?
2442016-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.
2452016-04-04T09:20:47  <jonasschnelli> gmaxwell: length variable length -> do you mean varint serialization?
2462016-04-04T09:21:07  <sipa> gmaxwell: i think varint serialization is overkill
2472016-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.
2482016-04-04T09:22:27  <gmaxwell> sipa: better than truncating the MAC to 8 bytes.
2492016-04-04T09:22:52  <wumpus> varint is slightly inconvenient, it's nice to be able to read network headers at once
2502016-04-04T09:23:05  <wumpus> how does ssh handle this?
2512016-04-04T09:23:11  *** laurentmt has joined #bitcoin-core-dev
2522016-04-04T09:23:23  <gmaxwell> uses a fixed width interger, it's encrypted however.
2532016-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.
2542016-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
2552016-04-04T09:24:08  <gmaxwell> Many of the messages in bitcoin are quite small, so the extra lengths do make a meaningful impact.
2562016-04-04T09:24:24  <wumpus> yes, but reading one byte of a time from a TCP stream :-(
2572016-04-04T09:24:51  <gmaxwell> average message size in bitcoin p2p is someting like 100 bytes right now.
2582016-04-04T09:24:52  <wumpus> let's increase the MAC size and leave the length at four bytes for now
2592016-04-04T09:24:59  <gmaxwell> yup
2602016-04-04T09:25:04  <jonasschnelli> Okay. Will do.
2612016-04-04T09:25:23  <wumpus> gmaxwell: well you had the idea to collate P2P packets into encryption packets ...
2622016-04-04T09:25:39  <wumpus> (I know, futur work.)
2632016-04-04T09:25:41  <sipa> wumpus: which is also in the bip, btw
2642016-04-04T09:25:44  <jonasschnelli> gmaxwell: re-keying minimum of 600 seconds is to large?
2652016-04-04T09:25:45  <wumpus> oh!
2662016-04-04T09:25:54  <gmaxwell> yes, though there is 4 byte lengths at each level. At least that helps with mac overhead.
2672016-04-04T09:26:03  <wumpus> well in the inner packet I'm not opposed to varints
2682016-04-04T09:26:07  <wumpus> those packets are in memory already
2692016-04-04T09:26:08  <gmaxwell> jonasschnelli: I'd make it 10 seconds or something very small.
2702016-04-04T09:26:30  <sipa> rekey every 10 seconds?
2712016-04-04T09:26:38  <jonasschnelli> sipa: min. 10 sec
2722016-04-04T09:26:43  <jonasschnelli> flexible local policy.
2732016-04-04T09:26:57  <jonasschnelli> A node could detect repeating re-keys and ban
2742016-04-04T09:27:25  <jonasschnelli> I just want a minimum timespan between re-key in the BIP.
2752016-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.
2762016-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?
2772016-04-04T09:28:51  <sipa> if we care about overhead, the first thing to consider would be making those 12-byte message names varlen :)
2782016-04-04T09:29:06  <jonasschnelli> Indeed.
2792016-04-04T09:29:13  <wumpus> yes
2802016-04-04T09:29:26  <jonasschnelli> We could do this for the encrypted message stucture.
2812016-04-04T09:29:35  <sipa> jonasschnelli: rekeying every second will still be much lower overhead than normal transaction relay...
2822016-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 :)
2832016-04-04T09:30:03  <jonasschnelli> sipa: Hmm... right. Its just a 2xSHA256.
2842016-04-04T09:30:17  <sipa> jonasschnelli: no, it's an ecdh
2852016-04-04T09:30:24  *** AaronvanW has joined #bitcoin-core-dev
2862016-04-04T09:30:31  <sipa> which is similar to a signature validation in time
2872016-04-04T09:30:33  <jonasschnelli> sipa: No. The ECDH is done already,... its only hash(old_key)?
2882016-04-04T09:30:42  <sipa> jonasschnelli: rekey means doing ecdh again
2892016-04-04T09:30:48  <gmaxwell> it shouldn't.
2902016-04-04T09:30:54  <gmaxwell> it doesn't in the spec.
2912016-04-04T09:31:26  <sipa> ah
2922016-04-04T09:31:31  <gmaxwell> sipa: it's logically just cranking the initial KDF csprng to the next state.
2932016-04-04T09:33:11  <jonasschnelli>  okay. 1.) command varlen 2.) AEAD-tag 128bits, 3.) remove 256bit security mentioning.
2942016-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?
2952016-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
2962016-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?
2972016-04-04T09:34:52  <sipa> jonasschnelli: aes-gcm is slowish without hardware support, very fast with
2982016-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.
2992016-04-04T09:35:20  <sipa> jonasschnelli: aes-gcm can get to 1 cycle/byte on modern hardware with asm code
3002016-04-04T09:35:51  <sipa> jonasschnelli: chacha20-poly1305 is hard to get under 4ish, i think
3012016-04-04T09:35:53  <jonasschnelli> a... i see. AES-NI: 892 MB/s, ChaCha20+Poly1305, -march=native = 560 MB/s
3022016-04-04T09:36:41  <jonasschnelli> gmaxwell: the identity would only be revealed by the requesting peer.
3032016-04-04T09:36:52  <jonasschnelli> So the requesting peer would know who he wants to give its identity price.
3042016-04-04T09:37:22  <jonasschnelli> The responding peers only reveals its identity if the requesting peers identity "was accepted".
3052016-04-04T09:37:52  <sipa> jonasschnelli: gmaxwell's protocol never reveals identity, and only works if both sides know the pubkey beforehand
3062016-04-04T09:38:16  <jonasschnelli> Hmm... yes: H(session-id||server-pubkey)  makes sense.
3072016-04-04T09:38:42  <sipa> jonasschnelli: those numbers are certainly not the best possible ones
3082016-04-04T09:38:53  <jonasschnelli> okay.
3092016-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
3102016-04-04T09:39:06  <gmaxwell> s.
3112016-04-04T09:39:58  <jonasschnelli> hmm.. so we assume the requesting peer can link a IP to a pubkey
3122016-04-04T09:40:01  <sipa> i'd prefer focussing on encryption first :)
3132016-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.
3142016-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.
3152016-04-04T09:41:24  <gmaxwell> but yea, maybe hammer out encryption first.
3162016-04-04T09:41:27  <jonasschnelli> Could the responding peer answer with a signature of the received hash(received-hash || session-id||server-pubkey)?
3172016-04-04T09:41:55  <jonasschnelli> I think auth and enc has some overlaps.
3182016-04-04T09:42:07  <jonasschnelli> (at least in thinking about a solution)
3192016-04-04T09:43:05  * jonasschnelli needs to go afk for 1h
3202016-04-04T09:43:11  <gmaxwell> All he should need to do is sign the session-id.
3212016-04-04T09:48:49  *** Anduck has joined #bitcoin-core-dev
3222016-04-04T09:49:07  <Anduck> who answers from contact@bitcoincore.org?
3232016-04-04T09:49:22  <Anduck> i see lots of "contact us" etc. but no names
3242016-04-04T09:49:27  <Anduck> like who actually run it
3252016-04-04T09:52:04  *** laurentmt has quit IRC
3262016-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
3272016-04-04T10:02:55  *** AtashiCon has quit IRC
3282016-04-04T10:02:59  *** Arnavion3 has joined #bitcoin-core-dev
3292016-04-04T10:03:03  *** Arnavion3 is now known as AtashiCon
3302016-04-04T10:03:08  *** chris2000 has joined #bitcoin-core-dev
3312016-04-04T10:42:34  *** jtimon has joined #bitcoin-core-dev
3322016-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.
3332016-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
3342016-04-04T11:08:59  <GitHub144> [bitcoin] laanwj pushed 24 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/c5f94f6584cb...834aaef7bd37
3352016-04-04T11:09:00  <GitHub144> bitcoin/0.12 15ba08c Alex Morcos: Implement SequenceLocks functions...
3362016-04-04T11:09:00  <GitHub144> bitcoin/0.12 0d09af7 Suhas Daftuar: Add RPC test exercising BIP68 (mempool only)
3372016-04-04T11:09:01  <GitHub144> bitcoin/0.12 0a79c04 Alex Morcos: Bug fix to RPC test
3382016-04-04T11:10:29  <sipa> jonasschnelli: bf for?
3392016-04-04T11:10:36  <sipa> bf fpr?
3402016-04-04T11:10:45  <jonasschnelli> bloomfilter false positive rate
3412016-04-04T11:10:58  <jonasschnelli> (in case you want to connect a SPV wallet to a node over enc. channels)
3422016-04-04T11:11:07  <sipa> jonasschnelli: i don't mean that we should encryption running first in production
3432016-04-04T11:11:23  <sipa> but just have it designed and perhaps implemented first
3442016-04-04T11:11:31  <sipa> as it interacts heavily with network code
3452016-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
3462016-04-04T11:11:59  <jonasschnelli> sipa: okay. Yes. That make sense.
3472016-04-04T11:12:10  <sipa> jonasschnelli: if you don't have pre-shared keys, what are you trying to accomplish?
3482016-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.
3492016-04-04T11:13:04  <sipa> jonasschnelli: that's by definition fingerprinting the node
3502016-04-04T11:13:37  <sipa> i'm unconvinced that's something we should aim for
3512016-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
3522016-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
3532016-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.
3542016-04-04T11:15:34  <sipa> jonasschnelli: yes, that's called tofu (trust on first use)
3552016-04-04T11:15:51  *** abritoid has joined #bitcoin-core-dev
3562016-04-04T11:16:10  <jonasschnelli> Ah.. that's the tofu. Thanks.
3572016-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
3582016-04-04T11:18:08  <jonasschnelli> sipa: hmm.. this would mean one identity per net-type?
3592016-04-04T11:18:15  <sipa> maybe something you only want for servers on static ips, and only on the listening side
3602016-04-04T11:19:28  <sipa> so i think it's an orthogonal use case
3612016-04-04T11:20:47  <sipa> not just per net type
3622016-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
3632016-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.
3642016-04-04T11:35:40  <jonasschnelli> auth: H(enc-session-id-A || indenity-pubkey)-A
3652016-04-04T11:36:21  <jonasschnelli> auth: H(enc-session-id-A || indenity-pubkey-A), authack: sig(H(enc-session-id-B || indenity-pubkey-B))
3662016-04-04T11:36:34  <jonasschnelli> no wait...
3672016-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))
3682016-04-04T11:37:08  <sipa> where does the pubkey of the other side come from?
3692016-04-04T11:37:56  <jonasschnelli> sipa: the identity pubkey from the other side.
3702016-04-04T11:38:19  <jonasschnelli> (should be node by the requesting peer because we assume pre-shared keys)
3712016-04-04T11:38:26  <jonasschnelli> *pre-shared pubkey*
3722016-04-04T11:40:46  <sipa> let's go over the use cases one by one
3732016-04-04T11:40:48  <sipa> i know 3
3742016-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
3752016-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
3762016-04-04T11:42:30  <sipa> 3) tofu security between any nodes on the network
3772016-04-04T11:42:37  <sipa> i think 1 and 2 are fundamentally different from 3
3782016-04-04T11:42:42  *** OGF`off is now known as OGF
3792016-04-04T11:42:57  <jonasschnelli> I think we should focus for 1/2.
3802016-04-04T11:42:58  <sipa> because 1 and 2 never need to reveal identities, only provide proof when requested
3812016-04-04T11:43:12  *** OGF is now known as Guest33626
3822016-04-04T11:43:18  <jonasschnelli> Do you think 1 without 2 is something we should aim for?
3832016-04-04T11:43:33  <sipa> i think 1 and 2 are orthogonal
3842016-04-04T11:43:41  <jonasschnelli> Yes. I agree.
3852016-04-04T11:43:43  <sipa> and they can use the exact same code, just in the other direction
3862016-04-04T11:44:05  <jonasschnelli> Then we probably need: auth: H(enc-session-id-A || indenity-pubkey-A), authack: sig(requesting-hash)
3872016-04-04T11:44:09  <jonasschnelli> For both sides.
3882016-04-04T11:45:07  <sipa> i don't think that adds anything over signing just the session id
3892016-04-04T11:45:39  <sipa> Schnorr signatures internally compute a message hash, which is based on the message and the signing pubkey
3902016-04-04T11:45:48  <sipa> so they already do that internally
3912016-04-04T11:46:28  <jonasschnelli> if we assume ECDSA, would you then recover the pubkey from the sig to lookup the identity?
3922016-04-04T11:47:13  <sipa> ? you asked for it, you know it already
3932016-04-04T11:47:31  <sipa> "hey, are you X?" - "yes, here is proof"
3942016-04-04T11:48:16  <sipa> we could use bitcoin script for the signatures, so you can do multisig auth :p
3952016-04-04T11:48:24  <jonasschnelli> heh.
3962016-04-04T11:48:39  <sipa> "hey, are you X, Y, or Z?" - "yes, here is a scriptSig"
3972016-04-04T11:49:04  <sipa> no good use case for that though, so let's not exaggerate
3982016-04-04T11:49:30  * jonasschnelli thinking...
3992016-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"?
4002016-04-04T11:50:20  <jonasschnelli> A new message-type from the requesting peer?
4012016-04-04T11:50:36  <jonasschnelli> Or as soon as the requesting peer accesses a restrictied service?
4022016-04-04T11:50:49  *** Guest33626 has left #bitcoin-core-dev
4032016-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))
4042016-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
4052016-04-04T11:59:28  <sipa> there should probably be an explicit "i don't need you to authenticate" ?
4062016-04-04T12:00:04  <sipa> actually, no
4072016-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
4082016-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?
4092016-04-04T12:05:59  <jonasschnelli> Or could the requesting peer not just send a "yesiam"(H(my-pubkey || send-session-id)
4102016-04-04T12:06:27  <sipa> the protocol doesn't continue if they don't respond
4112016-04-04T12:08:37  <jonasschnelli> sipa: for your usecase 2) the requesting peer first needs to authenticate the responding peer... i think thats fine.
4122016-04-04T12:08:59  <jonasschnelli> But I don't see a way to do 2) without 1)
4132016-04-04T12:11:15  <jonasschnelli> but however, let me think a bit about it. My brain usually needs some minutes for processing the input. :)
4142016-04-04T12:12:05  <sipa> jonasschnelli: 1 and 2 are exactly the same!
4152016-04-04T12:12:32  <sipa> except initiated by the one listening instead of the one connecting
4162016-04-04T12:13:11  <sipa> 1 is "are you the server I know? if not, i won't tell you anything about myself!"
4172016-04-04T12:13:25  <sipa> 2 is "are you the client I know? if not, i won't tell you anything about myself!"
4182016-04-04T12:13:45  <sipa> but the p2p protocol has no distinction between the one connecting and the one listening
4192016-04-04T12:13:57  <jonasschnelli> sipa: yes. But for 2) you might not want to ask every peer for authentication.
4202016-04-04T12:14:21  <sipa> ah, i see
4212016-04-04T12:14:50  <jonasschnelli> I think in practice, 2 makes only sense with 1
4222016-04-04T12:15:40  <jonasschnelli> Though, it could be policy (ask every peer, ask only peer where you have authacked).
4232016-04-04T12:16:24  <sipa> let's get encryption flushed out first :)
4242016-04-04T12:16:42  <sipa> that's a part that can be shared across all use cases
4252016-04-04T12:17:00  <jonasschnelli> okay... lets do that.
4262016-04-04T12:17:24  <jonasschnelli> I'll update the auth bip with all the stuff we have disusses but focus on the enc BIP
4272016-04-04T12:26:54  *** cryptapus_afk is now known as cryptapus
4282016-04-04T12:30:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4292016-04-04T12:39:49  *** chris2000 has quit IRC
4302016-04-04T12:40:13  *** Chris_Stewart_5 has quit IRC
4312016-04-04T12:41:23  <GitHub28> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/834aaef7bd37...e3341aa94e1f
4322016-04-04T12:41:23  <GitHub28> bitcoin/0.12 e10c044 BtcDrak: [0.12] Update release notes
4332016-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
4342016-04-04T12:41:24  <GitHub28> bitcoin/0.12 e3341aa Wladimir J. van der Laan: Merge #7800: [0.12] Update release notes...
4352016-04-04T12:44:16  *** p15 has quit IRC
4362016-04-04T12:54:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4372016-04-04T13:00:01  *** Alopex has quit IRC
4382016-04-04T13:01:06  *** Alopex has joined #bitcoin-core-dev
4392016-04-04T13:23:49  <wumpus> oh wow re: tracing and profiling https://github.com/brendangregg/FlameGraph
4402016-04-04T13:25:04  *** gevs_ has joined #bitcoin-core-dev
4412016-04-04T13:27:13  *** gevs has quit IRC
4422016-04-04T13:29:00  *** frankenmint has quit IRC
4432016-04-04T13:50:20  *** d_t has joined #bitcoin-core-dev
4442016-04-04T13:50:22  *** d_t has quit IRC
4452016-04-04T13:51:02  *** zooko has joined #bitcoin-core-dev
4462016-04-04T13:52:28  *** AaronvanW has quit IRC
4472016-04-04T14:10:21  *** gevs_ has quit IRC
4482016-04-04T14:12:56  *** laurentmt has joined #bitcoin-core-dev
4492016-04-04T14:14:26  *** gevs has joined #bitcoin-core-dev
4502016-04-04T14:14:38  *** AaronvanW has joined #bitcoin-core-dev
4512016-04-04T14:29:51  *** frankenmint has joined #bitcoin-core-dev
4522016-04-04T14:34:38  *** frankenmint has quit IRC
4532016-04-04T14:39:39  *** laurentmt has quit IRC
4542016-04-04T14:45:33  *** zooko has quit IRC
4552016-04-04T14:57:19  *** Giszmo has joined #bitcoin-core-dev
4562016-04-04T14:57:34  *** dirtynewshoes has quit IRC
4572016-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
4582016-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
4592016-04-04T15:30:34  *** frankenmint has joined #bitcoin-core-dev
4602016-04-04T15:31:04  *** abritoid has quit IRC
4612016-04-04T15:35:04  *** frankenmint has quit IRC
4622016-04-04T15:59:48  *** paveljanik has joined #bitcoin-core-dev
4632016-04-04T16:31:29  *** frankenmint has joined #bitcoin-core-dev
4642016-04-04T16:36:42  *** frankenmint has quit IRC
4652016-04-04T16:53:48  *** paveljanik has quit IRC
4662016-04-04T16:58:28  *** paveljanik has joined #bitcoin-core-dev
4672016-04-04T16:58:28  *** paveljanik has joined #bitcoin-core-dev
4682016-04-04T17:34:11  *** frankenmint has joined #bitcoin-core-dev
4692016-04-04T17:38:38  *** frankenmint has quit IRC
4702016-04-04T17:56:00  <Luke-Jr> FWIW, it sounds like bc.i is making bogus problems for 0.12 txns
4712016-04-04T17:56:12  <Luke-Jr> the fee sniping chang
4722016-04-04T17:56:13  <Luke-Jr> change*
4732016-04-04T17:56:58  <gmaxwell> making bogus problems?
4742016-04-04T17:58:43  <btcdrak> ?
4752016-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."
4762016-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.
4772016-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.
4782016-04-04T18:41:00  *** molz has quit IRC
4792016-04-04T19:35:02  *** frankenmint has joined #bitcoin-core-dev
4802016-04-04T19:40:34  *** frankenmint has quit IRC
4812016-04-04T20:22:32  *** Don_John has joined #bitcoin-core-dev
4822016-04-04T20:45:51  *** droark has joined #bitcoin-core-dev
4832016-04-04T21:05:04  *** frankenmint has joined #bitcoin-core-dev
4842016-04-04T21:09:46  *** frankenmint has quit IRC
4852016-04-04T21:21:53  *** cheese_ has joined #bitcoin-core-dev
4862016-04-04T21:21:53  *** cheese_ has joined #bitcoin-core-dev
4872016-04-04T21:24:39  *** Cheeseo has quit IRC
4882016-04-04T21:25:51  *** Chris_Stewart_5 has quit IRC
4892016-04-04T21:31:33  *** da2ce7 has quit IRC
4902016-04-04T21:34:12  *** da2ce7 has joined #bitcoin-core-dev
4912016-04-04T21:36:39  *** Guyver2 has quit IRC
4922016-04-04T21:39:37  *** randy-waterhouse has joined #bitcoin-core-dev
4932016-04-04T21:40:45  *** frankenmint has joined #bitcoin-core-dev
4942016-04-04T21:44:13  *** cguida has quit IRC
4952016-04-04T21:56:53  *** cryptapus__ has joined #bitcoin-core-dev
4962016-04-04T22:02:27  *** cryptapus__ has quit IRC
4972016-04-04T22:04:18  *** cryptapus_ has joined #bitcoin-core-dev
4982016-04-04T22:04:18  *** cryptapus_ has joined #bitcoin-core-dev
4992016-04-04T22:06:29  *** cryptapus is now known as cryptapus_afk
5002016-04-04T22:08:15  *** cryptapus_afk is now known as cryptapus
5012016-04-04T22:09:47  *** cryptapus_ has quit IRC
5022016-04-04T22:11:19  *** cryptapus has quit IRC
5032016-04-04T22:14:41  *** cryptapus has joined #bitcoin-core-dev
5042016-04-04T22:14:41  *** cryptapus has joined #bitcoin-core-dev
5052016-04-04T22:15:03  *** cryptapus is now known as cryptapus_afk
5062016-04-04T22:36:21  *** MarcoFalke has quit IRC
5072016-04-04T22:43:33  *** moli has joined #bitcoin-core-dev
5082016-04-04T23:10:01  *** frankenmint has quit IRC
5092016-04-04T23:21:46  *** AaronvanW has quit IRC
5102016-04-04T23:44:32  *** zooko has joined #bitcoin-core-dev
5112016-04-04T23:47:03  *** zooko` has joined #bitcoin-core-dev
5122016-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
5132016-04-04T23:50:04  *** zooko has quit IRC
5142016-04-04T23:54:32  *** zooko` has quit IRC
5152016-04-04T23:56:59  *** zooko has joined #bitcoin-core-dev