Skip to content
This repository has been archived by the owner on Aug 14, 2019. It is now read-only.

+ob overhaul #1110

Merged
merged 13 commits into from
Mar 20, 2019
Merged

+ob overhaul #1110

merged 13 commits into from
Mar 20, 2019

Conversation

jtobin
Copy link
Contributor

@jtobin jtobin commented Mar 18, 2019

(Resolves #1105)

+ob, a core that implemented a permutation cipher for planet-sized atoms, contained a critical bug that allowed multiple inputs to encipher to the same output. This created collisions between some planet-sized @p values.

The rewritten version corrects the bug, and also rewrites +ob to more clearly match both 1) the paper that the algorithm comes from, and 2) the parallel implementation in urbit-ob that has gone through a full-scale exhaustive test.

The rewritten version is also itself easier to test; this PR adds a small-scale exhaustive test, as well as small battery of sanity checks on +ob internals (including on @p values previously known to collide).

NOTE: One thing I'm observing here is that dojo may be lagging behind on changes to hoon.hoon. For example, the following in tests/sys/hoon/auras.hoon passes:

    %+  expect-eq
      !>  ~dilwes-fadnel
      !>  `@p`23.554.048
    ::
    %+  expect-eq
      !>  ~fipfes-dilwes
      !>  `@p`529.511.092

but in dojo, I still get collisions:

> `@p`23.554.048
~dilwes-fadnel
> `@p`529.511.092
~dilwes-fadnel

Should I trust the test suite here? I'd like to figure out what's going on, regardless.

'ob', a core that implemented a permutation cipher for planet-sized
atoms, contained a critical bug that allowed multiple inputs to encipher
to the same output.  This created collisions between some planet-sized
@p values.

The rewritten version corrects this bug, and also rewrites +ob to more
clearly match both 1) the paper that the algorithm comes from, and 2)
the parallel implementation in urbit-ob that has gone through an
exhaustive test.

This also adjusts two calls to 'ob' elsewhere in hoon.hoon such that
they match the updated core.
This allows us to test the +ob functions exhaustively on smaller input
spaces.
We can test +ob exhaustively over a smaller input space; if it behaves
correctly, that gives us much greater assurance that the implementation
is correct for the full planet space.
Copy link
Member

@Fang- Fang- left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The dojo behavior you're seeing seems like #1078, or maybe still some form of #796? It should Just Work if you build a pill and boot from that, in any case.

sys/hoon.hoon Outdated Show resolved Hide resolved
@jtobin
Copy link
Contributor Author

jtobin commented Mar 18, 2019

@Fang- nice, I'll try whipping up a pill.

Copy link
Contributor

@belisarius222 belisarius222 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could generally use a bit more documentation, as I mentioned in a couple other comments. I'd also like to see a long-form comment at the place where the new permutation was added that describes the bug and the solution.

(The cipher's domain was documented incorrectly.)
Added a few previously-known-to-conflict cases to tests that were
missing them.
@jtobin
Copy link
Contributor Author

jtobin commented Mar 19, 2019

After scratching my head for awhile as to why a pill wouldn't work, I realised I was using the one in zod/.urb, not zod/.urb/put. Derp.

Using the correct one persisted my changes to dojo:

> `@p`145.391.618
~fipfes-hossev
> `@p`1.859.915.444
~hossev-roppec

@joshuareagan
Copy link
Contributor

fwiw @jtobin I made the exact same mistake when I was learning to make modifications to hoon.hoon. It took me way too long to realize what I was doing wrong.

Copy link
Member

@joemfb joemfb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jtobin, I've noted a couple minor style quibbles. Otherwise, this looks great!

sys/hoon.hoon Outdated Show resolved Hide resolved
sys/hoon.hoon Outdated Show resolved Hide resolved
sys/hoon.hoon Outdated Show resolved Hide resolved
I believe =/ is the superior choice and is worth standardising on.
Indent lengthy subexpressions after using =/.
@jtobin jtobin requested a review from joemfb March 19, 2019 20:46
Copy link
Member

@joemfb joemfb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple tweaks to the tweaks, and one more idiom consideration I missed:

sys/hoon.hoon Outdated Show resolved Hide resolved
sys/hoon.hoon Outdated Show resolved Hide resolved
sys/hoon.hoon Outdated Show resolved Hide resolved
Copy link
Member

@joemfb joemfb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@jtobin
Copy link
Contributor Author

jtobin commented Mar 20, 2019

I'll merge this in -- don't want to sidestep @belisarius222, but I reckon the changes meet his approval, so I'll be bold.

@jtobin jtobin merged commit 485e09c into next Mar 20, 2019
@jtobin jtobin deleted the jt-patp-fixes branch March 20, 2019 06:19
Copy link
Contributor

@belisarius222 belisarius222 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, LGTM

@ixv ixv mentioned this pull request Apr 3, 2019
@ixv ixv mentioned this pull request Apr 12, 2019
@Fang- Fang- mentioned this pull request Apr 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants