| 00:00:37 | akrmn: | does anyone have a link to a proposal for miner decentralization that doesn't involve tree chain like structures? |
| 00:00:58 | akrmn: | like something that has a good chance of scaling |
| 00:02:14 | leakypat: | petertodd: do you have builds for the RBF client or am I to compile from github myself? |
| 00:10:37 | CodeShark: | akrmn: working on ideas - hopefully one of these days I can be more constructive on this front rather than mostly pointing out how what we have won't work :p |
| 00:14:36 | akrmn: | CodeShark: My best idea is tree-structured subchains, but if someone has a better idea I would like to read it |
| 00:15:14 | akrmn: | I guess we can just set a limit on the scalability and rely on contracts |
| 00:15:19 | akrmn: | but doesn't seem elegant to me |
| 00:15:45 | petertodd: | leakypat: no builds just yet; will soon |
| 00:16:33 | petertodd: | leakypat: just did rbf for v0.11.0rc2 actually: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.11.0rc2 |
| 00:17:03 | c0rw|away: | c0rw|away is now known as c0rw1n |
| 00:18:34 | petertodd: | leakypat: also working on a fix so full and fss RBF will be more compatibile, so you can use both at the same time |
| 00:18:53 | CodeShark: | a few things: 1) it's not necessary for everyone to verify everyone else's stuff...what really matters is that validators don't collude to fool everyone else. 2) it's not necessary to check everything...it is enough that the rate of failure be sufficiently negligible and we can rely on nondeterminism. 3) It is better for those who need to construct proofs to have some stake in the result so that incentives are there to do |
| 00:18:53 | CodeShark: | so. 4) Risk can be managed by adding collective fees of some sort...or encouraging insurance, market making, and other such people who are willing to assume risk |
| 00:20:28 | CodeShark: | 5) a nested structure is probably a good idea, with the stuff closer to the root representing more global consensus states |
| 00:24:20 | akrmn: | CodeShark: I think you have the same idea as me (https://bitcointalk.org/index.php?topic=1083345.0) |
| 00:25:22 | akrmn: | You just need a way to keep deep forks minimal. That's what I'm trying to think about now. |
| 00:26:04 | akrmn: | like if a deep child chain has a mistake, do all the other chains get affected? |
| 00:26:26 | akrmn: | I think it should be acceptable to keep going even if there is a small mistake in a child chain transaction |
| 00:27:02 | CodeShark: | regarding things like invalid blocks, we could just roll back the bad transactions and their dependencies and punish the miner rather than rolling back the entire block if a bad transaction is discovered |
| 00:27:14 | CodeShark: | but the process of rolling back transaction dependencies is not that cheap |
| 00:27:39 | CodeShark: | it gets more expensive with time...but at least it results in far less disruption to everyone else |
| 00:27:59 | akrmn: | I think once a transaction goes from a child chain to a parent chain, the parent chain has to stick with it |
| 00:28:15 | akrmn: | even if later a mistake is found in the child chain transaction |
| 00:30:36 | akrmn: | but good to know I'm not the only one thinking about these things. Sipa doesn't seem to like it. He seems to think that only omniscient nodes are useful for network security. But I think with this kind of rule that I just gave, it can limit the effect on the parent chains so maybe it is more acceptable. |
| 00:31:14 | CodeShark: | I think sipa's main critique, if I remember seeing it right, was the cost of transfering between chains |
| 00:32:03 | akrmn: | there's no delay if the parent gets to commit to the child. |
| 00:40:04 | CodeShark: | so one way is fast, but what about going in the other direction? |
| 00:40:09 | akrmn: | (I mean: If an output goes in a transaction in a child chain, and then later in a transaction in a parent chain, then even though the value in the child chain is later found out to be wrong, nodes should just keep going with the value in the parent chain) |
| 00:40:16 | akrmn: | still need to clarify that |
| 00:40:43 | akrmn: | the child chain trusts the parent chain so it's easy the other way also |
| 00:41:09 | dgenr8: | CodeShark: setting aside radical redesigns of the blockchain, and ignoring privacy, a way to ask your remaining peers to prove a new tx invalid would seem very helpful |
| 00:43:16 | CodeShark: | dgenr8: if we could somehow reward peers for doing so you may be onto something |
| 00:44:09 | CodeShark: | then the main threat would be at the network level...where someone manages to block your connections to honest nodes |
| 00:44:32 | CodeShark: | (ignoring privacy for a moment) |
| 00:44:50 | dgenr8: | CodeShark: is that a big issue? they aren't rewarded for anything else... |
| 00:46:52 | CodeShark: | dgenr8: how costly is it for the node to do this? we'd need a full txout index, no? |
| 00:47:02 | CodeShark: | I mean, a full tx index |
| 00:47:47 | CodeShark: | or hmm...I guess spent outputs don't really matter |
| 00:47:52 | CodeShark: | except for reorgs |
| 00:51:10 | CodeShark: | it would actually be possible to pay people for these proofs if only the bitcoin script could reference other parts of the blockchain :p |
| 00:51:56 | dgenr8: | CodeShark: first task is to decide what the question would be, and what the answer would look like. then how to get there. |
| 00:53:56 | dgenr8: | CodeShark: sorry i can't just point you at a commit ;) |
| 00:54:05 | CodeShark: | heh |
| 00:55:16 | CodeShark: | so the question is: does this transaction conflict with any other transaction you know of? and the answer is a proof that they spend a common input |
| 00:56:04 | CodeShark: | they or one of their dependencies, that is |
| 00:56:50 | CodeShark: | so in the general case it requires constructing two dependency chains - but it's easier to prove conflict than to prove that they connect to the blockchain |
| 00:57:12 | CodeShark: | so we really have two questions here |
| 00:57:14 | dgenr8: | you started out just concerned about double-spends |
| 00:57:41 | CodeShark: | right - if you are only concerned about double-spends then just demonstrating a shared spent output is sufficient |
| 00:58:16 | CodeShark: | and you'd probably want to be able to check the signatures along the way |
| 00:58:49 | CodeShark: | but hmm |
| 00:59:01 | CodeShark: | even checking signatures, unless you check that they do connect to the main chain it's super simple to cheat |
| 00:59:23 | CodeShark: | you could stick your own transactions in the middle and sign them...and they'll never confirm |
| 01:00:52 | CodeShark: | so it doesn't really seem worth doing unless you can prove that they do connect |
| 01:00:57 | dgenr8: | ofc |
| 01:01:18 | CodeShark: | right, so I take that back :p |
| 01:01:28 | CodeShark: | it is not sufficient to just show a shared spent output :) |
| 01:02:39 | CodeShark: | I guess a more general question is: show me how this transaction connects to the block chain |
| 01:03:02 | dgenr8: | an invalidation proof could consist of a single connected conflicting spend |
| 01:03:20 | CodeShark: | right |
| 01:05:43 | dgenr8: | do you check whether other peers inv'ed a tx that pays you? that means they like it |
| 01:06:05 | dgenr8: | oh you have a filter |
| 01:06:24 | CodeShark: | yeah - lol |
| 01:06:41 | dgenr8: | gtg ttyl |
| 01:06:51 | CodeShark: | later, dgenr8 - thanks for the thoughts |
| 01:08:10 | CodeShark: | akrmn: still looking over your proposal... |
| 01:09:24 | phantomcircuit: | CodeShark, nobody has yet shown an efficient way do fraud proofs for aggregate limits short of zk-SNARKS |
| 01:09:51 | phantomcircuit: | proposals to commit to the aggregate limit values in fixed locations are the closest but have significant issues |
| 01:11:11 | CodeShark: | doesn't have to be zk, but yeah |
| 01:12:11 | CodeShark: | the thing is that it is probably not necessary for everyone to check the fraud proofs |
| 01:13:29 | CodeShark: | but I sense self-reference here :p |
| 01:14:14 | CodeShark: | someone then needs to construct a fraud proof of the fraud proof :p |
| 01:15:34 | phantomcircuit: | CodeShark, everybody needs to check the fraud proofs that they receive |
| 01:15:48 | phantomcircuit: | the problem is that the fraud proof for aggregate limit violations is... the entire block |
| 01:15:51 | phantomcircuit: | oops |
| 01:16:24 | akrmn: | CodeShark: Thanks. I don't really have a high level of popularity in this community, so it is hard to get people to give serious feedback |
| 01:17:11 | dgenr8: | CodeShark: XT nodes relay direct double-spends that match your filter. but not when they appear in a block, and not when the conflict is with an ancestor. |
| 01:17:28 | dgenr8: | CodeShark: as the author of that patch i'm going to consider that ... |
| 01:17:45 | akrmn: | also I have to rewrite some things more clearly |
| 01:18:33 | CodeShark: | phantomcircuit: I was speaking regarding the ability to reward fraud proofs |
| 01:18:53 | phantomcircuit: | CodeShark, uh |
| 01:18:59 | CodeShark: | but yeah, let's not get into that problem yet |
| 01:19:02 | phantomcircuit: | how do you reward the producer of a fraud proof? |
| 01:19:08 | phantomcircuit: | im not sure that's possible |
| 01:19:13 | CodeShark: | with a script that can reference the relevant parts of the state |
| 01:19:25 | CodeShark: | signed by both |
| 01:21:00 | phantomcircuit: | CodeShark, and you pass the fraud proof off to a node |
| 01:21:13 | phantomcircuit: | who immediately removes your script and issues a new fraud proof with his |
| 01:21:27 | CodeShark: | hence requiring both signatures |
| 01:21:44 | phantomcircuit: | both? |
| 01:22:01 | CodeShark: | yes, it requires some blinding |
| 01:22:30 | CodeShark: | might require some pk fancy crypto :p |
| 01:22:33 | CodeShark: | but I think it's possible |
| 01:22:43 | CodeShark: | err, zk fancy crypto |
| 01:23:01 | phantomcircuit: | CodeShark, im thinking it's impossible |
| 01:23:15 | phantomcircuit: | the other party has to be able to validate the fraud proof |
| 01:23:17 | CodeShark: | three phases: |
| 01:23:21 | phantomcircuit: | in which case they can generate their own |
| 01:23:57 | CodeShark: | actually four rounds |
| 01:24:10 | CodeShark: | 1) party A requests proof from party B. 2) party B supplies zk proof, 3) party A signs, 4) party B reveals plaintext proof |
| 01:24:53 | CodeShark: | the script is only satisfied if (4) happens, of course |
| 01:30:16 | CodeShark: | there might even be a way to condense it into only two rounds with some more clever tricks |
| 02:20:11 | c0rw1n: | c0rw1n is now known as c0rw|zZz |
| 02:23:59 | morcos: | This was just posted by sdaftuar, some good thoughts on the dangers of the current hard fork crusade: https://medium.com/@sdaftuar/how-the-bitcoin-experiment-might-fail-7f6c24f99ecf |
| 04:14:17 | amiller: | how "robust" is the assumption that people will treat something like money / like a commodity if it behaves one? |
| 04:14:20 | amiller: | like, how crappy can a monetary policy where tons of people will use a cryptocurrency based on it, and the system would still work |
| 04:15:51 | amiller: | its too bad that there aren't yet many "appcoins" that have been a demonstrable success, because it would be easier to look at the incentives in those systems.. they wouldn't even necessarily need to compete |
| 04:16:16 | amiller: | namecoin as a whole should be 'earning income' from domain name registration fees... my understanding is that no one is using it though |
| 04:17:00 | amiller: | but a cryptocurrency with some nice feature like that basically has an export economy of some kind, surely that can only help it |
| 04:17:27 | phantomcircuit: | amiller, that nobody is using namecoin is itself a data point |
| 04:18:08 | amiller: | yeah well i don't trust any strong inferences based on it :O |
| 04:28:12 | zooko: | amiller: I don't think we can make any reliable predictions or generalizations about this. |
| 04:28:22 | zooko: | But if you do make some, I want to know! |
| 04:53:56 | leakypat: | * leakypat compiles Bitcoin qt for the first time and reflects on what a huge responsibility running the release procedure an official version would be |
| 04:55:44 | jgarzik: | phantomcircuit, amiller: it is false that no one is using namecoin |
| 04:56:12 | jgarzik: | several identity projects are building on top of it |
| 04:56:33 | phantomcircuit: | jgarzik, that's not a good idea |
| 04:56:40 | phantomcircuit: | the codebase is almost entirely unmaintained |
| 04:58:26 | CodeShark: | leakypat: welcome to the club :) |
| 04:58:29 | jgarzik: | phantomcircuit, also untrue |
| 04:58:29 | jgarzik: | but whatever. Spewing falsehoods we wish to be true on this channel is becoming the norm. |
| 04:59:21 | amiller: | here's joe bonneau's takedown of namecoin http://weis2015.econinfosec.org/papers/WEIS_2015_kalodner.pdf |
| 04:59:29 | phantomcircuit: | jgarzik, i'd bet you serious money i can cripple namecoin in a matter of a few days |
| 04:59:34 | phantomcircuit: | but doing so is probably a felony |
| 05:00:01 | amiller: | in this channel falsehoods must be spewed in pdf form |
| 05:00:03 | jgarzik: | phantomcircuit, you also claim the ability to cripple bitcoin |
| 05:01:14 | CodeShark: | usage isn't really the point - the current design simply is not viable |
| 05:01:26 | CodeShark: | at least not beyond an experimental research network |
| 05:01:35 | CodeShark: | that's just hard math |
| 05:01:58 | CodeShark: | it's not even controversial to anyone who bothers to make the calculations |
| 05:02:22 | CodeShark: | but it's still a cool idea - I hope someone manages to find a way to make something like that viable |
| 05:04:32 | CodeShark: | it's hardly ever the case with any technology that early prototypes are viable. this space is a little exceptional in seeming to expect that this doesn't apply here |
| 05:05:29 | phantomcircuit: | jgarzik, k |
| 05:05:40 | CodeShark: | add to that the fact that the design makes it so that all upgrades to the plane can only be done while in flight...and if you screw up you crash...and...voila! |
| 05:06:05 | CodeShark: | fun, no? :) |
| 05:06:14 | amiller: | i wish we could learn more from altcoins |
| 05:06:22 | amiller: | maybe there's something to glean from them |
| 05:06:40 | amiller: | bitcoin is still 'small', and so all the altcoins are really small, it's hard to believe there's a lot of signal there as far as what to do and not to do |
| 05:06:58 | amiller: | does a crash usually kill those or is it slow atrophy |
| 05:08:06 | amiller: | i think (not too sure) no one cares enough about them to have big hard-fork dilemmas |
| 05:09:35 | phantomcircuit: | amiller, slow atrophy |
| 05:09:56 | phantomcircuit: | amiller, the one thing that has been shown to be 100% true is that anything which is available on a liquid market has value regardless of actual utility |
| 05:10:05 | phantomcircuit: | which is a neat observation |
| 05:10:29 | amiller: | yeah |
| 05:19:08 | zooko: | jgarzik: Do you see IRC privmsgs for me? Once upon a time freenode silently silenced my privmsgs to some folks, and I've never trusted it since. |
| 05:19:13 | zooko: | jgarzik: from me, that is. |
| 05:20:20 | jgarzik: | zooko, I just responded to your PM. Lots going on right now and I'm kinda burned out on FUD (not yours, others). |
| 05:21:01 | zooko: | *nod* |
| 07:03:05 | www: | hi |
| 07:03:24 | www: | can you encrypt/decrypt messages using Secp256k1 ? |
| 07:09:45 | www: | i have heard conflicting statements - who knows for sure? |
| 07:14:43 | fluffypony: | www: secp256k1 is *just* an elliptic curve |
| 07:14:47 | fluffypony: | that said, you can use ECIES |
| 07:15:03 | fluffypony: | (Elliptic Curve Integrated Encryption Scheme) |
| 07:16:06 | fluffypony: | here's an implementation: https://bitcointalk.org/index.php?topic=627927.0 |
| 07:16:12 | fluffypony: | here's another one: https://github.com/planetbeing/bitcoin-encrypt |
| 07:16:16 | fluffypony: | both use ECIES |
| 07:18:06 | www: | thanks fluffypony |
| 07:18:14 | www: | 'a little known elliptic curve encryption system using ECDH and a Symmetric Cipher ' |
| 07:42:31 | amiller: | that seems a lot like DHAES https://www.iacr.org/cryptodb/data/paper.php?pubkey=11329 |
| 07:43:31 | amiller: | if you really want to stick within bitcoin crypto |
| 07:43:47 | fluffypony: | it's an improvement on DHAES |
| 07:43:53 | fluffypony: | from 2 or 3 years later |
| 07:44:01 | amiller: | you could chain sha256s together for your symmetric crypto |
| 07:44:18 | fluffypony: | http://www.shoup.net/papers/iso-2_1.pdf |
| 07:45:05 | fluffypony: | "ECIES has been standardized in ANSI X9.63, IEEE 1363a, ISO/IEC 18033-2, and SECG SEC-1" |
| 08:05:15 | hobana.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
| 08:05:15 | hobana.freenode.net: | Users on #bitcoin-wizards: andy-logbot paveljanik priidu Quanttek gill3s NewLiberty Aquentin jtimon jmcn Tiraspol cdecker www ThomasV spinza damethos moa Mably wallet42 badmofo execut3 zooko [7] Dr-G Madars nessence c0rw|zZz adam3us2 melvster jgarzik shaul bosma mkarrer roybadami LeMiner sparetire_ waxwing MoALTz justanotherusr MrTratta gielbier digitalmagus UllrSkis lnovy MRL-Relay theymos stonecoldpat epscy dgenr8 mountaingoat SDCDev pollux-bts p15 rht__ Jaamg PRab |
| 08:05:15 | hobana.freenode.net: | Users on #bitcoin-wizards: Tebbo rustyn PaulCapestany forrestv espes gnusha Cory Luke-Jr tucenaber p15x Emcy goregrind bliljerk101 elastoma ThinThread austinhill jonasschnelli huseby null_radix catcow adams__ Taek rasengan cfields btcdrak bedeho phantomcircuit kanzure sadoshi SwedFTP dc17523be3 TD-Linux GreenIsMyPepper hulkhogan_ richardus sl01 michagogo otoburb isis ttttemp kinlo EasyAt nephyrin` Krellan nsh vonzipper larraboj_ mariorz coryfields_ sneak optimator |
| 08:05:16 | hobana.freenode.net: | Users on #bitcoin-wizards: go1111111 stevenroose BlueMatt eric afdudley0 warptangent ryan-c luny crescendo prosodyContext_ mappum wiz nickler_ jbenet kyuupichan livegnik pigeons davout Fistful_of_Coins @ChanServ AdrianG Graet morcos xabbix Eliel leakypat brand0 harrigan harrow berndj weex thrasher` smooth iddo Apocalyptic yorick platinuum kumavis runeks artifexd CryptoGoon yrashk s1w so ajweiss wizkid057 lclc gwillen K1773R CodeShark bsm117532 sundance jcorgan OneFixt |
| 08:05:16 | hobana.freenode.net: | Users on #bitcoin-wizards: ebfull dasource _whitelogger koshii lmatteis akrmn SubCreative tromp_ face mm_1 maaku Meeh_ qawap jrayhawk azariah_ warren merlincorey midnightmagic HM sturles AlexStraunoff [d__d] dansmith_ jessepollak a5m0_ wumpus petertodd comboy Xzibit17 Muis binaryatrocity_ starsoccer Iriez ggreer roasbeef heath grubles helo veox Anduck gavinand1esen yoleaux dignork guruvan poggy sparetire throughnothing catlasshrugged [ace] BrainOverfl0w indolering |
| 08:05:16 | hobana.freenode.net: | Users on #bitcoin-wizards: grandmaster mengine Guest68586 nanotube gribble fenn jaromil Alanius_ jouke STRML superobserver andytoshi scoria Logicwax BananaLotus akstunt600 amiller Starduster fluffypony mikolalysenko |
| 08:24:44 | nsh: | .wik Forking lemma |
| 08:24:45 | yoleaux: | "The forking lemma is any of a number of related lemmas in cryptography research." — https://en.wikipedia.org/wiki/Forking_lemma |
| 11:06:35 | c0rw|zZz: | c0rw|zZz is now known as c0rw1n |
| 12:49:58 | waxwing: | Electrum is using ECIES now, plus other things too, i forgot .. maybe subspace? |
| 12:50:05 | waxwing: | disclaimer: i have the memory of a goldfish |
| 12:55:30 | fluffypony: | waxwing: I believe it's all telepathy nowadays |
| 12:58:40 | waxwing: | yeah, it was subspace i was thinking of |
| 13:58:45 | giel_: | giel_ is now known as gielbier |
| 14:05:34 | kanzure: | waxwing: perhaps it was mentioned in http://diyhpl.us/wiki/transcripts/gmaxwell-bitcoin-selection-cryptography/ |
| 14:06:36 | waxwing: | kanzure: i know that story quite intimately 'cos i was the one who alerted gmaxwell to it here on IRC :) |
| 14:06:53 | waxwing: | i just have a feelign that it's been redone on electrum, but properly. i may be imagining that though |
| 14:07:03 | waxwing: | as for subspace, they are using ECIES via pyelliptic |
| 14:17:28 | instagibbs: | falsehoods must be spread in *latex* form *wags finger at jgarzik BIP100 pdf* |
| 14:18:59 | instagibbs: | Checking namecoin github... namecoin hasn't had a merge in half a year AFAICT. Namecore(?) is much more active. |
| 14:20:09 | instagibbs: | (not calling your bip falsehood, just goofing) |
| 14:20:11 | zooko: | I've been chatting with Namecoin devs who told me that they were working on stuff. |
| 14:20:17 | zooko: | But I didn't look at commit logs. |
| 14:20:43 | instagibbs: | dunno, just reporting my 10 second google search :) |
| 14:20:48 | instagibbs: | makes me an expert |
| 14:20:51 | zooko: | :-) |
| 14:20:53 | zooko: | More than me! |
| 14:20:57 | zooko: | Or, we're different kinds of experts. |
| 14:21:59 | zooko: | amiller: it seems to me that Namecoin has never (yet) offered the actual functionality that is its suppose added functionality on top of being a currency. |
| 14:22:21 | zooko: | Because, that functionality requires being accessible+integrated into the web browsers of hundreds of millions of normal users. |
| 14:22:26 | zooko: | And Namecoin has never (yet) done that. |
| 14:24:29 | midnightmagic: | namecoin is not where the current namecoin developers are doing their work and is essentially abandoned. |
| 14:24:57 | instagibbs: | that was my only reasonable interpretation of zooko and my observations :) |
| 14:28:16 | instagibbs: | midnightmagic: any details on where then? I'd like to follow the work |
| 14:30:34 | midnightmagic: | yep. i believe right here is where miners are supposed to get their namecoind from: https://github.com/namecoin/namecore.git |
| 14:33:27 | instagibbs: | thanks. Alright back to work |
| 14:38:23 | zooko: | midnightmagic: thanks! |
| 14:42:22 | nsh: | * nsh squares zooko's bar tab |
| 14:43:03 | zooko: | * zooko looks askance at nsh |
| 14:43:04 | zooko: | huh? |
| 14:43:24 | nsh: | i can't square your circle, but i can pay for you drinks |
| 14:43:28 | zooko: | :-) |
| 14:43:31 | nsh: | it was a silly gesture of friendship :) |
| 14:43:32 | zooko: | Thanks! |
| 14:43:35 | nsh: | np |
| 14:43:54 | nsh: | *triangle even |
| 14:43:57 | zooko: | I was thinking of visiting UK soon, but it looks like I might be headed for S. Korea instead ... |
| 14:44:07 | nsh: | ah |
| 14:44:13 | nsh: | for recreation or ? |
| 14:44:20 | zooko: | Okay, my 5 year old is waiting for me to play Minecraft with him so he can show me a new house he has constructed... |
| 14:44:23 | zooko: | nsh: yes! |
| 14:44:25 | zooko: | ;-) |
| 14:44:27 | zooko: | bye for now! |
| 14:44:28 | nsh: | hope you have fun :) |
| 14:44:38 | nsh: | o/ |
| 14:44:41 | fluffypony: | lol nsh |
| 14:44:44 | fluffypony: | * fluffypony got the squaring joke |
| 14:46:16 | nsh: | * nsh smiles |
| 15:33:33 | c0rw1n: | c0rw1n is now known as c0rw|away |
| 15:51:02 | prosodyContext_: | prosodyContext_ is now known as prosodyContext |
| 16:01:23 | hearn_: | hearn_ is now known as hearn |
| 16:59:29 | afdudley0: | afdudley0 is now known as afdudley |
| 18:38:17 | mrkent: | Any well documented descriptions of what happened with the testnet fork a few weeks back? |
| 18:42:00 | MRL-Relay: | [shen] www perhaps see https://security.stackexchange.com/questions/34567/ecc-in-openpgp |
| 18:42:10 | MRL-Relay: | [shen] oops didn't scroll to bottom |
| 18:42:13 | MRL-Relay: | [shen] :p |
| 20:54:09 | cryptojonathan_d: | cryptojonathan_d is now known as cryptojonathan |
| 22:57:56 | jb55-: | jb55- is now known as jb55 |
| 23:38:14 | dEBRUYNE_: | dEBRUYNE_ is now known as dEBRUYNE |