Show Idle (>14 d.) Chans
← 2019-05-27 | 2019-05-29 → ↓
mp_en_viaje: holy hell, deedbot ran off again!
mp_en_viaje: diana_coman, sorry about last night lol. had to order another truckful of internet.
mp_en_viaje: http://btcbase.org/log/2019-05-27#1915694 << philosophically, the situation where player is happy offline, and unaware of it does not require fixing. take asciilifeform for instance, he's been happily playing eulora offline for years, and hasn't yet noticed!
a111: Logged on 2019-05-27 22:32 diana_coman: you mean if it timeouts on a request then it lets it just lets it be? it makes it even simpler from my pov, not as if it's an issue but essentially I'm not sure how do you then avoid the case where you play happily offline and ...not notice it?
mp_en_viaje: practically, yes it;s undesirable, but the overwhelming consideration is that this undesirableness can not be managed for the client by the server, because the server suffers from a serious knowledge problem wrt it.
mp_en_viaje: therefore will necessarily have to be resolved by the client. in many important fields (such as where the client thinks its located), the server has the important mechanism of denial, to support fast correction. but when it comes to, eg, what icon should represent x item, or how its 3d texture shoudl look etc, there's no shits given. client can display the world any way it does, and the server will not care.
mp_en_viaje: in another statement : there's two classes of data : erste klasse, which is data which the client may reference (such as, move me two to the left), and buluk klasse, which is data the client may never reference (such as, make my armor one iota shinier).
mp_en_viaje: (the fundament of the male world, this division, btw. not permitting any-thing-whatsoever being discussed is what repressing the female mind, worldview and experiential approach is all about)
mp_en_viaje: http://btcbase.org/log/2019-05-27#1915695 << what would this "nothing fits" look like ? for instance, if a client makes himself a modfile, to have all the characters move lasciviously and otherwise sit about nude, or if joe the manga fan makes his shield sport a tentacle pattern, the server should periodically re-enact the one-true-look with medieval officialness ? why ?
a111: Logged on 2019-05-27 22:33 diana_coman: not notice it until all of a sudden nothing fits
mp_en_viaje: in the vhs-unix-that-never-existed ideal in my own mind, i should be able to, upon encountering for the first time a dude i don't like, alt-tab out of the game, edit the cached file representing this dude's armor, write "dickhead" in spray paint all over the breastplate, and without any further interaction on my part see the dickhead appropriately labeled all over the game forevermore.
mp_en_viaje: whether i can be arsed or not to do this is one thing ; but if i am arsed i should encounter no further difficulty.
mp_en_viaje: (the programmatic logic being that as i focus on the game again, the screen will have to be redrawn, which will suck from the cache ; obviously this may not work ~exactly~ like this for a number of reasons -- which is why it's called an ideal. it should work like this.)
mp_en_viaje: (obviously "forevermore" means -- for as long as he's wearing that type of armor, and include all other dudes wearing the same type, yes, i'm not looking for dwim here.)
mp_en_viaje: http://btcbase.org/log/2019-05-27#1915697 << trist da' tru. the fucking problem with solving problems is that as the problem solvers get old the next generation takes over, and they only ever dealt with the solution ; didn't ever deal with the problem. consequently they limply expect the solution, in the sad terms of "oh, do we still have to", without any appreciation for the difficulty of the problem, resulting in fucking amer
a111: Logged on 2019-05-27 22:35 diana_coman: lol, internet a la cluj
mp_en_viaje: ver again.
mp_en_viaje: "grandfather was rich, what means 'don't squander.
a111: Logged on 2019-05-27 22:41 diana_coman: anyway, if it shouldn't even retry the correct way to put it is that it doesn't *care* at all about the result; i.e. it sends the request, it goes to sleep for timeout interval and then when it wakes up it simply makes and sends the next request, without any care in the world re anything
mp_en_viaje: and more generally i believe a lot of software systems would greatly improved through liberal application of just this kind of carelessness. the idiots are careless at the wrong ends -- by all means, DO http://btcbase.org/log/2019-05-13#1912968 ; do NOT "hi this is the glass from last night, how would you rate your drinking experience please fill out this form".
a111: Logged on 2019-05-13 17:09 asciilifeform: meanwhile , in ru heathendom , (translation mine) : 'there is a sign that distinguishes a troo programmer from an impostor. a true programmer , before going to bed, will put on his nightstand two glasses. one with water -- in case in the night he becomes thirsty. and one empty -- in case not.'
mp_en_viaje: http://btcbase.org/log/2019-05-27#1915699 << model for me how this waste of traffic would look ? seems exactly the opposite to me, specifically : 1. case careless -- request is sent ; were resppnse receinved, all the better ; otherwise, whatever. total sent : 1 request ; maybe 1 answer. say symbolically 1.5 "packets"
a111: Logged on 2019-05-27 22:51 diana_coman: while this has the advantage of being very simple indeed, all it does in fact is that it pushes the complexity a bit higher up at the added cost of a lot of waste traffic
mp_en_viaje: 2. case careful -- request is sent (p=1), if received correctly (p=2) then all is well, else new request sent (p=2.5) and if now received correctly all is well but if not yet new request sent (p=3.5) and if not well again you're looking at... well, depends how noisy/lossy the channel is, but it seems to me the careless case saves a good chunk of bw, roughly speaking the square of the noise rate.
mp_en_viaje: http://btcbase.org/log/2019-05-27#1915700 << if your argument is actually "the client should asynchronously ask for all data it uses defaults for AT SOME OTHER TIME than in the middle of heavy gameplay, such that all the complex gfx of everyone's armors, mounts and flying dildoes are downloaded piecemeal and while sitting around, rather than en masse whenever teleporting to a large market town" you have a solid point. but it's
a111: Logged on 2019-05-27 22:54 diana_coman: if that armor of the stars is requested once then it's wanted *anyway* so what's the point in not tracking it where the request is assembled and instead having it tracked through repeated requests; after all this "oh, still not have it" is anyway still a look "is it in the cache now?" just that it's pushed higher up
mp_en_viaje: a case for "retry X magic number of times at Y magic intervals which i the designer knew ahead of time, for everyone and for all time".
mp_en_viaje: the elegant solution for this would be for the client to keep a list, "items the server mentioned, we asked for but never received usable answer therefore using a default", and either go through it whenever convenient (eg, when player goes afk) or else even expose a button for player to do himself).
mp_en_viaje: http://btcbase.org/log/2019-05-27#1915701 << no, let the server stop being fucking stupid and reference things it can't provide.
a111: Logged on 2019-05-27 22:58 diana_coman: basically I don't actually think that "needed 100 times" SHOULD translate into "send 100 requests to the server" ; something is either needed or not; it might be more needed than something else, sure but that's a relative (and changing) ordering of requests at most, not a traffic-generator essentially.
mp_en_viaje: win-win!
diana_coman is reading
diana_coman: mp_en_viaje: I suspect it's again one of those things where there is no disagreement at the core but we are not yet fully in sync re various bits and pieces;
diana_coman: one thing that I see there is that you seem to consider that this "request" is ONLY for art stuff; the way I see it, it's not just for that but a generic mechanism for any sort of thing requested, be it art or contents or position or whatever
diana_coman: hence my "doesn't fit" - in this specific data-that-matters sense, not re eye candy
diana_coman: let me expand a bit on the concrete solution I'm talking about:
diana_coman: client asks for data from EuCache; EuCache replies with either true (data found + whatever values that data has) or false (not found + default values)
diana_coman: this can/is to be done by any bit and part of the client that is looking for some data of any sort, be it art, position, whatever
diana_coman: so up to here I think it's clear that yes, client can therefore play happily forever after totally offline
diana_coman: cache will have some default value for anything (because defaults are by type/role so not a problem to have them upfront) and it provides those or better, simply marking them as what they are but never saying "huh, no such thing"
diana_coman: on top of the above, the client further has this choice: it can decide it wants to ask for some fresh stuff basically, be it file or anything else
diana_coman: and I say "fresh" because it's not even necessarily a case that it doesn't have it but maybe (e.g. for position) it considers it obsolete hence deletes it and wants it new
diana_coman: anytime it wants something fresh, it will place a request with the local Requester (hence, NOT directly with the server, for all it cares the data comes from Fuckgoats really)
diana_coman: the Requester is the one who knows where data comes from, what does one need to do to obtain it, what sort of constraints there are (e.g. don't spam server with 1001 requests per second) and even what has to be obtained in order to be able to make a request at all (e.g. a set of Serpent keys!)
diana_coman: so the Requester accepts all and any requests and keeps them neatly in a queue
diana_coman: whenever it decides it CAN actually send a message to the server to ask for something, it packs together as many of those pending requested stuff as it can in one message (protocol allows a request for several files/obj in same message) and it sends it on its way
diana_coman: now there is the apparently disputed bit: in the simplest implementation, requester can now consider that it's job is done and therefore go to sleep until next time when it might send a message
diana_coman: the idea here being that well, if the caller still wants that stuff and it's not there, they will just request it again anyway so it gets again into the queue and at some point it will make it into a message
diana_coman: and now re waste traffic: at t1 there are requests for obj a, b, c; at t2 Requester wakes up and asks the server "what are a, b, c", drops those as "done" and goes back to sleep; at t3 there is another request for a,b,c so Requester puts them back in its queue; at t4 a,b,c arrive; at t5 Requester wakes up and ...asks the server again "what are a,b,c?" because well, they are there in the queue, right?
diana_coman: my proposal was to have the Requester ask "what are a,b,c" and move those three objects into a "pending" queue; when another request for them arrives, that's fine; when requester wakes up, it checks and prunes any that meanwhile are there so it doesn't ask again for stuff it meanwhile got
diana_coman: for that matter I suppose it can even just have one queue, they are all "pending" and simply prune it every time it wakes up;
diana_coman: might add also, since it's perhaps not obvious: there is no exact "repeat request" as such because anyway, how could that be (counter of messages at the very least is different!) but more importantly, every time Requester asks the server for something, it simply asks about as many pending things as it can, there is no "oh, I asked about those and not yet here so let's ask exactly those again"
diana_coman: and given the two-class system those are effectively priorities: at every ask-opportunity, the Requester will choose first object request and only second file request (those really are the ONLY two types of questions the client may ask the server)
diana_coman: http://btcbase.org/log/2019-05-28#1915729 - fully asynch is the core of it but I don't see the case of x magic number of times; logically speaking x is simply ask until you are answered, there is no set or fixed x times
a111: Logged on 2019-05-28 09:12 mp_en_viaje: http://btcbase.org/log/2019-05-27#1915700 << if your argument is actually "the client should asynchronously ask for all data it uses defaults for AT SOME OTHER TIME than in the middle of heavy gameplay, such that all the complex gfx of everyone's armors, mounts and flying dildoes are downloaded piecemeal and while sitting around, rather than en masse whenever teleporting to a large market town" you have a solid point. but it's
diana_coman: it's true that atm at least it's more independent from game play rather than "when not busy"
diana_coman: or strictly speaking when "not busy as measured by number of erste klasse requests still pending"
diana_coman: and re Y magic intervals, that is not really there either, that's the whole point of data-received notifications, to NOT rely on magic Y interval
diana_coman: the timeout is the only magic value, yes, but that is literally last resort, aka guaranteed after that time, it WILL send another request; it WILL however send one sooner if the previous one is answered, why would it wait longer than it has to
diana_coman: http://btcbase.org/log/2019-05-28#1915708 - even on re-re-read I can't follow this: where does it seem as if I'm saying in the least that server should solve this at all for client? (no, it can't, of course); my approach is to solve this in a single point in client aka Requester rather than have it spread throughout client at every point where some part finds out it wants some data.
a111: Logged on 2019-05-28 08:49 mp_en_viaje: practically, yes it;s undesirable, but the overwhelming consideration is that this undesirableness can not be managed for the client by the server, because the server suffers from a serious knowledge problem wrt it.
diana_coman: !!up nocredit
deedbot: nocredit voiced for 30 minutes.
diana_coman: nocredit says he needs support with trb so let's here
diana_coman: what did you do and where are you stuck nocredit ?
nocredit: hi, thanks for the voice. Basically trb (with aggressive patch) simply is too slow to sync, and i'm using a VULTR vps with 6 cores and 16GB of ram. For too slow i mean that after 1 week is just at block height 300k
nocredit: for instance, with bitcoin core in half a day I have a synced node
diana_coman: nocredit: it's unlikely that it's too slow since plenty of people are running same and sync no problem ; it is true that it's not on vps usually but at any rate, it may be all sorts of other stuff: is it blackholed?
diana_coman: it does take time to sync fully if you start from 0, yes;
nocredit: 80% of the debug.log is about discarded blocks
diana_coman: you can feed it manually blocks if you have them & are in a hurry but otherwise I don't yet fully grasp your problem as such: is it stalled or is it just that you don't expect it to take longer than 1 week or what?
trinque: having serious problems with the DC I'm using for deedbot, sorry folks. I'm going to try to get the migration to pizarro completed this weekend.
trinque: they had an outage earlier today in singapore, and for some reason this resulted in the bot being permastuck
nocredit: first of all i'd like to ask what is a sane time for sync from zero to 100%
asciilifeform: nocredit: approx 3 weeks, if you're syncing from trb nodes via -addnode .
asciilifeform: this is indep. of cpu/ram, so long as box meets minimum spec (2GB)
nocredit: second, my vps provider (vultr) is complaining with me that i put too much wear and tear to their ssd
asciilifeform: nocredit: the reason your log consists 80+% of 'discarded block' is that trb deliberately does NOT hold on to a received block unless it matches the litmus for possibly being the immediately next block in the chain. this is deliberate, and i personally wrote this patch.
nocredit: is there a recommended vps provider to use?
asciilifeform: nocredit: bitcoin on vps is a nonstarter
asciilifeform: esp. if your hoster is 'oh noes, someone is actually ~using~ what he paid for!' type.
diana_coman: asciilifeform: doesn't pizarro offer anything though?
diana_coman: BingoBoingo: ^ ?
asciilifeform: diana_coman: for trb ?! it already has 3 iirc trb nodes
diana_coman: for paying customers who may want to run trb, what?
asciilifeform: diana_coman: colo people can run trb, or for that matter anythign else
diana_coman: or nao you are not interested in such customers or what?
diana_coman: so there, let the man know about it, no?
asciilifeform: entirely interested. colo available any time, this is on the price sheet.
diana_coman: nocredit: to answer your question: the recommended provider to use is Pizarro; it offers colocation that would fit your needs quite well ; you can join them in #pizarro and ask and you can have a look at http://pizarroisp.net/pizarro-hosting-rate-sheet/
asciilifeform: incidentally, there's a vacant rk, and if customer chooses to use the available sata snake and a 1tb ssd, he can trb. BingoBoingo plox to add this to the advertised list.
nocredit: my problem is that i don't have a static ip at my premises, so at home it's a pain with the myip parameter. I was trying with a pico vps to bypass this by set up a private vpn, but as now i'm stuck
asciilifeform: nocredit: vps is woefully inadequate for the job. you need a physical machine.
nocredit: the small vps would only handle the network traffic
nocredit: as it's doing VPN host tasks
asciilifeform: nocredit: if you absolutely cannot afford physical colo, you can use vps as a means of getting static ip. set up ssh tunnel to your home node from the vps.
diana_coman: nocredit: re provider I warmly recommend talking to Pizarro and in particular to BingoBoingo in #pizarro.
nocredit: thanks, yes physical colo is too much, i hope that ssh tunnel is stable enough for 3 weeks of sync
asciilifeform brb:teatime
BingoBoingo: The vacant rk can indeed be rigged with the SATA snake to add a 1tb drive.
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?
BingoBoingo: It takes time, but I can also but a blockchain on a drive.
BingoBoingo: nocredit: Segwit and all the other core weird happens on 3 addresses
BingoBoingo: 1 addresses are pay to public key hash. 3 addresses are pay to weird addresses.
diana_coman: nocredit: since you have nothing to do with segwit, you are immune to attacks on segwit, not as much protected as entirely immune by definition, no?
BingoBoingo: The bigger concern with core is the bloat. Shit like the "payment protocol"
nocredit: correct, I appreciate TRB as it removes the bloat. But 3 weeks to sync is really a pain
BingoBoingo: The Gavin or some other shitgnome early on tried to push a "mandatory" segwitting, but that proposal died quickly and they all now pretend that never happened.
BingoBoingo: nocredit: Once synced it is very tenacious with staying synced. Most of the core sync speedup is they stopped verifying many blocks
diana_coman: nocredit: for that matter if running own trb is too big a pain/expense, I suppose you might be better served by getting in the wot and using deedbot's wallet for that matter.
nocredit: and last: if i tar gz everything synced as far as now on the VPS and dump it at my premise, i'll be able to restart at block height 300k in the future?
BingoBoingo: The TRB 3-6 week sync (CPU and disk bound) is a strictly linear, no exceptions to verification affair
BingoBoingo: <nocredit> and last: if i tar gz everything synced as far as now on the VPS and dump it at my premise, i'll be able to restart at block height 300k in the future? << As long as you cleanly shut down the daemon before dumping
nocredit: because vultr vps has sent me a takedown notice
nocredit: with some spare time to dump the hdd
diana_coman: lolz @ service
nocredit: totally a shit service btw
diana_coman: nocredit: you know that saying that one's too poor to use cheap stuff?
BingoBoingo: But you have to shut the daemon down cleanly for blockindex.dat to be portable
nocredit: but yes, i've learn the lesson. Only bare metal at my home
diana_coman: it seems to me you can't afford to not use pizarro for bitcoin really
diana_coman: or that, yes.
nocredit: ok perfect. Will update here when I complete the sync
diana_coman: !!key nocredit
deedbot: Not registered.
BingoBoingo: nocredit: Maybe register a GPG key. Otherwise hard to tell whoever returns is you
diana_coman: nocredit: register a key with deedbot as otherwise there can't possibly be a "next time/later", it's always first time...
BingoBoingo: !!up nocredit
deedbot: nocredit voiced for 30 minutes.
BingoBoingo: nocredit: How about you make your way to #pizarro
BingoBoingo: nocredit: Other than running a Bitcoin node, what else do you spend your time on?
feedbot: http://qntra.net/2019/05/china-squeezes-us-as-tensions-rise-windows-out-in-the-pla-rare-earth-exports-on-the-chopping-block/ << Qntra -- China Squeezes US As Tensions Rise: Windows Out In The PLA, Rare Earth Exports On The Chopping Block
a111: Logged on 2019-05-28 11:47 diana_coman: mp_en_viaje: I suspect it's again one of those things where there is no disagreement at the core but we are not yet fully in sync re various bits and pieces;
mp_en_viaje: http://btcbase.org/log/2019-05-28#1915741 << imo should not deliver default values every time it delivers a false, lotta traffic wastage. default should be a special object in each class.
a111: Logged on 2019-05-28 11:51 diana_coman: client asks for data from EuCache; EuCache replies with either true (data found + whatever values that data has) or false (not found + default values)
diana_coman: mp_en_viaje: what traffic?
diana_coman: between c and ada ?
mp_en_viaje: it's remarkable, reading through all this, how much like a web browser this client actually is. TTL next ?
diana_coman: for the same money the c code can have the defaults and that is it
diana_coman: not like the cache is on server
diana_coman: ahahhaha
diana_coman has just re-read the cs manual so feels rather ..funny
mp_en_viaje: (fucking obviously they got the ttl wrong, who the fuck heard of ttl as a SERVER-side setting. how is the server to know how often my pictures of jodie foster's injured snatch need refreshing ?!)
mp_en_viaje: http://btcbase.org/log/2019-05-28#1915754 << your proposal does not fix your own proposed problem. suppose things work as you describe, and the requester gets the reques again... it puts it in the queue again yes ?
a111: Logged on 2019-05-28 12:07 diana_coman: my proposal was to have the Requester ask "what are a,b,c" and move those three objects into a "pending" queue; when another request for them arrives, that's fine; when requester wakes up, it checks and prunes any that meanwhile are there so it doesn't ask again for stuff it meanwhile got
diana_coman: uhm, while it still has them pending or what?
mp_en_viaje: diana_coman, if the server asked what's b answers no such thing, use default.jpg every time, you're sending default.jpg every time.
mp_en_viaje: diana_coman, no, after they resolved.
diana_coman: after they resolved is however "refresh", isn't it?
mp_en_viaje: not objectively fresher than they are when there's no queue and t4 comes around.
diana_coman: uhm, wait
diana_coman: so you say there is no difference between caller asking for it 10 times and this resulting guaranteed in 10 messages to the server because requester does not keep track of anything on one hand and on the other hand 10 requests resulting in only 1 message to server because requester does keep track?
diana_coman: freshness is not objective, no; it's subjective and decided by user of cache
diana_coman: the point is not about "how fresh the final data is" but rather simply that: how many messages get generated for x requests
mp_en_viaje: i am not saying "there is no difference". i am saying "you are proposing to produce a mechanism to resolve a problem you imagine exists, such that the solution's parameters are populated by guesswork and the imagined problem is not eliminated"
diana_coman: the default.jpg is not sent by server, no; local cache has defaults because it has to - it needs to use something before there is even any answer from server; hence the defaults part is not about traffic at all
diana_coman: what parameters?
mp_en_viaje: i do not agree with this.
mp_en_viaje: but let's resolve one issue at a time, because this is not working.
mp_en_viaje: so, as to the matter of client cache. situation 1, no-cache : client wants some item, asks for it, potentially asks again before server has had chance to answer.
mp_en_viaje: situation 2, cache (called "requester") : client will abstain from asking for some item for a certain time after having asked.
diana_coman: uhm, "no cache" is ...impossible; by definition the data on client IS CACHE
diana_coman: only if it throws it away without even using it, can there be "no cache"
mp_en_viaje: o brother.
diana_coman: well yes, because requester is not cache, ugh.
mp_en_viaje: i guess we go back to the text, hang on.
a111: Logged on 2019-05-28 12:06 diana_coman: and now re waste traffic: at t1 there are requests for obj a, b, c; at t2 Requester wakes up and asks the server "what are a, b, c", drops those as "done" and goes back to sleep; at t3 there is another request for a,b,c so Requester puts them back in its queue; at t4 a,b,c arrive; at t5 Requester wakes up and ...asks the server again "what are a,b,c?" because well, they are there in the queue, right?
a111: Logged on 2019-05-28 12:07 diana_coman: my proposal was to have the Requester ask "what are a,b,c" and move those three objects into a "pending" queue; when another request for them arrives, that's fine; when requester wakes up, it checks and prunes any that meanwhile are there so it doesn't ask again for stuff it meanwhile got
diana_coman: move those three IDs* I should have said; not the objects themselves
mp_en_viaje: your proposal does not resolve the t4-t5 problem. having a pending queue does not mean that the client may not decide to ask again JUST as the "requester" took them out of the pending queue.
diana_coman: yes but requester does not put it back in queue
diana_coman: it accepts the new request, looks that it's pending so ..nothing to do with it
diana_coman: i.e. client comes in the shop and asks 100 times for the same thing while shopkeeper is working on delivering it so what
diana_coman: it's still the same thing
diana_coman: otherwise yes, no point in having the queues in the first place really; a duplicate request can have at most the effect of increasing counter of "requests for this here object a" if one wants then to treat them as priorities basically aka ask first for those items that have been demanded most times
diana_coman: or you mean a potential "race condition" there?
mp_en_viaje: lol this shiternet... im getting like 7 lines in a bundle.
mp_en_viaje: diana_coman, nevermind the "it's pending
mp_en_viaje: AFTER it took it out of the queue. immediately after.
diana_coman: the point is not to forbid to the client repeated request
diana_coman: then I don't get it; because if it is the client's decision to ask immediate refresh then sure, what's the problem? it's their decision and it still is the minimum traffic resulting
mp_en_viaje: dude this piece of shit... it's showing your lines but not sending mine.
mp_en_viaje: i have NEVER seen this shitty internet in my fuckign life jesus
mp_en_viaje: http://p.bvulpes.com/pastes/G85i2/?raw=true << this is how this convo looks on my side
diana_coman: ugh; at least Internet used to be working well in Ro.
mp_en_viaje: not anymore. anyway, looky : take the object icon.jpg. the client may ask for this item icon.jpg at time intervals Ti which, as far as we know, are random. now, if you have a queue, of fixed duration L, you offer the guarantee that "for any Tjs that are closer than L only the first does go through". this, you say, "reduces overal requests".
mp_en_viaje: it ~might~. you can not prove they do, for all you know all Ti come at L+e. how do you know it helps anything ?
mp_en_viaje: diana_coman, makes sense ?
diana_coman: I don't think I get it and I'm not sure whether it's because some things are still not right (for starters there is no fixed duration as it's dynamic basically)
mp_en_viaje: what is this "dynamic" mean ?
diana_coman: or because I don't get it
diana_coman: it depends on what arrives and when + on the contents of the queue itself really since for instance a huge filename will fill a whole msg
mp_en_viaje: this is such a bizarre issue to have.
diana_coman: let's take it from the other end, maybe it's easier
mp_en_viaje: looky : if there's no queue, you can in principle get a new request just as the old request was satisfied.
diana_coman: what is the gain in forcing every request -> a message to server?
mp_en_viaje: if there IS a queue, you can STILL get a new request just as the queued request is satisfied.
mp_en_viaje: this not self-evident ?
diana_coman: no, because it forces the very same problem higher up where there is even less information to decide on when to request
mp_en_viaje: decision seems simple enough : how about now.
diana_coman: it does seem a weird problem to have in the simple sense that honestly it's just easier to do it as you say: no responsibility for traffic, just shoot whatever and as many times as higher level asks for... data, not for traffic, but whatevers.
mp_en_viaje: it's easier, and it's not clear that the complicateder way is in any sense better.
diana_coman: let me get this part straight though: how is this "now" decided? every frame whoever has something unknown asks for it? some parameter every x ms ask for everything unknown?
diana_coman: or what?
diana_coman: honestly, as a player, I'll then have to hack my own client, lolz
mp_en_viaje: client asks what is X, gets a response including data it doesn't have ; asks for the data.
mp_en_viaje: if it gets it, it uses it. if it doesn't get it, it uses the default.
diana_coman: and here we go again
mp_en_viaje: optionally, as per http://btcbase.org/log/2019-05-28#1915732 ; but this doesn't have to be first pass.
a111: Logged on 2019-05-28 09:13 mp_en_viaje: the elegant solution for this would be for the client to keep a list, "items the server mentioned, we asked for but never received usable answer therefore using a default", and either go through it whenever convenient (eg, when player goes afk) or else even expose a button for player to do himself).
diana_coman: is at all clear that there is this separation between the client-part that uses/needs some data on one hand, the one I kept calling "client" or c/cpp and on the other hand the lower layer that is protocol aware and actually "asks what is x"?
diana_coman: or you propose that this shouldn't even be
mp_en_viaje: it's clear, one's in c the other in ada, yes.
diana_coman: oook; so then, do you mean that "asks for data" is to be driven by.... what it receives from server rather than attempted use?
diana_coman: finally at least the whole trouble makes sense
diana_coman: this bit here is the part where we were not in sync
diana_coman: why exactly though would client ask based on what server says rather than based on what it finds itself actually needing to use?
mp_en_viaje: because usage is imperative, and it will use default in any case.
mp_en_viaje: similarily you look up new words when you hear them rather than when you decide to use them.
diana_coman: how is it imperative?? server says this guy wears the helmet of doom; client says meh, can't be arsed to show helmets; how is it imperative?
mp_en_viaje: "now we're printing this guy's helmet. wait, wtf do we put in the press ?!"
diana_coman: the difference being that client (as previously discussed) anyway does not keep everything so asking when it doesn't need it is not solving that problem
diana_coman: (and this thing that "doesn't keep everything" is why I went with the different approach aka ask when needed, not when heard of it)
mp_en_viaje: the client does not keep everything in the sense that it's not required to keep everything, not in the sense that it can be relied on to not keep everything.
mp_en_viaje: function of how much space the user is willing to give the cache, client could indeed keep everything.
diana_coman: "wtf do we put in the press ?! " -> the default.
diana_coman: well yes, but that's the thing, the problem is not solved by asking in advance
mp_en_viaje: hence, imperative. once client decides to print something, IT WILL BE PRINTED. no ifs or buts or lookups.
mp_en_viaje: what advance ?
diana_coman: client asks what is a? server says it's (name this) (position that) (mesh theother) and so on
diana_coman: if client doesn't care about mesh , but it asks for it because it saw it, isn't that in advance?
mp_en_viaje: if it doesn't care, it doesn't ask.
mp_en_viaje: that's what "doesn't care" means, definitionally.
mp_en_viaje: not "does not print" but "does not ask"
diana_coman: from my pov I'm fine to switch perspective and go then with this approach, so basically there are no "client/cpp demands" anything since Ada-part directly handles it on the principle "if I saw it and it's not there, then I'll ask for it"; how is any limit re space or anything of the sort to be defined and handled in this case?
mp_en_viaje: well, if client sets a limit, then oldest-used files get wiped.
diana_coman: so it needs now to keep in addition a timestamp on data access?
mp_en_viaje: doesn't fs keep this ?
mp_en_viaje: i mean, it's in the stat innit ?
diana_coman: fwiw I'll clearly have to hack my own client at the very least for making it text-only since there's no point in asking for all the graphical parts just because server did inform that those objects have this and that graphical part
mp_en_viaje: how would the server not inform ?!
mp_en_viaje: i mean, if client doesn't know wtf it is, how is client to use it ? obviously it informs.
diana_coman: I said "server did inform" not didn't, lol
mp_en_viaje: so if your client doesn't care about them, it doesn't ask for them, what's the problem ?
diana_coman: it asks for the object; the object descriptor includes the properties; on the principle that "what client doesn't yet know, client will investigate further", it should ask for them further,right?
diana_coman: it cares about the object; this doesn't mean it cares about ALL its properties
mp_en_viaje: ok, so those it cares about it asks about and those it doesn't care about it doesn't ask about.
diana_coman: but if it is to ask of anything it doesn't yet have/know, then it should ask for all of them, it can't not care about some of them
mp_en_viaje: "anything it hears mentioned it doesn't know and cares about".
diana_coman: but that care is not "use" from earlier but..what?
mp_en_viaje: client setting.
mp_en_viaje: it's only the user whocan decide "i don't want any sounds" or "no videos" or "no meshes only icons" or anything like this.
diana_coman: (re files and access time I need to look if I can get it, hopefully, via Ada.Directories)
mp_en_viaje: and so i suppose all this can go in config file.
diana_coman: oh joy
mp_en_viaje: this part is not avoidable though, only user can tailor this sorta thing. "how much space to give cache and what sorta thigns to keep there" is emintently the function of config
diana_coman: myeah, "useful" things.
diana_coman: what else does one want in cache really.
mp_en_viaje: if you recall the whole theory with "give alternatives for gfx", server could in principle offer a LIST of meshes. possibly different qualities, and even same quality.
mp_en_viaje: so this goes right into that anyway.
diana_coman: rolling back to the original thing, this is all there is to it: if c/cpp does not actually get to ask for anything then there is no trouble at all, sure.
mp_en_viaje: right.
mp_en_viaje: imo much sounder like that, for myriad reasons.
mp_en_viaje: now what was the other one
diana_coman: iirc it was specifically not a list of meshes but at most a list of overall graphical profiles as it were; i.e. each thing then at any time has only one option
mp_en_viaje: nah! see, "what is armor of the pigs ?" "well, it could be joes_armorofpigs.mesh or moes_armorofpigs.mesh or dyna_armorofpigs.mesh" and client is set to get dyna* so continues "what is dyna_armorofpigs.mesh"
mp_en_viaje: [rough sketch, not exact implementation detail]
diana_coman: ugh, last time the rough sketch sounded as I said above though, lolz
diana_coman: open-ended lists like that are always a mess and doubly so via messages
mp_en_viaje: oh, they're a mesh ?
diana_coman: a mshhh
mp_en_viaje: this design permits fallback ("i want to see dynas but if absent gimme joes" sorta setting)
mp_en_viaje: ie, we can accept incomplete art sets.
mp_en_viaje: aka "trust me, it's really smart (tm)"
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: exactly what i mean.
diana_coman: lolz, given earlier thing, possibly not :P
mp_en_viaje: oh, you're saying server shouldn't advertise what it has ?
diana_coman: why would it do it like that for each and every thing?
diana_coman now realises this should have been on #eulora
mp_en_viaje: kinda, huh.
mp_en_viaje: are we moving over ?
asciilifeform: !#seen copypaste
a111: 2016-02-14 <copypaste> it's an IDE for a new proprietary language. it's crud, sure, but code generation isn't bad by itself
asciilifeform: !!gettrust copypaste
deedbot: L1: 0, L2: -6 by 2 connections.
mp_en_viaje: guy's trying.
asciilifeform: 'can translate Spanish and Tagalog. sorry if you think this is spam'
asciilifeform: if i knew tagalog, i think i'd try an' keep it seekrit, lol
mp_en_viaje: what's that, pinoy lang ?
mp_en_viaje: i think he lived there.
mp_en_viaje: http://btcbase.org/log/2019-05-28#1915778 << honestly, i don't even see this as a legitimate question.
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%
mp_en_viaje: "how long will it take me to read all the books ? IT SEEMS UNREASONABLY LONG!!!"
asciilifeform: at uni of clony circa 1400 prolly was answerable q , with 'reasonable' number as answr
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: shoulda been here in 2009.
mp_en_viaje: holy shit, vps too. dude, go away.
asciilifeform: already went away
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.
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?
asciilifeform: mp_en_viaje: iirc this is 1st recorded such case ( d00d took the sweat to build trb, note that there ain't a '4lusers' binariola package or anyffin of the kind) but then went and planted it on a lolhost
mp_en_viaje: the list of fixations.
mp_en_viaje: there's a list of ("independent") fixations. even if patient finds way out of one (thereby becoming ballas' "single issue independent"), the rest still remain.
mp_en_viaje: so yes compiled, but ~of course~ uses vps (with any luck, "kubinetes '''deployment'''"), and also coca cola and also cisco router and also and also.
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."
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."
asciilifeform: still gotta add, that trb bringup takes weeks not because the set weighs 100TB ( as erryone already knows, it's below 300GB atm ) but cuz the sync mechanism is rather sad
BingoBoingo: Don't forget the more important part. It takes time because verification IS NOT sad
mp_en_viaje: this is true
asciilifeform: BingoBoingo: most of the time aint spent in verify tho
asciilifeform: it's spent waiting for someone to 'please drop a block in my gaping mouth'
mp_en_viaje: moreover verification eminently paralelizable. his "6 cores" make no diff whatsoever.
asciilifeform: this is true even with 'aggressor', the latter merely asks ~newly connected~ peers to give blox
mp_en_viaje: but ~could~.
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.
asciilifeform: mp_en_viaje: db could be not only parallelized but made O(1) , iirc we had lengthy worked example of just how
mp_en_viaje: ie, one day per year ellapsed (and yes, this will stay linear)
asciilifeform: and mp_en_viaje's napkin figure is correct (and pessimistic, could easily ~day on existing irons if rewritten properly )
mp_en_viaje: only if that properly involves a whole lotta unrolling. which, im not even callin a bad idea
asciilifeform: mp_en_viaje: no elaborate massage needed -- simply need 32GB or so hashtable . ( who wants, can dig up old thread with the exact algo, atm asciilifeform's hands somewhat full )
mp_en_viaje: 32gb is a lotta unrolling in this context. and yes, not terribru idea, seeing how dataset is >100gb
asciilifeform: handily fits in a reasonable ram. and 99.9999% of queries will land in it in O(1)
mp_en_viaje: * not exact figures
asciilifeform: ( the remainder, end up asking for a second lookup )
mp_en_viaje: im sure his vultr comes with 192gb ram and a takedown notice if you allocate >@
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: it just happens to need >32gb ram much like it happens to need >100gb hdd
asciilifeform: for uses where absolutely gotta fetch arbitrary tx in O(1) , indeed >=32G
asciilifeform: it's a ~linear trade of time for space tho, conceivably could use same scheme with various sizes of table, at predictable cost
mp_en_viaje: for other uses, just not load it in memory. but trb gotta ship with them.
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.
asciilifeform: can point to ~concrete~ braindamages of orig author that resulted in the sad db. one was the expectation that tx 'down to genesis' are mutable 4evah; the other, the idea that 'utxo set' is what matters to fetch quickly, rather than ~any~ tx
mp_en_viaje: very specifically naive sorta "generality fixation" / premature optimization. but yes.
asciilifeform: granted i cannot say how he ought to have decided on concrete number 'down below which not mutable.' he would've had to 'guts' .
a111: Logged on 2018-12-28 17:03 asciilifeform: with guts.
mp_en_viaje: im not sure an actual number need have been produced.
asciilifeform: well for 2-level db ( 'nursery' where blocks that are thought to be part of the snake's tongue that may still reorg ; 'graveyard' where errything else ) does require a number.
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.
asciilifeform: this is entirely correct afaik
mp_en_viaje: so then all that's needed is a % rule. "99% means, graveyward starts where the last 1% of total difficulty starts"
asciilifeform: mp_en_viaje: this is potentially risky when node is young .
mp_en_viaje: 80% similarly. and so on. just pick one -- by which i mean, expose knob in config, let any user pick his hairdo"
asciilifeform: knob -- yes.
mp_en_viaje: right.
mp_en_viaje: start with 100%, change when to what feels like.
mp_en_viaje: moreover, this discussion illustrates a major flaw in current bitcoin protocol -- it does not correctly judge SUMS.
asciilifeform: mp_en_viaje: i still suspect that safe bringup of a noad where certain blocks are immediately stored in readonly form requires some form of a http://btcbase.org/log/2018-10-22#1865197
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: 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.
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: this is currently kept off the table by hand.
asciilifeform: ( observe that it is rather inexpensive, using current-day iron, to bake a phony chain from genesis to... blk# 200k or so )
mp_en_viaje: asciilifeform, to block 1mn or so.
mp_en_viaje: i do not need to match difficulty block by block, see.
asciilifeform: possibly, i have not experimentally verified
asciilifeform: and indeed no need to match diff
asciilifeform: can artificially keep it floating at whatever value
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.
asciilifeform: any # that'll fit on yer disk, really
asciilifeform: there's no monotonic component in the diff eqn.
mp_en_viaje: my chain, being both a) longer and b) having a "better" early block, is therefore the "longer chain" in bitcoin sense.
asciilifeform: therefore there's an intrinsic wot component in noad bringup
mp_en_viaje: now, this "wouldn't work" because reasons to do with handwave.
mp_en_viaje: asciilifeform, exactly.
mp_en_viaje: but this is also orig author braindamage. "longer chain" has NO NOTION of "proposed chain sigm-adiff"
asciilifeform: hence why asciilifeform wrote a 'cement' mechanism, where you can explicitly feed in a signed list of hashes to newborn noad
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.
asciilifeform: but iirc i never published this ( not that it's hard to make ) , cuz wasn't burning ( and still unsure whether this was the right approach as such )
mp_en_viaje: rather than this sad sum of parts.
asciilifeform: mp_en_viaje: theoretically even nao 'longest chain is the 1 with highest hash' . problem is that this takes arbitrary space to evaluate.
mp_en_viaje: so, in short : to find lulz in bitcoin one needn't indeed look far.
mp_en_viaje: asciilifeform, what do you mean /
asciilifeform: nm, wrong
mp_en_viaje: 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"
asciilifeform: it's funny, erry yr or so asciilifeform goes 'bbbut i distinctly recall, protocol went like x' ...then dig in the sores again and 'mno, instead did the retarded thing'
asciilifeform: from the 1000000-byte block thing, to this
mp_en_viaje: i recall at least a half dozen of these "nope, nm, mp was right"
asciilifeform: there was at least 1 where we both went 'bbbut x'
mp_en_viaje is sad to be right each time
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: by diverging at some point.
mp_en_viaje: since we're discussing "trb should
asciilifeform: nao that i think about it, iirc we indeed had thread where calculated that with 10 or so % of total hash horse , could frag the net ~by orphanage size~ ( us, 0, heathens, a range of x's )
mp_en_viaje: " and dbs -- trb ALSO should keep track and sum the hash weights.
asciilifeform: by constructing a set of successively-longer reorgable chains that take X 'on credit to allcomer' buffers to actually evaluate
mp_en_viaje: myeah.
asciilifeform: to round out this thrd : asciilifeform suspects that some unknown but nonzero % of 'perma-wedged noad' cases, are accounted for by adhoc attempts to carry out this experiment
asciilifeform: ( it'd be easier to say something concrete on this subj if ye olde shitoshi had actually included a reasonable set of debug knobs. but, unsurprisingly, did not, and made it quite difficult to retrofit, also )
asciilifeform: theoretically if you built with 'dumpblock', can debug this scenario by hand.
mp_en_viaje shall bbl
asciilifeform: ( to date -- no reports of a live specimen of constructed wedge chain, afaik )
asciilifeform: laters.
asciilifeform also bbl:meat
feedbot: http://qntra.net/2019/05/balkan-tensions-rise-with-serbian-military-on-alert-after-kosovo-police-persecute-ethnic-serbs/ << Qntra -- Balkan Tensions Rise With Serbian Military On Alert After Kosovo Police Persecute Ethnic Serbs
← 2019-05-27 | 2019-05-29 → ↑
Random(trilema) | Download hourly DB snapshot | Get Source Code