405600+ entries in 0.265s
mircea_popescu: suffice it
to say, 4kb
txn SHOULD NOT have any fucking problems.
jurov: alf gotta switch
to "unfreeze me when..."
jurov: how was
the
tx issue resolved? aa956edc2dd94722b5794eaf4e987ebdc8189d2e4c6334c433d7514a28d6b3ab
ascii_field: but
then again
the whole
thing is
trivial.
trinque: is not, computer isn't
trustworthy
trinque: I can
think of many applications on
the net I'd like
to demand only ever say
things according
to grammar G
trinque: parsing packets in/out according
to some grammar
trinque: I see
two separate problems
ascii_field: but no, it does not make any sense
to consider any of
this without si fab
ascii_field: given as
the overwhelming brunt of
the load is on crud rejection
ascii_field: trinque:
the 'adult' version would also emit packets. but
this is far less essential
to 'hardwareize'
assbot: All of
the Nopes: "There is no such
thing as
the crime of 'rape'" and
that's arguably not
the worst part : againstmensrights ... (
http://bit.ly/1JmXd7o )
trinque: ascii_field: just
to wrap up
the
thought,
this network device is simply (and exactly) a packet filter
that accepts packets
through one orifice, checks signatures (presumably has a slot somewhere in its head for pubkeys) and farts
them inward via second orifice or drops on
the floor
ascii_field: these would expand
to actual (colourized) diffs which
the patch in question concerned.
ascii_field: which is
to say, it needs
to produce 1) ascii art, wit
ascii_field: because 'press' assumes
that ~all~ patches are part of longest chain somewhere.
ascii_field: to see what i mean,
try adding a patch
that depends on a rel1
terminus but is not built on by anything else.
punkman: ascii_field: mike_c: i'd prefer
that someone were
to add
the desperately needed
topological walker, rather
than focusing on
the little chipped paint bits, but
that's just me << what would
this walker do?
mike_c: why not make it libraryized? if gpg was libraryized shit like
this wouldn't be so hard
mike_c: of course,
that is partially because of
the hairball
that is gnupg..
ascii_field: aha, i didn't. specifically in
the interest of keeping it short and destroying redundancy
ascii_field: this is not a proggy
to be 'libraryized' and dijkstraized
ben_vulpes: mike_c: and
that's after i burned out like 70% of
them!
mike_c: and it will be very nice
to have a
test suite while doing so. so
thanks ben_vulpes.
mike_c: so many globals :) ok, I'll definitely
take a swing at reorganizing a bit
ascii_field: mike_c:
that's ben_vulpes's version, not mine
mike_c: the
two places being
the argparse and
the switch statement at
the end?
ascii_field: but all
the unix scripting langs are quite alike
ben_vulpes: you're not wrong, i just hate
the straightjacket of argparse's function call behavior.
trinque: so make a lisp data structure and
then derive your argparsing code from... oh wait
ben_vulpes: because
the way
that argparse suggests you set up function calls is stupid as hell!
ascii_field: as in, why
the fuck do i have
to change something in 3 separate places when adding a knob
ascii_field: ben_vulpes: in principle i object
to repetition in a proggy
ben_vulpes: mike_c: asciilifeform objected
to
the "which method, which args" approach
to routing around argparse's braindamage, so if you have good ideas down
there
throw 'em out
ascii_field: my initial 'v' presses rel1 and
the bleeding-edge rel2, yes, but it ought
to be regarded as a proof-of-concept
mike_c: ok. i'm working from your
tarball. I'll see what
the diffs end up looking like
ben_vulpes: mike_c: i posted a
tarball, as i did some messy surgery and expected brutal diffs. if you can get cleaner diffs,
that'd be great.
trinque: I dunno about
the
tactical sense in every soldier creating his own
mike_c: ben_vulpes: you want me
to post a full
tarball or diffs
to mailing list?
ascii_field: 'v' is far
too necessary
to remain a me-thing (much less a python-thing or pc-thing)
mike_c: whelp,
the foundation might as well have an implementation
ascii_field: and
that
there would exist several incarnations, which do not ever disagree on answers
ascii_field: mike_c: i confess
that my intent was
to have folks rewrite it
mike_c: ascii_field: what's
the plan here? you want updates signed/posted on
the mailing list? we going
to use v
to manage changes
to v?
ascii_field: a valid packet is necessarily 1) rsa'd
to
the node's ephem-key 2) signed by originator's ephem-key
trinque: *garbage arranged
to look like a sig
to a dumb parser
jurov: yes
that's what i had in mind. nothing stops anyone from producing arbitrary number of "almost signed" packets
mike_c: hm, v.py is leaking file descriptors all over
the place. muy messy :)
ascii_field: trinque: sig checker ~must~ operate at line speed, and in practice
this means it is integral
to
the die which actually
throws
the packets around.
trinque: but perhaps yes, sig checker without dedicated sig-checking hardware is
too slow?
trinque: was imagining a network device connected in
three directions, outside world, sig checker, and inside world
trinque: I understand
that very well.
ascii_field: the
thing
to understand is
that 'hardware gosspid' nodes would form an impenetrable skin around a p2p sane internet.
trinque doesn't expect fabs on
the battlefield,
trying
to consider what
the simplest useful piece of hardware might be
ascii_field: simply means
that
the enemy needs
to spend
three minutes adjusting his shit cannon
trinque: what if it didn't verify
the sig; it just verified
that it looks like a sig, and hands off
to something
that can
ascii_field: also it will of course depend on
the line. but you can mux/demux
the bits, recall.
ascii_field: mircea_popescu: i can show rigorously
that it can be. but requires custom si.
ascii_field: AND
that
this can
take place at line speed.
ascii_field: jurov: basic principle, at least in my variant of its statement, was
that an unknown endpoint is
to be listened
to STRICTLY for as long as it
takes
to establish
that it can sign with a key
that you wot.
mircea_popescu: ie, you put
the filter node up, yet it can't be accessed because syn flood. irrespective of its function.
mike_c: and if i alter one of
the public keys more
tests fail, so
that's good.
mircea_popescu: when you say ddos people are going
to assume you mean, you know, as it is.
jurov: and
thus can shrug any ddos
mircea_popescu: because cpus are so much better
than pipes
these days, a dirty little secret
the us
telcos have managed
to hide from
their market like
they managed
to hide
the fact
that NOBODY CHARGES FOR INCOMING CALLS!!11,
jurov: and
they examine each packet signature?
mircea_popescu: and
this without any sort of imperial investments, either. also quite deliberately, and at least in part for
the reason of
this discussion.
ben_vulpes: mike_c:
that is
the
test i left off at. feel free
to replace
the "gotcha" assertion with an actual
test, or just eliminate
the assertion completely.
mircea_popescu: jurov consider
the experimentally verified, and publicly at
that, fact
that ddos couldn't do any appreciabvle harm
to qntra, or
trilema.
trinque: provided
the device *works* obviously
trinque: seems I could have whatever shitty computers I like behind such a device, and could be relatively certain
that no command and control messages are making it in
ben_vulpes: and
then on
top of
that, every project i pick up has some arcane setup for running its
tests, because...legacy.
mircea_popescu: jurov it's unsound
to proceed from
that point by makin assumptions.
ascii_field: trinque, jurov: if device which silently drops unsigned (or signed by unblessed) packets straight on
the floor were mass-produced and inexpensive, ddos as a
thing ends.
ben_vulpes: this is a
thing i do once per project and always forget how it's supposed
to go.