475900+ entries in 0.303s
mircea_popescu: kakobrekla
that's how
the new garrs and nefarios and gigavps and etc run
the same old scam. "it COULD be 11btc each. YOU HAVE NO PROOF IT ISNT"
assbot: GBTC Bitcoin Investment
Trust: Summary, Stock Quote &
Trades for Bitcoin Investment
Trust - OTCMarkets.com ... (
http://bit.ly/1EIyQyu )
mircea_popescu: spent millenia not even knowing
there was a global namespace, perfectly happy.
mircea_popescu: (this is exactly how nature does it - as far as it's concerned
the namespace is
the genotype, as far as you're concerned you just use a nick for
the fenotype)
mircea_popescu: or in other words,
the solution
to zooko's
triangle is
to use
the local-global axe on
the fucking knot. unique and secure names globally ; memorable locally.
assbot: Logged on 14-05-2015 16:14:04; jurov: i hope gossipd spec has a part concerning
this. otherwise it will be inevitably bolted on in some ugly haphazard fashion
mircea_popescu: as
time goes by, i get more and more fascinated by
the concept of "offended"
mircea_popescu: Adlai hey, wouldja like
to advertise your jdif blog on /pol/ ?
mircea_popescu: ;;later
tell mike_c hey mike! can you make
the bitbet banners in 728x90 ?
mircea_popescu: kakobrekla
they're
the wrong size but yeah,
that's
the correct solution
jurov: the engine did not even had
time sync
till 20 minute drift was discovered
davout: yup, wasn't sure of whether *proxies* updated keys as opposed
to
the engine, but i guess
that yes, it's pretty plainly written
ben_vulpes: <jurov> mpex does not honor
that << davout: i can confirm
this
ascii_field: (the other
thing is, he didn't forbid upgrading keys - simply happens
to charge 30 btc for
the service)
ascii_field: this is his greatest error and i'm not afraid
to point at it
☟︎ ascii_field: but i also want
to be able
to upgrade keys
ascii_field: jurov: but what if someone 'unearths' a signature from last year
that no one has seen before ?
jurov: so
the consensus is
the key is dead
jurov: owner signed last merkle hash from a month ago, nothing seen from
that key since
trinque: I could also make changes
to
the
thing
to accomodate; maybe it rolls over all messages looking for particulars, produces some output every X
ascii_field: or rather, communicating authoritatively
the statement
that 'anyone using
this key after
this moment is an impostor'
☟︎ trinque: ascii_field something like deedbot for key expirations (and
the presently nonexistent but direly necessary expire-for-new-signatures-only) is inevitable << could you use a specific message format with
the deedbot- as is?
ascii_field: the whole point of 'expiring' a key is
to prevent its use in
the future
jurov: how would it help
them?
ascii_field: how
to prevent folks from backdating signatures
to when it was alive
ascii_field: jurov: for
the purposes of establishing
the
time of a particular signature
jurov: only
the
tree's date is considered for purposes of dead man's switch, what's
the problem with it?
ascii_field: jurov: signing
today's
tree can be done
tomorrow, no ?
jurov: stuff
that cannot be predicted in advance
jurov: must sign current merkle
tree
ascii_field: as i understand,
the only way
to do
this is
to require a blockchain 'ping' with -every- signature
ascii_field: jurov: when it is dead, how do you prevent folks from signing with it 'backwards in
time' backdated
to before death ?
ascii_field: jurov: referring
to
the 'dead man switch'
thread from earlier
ascii_field: if
there is a 'key is dead'
token
that one is relying on some
third party
to keep secret - it can be captured
☟︎ jurov: and
this can be in blockchain,
too
jurov: there has
to be only one keyserver?
assbot: Logged on 14-05-2015 17:06:45; jurov: kakobrekla: but
that's good idea for our keyserver. sign ping every month, otherwise keyserver publishes
the key as dead
assbot: Logged on 14-05-2015 16:57:52; jurov: how does "initial contract" resolve
the problem of
transfer without previous owner retaining
the key?
ascii_field: but no one is
to be -identified- for purposes of
trust by his claimed name, rather
than key
ascii_field: key can say what it likes
to be called, sure
assbot: Logged on 14-05-2015 16:10:00; jurov: but if you really want
to call me BBB0A99950037551F533850A677ABD62D0AEE7D7 ...
ascii_field: and yes,
the only way
to solve
the expire-for-new-sigs problem is, likely,
to require blockchain
turd emission for every single sig, for such a key
ascii_field: something like deedbot for key expirations (and
the presently nonexistent but direly necessary expire-for-new-signatures-only) is inevitable
davout: hmm, if it doesn't update keys you can start with a non expiring one and add
the expiration date after opening your acct
jurov: i had one
time exemption, had
to change
the key
to non-expiring
jurov: mpex does not honor
that
davout: you can always extend
the expiration date of a key
jurov: whereby with
this "dead" flag you issue non-expiring key and decide what happens and why
jurov: and when you
try
to use
this "expiry date" stuff, your mpex account expires,too
jurov: you usually don't know in advance when a key needs
to expire or get invalidated
jurov: better
than current "expiration date" mechanism
davout: jurov: what would be
the point?
jurov: kakobrekla: but
that's good idea for our keyserver. sign ping every month, otherwise keyserver publishes
the key as dead
☟︎☟︎ davout: well, i guess you're fuxxored unless
there was a sensible plan in place
davout: jurov: well no, owner 1 deedbots "o hey, i'm out, speak
to owner 2 starting July 1st 2015, kthxbye"
kakobrekla: such as failing
to sign 'ping' in
time?
jurov: such as? all copies of previous owner's gpg key
to be provably destroyed?
davout: you can specify
the conditions under which you'd
transfer
the business
to another key
jurov: how does "initial contract" resolve
the problem of
transfer without previous owner retaining
the key?
☟︎ davout: also if
the
transfer procedure is specified in
the initial contract
that shouldn't be a problem
jurov: that needs
the notion
that "all corporations die with
their owner"
to catch on
assbot: Logged on 14-05-2015 16:39:24; jurov: anything! keys cannot be really
transferred
mod6: aight well, have
to check later. bbs.
jurov: yes, no one
takes it seriously
mod6: <+jurov> can't we just use namecoin? << yeah, I
thought maybe
this was addressed in
the logs before...
mats: that price
tag
though
ben_vulpes: global lookup mapping of names
to servers is dumbbbb
jurov: to be sure everyone has
the latest deeds
mod6: <+jurov> but gpg pubkeys are not practical for replacing DNS. what if you want
to
tranfer
the name? <<
then
there would be a deed detailing
the
transfer of
the name
to a new key fingerprint?
jurov: anything! keys cannot be really
transferred
☟︎ jurov: so if, say i start doing coinbr support over gossipd, and i
transfer it, have
to ask everyone
to update
their /etc/hosts?
davout: jurov:
the naming in gossipd is supposed
to be local
jurov: names have
too long history of being bought, sold, stolen or counterfeited
to neglect
them such
ben_vulpes: "namshub" et al have no import, are just mnemonic devices for remembering
the keyids
jurov: but gpg pubkeys are not practical for replacing DNS. what if you want
to
tranfer
the name?
ben_vulpes: there's also
the urbit style naming convention for keys
mod6: In
this case, wouldn't you just be called "Juraj Variny (jurov) <rini17@gmail.com>"
jurov: i hope gossipd spec has a part concerning
this. otherwise it will be inevitably bolted on in some ugly haphazard fashion
☟︎ jurov: but if you really want
to call me BBB0A99950037551F533850A677ABD62D0AEE7D7 ...
☟︎ jurov: but
there will certainly be some stupid naming system over it.
jurov: you know anyone who really does not use
the stupid naming system?