--- Day changed Mon Apr 04 2016
00:06 < 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?
00:09 < wumpus> (for linux)
00:13 < wumpus> thanks for all the work on the tests MarcoFalke
00:21 < Lightsword> wumpus, I think valgrind may have something for that
00:21 < wumpus> thanks
00:22 < Lightsword> http://valgrind.org/docs/manual/drd-manual.html#drd-manual.lock-contention
00:24 < sipa> if contention is really significant i expect it to show up in profilimg
00:25 < 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 :)
00:26 < sipa> haha
00:26 < 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
00:28 < 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
00:28 < Lightsword> dtrace?
00:28 < wumpus> yes it was a proprietary tool based on dtrace
00:29 < Lightsword> https://github.com/dtrace4linux/linux
00:29 < wumpus> yes saw that one, there's also systemtap, and oprofile, which have similar aims but use slightly different mechanisms
00:30 < wumpus> oh and sysdig!
00:30  * wumpus mumbles something about fragmentation
00:33 < Lightsword> because who doesn’t like to have 10 different profiling tools that work slightly differently :P
00:33 < wumpus> :-)
00:34 < 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
00:34  * Lightsword has noticed ethereum has decided to do the same thing by apparently trying to write their clients in as many languages as possible
00:36 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hkzteexiyinczieh] has joined #bitcoin-core-dev
00:36 < 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
00:36 < wumpus> "we" is general, especially the open source community
00:36 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Ping timeout: 250 seconds]
00:37 < wumpus> for c++ we even want multiple version of *thing* based on what the favourite combination of dependencies of the day is
00:37 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 268 seconds]
00:38 < Lightsword> heh, seems that’s why c is so common with linux stuff, since those libraries are pretty much compatible with any language
00:38 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
00:39 -!- p15 [~p15@36.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 250 seconds]
00:41 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 268 seconds]
00:42 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 268 seconds]
00:42 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
00:42 -!- p15 [~p15@36.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev
00:42 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
00:44 < jonasschnelli> Any final feelings about RBF for createrawtx (https://github.com/bitcoin/bitcoin/pull/7159/files)?
00:44 < jonasschnelli> Should I remove the general opt-in boolean?
00:44 < jonasschnelli> And add a seq-nr per input?
00:44 < jonasschnelli> I like both approaches.
00:45 < jonasschnelli> The per-tx-global opt-in bool is a higher level function. The seq-nr per input is something we should have anyways.
00:45 < jonasschnelli> Maybe we can have both?
00:49 < jonasschnelli> Wait. The sequence option was added already.
00:50 < gmaxwell> needs nlock too.. globals could be used to autopopulate sequence/nlock if not overridden.
00:52 < sipa> hmm, i'm unsure
00:52 < sipa> the question is what createrawtransaction's goal os
00:52 < sipa> just only using explicit values would be more in line with its name
00:52 < 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.
00:53 < 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
00:53 < gmaxwell> why make it gratitiously less useful? 
00:53 < 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
00:58 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
00:58 < GitHub77> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e662a7628801...a9149688f87c
00:58 < GitHub77> bitcoin/master 8efed3b Jonas Schnelli: [Qt] Support for abandoned/abandoning transactions
00:58 < GitHub77> bitcoin/master a914968 Jonas Schnelli: Merge #7707: [RPC][QT] UI support for abandoned transactions...
00:59 < 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
00:59 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
01:02 < sipa> gmaxwell: i dislike feature creep
01:03 < 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?"
01:03 < gmaxwell> I dislike having functionality which doesn't get used but for small shortcoming that take away its utility.
01:05 < sipa> i just don't know how to reconcile it being "raw" with the suggested functionality
01:05 < gmaxwell> raw is the fact that it returns a rawtransaction to you.
01:06 < sipa> my preference would be just allowing setting nlocktime and nsequence
01:06 < sipa> it also doesn't create change outputs automatocally
01:06 < 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.
01:06 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
01:07 < sipa> but have another RPC for higher level operations like this
01:07 < gmaxwell> it would just be an exact copy of createrawtransaction, with extra flags and or slightly different defaults.
01:10 < 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, ...?
01:11 < gmaxwell> I wouldn't object to just having another RPC like that... but it seems a waste.
01:11 < gmaxwell> sipa: yes. 
01:12 < 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.
01:12 < sipa> so what if you want the rbf/sniping/rellocktime/... logic, but not createrawtransaction?
01:12 < gmaxwell> sounds like arguments for sendmany.
01:13 < sipa> so we'd add those to both sendmany and createrawtransaction?
01:14 < sipa> just trying to think this through
01:14 < 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.
01:15 < gmaxwell> e.g. totally reasonable to use the rawworkflow to make a nlocked transaction for the future.
01:16 < sipa> it's just so ugly to have both high level logic and the ability to override
01:16 < sipa> say we didn't add csv support now, just optinrbf or not
01:16 < sipa> someone starts using csv by setting the sequence number explicitly, but also passes optinrbf=no
01:17 < sipa> and expects a transaction that is not replacable
01: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.
01:19 < sipa> if createrawtransaction was instead just something that took an existing raw tx (empty be default?) and allowed adding inputs and outputs
01:33 < 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.
01:34 < jonasschnelli> IMO it's on a different level then the rawtx abstraction
01:35 < sipa> jonasschnelli: createrawtransaction users also need to know that creating less outouts than inputs will send their life savings to miners
01:35 < jonasschnelli> sipa: not if they use fundraw. :)
01:35 < 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
01:36 < sipa> but so far, createrawtransaction has been the way to actually do control the exact values, and not the high level behaviour
01:36 < 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
01:36 < jonasschnelli> sipa: I agree. But knowing also the magic numbers we use for nSequence is another "level":
01:37 < jonasschnelli> At least we should offer some nSequence=BIP125 abstraction.
01:37 < sipa> yes, agree
01:37 < jonasschnelli> The per-tx-general opt-in-to-Bip125 is probably to high. I agree.
01:37 < 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)
01:38 < 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
01:38 < jonasschnelli> Yes. Agree.
01:38 < jonasschnelli> But the BIP125 MAXINT-2 is a policy we should offer directly.
01:39 < jonasschnelli> {"txid": <txid>, "vout" : 0, "sequence": "BIP12"} <--- feels ugly
01:39 < sipa> what will you do to add csv supoort to createrawtransaction?
01:39  * jonasschnelli is thinking...
01:40 < sipa> i really dislike mixing magic smart behaviour with raw overriding
01:40 < gmaxwell> I don't really like mixing types in a single argument name.
01:40 < sipa> that feels like the rpc is trying to solve things at different levels
01:41 < jonasschnelli> flags per input? FLAG_BIP125_RBF, SEQUENCE_LOCKTIME_TYPE_FLAG?
01:41 < gmaxwell> e.g. sequence: 12345  / and seqtype: "BIP12" and have their use be mutually exclusive would seem preferable to me.
01:41 < jonasschnelli> no. flags per input is bad.
01:41 < sipa> i'd almost argue for a computensequencevalue RPC
01:41 < sipa> which just gives you the number to use, which you can put in crt
01:42 < sipa> but that's cumbersome for human users...
01:42 < jonasschnelli> RPC is not made for "human" users.
01:42 < jonasschnelli> I think its fine... 
01:42 < jonasschnelli> Chains of commands is something that increase the modularity 
01:43 < 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.
01:43 < gmaxwell> like having an REPL makes python accessible to people.
01:43 < jonasschnelli> A "setoptinrbf <rawtx>" is probably a bad design and leads to overriding ther nsequence magics
01:44 < sipa> jonasschnelli: agree
01:44 < sipa> optinrbf should be something you choose per tx
01:44 < jonasschnelli> gmaxwell: imo RPC != commandline, .. bitcoin-cli == commandline
01:44 < sipa> some receivers may not want such transactions
01:44 < jonasschnelli> bitcoin-cli could combine stuff
01:44 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 276 seconds]
01:45 < jonasschnelli> sipa: "setoptinrbf" would be per rawtx.
01:45 < jonasschnelli> It would just set the nSequence number of all inputs to MAXINT-2
01:45 < gmaxwell> jonasschnelli: that would harm discoverability, I think it is unfortunate to create wildly different interfaces.
01:45 < jonasschnelli> But I don't like the override character. 
01:45 < 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.
01:45 < jonasschnelli> gmaxwell: Yes. It would add another level.. which I agree its bad.
01:46 < jonasschnelli> gmaxwell: Yes. That could be nice (move MAXINT/-1 to -2)
01:46 < jonasschnelli> but would "optinrbf <rawtx>" not be to prominent for a policy flag?
01:46 < gmaxwell> (and unix has worked for decades where the programmatic interface to unix commands is the same as the human one)
01:47 < sipa> our 'default' of using positional arguments does not help
01:47 < 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.
01:48 < sipa> multimodal?
01:48 < CodeShark> https://bitcoincore.org/en/2016/04/04/announcing_sponsorship_programme/
01:48 < 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.
01:49 < gmaxwell> sipa: as it tweakrawtxn "hex" optinrbf 
01:49 < sipa> gmaxwell: ah, reimplementing bitcoin-tx as an rpc? ;)
01:49 < gmaxwell> Ha. Indeed. 
01:49 < jonasschnelli> hehe..
01:50 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
01:50 < jonasschnelli> what speaks against having these tweak-flags in crt?
01:50 < 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.
01:51 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
01:51 < gmaxwell> crt?
01:51 < jonasschnelli> createrawtransaction
01:51 < jonasschnelli> createrawtransaction <inputs> <outputs> <flag|flag>
01:51 < gmaxwell> the existance of fundraw for one.
01:51 < jonasschnelli> fundrawtx interacts with the wallet
01:52 < gmaxwell> the point is that if you set flags in createraw, they won't be visible in fundraw and it might violate them.
01:52 < jonasschnelli> <flag|flag> could be {"bip125rbf":true, etc.}
01:52 < jonasschnelli> gmaxwell: good point.
01:52 < gmaxwell> where as createraw | fundraw | tweak | signraw | sendraw is a fine pipeline.
01:52 < jonasschnelli> hmm.. not bad. Fundraw could then remove the opt-in-rbf flag (because it can add inputs).
01:53 < jonasschnelli> alternative names for "tweak"?
01:53 < sipa> mutate
01:53 < jonasschnelli> alter?
01:53 < sipa> alter
01:53 < sipa> modify
01:53 < jonasschnelli> modify is probably most understandable... but that blitcoin-cli in RPC!
01:53 < sipa> in the bitcoin-tx source code they are called mutate
01:54 < gmaxwell> spindletx
01:54 < sipa> transmogrifyrawtx
01:54 < gmaxwell> Presotchangotx
01:54  * jonasschnelli lol
01:54 < gmaxwell> alterrawtx is probably fine.
01:54 < jonasschnelli> +1 for alterrawttransaction
01:55 < jonasschnelli> We could start with RBF...
01:55 < jonasschnelli> add CSV..
01:55 < gmaxwell> I guess thats more consistent. (the fact that transaction is spelled out is one of the sadder parts of the interface)
01:55 < jonasschnelli> and someone could also implement adding ins and outs.
01:55 < jonasschnelli> But once we said keep the utilities outside of the RPC level
01:55 < gmaxwell> We sometimes made made choices.
01:56 < jonasschnelli> I agree. RPC is very handy for utitilites... 
01:56 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
02:03 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 244 seconds]
02:05 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
02:06 < 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
02:10 < gmaxwell> 64-bit MAC, really?  This leaks message lengths. 
02:12 < 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)
02:12 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
02:13 < 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.
02:13 < wumpus> when AES-NI is used <- but our odroid C2 doesn't have AES-NI :o
02:14 < jonasschnelli> gmaxwell: why 64bit mac? Because of the SHA512?
02:14 < 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).
02:15 < 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
02:15 < 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)
02:15 < 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. 
02:15 < sipa> jonasschnelli: poly1305 does not have 256-bit security, and certainly not when you truncate the tag to 64 bits!
02:16 < 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. 
02:16 < jonasschnelli> sipa: Chacha20 offers 256bit security. I though the poly MAC does not affect the security itself,... only the authentication? Not?
02:17 < sipa> jonasschnelli: authentication is part of the security
02:17 < sipa> it protects against different types of tlattacks
02:17 < sipa> *attacks
02:17 < jonasschnelli> Okay... I see.
02:17 < 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.
02:18 < jonasschnelli> But 256bit security does not reflect the overall robustness....
02:18 < jonasschnelli> But right. Let me better remove this line.
02:18 < jonasschnelli> gmaxwell: So you think truncate the TAG to 8 byte is still to long?
02:18 < gmaxwell> no it's too short.
02:19 < gmaxwell> I would suggest the length be made variable length, self-delimiting, encrypted like in the ssh spec... and that tag length be increased. 
02:20 < jonasschnelli> Okay. So using the non-truncated full 128bit poly1305 tag?
02:20 < 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.
02:20 < jonasschnelli> gmaxwell: length variable length -> do you mean varint serialization?
02:21 < sipa> gmaxwell: i think varint serialization is overkill 
02:21 < jonasschnelli> The current message structure also has a int32 for the length. Maybe we keep the varint outside of the message header.
02:22 < gmaxwell> sipa: better than truncating the MAC to 8 bytes.
02:22 < wumpus> varint is slightly inconvenient, it's nice to be able to read network headers at once
02:23 < wumpus> how does ssh handle this?
02:23 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
02:23 < gmaxwell> uses a fixed width interger, it's encrypted however.
02:23 < gmaxwell> The varint suggestion was trying to recover the overhead from the longer mac tag, I'm not wed to the idea.
02:24 < 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
02:24 < gmaxwell> Many of the messages in bitcoin are quite small, so the extra lengths do make a meaningful impact.
02:24 < wumpus> yes, but reading one byte of a time from a TCP stream :-(
02:24 < gmaxwell> average message size in bitcoin p2p is someting like 100 bytes right now.
02:24 < wumpus> let's increase the MAC size and leave the length at four bytes for now
02:25 < gmaxwell> yup
02:25 < jonasschnelli> Okay. Will do.
02:25 < wumpus> gmaxwell: well you had the idea to collate P2P packets into encryption packets ...
02:25 < wumpus> (I know, futur work.)
02:25 < sipa> wumpus: which is also in the bip, btw
02:25 < jonasschnelli> gmaxwell: re-keying minimum of 600 seconds is to large?
02:25 < wumpus> oh!
02:25 < gmaxwell> yes, though there is 4 byte lengths at each level. At least that helps with mac overhead.
02:26 < wumpus> well in the inner packet I'm not opposed to varints
02:26 < wumpus> those packets are in memory already
02:26 < gmaxwell> jonasschnelli: I'd make it 10 seconds or something very small. 
02:26 < sipa> rekey every 10 seconds?
02:26 < jonasschnelli> sipa: min. 10 sec
02:26 < jonasschnelli> flexible local policy.
02:26 < jonasschnelli> A node could detect repeating re-keys and ban
02:27 < jonasschnelli> I just want a minimum timespan between re-key in the BIP.
02:27 < gmaxwell> I don't think a minimum timespan is needed, but if one is there it shouldn't be 600 seconds. 
02:28 < 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?
02:28 < sipa> if we care about overhead, the first thing to consider would be making those 12-byte message names varlen :)
02:29 < jonasschnelli> Indeed.
02:29 < wumpus> yes
02:29 < jonasschnelli> We could do this for the encrypted message stucture.
02:29 < sipa> jonasschnelli: rekeying every second will still be much lower overhead than normal transaction relay...
02:29 < wumpus> +1 for making those varlen, that padding is ugly and people have accidentally leaked memory contents into them in the past :)
02:30 < jonasschnelli> sipa: Hmm... right. Its just a 2xSHA256. 
02:30 < sipa> jonasschnelli: no, it's an ecdh
02:30 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:30 < sipa> which is similar to a signature validation in time
02:30 < jonasschnelli> sipa: No. The ECDH is done already,... its only hash(old_key)?
02:30 < sipa> jonasschnelli: rekey means doing ecdh again
02:30 < gmaxwell> it shouldn't.
02:30 < gmaxwell> it doesn't in the spec.
02:31 < sipa> ah
02:31 < gmaxwell> sipa: it's logically just cranking the initial KDF csprng to the next state.
02:33 < jonasschnelli>  okay. 1.) command varlen 2.) AEAD-tag 128bits, 3.) remove 256bit security mentioning.
02:33 < gmaxwell> on auth, this protocol looks like it would result in a bitcoin daemon announcing a persistant identity to everyone that connects to it?
02:34 < jonasschnelli> According to https://www.ietf.org/proceedings/88/slides/slides-88-tls-1.pdf AES-128-GCM is slower then ChaCha20+Poly1305
02:34 < 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?
02:34 < sipa> jonasschnelli: aes-gcm is slowish without hardware support, very fast with
02:35 < gmaxwell> jonasschnelli: only if you don not have AES-NI. If you do AES-128-GCM is maybe 7 times faster.
02:35 < sipa> jonasschnelli: aes-gcm can get to 1 cycle/byte on modern hardware with asm code
02:35 < sipa> jonasschnelli: chacha20-poly1305 is hard to get under 4ish, i think
02:35 < jonasschnelli> a... i see. AES-NI: 892 MB/s, ChaCha20+Poly1305, -march=native = 560 MB/s
02:36 < jonasschnelli> gmaxwell: the identity would only be revealed by the requesting peer.
02:36 < jonasschnelli> So the requesting peer would know who he wants to give its identity price.
02:37 < jonasschnelli> The responding peers only reveals its identity if the requesting peers identity "was accepted".
02:37 < sipa> jonasschnelli: gmaxwell's protocol never reveals identity, and only works if both sides know the pubkey beforehand
02:38 < jonasschnelli> Hmm... yes: H(session-id||server-pubkey)  makes sense.
02:38 < sipa> jonasschnelli: those numbers are certainly not the best possible ones
02:38 < jonasschnelli> okay.
02:39 < 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
02:39 < gmaxwell> s.
02:40 < jonasschnelli> hmm.. so we assume the requesting peer can link a IP to a pubkey
02:40 < sipa> i'd prefer focussing on encryption first :)
02:40 < 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. 
02:41 < 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.
02:41 < gmaxwell> but yea, maybe hammer out encryption first.
02:41 < jonasschnelli> Could the responding peer answer with a signature of the received hash(received-hash || session-id||server-pubkey)?
02:41 < jonasschnelli> I think auth and enc has some overlaps.
02:42 < jonasschnelli> (at least in thinking about a solution)
02:43  * jonasschnelli needs to go afk for 1h
02:43 < gmaxwell> All he should need to do is sign the session-id. 
02:48 -!- Anduck [~anduck@unaffiliated/anduck] has joined #bitcoin-core-dev
02:49 < Anduck> who answers from contact@bitcoincore.org?
02:49 < Anduck> i see lots of "contact us" etc. but no names
02:49 < Anduck> like who actually run it
02:52 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
03:01 < 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
03:02 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Disconnected by services]
03:03 -!- Arnavion3 [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
03:03 -!- Arnavion3 is now known as AtashiCon
03:03 -!- chris2000 [~chris2000@62.176.225.38] has joined #bitcoin-core-dev
03:42 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
04:05 < 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.
04:09 < 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
04:09 < GitHub144> [bitcoin] laanwj pushed 24 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/c5f94f6584cb...834aaef7bd37
04:09 < GitHub144> bitcoin/0.12 15ba08c Alex Morcos: Implement SequenceLocks functions...
04:09 < GitHub144> bitcoin/0.12 0d09af7 Suhas Daftuar: Add RPC test exercising BIP68 (mempool only)
04:09 < GitHub144> bitcoin/0.12 0a79c04 Alex Morcos: Bug fix to RPC test
04:10 < sipa> jonasschnelli: bf for?
04:10 < sipa> bf fpr?
04:10 < jonasschnelli> bloomfilter false positive rate
04:10 < jonasschnelli> (in case you want to connect a SPV wallet to a node over enc. channels)
04:11 < sipa> jonasschnelli: i don't mean that we should encryption running first in production
04:11 < sipa> but just have it designed and perhaps implemented first
04:11 < sipa> as it interacts heavily with network code
04:11 < 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
04:12 < jonasschnelli> sipa: okay. Yes. That make sense.
04:12 < sipa> jonasschnelli: if you don't have pre-shared keys, what are you trying to accomplish?
04:12 < 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.
04:13 < sipa> jonasschnelli: that's by definition fingerprinting the node
04:13 < sipa> i'm unconvinced that's something we should aim for
04:14 < sipa> at least, it's a very different thing from what we've been doing recently, namely trying to avoid fingerprinting
04:14 < 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
04:15 < 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.
04:15 < sipa> jonasschnelli: yes, that's called tofu (trust on first use)
04:15 -!- abritoid [~abritoid@46.16.193.99] has joined #bitcoin-core-dev
04:16 < jonasschnelli> Ah.. that's the tofu. Thanks.
04:16 < 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
04:18 < jonasschnelli> sipa: hmm.. this would mean one identity per net-type?
04:18 < sipa> maybe something you only want for servers on static ips, and only on the listening side
04:19 < sipa> so i think it's an orthogonal use case
04:20 < sipa> not just per net type
04:21 < 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
04:35 < 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.
04:35 < jonasschnelli> auth: H(enc-session-id-A || indenity-pubkey)-A
04:36 < jonasschnelli> auth: H(enc-session-id-A || indenity-pubkey-A), authack: sig(H(enc-session-id-B || indenity-pubkey-B))
04:36 < jonasschnelli> no wait...
04:36 < jonasschnelli> auth: H(enc-session-id-A || indenity-pubkey-A), authack: sig(H(auth-request-hash || enc-session-id-B || indenity-pubkey-B))
04:37 < sipa> where does the pubkey of the other side come from?
04:37 < jonasschnelli> sipa: the identity pubkey from the other side.
04:38 < jonasschnelli> (should be node by the requesting peer because we assume pre-shared keys)
04:38 < jonasschnelli> *pre-shared pubkey*
04:40 < sipa> let's go over the use cases one by one
04:40 < sipa> i know 3
04:41 < 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
04:42 < 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
04:42 < sipa> 3) tofu security between any nodes on the network
04:42 < sipa> i think 1 and 2 are fundamentally different from 3
04:42 -!- OGF`off is now known as OGF
04:42 < jonasschnelli> I think we should focus for 1/2.
04:43 < sipa> because 1 and 2 never need to reveal identities, only provide proof when requested
04:43 -!- OGF is now known as Guest33626
04:43 < jonasschnelli> Do you think 1 without 2 is something we should aim for?
04:43 < sipa> i think 1 and 2 are orthogonal
04:43 < jonasschnelli> Yes. I agree.
04:43 < sipa> and they can use the exact same code, just in the other direction
04:44 < jonasschnelli> Then we probably need: auth: H(enc-session-id-A || indenity-pubkey-A), authack: sig(requesting-hash)
04:44 < jonasschnelli> For both sides.
04:45 < sipa> i don't think that adds anything over signing just the session id
04:45 < sipa> Schnorr signatures internally compute a message hash, which is based on the message and the signing pubkey
04:45 < sipa> so they already do that internally
04:46 < jonasschnelli> if we assume ECDSA, would you then recover the pubkey from the sig to lookup the identity?
04:47 < sipa> ? you asked for it, you know it already
04:47 < sipa> "hey, are you X?" - "yes, here is proof"
04:48 < sipa> we could use bitcoin script for the signatures, so you can do multisig auth :p
04:48 < jonasschnelli> heh.
04:48 < sipa> "hey, are you X, Y, or Z?" - "yes, here is a scriptSig"
04:49 < sipa> no good use case for that though, so let's not exaggerate
04:49  * jonasschnelli thinking...
04:50 < jonasschnelli> For your usecase 2) when or how would the responding peer ask for "hey, are you X?" - "yes, here is proof"?
04:50 < jonasschnelli> A new message-type from the requesting peer?
04:50 < jonasschnelli> Or as soon as the requesting peer accesses a restrictied service?
04:50 -!- Guest33626 [sid21333@gateway/web/irccloud.com/x-paryjypvkwivybnv] has left #bitcoin-core-dev []
04:57 < 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))
04:58 < 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
04:59 < sipa> there should probably be an explicit "i don't need you to authenticate" ?
05:00 < sipa> actually, no
05:00 < sipa> you either send an 'areyou' (in which case you wait for a yesiam first), or you send a version yourself
05:05 < 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?
05:06 < jonasschnelli> Or could the requesting peer not just send a "yesiam"(H(my-pubkey || send-session-id)
05:06 < sipa> the protocol doesn't continue if they don't respond
05:08 < jonasschnelli> sipa: for your usecase 2) the requesting peer first needs to authenticate the responding peer... i think thats fine.
05:09 < jonasschnelli> But I don't see a way to do 2) without 1)
05:11 < jonasschnelli> but however, let me think a bit about it. My brain usually needs some minutes for processing the input. :)
05:12 < sipa> jonasschnelli: 1 and 2 are exactly the same!
05:12 < sipa> except initiated by the one listening instead of the one connecting
05:13 < sipa> 1 is "are you the server I know? if not, i won't tell you anything about myself!"
05:13 < sipa> 2 is "are you the client I know? if not, i won't tell you anything about myself!"
05:13 < sipa> but the p2p protocol has no distinction between the one connecting and the one listening
05:13 < jonasschnelli> sipa: yes. But for 2) you might not want to ask every peer for authentication.
05:14 < sipa> ah, i see
05:14 < jonasschnelli> I think in practice, 2 makes only sense with 1
05:15 < jonasschnelli> Though, it could be policy (ask every peer, ask only peer where you have authacked).
05:16 < sipa> let's get encryption flushed out first :)
05:16 < sipa> that's a part that can be shared across all use cases
05:17 < jonasschnelli> okay... lets do that.
05:17 < jonasschnelli> I'll update the auth bip with all the stuff we have disusses but focus on the enc BIP
05:26 -!- cryptapus_afk is now known as cryptapus
05:30 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:39 -!- chris2000 [~chris2000@62.176.225.38] has quit [Read error: Connection reset by peer]
05:40 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
05:41 < GitHub28> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/834aaef7bd37...e3341aa94e1f
05:41 < GitHub28> bitcoin/0.12 e10c044 BtcDrak: [0.12] Update release notes
05:41 < GitHub158> [bitcoin] laanwj closed pull request #7800: [0.12] Update release notes (0.12...docs) https://github.com/bitcoin/bitcoin/pull/7800
05:41 < GitHub28> bitcoin/0.12 e3341aa Wladimir J. van der Laan: Merge #7800: [0.12] Update release notes...
05:44 -!- p15 [~p15@36.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 264 seconds]
05:54 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev
06:00 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
06:01 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
06:23 < wumpus> oh wow re: tracing and profiling https://github.com/brendangregg/FlameGraph
06:25 -!- gevs_ [~greg@ip-80-236-236-245.dsl.scarlet.be] has joined #bitcoin-core-dev
06:27 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 252 seconds]
06:29 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
06:50 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
06:50 -!- d_t [~textual@185.69.203.10] has quit [Client Quit]
06:51 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
06:52 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
07:10 -!- gevs_ [~greg@ip-80-236-236-245.dsl.scarlet.be] has quit [Quit: bye]
07:12 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
07:14 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
07:14 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
07:29 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
07:34 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 248 seconds]
07:39 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
07:45 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 276 seconds]
07:57 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
07:57 -!- dirtynewshoes [~dirtynews@sydnns0115w-047055195008.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Ping timeout: 240 seconds]
08:20 < GitHub163> [bitcoin] instagibbs closed pull request #7784: miner_tests number clarification (master...patch-4) https://github.com/bitcoin/bitcoin/pull/7784
08:20 < 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
08:30 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
08:31 -!- abritoid [~abritoid@46.16.193.99] has quit [Ping timeout: 264 seconds]
08:35 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 244 seconds]
08:59 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
09:31 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
09:36 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 276 seconds]
09:53 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
09:58 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
09:58 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host]
09:58 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
10:34 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
10:38 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 248 seconds]
10:56 < Luke-Jr> FWIW, it sounds like bc.i is making bogus problems for 0.12 txns
10:56 < Luke-Jr> the fee sniping chang
10:56 < Luke-Jr> change*
10:56 < gmaxwell> making bogus problems?
10:58 < btcdrak> ?
10:58 < 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." 
10:59 < 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.
10:59 < gmaxwell> sipa: so this lets you do mutual auth without leaking client identities to people who don't already know them.
11:41 -!- molz [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
12:35 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
12:40 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 260 seconds]
13:22 -!- Don_John [~Don@247-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev
13:22 -!- Don_John [~Don@247-223-114-134.nat.resnet.nau.edu] has quit [Remote host closed the connection]
13:45 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev
14:05 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
14:09 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 252 seconds]
14:21 -!- cheese_ [~x@c-71-58-178-138.hsd1.pa.comcast.net] has joined #bitcoin-core-dev
14:21 -!- cheese_ [~x@c-71-58-178-138.hsd1.pa.comcast.net] has quit [Changing host]
14:21 -!- cheese_ [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev
14:24 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 276 seconds]
14:25 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 250 seconds]
14:31 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 244 seconds]
14:34 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev
14:36 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
14:39 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
14:40 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
14:44 -!- cguida [~chris@162.216.46.157] has quit [Quit: cguida]
14:56 -!- cryptapus__ [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
15:02 -!- cryptapus__ [~cyptapus@unaffiliated/cryptapus] has quit [Quit: Conversation terminated!]
15:04 -!- cryptapus_ [~cyptapus@jupiter.osmus.org] has joined #bitcoin-core-dev
15:04 -!- cryptapus_ [~cyptapus@jupiter.osmus.org] has quit [Changing host]
15:04 -!- cryptapus_ [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
15:06 -!- cryptapus is now known as cryptapus_afk
15:08 -!- cryptapus_afk is now known as cryptapus
15:09 -!- cryptapus_ [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
15:11 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: conversation terminated!]
15:14 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev
15:14 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host]
15:14 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
15:15 -!- cryptapus is now known as cryptapus_afk
15:36 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
15:43 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
16:10 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
16:21 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
16:44 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
16:47 -!- zooko` [~user@172.56.9.188] has joined #bitcoin-core-dev
16:48 < GitHub124> [bitcoin] theuni opened pull request #7809: depends: some base fixes/changes (master...depends-updates) https://github.com/bitcoin/bitcoin/pull/7809
16:50 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds]
16:54 -!- zooko` [~user@172.56.9.188] has quit [Ping timeout: 260 seconds]
16:57 -!- zooko [~user@172.56.9.188] has joined #bitcoin-core-dev
17:01 -!- zooko [~user@172.56.9.188] has quit [Ping timeout: 276 seconds]
17:02 -!- zooko`` [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
17:17 -!- zooko`` [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 252 seconds]
17:21 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hkzteexiyinczieh] has quit [Quit: Connection closed for inactivity]
17:39 -!- cguida [~chris@162.216.46.73] has joined #bitcoin-core-dev
17:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
17:53 -!- zooko`` [~user@c-24-9-79-61.hsd1.co.comcast.net] has joined #bitcoin-core-dev
18:26 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection]
18:26 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev
18:29 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
18:32 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
18:32 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
18:40 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
18:44 -!- zooko`` [~user@c-24-9-79-61.hsd1.co.comcast.net] has quit [Ping timeout: 268 seconds]
18:49 -!- wallet42 [uid154231@gateway/web/irccloud.com/x-lndjowlgfnvcxsdz] has joined #bitcoin-core-dev
19:03 -!- p15 [~p15@131.91.145.64.unassigned.bringover.net] has joined #bitcoin-core-dev
19:18 -!- gevs [~greg@unaffiliated/gevs] has quit [Remote host closed the connection]
19:41 -!- zooko [~user@50.246.213.170] has joined #bitcoin-core-dev
19:41 -!- hsmiths2 is now known as hsmiths
19:41 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Quit: END OF LINE]
19:42 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev
19:42 < gmaxwell> sipa: jonasschnelli:  Here is the authentication protocol I was thinking of:
19:42 < gmaxwell> https://people.xiph.org/~greg/auth0.txt
19:43 < gmaxwell> And this is an extension to the former that allows for mutual autentication while keeping the client identity private: https://people.xiph.org/~greg/auth1.txt  This is useful because it would protect against a shared server tracking clients (e.g. observing what they broadcast), but still allow the client to authenticate for elevated service.
19:45 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 244 seconds]
19:48 < gmaxwell> An example application where this would be important, is if clients paid a server for a priority access account. (more bandwidth, protection against DOS limits).. it would be unfortunate if the existance of such a service compromised the users privacy by giving them a persistant identity that the server could track them with.  I don't think it's something we'd implement right away, but it shows 
19:48 < gmaxwell> how our channel authentication could be extended.
19:48 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
20:04 -!- zooko [~user@50.246.213.170] has quit [Ping timeout: 252 seconds]
20:05 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:06 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:19 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
20:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
22:01 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:02 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:02 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 240 seconds]
22:17 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:53 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vpohxsuqdskqbace] has joined #bitcoin-core-dev
23:06 -!- murch [~murch@p4FE39993.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
23:09 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:10 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:19 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
23:20 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
23:28 -!- mesmer_ [~mesmer@unaffiliated/mesmer] has joined #bitcoin-core-dev
23:31 -!- mesmer [~mesmer@unaffiliated/mesmer] has quit [Ping timeout: 240 seconds]
23:33 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
23:55 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:56 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev