32000+ entries in 0.019s
a111: Logged on 2019-05-29 09:06 spyked:
the weird part is
that
the linux
tcp stack ~works~ for
the most part. I imagine
the maintainer of
that particular subsystem must be a neckbeard with 20+y experience in
tcp (because sure, it's not only
the implementation,
the protocol itself is a mountain of complexity)
a111: Logged on 2019-03-15 21:44 mircea_popescu: made slightly mroe interesting by it having been written before rather
than after linus went dumb.
spyked: the weird part is
that
the linux
tcp stack ~works~ for
the most part. I imagine
the maintainer of
that particular subsystem must be a neckbeard with 20+y experience in
tcp (because sure, it's not only
the implementation,
the protocol itself is a mountain of complexity)
☟︎ diana_coman: by now I suspect most code out
there is
the fungus sort as
that's how
things "naturally grow"
a111: Logged on 2019-05-22 21:36 lobbes: As it stands I have
two full pages of hand-written notes with various c and apache-stack likbez, and
that was just so I could understand up
to line 152 of
https://github.com/mbattyani/mod_lisp/blob/master/mod_lisp2.c (only 900 or so lines left
to eat). I most likely will publish
these notes as a blog post once all is said and done
spyked:
http://btcbase.org/log/2019-05-22#1915245 <-- in other c coad, /me spent his last 2-3 weeks looking at
the
tcp stack implementation in linus' kernel. it is
truly a fungus, macguyvered with duct
tape and rubber bands, such
that changing one line almost anywhere breaks shit all over
the place.
☝︎☟︎☟︎ spyked: and I guess I'd prefer starting from code already battle-tested by L1 (in
the form of a
tarball + ksum?) rather
than shithub, and
turning _that_ into a genesis. although I suspect I'll have
to dig deeper into
the heathenpits of git commits anyway.
spyked: in particular, I saw
trinque, phf and ben_vulpes have been using it in
the past, so I'd appreciate any input you have on
the matter
☟︎ spyked: so far I've been looking at
the project changelog and
the
patch history and
the patches seem like a mixed bunch, with (perhaps) some useful
things and breakage a la sslism. so before going further, I'd like
to get some idea of what version of hunchentoot
the lordship and
the L2 are using
mp_en_viaje: " and dbs --
trb ALSO should keep
track and sum
the hash weights.
mp_en_viaje: but
the good news is
that fixing
this is free. simply write
the protocol correclty, and let whoever smartass make "bitcoin cash
the real bitcoin
mp_en_viaje: i recall at least a half dozen of
these "nope, nm, mp was right"
mp_en_viaje: there's a romanian derrogatory negative
that exactly sums
this problem : "din parti" ie, "no fucking way" (literally, "made of parts").
thisis what satoshi made,
the "longest chain" of "highest early block and largest
total block count".
this does not actually sum
to "best chain"
mp_en_viaje: so, in short :
to find lulz in bitcoin one needn't indeed look far.
mp_en_viaje: what should have been written, and from out
the gate, would've been function
to sum all diffs, and declare longer chain == highest hash.
mp_en_viaje: but
this is also orig author braindamage. "longer chain" has NO NOTION of "proposed chain sigm-adiff"
mp_en_viaje: now,
this "wouldn't work" because reasons
to do with handwave.
mp_en_viaje: my chain, being both a) longer and b) having a "better" early block, is
therefore
the "longer chain" in bitcoin sense.
mp_en_viaje: so, real chain weighs 1bn and block #2 weighs 1, i make fake chain with block alt-#2 weigh 2 and
total chain weigh 10mn, in 1mn blocks.
mp_en_viaje: i do not need
to match difficulty block by block, see.
mp_en_viaje: this is currently kept off
the
table by hand.
mp_en_viaje: then i could continue
this way
to block 620k. just as long as i have both a) longest chain and b) a more difficultuous block sometime early on, my chain is
technically, by protocol rules,
the
true chain.
mp_en_viaje: i could (in principle) produce an alternate block #2, very cheaply, but of higher diff
than
the
true block #2.
this
then ~should~ be accepted by syncing node.
a111: Logged on 2018-10-22 22:37 asciilifeform: mircea_popescu: unrelated
to anyffing: i have a
tentative
thing
that eats a
http://btcbase.org/log/2018-10-20#1864354 and gives
trb option of replacing 'checkpoints' with it ( i.e. on boot,
tests all already-stored blox against it, and if any blox in
the
tape are not yet present,
then it requests & accepts
them and only
them, 1 at a
time ). do we want
this for field use ? (if so i can put on conveyor for cleanup)
mp_en_viaje: moreover,
this discussion illustrates a major flaw in current bitcoin protocol -- it does not correctly judge SUMS.
mp_en_viaje: start with 100%, change when
to what feels like.
mp_en_viaje: so
then all
that's needed is a % rule. "99% means, graveyward starts where
the last 1% of
total difficulty starts"
mp_en_viaje: consider
the following line : 1.
the only meaningful measure of
tx mutability is
the hashpower
that went into mining its block ; 2. consequently,
the mutability of
tx 100k blocks ago is ~=
the mutability of
tx 600k blocks ago.
mp_en_viaje: what i'm sayng here is,
that a
trb w/o
the rainbow
tables is shipped defective, like a car without wheels or w/e,
toys without batteries.
mp_en_viaje: for other uses, just not load it in memory. but
trb gotta ship with
them.
mp_en_viaje: it just happens
to need >32gb ram much like it happens
to need >100gb hdd
mp_en_viaje: asciilifeform,
thinkign about it,
there's just no way
to have a proper
trb without
the rainbows. and yes it'd be 32 gb, but so what.
the point stands,
there is a minimal bitcoin box.
☟︎ mp_en_viaje: im sure his vultr comes with 192gb ram and a
takedown notice if you allocate >@
mp_en_viaje: 32gb is a lotta unrolling in
this context. and yes, not
terribru idea, seeing how dataset is >100gb
mp_en_viaje: only if
that properly involves a whole lotta unrolling. which, im not even callin a bad idea
mp_en_viaje: ie, one day per year ellapsed (and yes,
this will stay linear)
mp_en_viaje: if 90% of
time were spent in verification ; and if verification were ~correctly~ MT,
then extant blockchain could be verified in roughly 10days / corecount.
BingoBoingo: Don't forget
the more important part. It
takes
time because verification IS NOT sad
mp_en_viaje: "cogentco doesn't give me ip" "ever wondered why ?" "you mean
there's a government conspiraci ?" "no. i mean
there doesn't need
to be one."
a111: Logged on 2016-07-04 21:47 mircea_popescu: but better keep movin' an' don't stand still - if
the skeeters don't get you
the gators will."
a111: Logged on 2019-05-28 16:22 nocredit: another question: if i run core without using segwit features (so sticking with
the 1 starting addresses) am i actually protected from an eventual attack on segwit? I know
that here is not core support, but
there is a way
to
tell core
to dump
the segwit part?
mp_en_viaje:
http://btcbase.org/log/2019-05-28#1915806 << yes, if you use bitcoin addresses you're protected from scammers
trying
to get people
to use non-bitcoin addresses ; no,
the scam unwinds on its own
time not on yours (or anyone else's)
time. you similarly can't
tell MMM
to "stop pyramid scheming" in 1995.
☝︎ mp_en_viaje: by and large, a
time penalty for being late equal
to
the square of
the years passed seems
the lowest possible bottom limit. so, if you start
today and sync in less
than a century, you're getting off
too easy.
mp_en_viaje: "how long will it
take me
to read all
the books ? IT SEEMS UNREASONABLY LONG!!!"
a111: Logged on 2019-05-28 16:11 nocredit: first of all i'd like
to ask what is a sane
time for sync from zero
to 100%
diana_coman now realises
this should have been on #eulora
diana_coman: why would it do it like
that for each and every
thing?
diana_coman: lolz, given earlier
thing, possibly not :P
diana_coman: it still seems over
the
top; it's enough if client has a known list of preferences and asks for
them in
that order, after all; if it doesn't get
that, it goes for next and so on
mp_en_viaje: this design permits fallback ("i want
to see dynas but if absent gimme joes" sorta setting)