27000+ entries in 0.015s
girlattorney: if you have no wot, and you are on your own, and you rely on
the goodwill of
the republican nodes, currently you wait 28 nodes
girlattorney: as already
told: i appreciate
that
TRB exist even if i still not able
to using it. However reading logs when syncing has been a pain and i
thought
that mempool during syncing could create just overhead
girlattorney: could be written on
trb a feature
that enable / disable mempool?
a111: Logged on 2018-10-30 18:16 asciilifeform: more interestingly,
there was even 1 of 10/30/18 17:05:41 ERROR: ProcessBlock() : CheckBlock FAILED from peer 213.148.193.153
girlattorney: asciilifeform
that's nice
to hear, so it has been kept simple for
the sake of security, correct?
girlattorney: asciilifeform i'm aware of
the fast sync part. Just saying
that when i sync a node i actually get data from other prb nodes. I'm not getting garbage or errors, and I
think (not being
technically able unfortunately)
that you could modify prb
to verify all
the blocks, and eventually discard
the excess if I reecived
them in sprayed order
a111: Logged on 2019-07-16 12:52 asciilifeform:
trb, unlike prb, does not accept blocks 'on credit' (i.e. ones for whom
the antecedent block is not yet on
the disk)
BingoBoingo: <girlattorney> but i could argue with
this: when i do bootstrap a core node, it actually get fed from other core nodes << During initial sync
trb wants
to receive blocks in order while core will intentionally spray blocks out of order
girlattorney: so i can effectively say
that i'm receiving blocks from other nodes,
they aren't just connecting and stay silent.
They are sending me blocks.
BingoBoingo: asciilifeform: I notice when I drop
the version number down enough I'll get a wider number of version strings in my peerslist
girlattorney: but i could argue with
this: when i do bootstrap a core node, it actually get fed from other core nodes
BingoBoingo: Playing with
the version string on a
TRB node is
the fastest and simplest way
to change
the sorts of peers your node encounters in
the wild
girlattorney: i was asking about where a
TRB node fetch
the blocks, if all of
the
TRB nodes are only interconnected with
themselves
a111: Logged on 2019-07-16 11:19 mp_en_viaje: girlattorney, your notion of identity is not adequate for
the situation you're dealing with.
girlattorney: asciilifeform i know
that it's centralized. A couple of CA
that runs
the game
BingoBoingo: girlattorney: It's been a while since I looked into it, but I believe if
the version string on a peer is greater
than X,
they insist on SSL'ing
girlattorney: BingoBoingo can you rephrase about
tunneling? Do you mean
they use ssl
to connect?
BingoBoingo: Nevermind
the
things nodes pass
to other nodes are not
the seekrit
things
BingoBoingo: Also recent NSAware nodes insist on encrypted
tunneling
to connect
to other nodes
girlattorney: you still are on a core node, but even if you aren't completely ignoring segwit shit, you aren't
touching it directly
girlattorney: but let's say
the following: you get a core (prb) node, you set a minrelaytxfee very high, so you don't propagate at all, just include what new blocks have because you have
to (to stay up
to date)
BingoBoingo: "To
the network, PseudoNode behaves
the same way as a full node by relaying
transactions, blocks, addresses, etc. However, unlike a normal full node, PseudoNode does not verify data (txs & blocks) itself. Rather, PseudoNode relies on neighboring peers (with configurable confidence levels)
to do
the verification on PseudoNode's behalf. As a result, PseudoNode is very lightweight."
BingoBoingo: At present its
too easy for Bezos customers
to spin up
things
that superficially act almost like nodes.
girlattorney: Also, what's
the problem in
the nodes not being rewarded from being just nodes? If I want
to run a serious business I'll need a node, otherwise i can stick with a
third party wallet such as primedice or deedbot
mp_en_viaje: girlattorney, nobody asked
them anything ; not in 2013, not in 2016, not now and not for
the foreseeavble future.
girlattorney: First of all, do you really expect millionaire businesses such as bitmain or bitfury
to support a fork
that instantly invalidates many millions of already-in-production ASICs?
BingoBoingo: girlattorney: You aren't missing much.
The protocol isn't changing any
time soon for reasons largely explained by handicaps inflicted by Mandarin language's
tendency
to
try insulating against
the future.
mp_en_viaje: in other lulz, anyone recall
the 1918 narkomprod
trying
to "organise
the peasants" into an orange revolution, only
to discover
that, contrary
to marxism-leninism, poor peasants do not actually hate rich peasants ; not
to mention have exactly
the same interests.
girlattorney: From
the article i read "In any case, a word
to
the wise : if you are designing ASIC chips, and you are not including
the possibility of feeding a bitfield like
this in blocks, you are deliberately ensuring failure not just for yourself, but for your customers as well.
This change WILL eventually come in, start planning accordingly,
today. ["
mp_en_viaje: asciilifeform, can has link
to your original lohatronarticle ?
girlattorney: and is
there a consensus about how much it should be raised?
girlattorney: another question
that i
think belong here.
Tried
to read
the logs but haven't found enough clarity. When Bitcoin should scale
the blocksize?
girlattorney: i
think
that
the large number of writes could be a problem in
the long
term
girlattorney: just like
the one
that i posted repeated
till half MB
girlattorney: i'm very near
to setup my blog
to post screenshot and other stuff about
the setup
girlattorney: bdb sits
the index on disk,
that's ok, but i got
the impression
that
to archive 1MB it needs
to write like 1GB
girlattorney: and
the amount of writes
that
TRB does with or without swap is insane
girlattorney: yes, still don't be able
to catch
the latest blocks
girlattorney: and even if i was stuck a dozen of blocks behind
the general block height,
the connection with
the other peers was still present, just producing garbage in debug.log
girlattorney: It's almost like
TRB
telling me: you're
too poor
to spend your
time
trying running me, do something different in your
time
girlattorney: so,
tried with many attempts
to restart
TRB and hoping it could fully sync. No fucking way. And at every shutdown (with ctrl - c) always a painful writing process of at least 50 gb,
taking 30 minutes or so
a111: Logged on 2019-07-17 16:42 asciilifeform: e.g. old man naggum -- evidently moar 'alive' nao
than when alive..
a111: Logged on 2019-07-17 16:38 asciilifeform:
http://btcbase.org/log/2019-07-17#1923088 <<
the circular situation of gnat , where 'need gnat
to build gnat', is
the
third reason for
the mips approach -- arch with 100 fixed-length instructions, simplify
the eventual rewriting of backend so can ditch gcc dep.