Michael Rogers writes:
> On 11/04/17 11:45, George Kadianakis wrote:
>> We basically add the canonical onion address in the inner encrypted
>> layer of the descriptor, and expect the client to verify it. I made this
>> feature optional in case we ever decide it was a bad idea.
>
> Is the version
Tony Arcieri writes:
> I'm trying to gauge interest on the IRTF's CFRG mailing list regarding
> collaborating on a draft for a standard Ed25519 hierarchical derivation /
> key blinding scheme:
>
> https://mailarchive.ietf.org/arch/msg/cfrg/lM1ix9R-0tVzhZorQhQlKvi4wpA
>
> The post makes several me
> From: George Kadianakis
> Date: Wed, Apr 12, 2017 at 7:57 AM
>
> An update:
>
> After lots of discussions in the Amsterdam Tor meeting, the following
> approach was suggested for cleansing keys of their torsion components
> that is more friendly towards hierarchical key-derivation schemes:
>
I will soon release the next version of txtorcon with a ton of cool new
features. This will be called 0.19.0. More details:
http://timaq4ygg2iegci7.onion/releases.html
Going forward, versioning will switch to a "CalVer.org" variant. At one
point, I thought of breaking a few now-regrettable A
Hi meejah. This sounds like a good move since txtorcon makes so many
small incremental releases. I like symantic versioning for stem [1],
but I've only made six releases thus far. Not nineteen. :P
Symantic versioning provides a clear way of indicating what upgrades
are safely backwards compatible
Damian Johnson writes:
> In the above you say "The onion service APIs *will* change" but also
> "At one point, I thought of breaking a few now-regrettable
> APIs. However, I will not do this." - are you changing APIs or not?
> If you are then Calendar Versioning will make it tricker for your
> u
