00:54 |
shinohai |
$uptime |
00:54 |
busybot |
The bot has been up for: 47 days 9 hours 19 minutes and 53 seconds |
01:01 |
jonsykkel |
section 4.3.1 step 9 is wrong imo, as long baffer only contains last hours worth of messages |
01:04 |
asciilifeform |
jonsykkel: last hr searched |
01:04 |
asciilifeform |
wai wrong ? |
01:05 |
jonsykkel |
well if i send a msg every 2h, it will do getdata chain bak to beginning of time on every msg |
01:05 |
asciilifeform |
gotta draw the line somewhere. if a hanging selfchain can make yer noad search GBs of log, it's a ddos vector (avail. to yer pestnet) |
01:05 |
asciilifeform |
ah hm |
01:06 |
asciilifeform |
ideally oughta store 'last hr or N , which is greater' as in 1st spec draft |
| |
↖ |
01:06 |
* |
asciilifeform will amend in 0xfa |
01:07 |
* |
asciilifeform taking suggestions for default val of N. prolly oughta be a knob. |
01:07 |
asciilifeform |
jonsykkel: it won't 'to begining of time' tho, will simply say 'chain break' |
01:09 |
* |
asciilifeform found buncha gaffes in 0xfb, mainly broken links, but also various early sections need massage in light of later material |
01:11 |
jonsykkel |
then it will say "chain break" on every msg where prev was older than 1h or so, cuz no longer in buffer. if follow that recipe autistically anyway |
01:13 |
jonsykkel |
imo need something like: 1. check if fits end of chain stored for peer P, if yes its a valid continuation, done 2. check if fits anywhere else in chain, if yes its a fork, done 3. now can be determined that have break in chain, put in order buffer |
01:13 |
asciilifeform |
for selfchain yes |
01:14 |
asciilifeform |
btw the 'netchain not used' in 3.2.3.1 is obv. a lie, it's to be used for ordering |
01:15 |
asciilifeform |
the chains thing defo needs massage, e.g. 3.2.2.1 not touched since coupla rev. ago |
01:15 |
* |
asciilifeform not even had chance to mend all the inevitable broken links from shoving sections around in idjit 'markdown' |
01:19 |
* |
asciilifeform must bbl |
01:21 |
jonsykkel |
"if a hanging selfchain can make yer noad search GBs of log" << not a problem imo if store corectly as hash table on disk |
01:24 |
jonsykkel |
if idjit inside net making u assrape io by spamming old msgs is unpeer time anyway |
| |
~ 1 hours 33 minutes ~ |
02:57 |
asciilifeform |
jonsykkel: well 'inside net' i.e. l2 |
02:58 |
asciilifeform |
jonsykkel: would have to gag, rather than unpeer, if not in l1 |
02:58 |
asciilifeform |
( l2 .. l_cut technically ) |
02:58 |
jonsykkel |
true |
02:59 |
asciilifeform |
a pestnet e.g. 5 deep (as current rec'd cut) would get expensive even if no one is deliberately pissing in it, if had to search 'all time' log whenever hanging chain |
03:00 |
jonsykkel |
or actually depends if store chains for >=l2 |
03:00 |
asciilifeform |
hence asciilifeform's current notion |
03:00 |
dulapbot |
Logged on 2022-01-19 20:06:17 asciilifeform: ideally oughta store 'last hr or N , which is greater' as in 1st spec draft |
03:00 |
asciilifeform |
jonsykkel: gotta store chains for all speakers seen on pestnet, or chains aint very useful |
03:00 |
asciilifeform |
(the msgs from ~peers~ are already known to be authentic) |
03:02 |
asciilifeform |
chains to begin with were asciilifeform's notion of how to give ~some~ measure of authenticity for l2+ hearsays |
| |
↖ |
03:02 |
jonsykkel |
pestron is supposed to keep track of breaks/fork for nonpeers? |
03:02 |
asciilifeform |
indeed, per all vers of spec to date |
03:02 |
jonsykkel |
was not obv to me anyway |
03:03 |
asciilifeform |
prolly oughta make it more explicit in spec |
03:03 |
asciilifeform |
but yes, the orig. purpose of selfchain is to indicate if >1 station is trying to originate as 1 speaker |
03:04 |
asciilifeform |
(on a given pestnet) |
03:04 |
asciilifeform |
when someone does this, the 'genuine' $speaker's selfchain will skip the impostor's msg, and you have the 'split' |
03:05 |
asciilifeform |
after which, can distinguish the chains of $genuine and $impostor-1, $impostor-2, ... $impostor_n |
03:06 |
asciilifeform |
if $genuine is a peer, you can autoresolve the fork and simply throw out the rest |
| |
↖ |
03:07 |
asciilifeform |
if he aint, you nao have console displaying e.g. asciilifeform-1: ... asciilifeform-2: i eat bugs asciilifeform-1: hey jonsykkel see PM and then hit /RESOLVE asciilifeform after satisfied that the frauds have gone off and the last msg is from genuine speaker |
03:08 |
asciilifeform |
in most cases, the ~first~ station to speak as $speaker on a net oughta be considered the 'rightful' user of $speaker handle |
03:09 |
* |
asciilifeform can think of exceptions, but this aint partic. relevant to spec, folx oughta decide for selves when to resolve fork |
03:09 |
asciilifeform |
jonsykkel: lemme know whether makes sense to you. |
03:09 |
jonsykkel |
ok gotta think first |
03:10 |
asciilifeform |
this was prolly the 1 original idea in pest, come to think of it |
03:10 |
asciilifeform |
errything else is moar or less obv. |
03:15 |
asciilifeform |
see orig. thrd. |
03:15 |
dulapbot |
Logged on 2021-08-11 13:07:23 asciilifeform: now's prolly a good time to share detail from asciilifeform's p2ptron scheme. each message contains, in addition to payload and speaker's handle, two hashes : "selfhash" -- hash of previous message spoken by him; and "nethash" -- hash of previous message seen by him (these can be identical , when two or more msgs sent in quick succession) |
03:16 |
asciilifeform |
^ where introduced this. |
03:18 |
asciilifeform |
the desired condition is that all speakers on a given pestnet must use distinct handles. |
03:18 |
* |
asciilifeform was only able to come up w/ 1 algo, the 1 given above, for enforcing this while still permitting hearsay. |
03:19 |
asciilifeform |
if someone can think of a better one -- plox to write in. |
03:20 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2022-01-19#1075128 << to be concrete, can auto-resolve ~once you get an immediate msg from the peer~ and not otherwise |
03:20 |
dulapbot |
Logged on 2022-01-19 22:06:08 asciilifeform: if $genuine is a peer, you can autoresolve the fork and simply throw out the rest |
03:20 |
jonsykkel |
figured |
03:20 |
jonsykkel |
ill read orig thread |
03:21 |
asciilifeform |
a++ |
03:21 |
asciilifeform |
the algo not substantially changed since that thrd |
03:21 |
* |
asciilifeform can't guarantee that it's the only possib. one, but imho likely |
03:22 |
asciilifeform |
the 1 and only thing the $impostor can't do, is to get $original to selfchain the $impostor's spew as his own |
03:22 |
asciilifeform |
so that's what we detect. i.e. 'split' |
03:23 |
asciilifeform |
otherwise, in cases where $original is not a direct peer of yours, you have no means to distinguish |
03:24 |
jonsykkel |
indeed |
03:24 |
asciilifeform |
factually you could autoresolve forks by simply insisting that the earliest seen contig. chain is the genuine speaker's |
03:25 |
asciilifeform |
in practice this requires 100% uptime. tho w/ 'getdata' can get pretty close to same effect |
03:25 |
asciilifeform |
problem is, 'getdata' aint guaranteed to fully seal a gap in deterministic time |
03:26 |
jonsykkel |
you cant do that if itis an actual fork rather than break in chain tho? |
03:26 |
asciilifeform |
you can do it if all yer chains are contiguous atm to 'beginning of time' |
03:26 |
asciilifeform |
but this aint always guaranteed to be the case |
03:26 |
asciilifeform |
(say you lost yer log somehow) |
03:28 |
jonsykkel |
nonpeer1 chain: a-b-c-d, nonpeer2 chain: a-b-c-q |
03:28 |
jonsykkel |
same chain forked at d/q |
03:28 |
asciilifeform |
where's q though |
03:29 |
jonsykkel |
2 diffrent continuations from presumably 2 diff nonpeers |
03:30 |
jonsykkel |
this is case where someone trying to impersonate someone, i guess simpler case is when forked at genesis point |
03:31 |
jonsykkel |
like a-b-c and q-p-r from same speker (both a and q pointing back to 0), in that case indeed can autoresolve favoring oldest one |
03:32 |
asciilifeform |
it is indeed the case that you couldn't autoresolve until 1 fork or the other is longer |
03:33 |
asciilifeform |
(or could you) |
03:33 |
asciilifeform |
thinking about it, you can autoresolve as soon as a msg is 'skipped' by 1 of the chains |
03:34 |
asciilifeform |
actually you still can't -- the impostor in fact can be the 1st to 'skip' the original's |
03:35 |
* |
asciilifeform digs through notes, in fact thought of this, and hence wai forks are not autoresolved |
03:35 |
jonsykkel |
as far as can tell theres 2 distinct cases http://zzz.st/up/hU65ceAM |
03:35 |
asciilifeform |
remember, impostor is not stuck following the algo in spec for generating the chain hashes, can insert whatever he wants |
03:36 |
asciilifeform |
jonsykkel: what does 0 refer to there ? |
03:36 |
jonsykkel |
nothing, jsut means next message has slefchain=000000 |
03:36 |
asciilifeform |
a |
03:37 |
jonsykkel |
so "a" msg is first ever originated |
03:37 |
asciilifeform |
you still know whether you saw a or q 1st tho |
03:37 |
asciilifeform |
cuz you've a clock |
03:37 |
jonsykkel |
case 1 can occur either cuz evil guy trying to impersonate, or cuz normal guy lost his data and restored old bakup |
03:38 |
jonsykkel |
in case 1 or 2 u mean? |
03:38 |
asciilifeform |
2 |
03:38 |
asciilifeform |
if it's a lost backup, tho, there won't be a d in case1 |
03:38 |
jonsykkel |
yep, there can autoresolve if decide oldest = validest |
03:38 |
jonsykkel |
there will be if sent d msg after backing up |
03:39 |
jonsykkel |
then comp crash and restore to state where c was last msg |
03:39 |
asciilifeform |
if you lost backup, incidentally, oughta mechanically set yer selfchain via getdata to yer handle's most recent (public) msg's hash |
03:39 |
asciilifeform |
(naturally impostor can do similarly) |
03:40 |
jonsykkel |
i guess ye |
03:40 |
asciilifeform |
neither the chain hashes nor the messages in this case are seekrit |
03:41 |
asciilifeform |
so , if dr.evil boots up a fresh station and 'restore(asciilifeform)' (hypothetical command for this), you get scenario 1 |
03:42 |
jonsykkel |
yes |
03:42 |
asciilifeform |
the folx who l1 peers of asciilifeform , don't even need to see the forkolade (and won't rebroadcast it) |
03:42 |
jonsykkel |
fuck p comes before q in alfabet |
03:42 |
asciilifeform |
lol |
03:43 |
asciilifeform |
( btw, the reason why not, is 'prod' ) |
03:45 |
asciilifeform |
i.e. if you get a hearsay where ' asciilifeform : i eat bugs ' but then a prod from asciilifeform where selfchain aint h('i eat bugs') you know the hearsay is on a bogofork |
03:45 |
asciilifeform |
'prod' ftr introduced in 0xfb. |
03:45 |
asciilifeform |
prolly does need a subsection in 4 tho |
03:47 |
jonsykkel |
probably, i think are some (unlikely) exeptions to that. if many pakets dropped |
03:47 |
asciilifeform |
the chains become the operative mechanism , however, when yer getting l2+ hearsays with identical speaker |
03:47 |
asciilifeform |
jonsykkel: indeed. also needs thought |
03:48 |
asciilifeform |
asciilifeform's original supposition btw was that the ~ultimately longest~ chain will represent genuine speaker. |
03:49 |
asciilifeform |
chains aint a pill against 'dr.evil shot the actual asciilifeform and stood up a station to speak as asciilifeform' from pov of asciilifeform's l2 |
03:49 |
asciilifeform |
they're a pill against ~indistinguishability~ of colliding speakers. |
| |
↖ |
03:50 |
jonsykkel |
true |
03:50 |
asciilifeform |
i.e. yer station oughta know ~that~ 2+ pestnet inhabitants are colliding handles. |
03:51 |
asciilifeform |
and to know when only 1 has remained. |
03:51 |
asciilifeform |
then you can hit 'resolve', if satisfied that the bogospeaker has departed. |
03:51 |
jonsykkel |
indeed, gotta add nick-1-2 stuff to my impl. |
03:55 |
asciilifeform |
iirc blatta currently ignores chains |
03:55 |
asciilifeform |
they're part of the spec for a reason tho. and gotta be baked eventually |
03:56 |
asciilifeform |
atm there aint much in the way of anyone having an 'l2' much 'l3', except by happenstance when various peerings didn't work |
03:56 |
asciilifeform |
on a moar populated net tho, you'll want the chain mechanisms to work. |
03:58 |
* |
asciilifeform must bbl |
03:58 |
jonsykkel |
breaks/forks handling is trickyest stuff imo by far, all kinda difrent cases, multiple breaks fusing togheter, breaks turning into forks, forks within breaks etc etc |
| |
↖ ↖ |
| |
~ 9 hours 16 minutes ~ |
13:14 |
billymg |
http://logs.nosuchlabs.com/log/asciilifeform/2022-01-19#1075015 << putting together the patch now |
13:14 |
dulapbot |
Logged on 2022-01-19 17:38:56 asciilifeform: promises to fix shortly, unless billymg gets there 1st |
| |
~ 34 minutes ~ |
13:48 |
thimbronion |
http://logs.nosuchlabs.com/log/asciilifeform/2022-01-19#1075215 << my experience as well |
| |
↖ |
13:48 |
dulapbot |
Logged on 2022-01-19 22:58:08 jonsykkel: breaks/forks handling is trickyest stuff imo by far, all kinda difrent cases, multiple breaks fusing togheter, breaks turning into forks, forks within breaks etc etc |
| |
~ 1 hours 5 minutes ~ |
14:54 |
whaack |
morning |
14:55 |
whaack |
verisimilitude: you gave me some good chuckles reading the log yesterday |
14:57 |
whaack |
i skimmed it so i knew what was coming, and then reading down the lines.... 'ascii i have found a bug i can exploit *goes silent for a while* Ladies and gents, Behold! *nothing happens* Sorry about that, behold! *nothing happens* okay this time *nothing happens* i give up ... nvm got it *spam ensues*' |
15:12 |
billymg |
!. version |
15:12 |
bitbot |
I am bot version 719639. |
15:13 |
billymg |
test: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-19#1074861 |
15:13 |
dulapbot |
Logged on 2022-01-19 17:18:57 dulapbot: Logged on 2022-01-19 17:18:27 verisimilitude: http://logs.bitdash.io/asciilifeform/2022-01-19#1074821 |
15:13 |
bitbot |
Logged on 2022-01-19 22:16:37 verisimilitude: I've the math figured out. |
15:13 |
billymg |
hrm |
15:13 |
billymg |
should've tested locally |
| |
~ 18 minutes ~ |
15:32 |
billymg |
ok that's strange, the same code seems to work locally, perhaps i messed up the config somewhere |
15:32 |
asciilifeform |
billymg: make sure the bots list in the deployed one is up to date |
15:39 |
billymg |
!. version |
15:39 |
bitbot |
I am bot version 719639. |
15:45 |
billymg |
!. version |
15:45 |
bitbot |
I am bot version 719639. |
15:45 |
billymg |
http://logs.nosuchlabs.com/log/asciilifeform/2022-01-19#1074861 |
15:45 |
dulapbot |
Logged on 2022-01-19 17:18:57 dulapbot: Logged on 2022-01-19 17:18:27 verisimilitude: http://logs.bitdash.io/asciilifeform/2022-01-19#1074821 |
15:46 |
billymg |
ok, i indeed messed up my config, but in a pest related knob. i got tripped up when casting a False in the config to a boolean (is True because non-empty string) |
15:47 |
whaack |
billymg: what are your plans for using trbexplorer? i think we discussed this a long while back, but if you are planning on putting an interface on bitdash then i recommend you (temporarily) use a python script to get the data from explorer.ztkfg.com. |
15:51 |
billymg |
whaack: yeah, i'd like to put a fancy frontend on it at some point |
15:53 |
billymg |
if your plan is to genesis the "backend" then i would have to do the work of standing up my own and modifying it to spit out e.g. JSON for easy parsing on the flask side |
15:54 |
whaack |
billymg: i already have the script that takes what explorer.ztkfg.com returns and puts results into a python object |
15:54 |
billymg |
ah, that would be even better then |
15:54 |
whaack |
only reason i haven't published / sent it out is i'm still testing and making sure i don't want to make any changes to the api first |
15:55 |
billymg |
whaack: makes sense |
15:56 |
whaack |
right now i'm wrestling with the idea that i need to keep the block explorer up to the chain tip as fast possible, from a practical use scenario it's going to be quite annoying that trbexplorer is always 2-3 blocks behind the tip |
16:02 |
billymg |
yeah, definitely, that's a solid half hour in block time |
16:02 |
billymg |
no rush on my end, there are still features i'd like to add to the crawler, and some guides i'd like to publish |
16:03 |
billymg |
btw, verisimilitude, you can try to break the bot(s) again if you like |
16:08 |
whaack |
alright cool, i'm also going to make a nice interface myself, but it'll be good to have multiple |
16:13 |
billymg |
yup, the more the merrier |
| |
~ 21 minutes ~ |
16:35 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2022-01-20#1075218 << it's by far the least fleshed out mechanism in asciilifeform's spec so far |
16:35 |
dulapbot |
Logged on 2022-01-20 08:48:49 thimbronion: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-19#1075215 << my experience as well |
16:36 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2022-01-19#1075215 << re the matter of chain breaks -- imho the objective should be 'no long-term chain breaks from station's pov'. |
16:36 |
dulapbot |
Logged on 2022-01-19 22:58:08 jonsykkel: breaks/forks handling is trickyest stuff imo by far, all kinda difrent cases, multiple breaks fusing togheter, breaks turning into forks, forks within breaks etc etc |
16:37 |
asciilifeform |
if you went into a submarine and emerged 3wks later, yer station oughta be able to fully close whatever gaps in both netchain (i.e. broadcast msgs) and indiv. folxs' selfchains |
16:40 |
asciilifeform |
the simplest way to make this happen is that folx specify x MB for how much pestnet log they're willing to store, and then chances are that 1 of yer peers will fill you up when asked. |
16:40 |
asciilifeform |
longbuffer still oughta cap at 1h / N MB of msgs (whichever greater) tho, to cap cost of dedup |
16:45 |
asciilifeform |
( if folx recall, the entire point of timestamp is that you dun have to walk a century of log to dedupe incomings ) |
16:46 |
thimbronion |
whaack, etc: the source for the the ruby bot and indexer I made (that actually worked) is here: http://share.alethepedia.com/lekythion/ |
16:47 |
asciilifeform |
( also recall that ~anyone~ who is able to get hold of a valid packet can send it to you x9000 as a dupe flood ) |
16:48 |
whaack |
thimbronion: ty |
16:49 |
asciilifeform |
( see also -- that's approx. how long you have to dedupe an incoming. no more. ) |
16:49 |
dulapbot |
Logged on 2021-09-23 15:16:44 asciilifeform: 1e9 / 8*551 ~= 226860 packets/s, if all received packets match the 446byte length (ones which do not, you throw out immediately, they do not cost very much except in bw terms) |
16:49 |
dulapbot |
Logged on 2021-09-23 15:21:07 asciilifeform: i expect you'd have at least 8cores on reasonable box, which gives you ~105840 ticks to process a packet, imho entirely doable. |
16:50 |
asciilifeform |
^ in light of which 'x MB' is rather optimistic. |
16:54 |
* |
asciilifeform in fact thinking that for line-rate operation, the receiver prologue in fact oughta look at chain hashes ~before~ searching longbuffer, and deprioritize anyffin that aint pointing to the immediately prior msg |
16:55 |
asciilifeform |
1e5 cycles aint enuff to query even a 128kB buffer, likely |
| |
↖ |
16:57 |
asciilifeform |
need a rejection pass b/w 'stale' and 'dupe', which could consist of e.g. 'packet that doesn't chain to the immed. previous one received is interned and processed on as-cpu avail. basis' |
16:58 |
* |
asciilifeform not sure whether this monologue makes sense to anyone, but hopefully the elaboration in 0xfa will |
16:59 |
asciilifeform |
also this ('SelfChain hashes are computed strictly for Broadcast Text and Direct Text Messages. For all other Message types, the values of these fields are undefined.') may be a catastrophic mistake. |
17:00 |
asciilifeform |
under the current algo, a flood of captured packets turned into a dupe flood which includes e.g. a prod will end up querying the longbuffer errytime and exceed the avail. cycles to maintain linerate rejection. |
| |
↖ |
17:02 |
asciilifeform |
jonsykkel, thimbronion , et al ^ invited to comment |
17:07 |
asciilifeform |
in other gnarl, this is probably the Wrong Thing -- 1st oughta ask the originator, if you can, or Rm set, if you can't |
17:13 |
asciilifeform |
grr, broken highliter, |
17:14 |
asciilifeform |
points to 'If the "offending" message was a Broadcast Text, at least one GetData request is issued to each peer of the station.' |
17:19 |
thimbronion |
whaack: here is a dump of the lisp indexer, which |
17:21 |
thimbronion |
lol, which rendered links using headless chrome and saved the resulting text in a postgres db: http://share.alethepedia.com/lekythion/log-indexer.tar.gz |
| |
~ 20 minutes ~ |
17:41 |
whaack |
thimbronion: nice, i'll probably be able to grok that quicker than the ruby code |
17:42 |
* |
whaack has only done 3 months in the ruby saltmine |
| |
~ 53 minutes ~ |
18:36 |
asciilifeform |
$ticker btc usd |
18:36 |
busybot |
Current BTC price in USD: $42921.54 |
18:36 |
asciilifeform |
!w poll |
18:36 |
watchglass |
Polling 14 nodes... |
18:36 |
watchglass |
71.191.220.241:8333 : (pool-71-191-220-241.washdc.fios.verizon.net) Alive: (0.038s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=719666 (Operator: asciilifeform) |
18:36 |
watchglass |
205.134.172.6:8333 : (172-6.core.ai.net) Alive: (0.081s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=719666 |
18:36 |
watchglass |
205.134.172.4:8333 : (172-4.core.ai.net) Alive: (0.082s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=719666 |
18:36 |
watchglass |
205.134.172.27:8333 : Alive: (0.084s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=719666 (Operator: asciilifeform) |
18:36 |
watchglass |
205.134.172.26:8333 : Alive: (0.141s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=719666 |
18:36 |
watchglass |
54.39.156.171:8333 : (ns562940.ip-54-39-156.net) Alive: (0.112s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=719666 |
18:36 |
watchglass |
208.94.240.42:8333 : Alive: (0.143s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=719666 |
18:36 |
watchglass |
205.134.172.28:8333 : Alive: (0.083s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=719666 (Operator: whaack) |
18:36 |
watchglass |
54.38.94.63:8333 : (ns3140226.ip-54-38-94.eu) Alive: (0.258s) V=88888 (/therealbitcoin.org:0.8.88.88/) Jumpers=0x1 (TRB-Compat.) Blocks=719666 |
18:36 |
watchglass |
82.79.58.192:8333 : (static-82-79-58-192.rdsnet.ro) Alive: (0.277s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=719666 |
18:36 |
watchglass |
94.176.238.102:8333 : (2ppf.s.time4vps.cloud) Alive: (0.308s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=718917 |
18:36 |
watchglass |
103.36.92.112:8333 : (terebe.ns01.net) Alive: (0.642s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=719666 |
18:36 |
watchglass |
75.106.222.93:8333 : Alive: (0.469s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=719666 |
18:37 |
watchglass |
143.202.160.10:8333 : Busy? (No answer in 100 sec.) |
| |
~ 19 minutes ~ |
18:57 |
jonsykkel |
http://logs.nosuchlabs.com/log/asciilifeform/2022-01-20#1075268 << according to new spec longbuffer is indexed by hash, shud be like <10e3 cycles regardless of baffer size? |
18:57 |
dulapbot |
Logged on 2022-01-20 11:55:29 asciilifeform: 1e5 cycles aint enuff to query even a 128kB buffer, likely |
18:57 |
asciilifeform |
jonsykkel: recall that the interval also includes verifying sig against erry k(s) in wot |
18:58 |
jonsykkel |
sure, talking about just querying the buffer step |
18:58 |
asciilifeform |
indeed oughta be queryable in o(n log n) or around |
| |
↖ |
18:58 |
asciilifeform |
absolutely must rule out disk assess tho |
18:58 |
asciilifeform |
if an arbitrary packet can force you to access disk, yer sunk |
| |
↖ ↖ ↖ |
18:59 |
jonsykkel |
inded |
| |
~ 1 hours 30 minutes ~ |
20:29 |
whaack |
asciilifeform: (or anyone else running trb) do you perhaps know what the lag is between when heathen block explorers see new blox and when trb sees new blox (in either direction, perhaps trb is getting them first) |
| |
↖ |
20:31 |
whaack |
restarting trb explorer... |
20:32 |
whaack |
!e help |
20:35 |
whaack |
!e help |
20:35 |
trbexplorer |
whaack: my valid commands are: src, uptime, version, help, view-address, help, view-height, scan, view-raw-tx, verify-block, view-raw-block, view-tx, reset, view-balance, view-block, view-merkle-root, remove-top-blocks, verify-all-blocks, view-utxos, push |
20:37 |
whaack |
!e help |
20:37 |
trbexplorer |
whaack: my valid commands are: src, uptime, version, help, view-height, view-address, view-utxos, view-balance, view-block, view-raw-block, view-tx, view-raw-tx, push |
20:38 |
whaack |
!e view-height |
20:38 |
trbexplorer |
block_height: 719671 |
| |
~ 43 minutes ~ |
21:22 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2022-01-20#1075307 << asciilifeform not noticed a substantial lag. (and often enuff my noades see'em before certain heathen exploders do) |
21:22 |
dulapbot |
Logged on 2022-01-20 15:29:40 whaack: asciilifeform: (or anyone else running trb) do you perhaps know what the lag is between when heathen block explorers see new blox and when trb sees new blox (in either direction, perhaps trb is getting them first) |
| |
~ 1 hours 58 minutes ~ |
23:20 |
thimbronion |
https://twitter.com/Cernovich/status/1484300535377235970 ghost of pankakke continues to haunt |