On 10 Nov (04:06:55), teor wrote:
>
> > On 10 Nov 2017, at 03:17, Yawning Angel wrote:
> >
> > On Thu, 9 Nov 2017 10:13:45 -0500
> > David Goulet wrote:
> Ok fun! I'll add this. Good catch! And control-spec.txt should be
> updated.
>
> On 10 Nov 2017, at 03:17, Yawning Angel wrote:
>
> On Thu, 9 Nov 2017 10:13:45 -0500
> David Goulet wrote:
Ok fun! I'll add this. Good catch! And control-spec.txt should be
updated.
To be consistent then we could ask for a as
On Thu, 9 Nov 2017 10:13:45 -0500
David Goulet wrote:
> > > Ok fun! I'll add this. Good catch! And control-spec.txt should be
> > > updated.
> > >
> > > To be consistent then we could ask for a as well:
> > >
> > > "ED25519-V3:"
> > >
> > > ... which contains the
On 09 Nov (09:27:15), Yawning Angel wrote:
> On Tue, 7 Nov 2017 12:20:15 -0500
> David Goulet wrote:
> > > This might need a couple more details; as-is ADD_ONION can take
> > > "NEW:BEST" (which should now return a v3 service?) or
> > > "NEW:ED25519-V3" for explicitly asking
> I added your note to Sebastian's ticket about publishing key expiry
> information in descriptors. I like Sebastian's idea but I also agree to
> your opt-in remark - which means that we will likely not get much data
> at all (how many relay operators will opt-in vs. the effort to make that
>
teor:
>> - OfflineMasterKey setting (0/1)
>> - SigningKeyLifetime
>> - Sandbox (0/1)
> Yes, these are directly related to relay security, so if they can be linked
> to the relay, they should be opt-in.
I added your note to Sebastian's ticket about publishing key expiry
information in
On 8 Nov 2017, at 04:20, David Goulet wrote:
>>> 3.1.3. ADD_ONION
>>>
>>> For this command to support version 3, new values are added but the syntax
>>> is unchanged:
>>>
>>> "ADD_ONION" SP KeyType ":" KeyBlob
>>> [SP "Flags=" Flag *("," Flag)]
>>>